How do you find great developers in a sea of resumes?
Resumes are terrible at giving you any insight into a candidate’s personality and skill set. In the case of developers, this process carries additional risk because a single bad developer can substantially impact a team’s velocity, sink a project, and your reputation.
Reverse your mindset
At Admios, we solved this problem by viewing hiring as a race to say no. Rather than worrying about exactly whom we should hire, we focus on weeding out anyone we think won't succeed. We’re not afraid to say no politely and quickly. In order to support this mindset we've developed a scalable pre screen process and a collaborative interview format that reflects how we actually work.
Scale your screening
No one has ever aced our pre screen programming exam or assignment. I don’t expect them to. The goal of both of these is to identify candidates that can code and will fit into our organization. We want to get a sense of their current capabilities and the delta between those and what we need. Given the size of that delta, they could be a fit as they are, or could require some additional training. All of our new hires complete 2 months of training (more on that in another post) so the latter point is very important to us.
The exam
Our exam allows developers to complete programming challenges in their browser and then have the results tested and a a report sent back to us. The exam is 8 questions and delivered via InterviewStreet. RightScale, one of our clients, introduced us to this tool and I swear by it.
The test contains the following questions:
- 3 increasing difficult coding challenges - It’s amazing how many candidates can not code at all. These questions can be done in any language and still many candidates leave them blank.
- Logic problem - This tests both reading comprehension and basic logic.
- SQL problem - This is difficult that you can ascertain the candidate’s level of SQL and experience handling data sets. More experienced candidates detail concerns around the data types. Junior candidates are just slam the data from table to table.
- SDLC problem - This is a basic test of how much they understand agile roles and responsibilities.
- Personality assessment - How would they handle a tough communication situation with a client?
- Why do they want to work at Admios?
As I mentioned above, no one scores perfectly on this exam. However, we do get a sense of who is capable of coding and what training they would require if they joined.
The assignment
Our current programming assignment is to create a web application that takes a Stock Ticker and returns all the recent tweets that have this ticker. It’s required to update in real time and we ask that candidates use node.js. Why node.js? Because few developers have deep expertise with it. While the exam tests general knowledge the programming assignment asks a developer to quickly learn a new technology and create a simple application that mimics a lot of the tasks we see in house.
Make your interviews collaborative and fun
Most developers dread interviewing. It’s time consuming and takes them away from what they like, coding. In our process once both the exam and the assignment are submitted and look solid we have a good sense of a candidate’s technical skill. This changes the entire dynamic of our in person interviews. Instead of a technical screen, they are collaborative working sessions where our team discusses current challenges they are working on, and gets the candidate involved. This gives them a chance to see how the candidate thinks and if they would be a personality fit for the office. Interviews are now a way for developers to show off their projects and continue coding.
If no one says "No", say "Yes"
After the exam, programming assignment and interview, if no one's said “No”, we make the hire. If anyone felt like the candidate was negative or displayed any indication that they did not meet our core values, we don’t.
Have confidence in the process, even though it will fail
Despite all this work, your process will occasionally fail. At some point all systems do. Pay attention when you have a bad hire and figure out if the process broke down, or if the process needs to be changed. In the case of the latter, don’t be afraid to change the process. As always, iterate and adapt.
