The Compendium Engineering group has a reputation locally for having a tough interview process. Our interview process generally looks like the following:
That is, after a recruiter screen is passed we perform an initial phone interview. Assuming the initial technical interview goes well we give the candidate a take home problem. Assuming the take home problem is solved satisfactorily we invite the candidate in for an in person interview.
About 80% of candidates never make it through the technical phone interview. Most people really struggle with CS fundamentals like data structures (when to use an array vs a hash vs a binary tree) and algorithms (runtime complexity, performance implications of using an array vs a hash). However, a number of candidates struggle with some of the basic FizzBuzz type problems.
The take home problem is intended to be solved without the use of a framework but in any language that the candidate is comfortable with. My belief has always been that anyone can learn a new language so I've never asked people to complete a project in a specific language although sometimes the position kind of requires it, e.g. a front-end take home problem probably ends up involving creating HTML/Javascript/CSS/etc. Of the remaining 20% of candidates who get to this point, about 50% of them pass this part of the process. You might be surprised at how many people either can't solve the problem (and, they're fairly trivial) or create buggy solutions that don't meet the requirements.
Of the remaining people who are invited in for the in person interviews, they can look forward to 4-6 hours of technical interviews with everyone on the engineering team. We take The Guerrilla Guide to Interviewing to the extreme. Before the candidate comes in the entire team gets together and reviews the take home problem and comes up with a comprehensive set of questions for the candidate. This group meeting ensures there is no overlap in questions and also that the question coverage is sufficient. The phrase 'test coverage' comes to mind.
We start the day by having the candidate join our scrum standup. Using scrum at Compendium, we have a daily standup at 11am. By allowing the candidate to join the standup as a chicken they get a brief introduction to the team, one of our most important processes (scrum) as well as some insight into our day to day work.
We also do a group code review near the end of the day. The primary purpose of the take home problem, besides demonstrating basic abilities, is to provide the entire group including the interviewee with a common piece of code. The take home problems are small enough that the team can review the code before the candidate comes in and we can perform a useful formal code review with the candidate. This provides the candidate with an opportunity to interact with the entire team as well as get a feel for some of our internal processes (since we do bi-weekly formal code reviews). A good candidate is interviewing us just as much as we're interviewing them and this is a great opportunity to do that.
In addition to each interviewer covering both soft (HR style) questions as well as technical questions, each interviewer follows up the interview by providing me with an immediate yes/no hiring recommendation along with a longer writeup of their reasoning. In some cases the interview is ended early if we have enough 'no' recommendations. We meet as a team after the interview has concluded to review the candidate and do a post-mortem of sorts on the process. This ensures that our interview process stays up to date and usable.
Although I've had some recruiters give me critical feedback about how 'tough' the process is, I disagree. Our interview process is extensive but it has also evolved regularly based on our own needs and experiences. We've developed a process that helps us not only find the best qualified candidate but the candidate that will be the best fit.
That is, after a recruiter screen is passed we perform an initial phone interview. Assuming the initial technical interview goes well we give the candidate a take home problem. Assuming the take home problem is solved satisfactorily we invite the candidate in for an in person interview.
About 80% of candidates never make it through the technical phone interview. Most people really struggle with CS fundamentals like data structures (when to use an array vs a hash vs a binary tree) and algorithms (runtime complexity, performance implications of using an array vs a hash). However, a number of candidates struggle with some of the basic FizzBuzz type problems.
The take home problem is intended to be solved without the use of a framework but in any language that the candidate is comfortable with. My belief has always been that anyone can learn a new language so I've never asked people to complete a project in a specific language although sometimes the position kind of requires it, e.g. a front-end take home problem probably ends up involving creating HTML/Javascript/CSS/etc. Of the remaining 20% of candidates who get to this point, about 50% of them pass this part of the process. You might be surprised at how many people either can't solve the problem (and, they're fairly trivial) or create buggy solutions that don't meet the requirements.
Of the remaining people who are invited in for the in person interviews, they can look forward to 4-6 hours of technical interviews with everyone on the engineering team. We take The Guerrilla Guide to Interviewing to the extreme. Before the candidate comes in the entire team gets together and reviews the take home problem and comes up with a comprehensive set of questions for the candidate. This group meeting ensures there is no overlap in questions and also that the question coverage is sufficient. The phrase 'test coverage' comes to mind.
We start the day by having the candidate join our scrum standup. Using scrum at Compendium, we have a daily standup at 11am. By allowing the candidate to join the standup as a chicken they get a brief introduction to the team, one of our most important processes (scrum) as well as some insight into our day to day work.
We also do a group code review near the end of the day. The primary purpose of the take home problem, besides demonstrating basic abilities, is to provide the entire group including the interviewee with a common piece of code. The take home problems are small enough that the team can review the code before the candidate comes in and we can perform a useful formal code review with the candidate. This provides the candidate with an opportunity to interact with the entire team as well as get a feel for some of our internal processes (since we do bi-weekly formal code reviews). A good candidate is interviewing us just as much as we're interviewing them and this is a great opportunity to do that.
In addition to each interviewer covering both soft (HR style) questions as well as technical questions, each interviewer follows up the interview by providing me with an immediate yes/no hiring recommendation along with a longer writeup of their reasoning. In some cases the interview is ended early if we have enough 'no' recommendations. We meet as a team after the interview has concluded to review the candidate and do a post-mortem of sorts on the process. This ensures that our interview process stays up to date and usable.
Although I've had some recruiters give me critical feedback about how 'tough' the process is, I disagree. Our interview process is extensive but it has also evolved regularly based on our own needs and experiences. We've developed a process that helps us not only find the best qualified candidate but the candidate that will be the best fit.
Comments for Interview Tactics
Leave a comment