We're hiring - how do we assess candidates for RSE jobs?

We want to make our candidate selection process as open as possible. Generally we’re not trying to hire people who can solve software problems on the acute timescale and in the pressured situation of a job interview, so maybe it’s best to share some example interview questions and assessment tools with everyone?

This is a representative example, and gives an idea of what to expect, but the process we use for any specific role may differ somewhat.

Before the interview

Once we have approval to advertise a post, the RSE Team agrees a job advert with “Human Resources” and this is listed on the University of Sheffield website and jobs.ac.uk. Once advertised we are bound to select candidates based on the advertised “About the Job” document. We promote these adverts using a variety of means, including the RSE Society Slack channel and Twitter. Applicants are welcome to ask informal questions via rse@sheffield.ac.uk, and can apply using the University of Sheffield website.

Prior to the interview the RSE Team will convene a panel (usually three people) including members with management responsibility and with relevant technical skills. These will review and rank applications primarily against the “essential” and “desirable” person specification criteria in the “About the Job” document, and select candidates for interview on this basis.

Interview

The purpose of the interview is to further assess and validate a candidate’s skills in relation to the job specification criteria. The interviewers have this in mind when asking standard or follow up questions. We often ask candidates to share some code with us before the interview. Sometimes this isn’t possible, particularly if their previous work has been in an environment where software engineering isn’t done in the open. That’s fine. At the start of the interview we might ask candidates to give a short presentation on this code, we’ll ask that the talk covers a few things such as:

• What were the challenges with regard to your development effort?
• Who has used (or is still using) the code?
• What is it used for and what you like and dislike about the code (with regards to good software engineering practice)?

We will then follow up with questions on this. Some of these will be to clarify points the panel don’t understand and others might be more standard such as:

• How does this code ensure that the results are reproducible? How could it be extended/used to do so?
• What programming language did you develop the code in? Why did you make this choice?
• How could this code be sustained long term?

Some of these are a bit challenging and might not have a simple answer that solves the problem. We might then ask some questions about working with others, and how the candidate develops and applies their skills, such as:

• How does your previous experience demonstrate a track record of collaborating with people on software?
• In your view, how does writing code from scratch differ from improving existing code? What are the issues involved in each case?
• What was the last technical skill that you learnt and why?

The last questions could be on planning and relating to others, like:

• What approaches could you use in this role to plan time on projects effectively and manage competing demands?
• How would you advocate for the importance of Research Software Engineering as a role and software as a research output?
• How would you motivate a reluctant academic to use version control?

After the interview

After the interview, the panel will rank interviewees, again this is against the criteria in the person specification and the job description, before recommending that “Human Resources” make offers.

---

Hopefully by sharing this we take some of the stress out of the interview process and encourage people to apply for jobs in the team!

We haven’t perfected this and would welcome feedback on aspects that we could improve.