Interviewing developers: the FutureLearn way
Matthew Valentine-House, a Developer at FutureLearn, discusses how we interview developers and shares his own experience of the process.
One of the hardest and most important parts about building a team is hiring; it can be an unsatisfactory, stressful and draining process for both the interviewers and the applicants, which can lead either party to the wrong conclusion.
At FutureLearn we think that more traditional interview processes fall short, especially when hiring into an established team who already integrate well together. I’m sure that these problems are not specific to hiring technical people, but as that’s the area I’m most familiar with, that’s where I’ll focus in this post.
Our interview process contains multiple steps. The first step is a phone conversation with Joel, our CTO. This stage is short, usually no more than half an hour, and is really just an informal chat to provide some background on what we do here at FutureLearn and to find out where you, the applicant, see yourself heading in your next role.
A short coding exercise
Once this phone interview is over, we like applicants to attempt a short coding exercise. This is a simple task that we expect applicants to spend a couple of hours on, but no more. Whether you successfully complete the exercise in this time is almost irrelevant. It is unusual for us to use the solutions of these exercises to make a decision about whether to proceed to the next stage. It is treated more like homework for the next stage rather than a barrier to entry; it gives us a starting point.
This is why we’re very careful about our wording. We never refer to the coding exercise as a test: it’s not about assessing coding ability, it’s about starting a conversation.
We don’t require applicants to have extensive Open Source contributions or swathes of personal projects that they can demo to us. So in most situations the solution to the exercise provides both us and you with a nice foundation to build on; we can then talk about different approaches, theories, ideas and implementations all within a context that is consistent and known from both sides.
The exception to this is for our Front-end Developer roles where we encourage applicants to send us a curated portfolio of their work in addition to their exercise solution. We’re always careful to only use material that you’ve chosen to send us, so that we our decisions aren’t coloured by unrelated information or missing context.
A day with the team
The next step in our process is the inevitable and dreaded face to face interview. Here’s where FutureLearn does things differently to all the other companies I’ve interviewed with before.
We like to bring applicants in for a whole day. As a company we are proud of our culture, our team and our workspace, and we think that the best way to show that to a potential new FutureLearner is to really absorb them into what we do.
You’ll be involved with more than one pairing session, working with our team to add some functionality to the product. You’ll have a chance to talk with our Product Managers, get involved with decision making and if the timing is right, you’ll get to attend one of our ‘FutureLearn talks’. We’ll buy lunch too!
Admittedly, this process is very intense. You’re dropped in at the deep end with a team you’ve not met before and solving problems in a domain you may not be familiar with. I left my interview day feeling elated, but drained.
The day starts at 9:30 with a sit down and a chat with Joel. This is generally before most of the team gets in, so the office can look a little sparse. You’ll get a chance to have a candid chat about how we expect the day to go and a rough timetable of what’s going to happen.
Daily standup is at 10:00. Don’t worry, you’re not expected to remember everyone’s names, or remember what they’re up to. But the standup gives us a nice way of introducing you to the team, and the team to you. It normally lasts about 10 minutes.
After that we segue into a pairing session for the rest of the morning. In mine I worked on adding some email controls for newsletter subscriptions to our learners’ settings page.
Deploying code
Melinda, my pair for the morning, didn’t know in advance what we were going to be working on, so the first step was to pick something from the top of the backlog. It felt great to be actively involved in choosing what we would be working on.
We chose something that would be small enough that we could reasonably complete it in the time we had available and also touched a complete vertical slice of the codebase, from the feature specs up through the models and controllers and into the views and the front-end.
Once we had finished the feature, I was asked if I was comfortable committing and deploying my code. As I had no specific reservations, we started going through the process of deploying my commits into production. This gave me a small shock: I’ve never been asked if I’d like to deploy production code during an interview before! I got to see the process of QA’ing the feature, delivering it first to staging and then to production, and it finally appearing on the live site.
Fixing bugs
If having commits in a new codebase and features on the live site wasn’t quite nerve-racking enough for an interview, my afternoon pairing session was interrupted when a fairly serious bug was discovered on the live site. I was expecting this to be a moment of respite; where, being the interviewee, I could sit back and watch how the team handled a crisis.
What actually happened was that we all worked together to identify, isolate and fix the bug, and I was in the middle, working with the team to find a solution. I felt like part of the team: at no point was I made to feel like the outsider.
It was an exhilarating experience, we deployed a fix to the bug almost straight away. The whole process, from being alerted to the problem to getting a fix deployed and verified took about an hour. After that I carried on with the rest of my interview as normal.
Seeing how the team work
What was different with my interview at FutureLearn compared to other interviews I’ve attended in the past is the level of consideration I feel I was given from everyone I spoke to on the day, both within the development team and from the product team as a whole. I saw how the team interact with each other and how they react under pressure when confronted with a live issue. I also got to see a lot of the process that the team uses on a regular basis, how they use their tools to communicate throughout the day, and how this process changes when serious issues arise.
These are not things I would expect to see in a more traditional interview situation, where the applicant and the interviewer are normally working on isolated problems, designed for the interview instead of stories from the backlog. It’s one thing having a conversation about how you like to use Git, but something much more illuminating to be immersed fully in a team’s workflow for a day.
Doing this also gave the team a chance to see how I integrated with the workflow, how easily I adapted to different processes, how I coped under the pressure of live issues, and how we could work through a problem together, to swiftly converge at a solution.
The benefits of our approach
Even though it was an interview and one of the main outcomes was to decide my suitability for a position, I never felt directly that my skills were being judged. In some interview experiences I have had, it was obvious when the questions were written to gauge a specific requirement in a job spec. This can lead to some calculating behaviour. If you know what the question is trying to measure then it’s natural to try and answer with what the interviewer wants to hear. This can make the process unintentionally dishonest and lead to disappointment from either side once a decision has been made.
In conclusion, we do some familiar things at FutureLearn and some things that we think are different from how most tech hiring works. We know that we still haven’t got it completely right yet; for instance, we require candidates to spend a whole day at our office and we’re aware that that can be difficult to arrange. We make an effort to reflect on the process after most interviews so that we continue to refine our approach, to make it more pleasant and rewarding for everyone involved.
Now that I’ve had the opportunity to see the whole process from both sides of the desk, I can say with confidence that our approach, whilst not perfect, has been really successful and we have a great team as a result.
Interested in learning more about joining the team? Take a look at our current vacancies and the way we work.
