ResDiary student interview process
Is there a better way to recruit developers than traditional interviews? That’s the question that we’ve been trying to answer at ResDiary over the last few months. We’ve just finished interviewing candidates for internships and graduate positions, and this time we went for a complete change of direction.
Last year we took on two interns for the first time — Callum and Kelvin — and it was a great experience. We got them to work on a project together that they took from start to finish, and their work is now being steadily rolled out to our customers in a beta program.
So what did we learn from our experiences last year? Firstly, it doesn’t matter if your interns have any existing experience in the technologies they’ll be using. Callum and Kelvin quickly picked up anything we sent their way by figuring stuff out for themselves, helping each other, and getting support from the more experienced devs on the team.
Secondly, interviews suck! We met with around 15 students for the two places we were offering last year. We used a traditional approach, where we had two experienced devs interviewing each student. We came out of it feeling that we really didn’t get a good idea of what differentiated each student, and that there had to be a better way to interview for developer roles.
Recently a new product manager, Colin J Riddell, came to ResDiary. Before he started, he gave our CEO and the development team copies of Joy Inc, written by Richard Sheridan. Joy Inc describes the way that Richard created a company, Menlo Innovations, completely focussed on workplace happiness, producing excellent products for their customers, and constant improvement.
I’m not quite sure I’m completely sold on the concept of “Joy” that Sheridan writes about in his book, but I found myself agreeing with a lot of his ideas. Some of the methods he uses are things that we already use at ResDiary, like automated testing. But one of the parts that really struck me was the interesting way their interview process works.
They use a multi-stage interview process that involves inviting groups of candidates in for an initial stage, where everyone is paired up and given tasks to complete. These group sessions seemed like a much better way to get a really good idea about how someone works with others, and whether they’ll fit on the team.
Since I knew we were going to be doing a new round of student recruitment in the next few months, I started talking about the possibility of using concepts from the book with our CTO, Colin, and one of the other developers, Ian. Both of them were really enthusiastic about the idea, so we decided to give it a try.
The goals for the interviews were:
- Getting the whole team involved.
- Trying to get a better feel for each student.
- Having fun (both us and the students).
To achieve those goals, we came up with the following process. When the students arrived, we gave them a short introduction explaining how the session would work, and we split them into pairs.
After the introduction, we got each pair to do a simple, paper-based task that they could complete within 15 minutes. Prior to the interviews, we came up with some ideas for tasks that we thought were achievable in 15 minutes. These included story boarding, code critique, and unit testing, and were designed to give us an idea of how the students worked together, along with whether they could problem solve and think logically.
Once the 15 minutes were up, we moved each pair to a different member of our team where they did another 15 minute task.
Finally, we gave each student a short one-on-one interview with a different team member. The point of these interviews was really just to have a conversation with each student, and to allow them to ask any questions they had in private. I had prepared a cheat sheet of information like salary, start date, etc. so that we were all on board with the basic questions the students might ask.
A few days before we had the first set of students in, we tried a dry run of the interview process. This highlighted a number of issues that we were able to tweak before inflicting it on the candidates.
I’m sure we would have managed to pull things together without doing this, but the process definitely wouldn’t have run as smoothly.
After each session, I rounded up all the team members who had supervised the students, and we discussed each candidate in turn. Because of the way we structured the interviews, it meant that each student had been seen by three team members.
Each of the three indicated “yes”, “no” or “maybe”. If a student got three yes votes, we marked them down as a definite contender. If they got two yes votes, we discussed them a bit more, and decided whether we wanted to put them down as a maybe or a no. If they got fewer than two yes votes, or anyone had put them down as a definite no, we took them out of contention.
This possibly sounds like a pretty harsh process of choosing, but the challenge we had this year was that almost 30 candidates were applying, so we needed to come up with a system that allowed us to make decisions without getting bogged down in endless discussion.
In order to help everyone decide, we came up with the following criteria as a rough guide:
- Would you be happy to work with this person?
- Are they working well with their partner, or are they dominating the conversation / not giving any input?
- Do they actually seem interested in working with us?
- Are they able to make a decent attempt at the tasks.
We finished the interviews on Friday. On Monday, we got together as a team to decide which students we wanted to hire.
Out of the 28 students who came for interviews, we managed to identify 14 people we would be happy to make offers to using the group sessions. Two of the 14 were looking for graduate places, so we were able to remove them from the decision making process.
This meant we had to choose six people out of the 12 remaining. To do this we used a combination of notes we’d taken during the sessions, along with asking if anyone had noticed people who really stood out.
How did it work out?
Overall, I think the whole process worked really well. It was great getting to work with the students, and I felt we learned much more about how they work with others than we otherwise would have.
Before we end, here’s some thoughts from myself and the rest of the ResDiary development team about the process:
- The interviews worked really well, and we definitely feel like we’re on the right track.
- We need to do more work on the tasks — we came up with them pretty quickly, and some could be better.
- Maybe we can come up with a way to relate the tasks. For example, if the first task was story boarding a scenario, maybe the second task could be to think about how to test their design.
- We should stick to four students (i.e. two pairs) per session. We managed the sessions with six students fine, but it was on the verge of being too much for us based on our office space and team size.
- Our one-on-one interviews were a bit too formal. We did two at a time and took the students into our meeting rooms. In future we’ll try pairing each student with a dev and having an informal chat in the office.
- We should switch all the students so they work in different pairs for the second task in case the original pair really can’t work together. This pretty much wasn’t an issue for us, but in one or two cases it may have helped.
- If any students don’t turn up and you have an odd number, just make a team of three instead of trying to pair up the student with a member of your team. We tried both approaches, and that seemed to work better.
Finally, I just want to say thanks to all the students who came to interview with us, and to everyone who helped out. I’m really looking forward to our new developers arriving over the summer, and I’m excited to work with them to help them learn new skills, and produce something amazing!