Interviewing is difficult for both sides - the interviewee may have to recall small bits of esoterica while standing in front of a group who all know the answers to their questions, while the interviewer needs to find a way to evaluate a very important decision (whether she wants to work with the candidate or not, potentially for years), in a very short amount of time.
Both sides take time out of their schedules to meet, so everyone wants to be efficient but still get the correct answers.
Word of Warning
We do not pretend to have the answer. This is simply our experience iterating our interview process: what has worked, what has not, and what we’re still testing.
The Phone Screen
We initially set up a 30 minute phone screen with a candidate. This is not particularly technical as we want to understand the candidate’s background and motivations beyond the resume. We talk about what the candidate has done, what she’s interested in, and sell Funding Circle as a great place to work (because it is!). Assuming both sides like what they hear, we send out a coding challenge, and then schedule a half-day on-site interview.
The Coding Challenge
Before the candidate comes in he gets a coding challenge from us. This is nothing particularly difficult - a few hours at most - we just want to give the candidate the opportunity to write a small program how he thinks it should be written. We prefer the candidate to put this on a Github repository, but we understand that not everyone wants to have a public “job interview test” repository, so the candidate is free to email us the code as well.
With the candidate on-site, we sit down with him to discuss the code. “Why did you name this class this way?” “What does this method do?” “Is there a way we can refactor this code to make it cleaner?” The goal isn’t to find the “right answer” but to understand how the candidate thinks and expresses himself in code.
A quick bathroom break and we’re back to it.
The Pairing Exercise
The other test we like to use is a pairing exercise. We pair program most of the time, so we find this the most realistic way to gauge how we would work with the candidate. The premise is a contrived example of our domain that is partially implemented. There are failing tests for the code that needs to be written.
The point isn’t to make the tests pass but to demonstrate what it is like to pair with someone on our team, and get the thought process of how the candidate writes code in real time. Since there are so many decisions to make, it is valuable to get a candidate to express how she arrives at the ones she makes, how she decides where her code fits within the existing application, how she deals with edge cases, and how she follows existing patterns.
Both we and the candidate should come away with a good idea of what it is like to work together and if that is a positive experience.
And the Rest
Engineering doesn’t exist in a vacuum, so we want the candidate to meet others in the company. He talks to the product team, since we collaborate with them very closely, and he talks to someone in a non-technical capacity. We strive to get a full, consistent understanding of the candidate before we make a decision, as well as giving the candidate a chance to ask questions to people in many different roles, to give him a better understanding of what Funding Circle is all about.
Post-interview, those involved vote on a four point scale
- “I would quit if we hired this person.”
- “I don’t think we should hire this person, but I could be convinced otherwise.”
- “I think we should hire this person, but I could be convinced otherwise.”
- “I would quit if we did not hire this person.”
There has never been a candidate who received a 1, and there has not (yet) been a candidate who received all 4s. The scale is effectively binary, but we find it is easier for everyone to say 2 or 3 instead of thumbs up or thumbs down. If there is not consensus, we discuss until we decide “hire” or “no hire.”
These discussions can last a few seconds or up to an hour. These longer conversations have gradually decreased as we hone our process and figure out how to better decide on a candidate.
What Else We Tried
There have been two alternative tests we tried and decided did not work. The first is a more technical phone screen. With candidates from such diverse backgrounds, it is difficult to find a list of questions that are simple enough to do over the phone and still give us insight into the candidate’s knowledge. We have found it easier to discuss what he has actually accomplished, going into detail about successful projects and areas of interest. Think questions about open source projects instead of explaining Ruby’s eigenclass.
We have also tried going “higher level” and discussing service oriented architecture design. This did not work well because it is a less concrete, more abstract, conversation. The candidates generally want to whiteboard specific implementations, and it has been difficult to stay at the higher conceptual level of the overall architecture. This also takes away from the pairing exercise which we find has been the most helpful for us.
We constantly reevaluate our interview process. The need to balance thoroughness and expediency is difficult since we don’t want to spend all our time interviewing instead of solving business problems, but we know how expensive a poor decision, either to hire or not, can be for the business. We’ll keep trying, as we know there are great developers out there who would thrive in our environment.
If you are interested in more specifics of our interview process, why don’t you apply?