Recruitment FAQs

REG Recruitment FAQs #

Here you can find answers to the most frequently asked questions about working for the team and the recruitment process.

Questions are grouped by:

Application Stage #

Is the position open to applicants outside of the UK who do not currently have a UK work visa? #

Yes, the positions are open to applicants outside the UK. If you do not currently have the Right to Work in the UK, the Turing is able to sponsor a Skilled Worker visa application (see below for details). If you have general questions about the process, feel free to reach out to the REG recruitment team; however, once your application has started, you should direct any questions about your specific situation to the Resourcing Officer who is handling your application.

Are you accepting remote applicants? #

Members need to be based in the UK. However, you do not need to be in the London office every day nor on a regular weekly schedule, as almost all of our work is done in a hybrid manner. We have team members that live further away in places such as Scotland and the South West of England who come to the office less frequently. The on-paper expectation is that it would not be unreasonable to ask team members to spend four days a month in the office, but in practice we have been able to support a range of hybrid working patterns with fewer days in the office. We prefer to let the work to be done dictate the most effective collaboration style for carrying it out, and thus there may be some reasonable variation across projects in terms of requirements for in-office work. We also hold two in-person team events per year, the Team Away Day (actually two days) in the winter and Hack Week in June.

What would be the starting date? #

We generally prefer that people start within three months of an offer being made. However, if necessary, we can also accommodate shorter or longer periods between the offer and starting; for previous candidates this time has ranged from 1 month to ~6 months. If you have a specific date in mind, please feel free to contact the REG recruitment team.

How many open positions are available? #

We don’t have this information for 2024 yet. We will update this page when we do.

What roles are you currently hiring for? #

The roles within our team are Research Data Scientist (RDS), Research Software Engineer (RSE), and Research Computing Engineer (RCE). You can read more about these roles below or on our website.

The RDS and RSE roles form part of the same job description; the skillset we look for is the same and there is no difference as to the projects you are given when you join. You are given a choice of which job title you prefer when starting. You can also change your job title later if you feel that the other is a more accurate description.

For this recruitment round, we will be hiring at Junior, Standard, and Senior levels. The difference between these are explained in the respective job descriptions. If you think you have enough experience to apply for the higher position, you can do so. You can also apply to the more junior role and mention in your cover letter that you are also considering the more senior position, in case you feel your profile or working experience is between the two. Every application at a given level will also be considered at the other levels if more appropriate.

If my application was unsuccessful in the past, am I allowed to apply again this time? #

If you applied and did not get selected to interview you are welcome to apply again, but we suggest to revise your cover letter and CV and make them more in line with the requirements specified in the job ad.

If you applied and were unsuccessful at the interview stage, you are welcome to reapply if your profile has significantly progressed since the interview (new projects, job roles or other sources of experience). In general, we suggest you wait for at least one year before applying again.

Does the Turing cover relocation and visa costs? #

Yes; the Turing recognises that relocating and applying for a visa have different associated costs and therefore will provide support for both. The Turing will reimburse up to:

  • £4000 for the cost of a visa application (including the NHS immigration surcharge);
  • £2000 for relocation costs (if you are moving from Europe or the UK, as long as the move is over 50 miles); and
  • £4000 for relocation costs (if you are moving from further overseas).

Do you provide reasonable adjustments to the application process for people with disabilities or health conditions ? #

Yes, reasonable adjustments can be requested during the application and interview process for individuals with disabilities or health conditions. These adjustments may include modifications to the interview format, additional time, or other necessary support. If you require any adjustments, please contact adjustments@turing.ac.uk. This email is monitored by the HR team and will be treated confidentially.

For more information about the Institute’s reasonable adjustment policy see the reasonable_adjustments page.

Profile #

Are there particular domains or skill sets that you are interested in for these roles? #

We are really open to any domain, area of expertise, or skill set that is broadly related to research data science or research software engineering.

If you have experience or are interested in High Performance Computing, as part of the open positions, we are actively looking for new members of the team to work on that area as Research Computing Engineers. You can drop an email to the REG recruitment team to learn more about it.

However, we are recruiting for multiple positions, and are interested in a wide range of skills and experience, so please do apply if you are interested and have experience relevant to research software engineering and data science, broadly defined. You can see the range of projects the team works on and backgrounds of current team members on our website.

Some of the team have also been featured in project and institute spotlight interviews and the Turing podcast (including episodes on AI for the Skies, Fantasy Football AI, 3D printed bridges, Reproducible data science, The problems of AI and Living with Machines).

I don’t have a physics / maths / computer science background. Is that okay? #

That is completely fine. Our team includes people with backgrounds in a broad range of subjects, including chemistry and biology, as well as the social sciences.

In practice, we do not often work on projects that align closely with our own academic backgrounds. As long as you are willing to pick up new skills and domains as you go along, your own background will not be a barrier.

I’m a woman / person of colour / LGBTQIA+ / person with disabilities / part of an underrepresented group(s). Will I feel welcome and supported in the team? #

We’d love to have you join our team! Inclusivity and diversity aren’t just things we encourage because we’re beholden to some corporate criteria; we believe they are essential to good research. We’d really encourage you to apply!

Our team has a very motivated group of people that work on things such as:

  • inputting to institute-wide policies (e.g. trans and non-binary inclusion)
  • doing analysis of diversity data, like for our Gender Pay Gap Report
  • making job ads more inclusive (not closing applications early, publishing salary bands, using clear language)
  • being ambassadors for REG and the Turing at events like the Hopper Colloquium and the BCSWomen Lovelace event
  • Attending network groups – a place to find community, organise events, and work on issues specific to that network. They exist for
    • LGBTQIA+
    • Race equality
    • Gender equality
    • Disability and wellbeing
  • and much more!

You can read more about a sample of the Equality, Diversity and Inclusion (EDI) initiatives in REG and the Turing on this page. Also, if you would like to arrange to speak to somebody in REG (in confidence) about this before applying, let us know; we would be happy to arrange that. That person will not subsequently be involved in evaluating your application. Reach out to the REG recruitment team – we’d love to chat!

Should the cover letter address each of the skills and requirements in the person specification section of the job description? #

It is important that the cover letter, in conjunction with the CV, highlights the requirements listed as “check at application” on the Person Specification, and shows a (general) understanding of the role of a research data scientist or software engineer. Also, it is important to highlight:

  • Your past experience working with code and/or data
  • Why you would like to become part of the Research Engineering Group
  • How your skill set would complement the activities of the team.

What does “equivalent professional experience” mean? #

If you do not have a PhD degree but have worked for a few years and believe you have gained the essential skills mentioned in the Person Specification, we encourage you to apply!

Such experience might include exposure to research projects, awareness of the importance of reproducible software and tools, working with or leading a team of people with different skillsets, deciding on how to best achieve an objective from a data science perspective, or presenting advice/results to an audience. We would like to hear about your prior experience in your cover letter. If you prefer, feel free to get in touch with the REG recruitment team (reg-recruitment-inbox@turing.ac.uk) about this point.

Would not having a PhD prevent me from career progression, in terms of becoming a Senior Research Data Scientist/Research Software Engineer at the Turing Institute? #

Absolutely not, our internal career progression is based on internal milestones and contributions to the group and the Turing community - do not worry about this at all.

Role #

What is a research software engineer? #

The RSE role is fundamentally about using skills in data science and/or software engineering to support research projects.

Compared to a traditional academic postdoctoral role, a RSE is typically more likely to:

  • focus on the software aspects of a project, with a particular emphasis on writing good code that is maintainable and reproducible (as opposed to the bare minimum needed to get a scientific result)
  • be involved in a wider range of projects, often moving between different projects on a timescale of months to years
  • be less involved in writing academic papers or grants, as these are less relevant metrics for career progression

For more information, you can read this page on the UKRSE website: What is a Research Software Engineer?. (The UKRSE has since become the Society of Research Software Engineering, but their new website doesn’t have as thorough a description of the role.)

What is a research computing engineer? #

This role presents a new exciting opportunity to join the growing team of research computing experts at the Turing. The team assists the Turing community with designing, building, deploying, and maintaining research infrastructures, as well as providing service delivery and user support for the Institute’s research computing platforms. This is an opportunity for a technically-skilled professional with a good understanding of either cloud or high-performance computing (HPC), experience with both application and infrastructure, and an interest in facilitating and enhancing world-leading data science and AI research. You will build tools and automation to eliminate mundane operations and craft repeatable processes. As part of the team, you will also work with other research software engineers and data scientists on various projects and will participate in all phases of cloud / HPC development, from requirements-capture, definition, and design; to development, deployment, and maintenance; to performance tuning and monitoring. You are also expected to keep up-to-date with the latest cutting-edge developments, and/or make use of the UK’s most advanced computing facilities like Dawn, ARCHER 2, JADE 2, and Baskerville.

What is the difference between a Junior and a Standard role? #

The main difference between the Junior and Standard roles is that the Junior is a training position for becoming (in 1-2 years) a Standard research data scientist or software engineer. We consider candidates for the Standard position if they have a PhD or an equivalent working experience (meaning for instance a few years of work in a data scientist or software engineer position, in close contact with research projects). If you think you have enough experience you can apply to the Standard position and stress this in your cover letter. You can also apply to the Junior position and mention in your cover letter that you are also considering the Standard position, in case you feel your profile or working experience is in between the two. Feel free to get in touch with the REG recruitment team (reg-recruitment-inbox@turing.ac.uk) about this point.

What kind of projects do you work on in REG? #

The projects at the Turing largely fall into three themes, namely Environment and Sustainability; Health; and Defence and National Security. These projects tend to revolve around the application of data science and AI to solve challenges in these areas. Apart from this, there are also projects in foundational research in data science and AI.

You can see a list of projects we are currently working on on our team website.

Are working hours flexible? #

Formally, the Turing’s core working hours are between 10 and 4. Most people would work these hours plus some additional time on either side to make up a 36-hour working week. However, in practice we are extremely flexible around working hours. Much of our work is done asynchronously, and does not require everyone to be online at the same time.

We are especially aware that team members may have responsibilities (e.g. childcare) which can make it difficult to work a typical 9–5 schedule.

What languages and technologies do you work with? #

The primary language we use in REG is Python.

However, depending on the project, we work with different programming languages and different settings, so more than the programming languages you currently know the important aspect for us is the willingness and ability to pick up new languages along the way, based on your previous experience (especially in research and data analysis contexts).

You can see an (unscientifically generated) word cloud of the languages and technologies we use in REG here:

wordcloud

How long do projects last for / how do you choose projects? #

The length of projects can vary significantly; some are as short as three months, and others have stayed on projects for multiple years. However, there is no requirement to stay on a project for its entire lifespan; there are always options to rotate onto other projects.

You will be given the chance to say which projects you are interested in working on, and you will (to the best of our ability) be placed on a project that you are keen on, rather than one that only matches your prior experience.

Given the job profile in the REG team, what other careers do REG members tend to transition to (e.g. academia, industry, or something else)? #

We have only had a few members of the team who have moved on with their career trajectory so far. To read about some of their career paths you can visit our REG alumni page. Some of them moved to a traditional academic position (for instance pursuing a PhD, taking a professorship), and others to industry and government positions. Others have progressed to more senior roles within the team.

Would the candidate be able to bring their own projects with them and/or seek funding while in the role ? #

The team’s role at the Turing is to collaborate with institute researchers to support their research agendas, rather than pursuing our own. It is much more common for team members to be working on other people’s projects than their own. If you would like to prioritise pursuing your own research agenda at the Turing there are other types of positions at the Institute that allow you to do this.

What else do you do as part of REG? #

80% of our time is formally allocated to project work. Apart from this, we also have 10% of our time set aside for personal development as well as 10% for internal team responsibilities (‘service areas’). There is also a yearly budget for professional development, which all team members can draw on.

Things done as part of personal development can include:

The team’s service areas are diverse, and work can include both internal and external activities. This list is not exhaustive, but some examples include:

  • Recruitment (overseeing the entire hiring process, including writing these FAQs!)
  • Equality, diversity, and inclusion (see the EDI page for some info)
  • Research computing support (providing members of the Turing with training and support on using high-performance computing resources)
  • Communications (social media and outreach)
  • Research programming support (running drop-in sessions for people at the Turing)
  • Knowledge sharing (organising our tech talks)

Can you tell me more about what it is like working at The Alan Turing Institute? #

At The Turing, we want to make sure you feel comfortable and supported in how you work. Here’s a bit about what to expect:

  • Hybrid Working: Although the Turing does require employees to come into the office (see above), we do our best to ensure a healthy work environment whether you are in the office or working remotely. Some of the team work primarily remotely, while others come in every day. We’ve set up our working style to be remote-first, ensuring that those not in the office aren’t at a disadvantage, so there’s no pressure or expectation to be in the office more than the minimum four days a month. However, some team members have found that when they work remotely, they miss out on the informal water cooler chats or lunchtime conversations that happen in the office. To help bridge the gap, we try to mitigate this with online randomised coffee chats and co-working sessions.

  • Flexible Hours: Our core hours are 10 am to 4 pm, but you’re free to work whenever works best for you. Whether you’re an early bird or prefer working later, we trust you to manage your time in a way that fits your life and responsibilities. We also understand that everyone has commitments — whether it’s a doctor’s appointment, picking up kids, or running errands — so working flexibly around these activities is completely fine.

  • Work-Life Balance: We value a healthy work-life balance and believe you should be able to switch off outside of work. There is no expectation to respond to emails or messages outside your working hours! While there may be rare occasions when deadlines lead to higher workloads and longer hours, we encourage you to ensure that you balance that, so on average you work the correct number of hours and maintain a balance that works for you.

  • Hot Desks: We use hot desks, meaning you can sit wherever you like when you’re in the office, on a first-come, first-served basis. The Research Engineering Group typically sits near one another on the first floor. If you need a permanent or bespoke workspace (such as standing/adjustable desks or footrests), we can work with the facilities team to make it happen.

  • Meeting Etiquette: We typically like to have our cameras on during Zoom meetings, but it’s absolutely fine to have your camera off if you feel more comfortable. And, while we encourage you to take regular breaks as needed, it’s also ok to eat or snack during meetings — in fact, we host regular lunchtime tech talks or reading groups where the team can lunch and learn simultaneously.

  • Come as You Are: We don’t have a written dress code; the team typically opts for smart-casual, but you can wear whatever makes you feel comfortable. We trust you to keep it professional when needed.

  • Office Snacks and Team Lunches: We love having team lunches together when we’re in. There is also free fruit, biscuits, juice, tea, and coffee to keep you going throughout the day. The kitchen area is great for group coffee breaks, or you can snack at your desk anytime.

  • Location and Socials: Our offices are based in the British Library, right in the heart of London and just 5 minutes from King’s Cross Station. As part of the Knowledge Quarter, there’s always something exciting happening nearby. We also have plenty of social outings organised by and for Turing staff, including five-a-side football, tennis, climbing, Thursday pub club, French club, film club, hikes…the list goes on (although absolutely none of it is compulsory!).

Other benefits of the role #

Some of the benefits of working in REG have already been covered in other questions (for example, flexible working, having strong input into the projects you work on, and time for professional development).

Other benefits include mental health support and private healthcare (the wellbeing page has a more detailed description of the support available at the Turing), as well as a 13% contribution to a defined contribution pension scheme (3% from the employee, 10% from the Turing). More employee benefits are listed on the Turing’s website.

Where can I find out more? #

Members of REG have been featured in various interviews and spotlights, where they discuss their work and team activities. Here are a few examples:

Interview #

Could you describe the interview process? #

As mentioned in the job description, all interviews are held remotely. We are currently looking into the possibility of holding interviews in person; please feel free to ask about this if this is something you would like.

We operate a two-stage interview process. If you are successful at the screening stage, you will be asked to attend the first interview via video call. In this interview, you will be expected to give a ten-minute presentation on code you have written to address a specific research question. This code should ideally illustrate your use of good research software engineering practices; however, imperfect code is totally fine as long as you can discuss what you would improve and why.

More information about this presentation can be found in the next sections.

The second interview is usually held about one week later for successful candidates. This interview focusses on your previous experience and competencies for the role. There will also be a problem-solving discussion with the interview panel, where you may want to use paper and pen to arrive at an understanding of a proposed data analysis challenge.

In both interviews, there will be the opportunity to ask questions about the role and the team.

Can you tell me more about this code presentation? #

In the first interview we expect you to demonstrate your ability to write code for addressing a data science task in a reproducible manner and/or to use good software engineering practices for developing research software. This could be done by presenting a data analysis script or piece of research software written entirely by you, or by presenting a larger piece of research software you have made a significant contribution to. Using existing libraries that implement algorithms you are using is fine (and good practice), but in all cases there must be a significant amount of code you have written yourself, it must be clear what code you have written yourself, and we expect you to talk about and answer questions on:

  1. the code you have written,
  2. the underlying algorithms or methods your code is implementing or using, and
  3. the research domain or question for which you are applying them.

We will not evaluate you on how complicated your algorithm is, but in your understanding of its implementation, awareness of its potential drawbacks, and its overall appropriateness to solve the problem you are trying to address.

You can write new code specifically for the interview if you so choose, but existing examples of work are encouraged, as long as the code was substantially written by you. You should be prepared to answer questions about both the code and the research challenge it addresses or the algorithm it demonstrates. Any source code shared for the interview will be treated in the strictest of confidence.

What sort of code have previous candidates presented? #

We collected several examples of code that have been presented by current team members in their interviews. This list is not exhaustive, and we really want to emphasise that you can present any code that you feel demonstrates your skills and experience. Some are scripts / notebooks which were put together specifically to demonstrate a particular technique for the interview:

  • A Jupyter notebook with a data analysis pipeline to solve an old Kaggle competition
  • A notebook (and module) demonstrating inference and analysis with a hidden Markov model using TensorFlow Probability, applied to synthetic healthcare data
  • An R script to calculate the depth of ocean floor sediment samples (GitHub)
  • Notebooks and scripts to reimplement the TAGME algorithm for annotating text with Wikipedia entities (GitHub)

There are also examples of fully-fledged libraries / applications that were written as part of applicants’ academic work, for example:

  • An R package for statistical analysis and visualisation of biological data (primarily gene expression) (GitHub)
  • A Python library for differentiable programming in high-energy physics (GitHub)
  • A web app (plain TypeScript) for NMR spectrometer code generation (GitHub)
  • A Python library for tensors with internal symmetries (GitHub)

Will I be only explaining the code, or running it and discussing the results? Should it be accompanied by other materials (e.g. a slideshow)? #

You should ideally able to show and run the code, using any means you are comfortable with: for example, Jupyter notebooks, Rmarkdown, an IDE, or the command line. We recognise, though, that it is not always possible to run the code in an interview setting. If this is not feasible, you should bring some previously generated results so that we can have a conversation around inputs and outputs.

The discussion will likely touch on the performance of your code in terms of e.g. speed, accuracy, or range of applicability. However, our main goal is to evaluate your understanding of the code and general software engineering practices, rather than assessing the performance of your particular implementation.

You are welcome to include any other material (such as slides) if you feel it is useful for supporting your presentation or providing context.

What will the problem solving aspect of the second interview involve? Will I be asked about particular data science or machine learning approaches? Will I need to write code or explain the details of an algorithm’s implementation? #

In the second interview we expect you to discuss a question related to the analysis of an example dataset. All information required to answer the question will be given to you in beginning of the interview. No preparation or specific technical knowledge is expected or required. The goal of this exercise is not to test your understanding of any particular algorithm or data science method, but rather to assess your general approach to tackling a data science question.

This exercise will not require you to write any code or explain the details of any algorithm. The exercise isn’t assessed on whether or not you know the “right” answer to a particular data science question, but on the process you go through to understand the question and the data and your reasoning for the approaches you suggest. Taking some time to think through the question is fine, as is asking questions to the interviewers. Consider them as subject matter experts coming to you to answer a question using their data.

Is there anything in particular I should prepare for the problem solving interview? #

Nothing at all. The best thing you could do to be prepared is to eat well, take some long walks far away from the computer and get a good night’s sleep.

Offer #

Is the offered salary negotiable? #

Fairness and transparency are key values for us and our goal is to avoid inequity by ensuring we are paying people the same salary for the same level of contribution to the team. We make initial salary offers at 0/3, 1/3, and 2/3 through the advertised salary range, based on the level and applicability of each candidate’s experience relative to their future peers already working in the team. Our offers are not negotiable.

What is salary progression like in the role? #

Each year, there is a cost of living increase which is applied to all Turing employees. On top of this, we also have annual pay reviews, where we actively review the performance and development of each team member against the expectations of their position within their seniority band, making salary adjustments where these expectations are being exceeded.

We also hold annual internal promotion rounds to allow people to move up to the next level of seniority when they are ready. There is no cap on the number of Junior, Standard, and Senior roles, so promotion opportunities are not limited by availability.

My question is not answered here #

Please contact the REG recruitment team (reg-recruitment-inbox@turing.ac.uk) with any additional questions you may have. We also run monthly drop-in sessions where you can meet some of the current team and ask them questions face to face. These sessions will be hosted by team members who won’t be involved in that month’s interview process, and questions you ask at these sessions will have no influence on how your application is treated. To be informed of the details for these drop-in sessions, please register for the team’s recruitment newsletter. (You can unsubscribe at any time via this link.)