2019-05-18 21:43 — By Erik van Eykelen
I’ve lost track but I must have interviewed hundreds of developers over the years, usually in the capacity of CTO or technical director of a small, fast growing company. Tiny companies are great but there’s a lot to do, not much help due to the small team size, and you have to work fast because if you’re not careful you become default dead. This means your hiring and interviewing process must be efficient and result in great hires, taking as little time as possible, without sacrificing quality.
I’ve been using the same interviewing process for years, and it has resulted in teams consisting of good programmers, who are building and maintaining complex applications and have been with the respective companies for many years.
I read the application letter, scan the résumé, visit links from the résumé (GitHub, blog, Twitter), and I google the last two or three companies the candidate has worked for. Degrees don’t matter.
Typos annoy me but are not a reason to dismiss a candidate. I tend to stay away from folks who have not actively developed for several years (as part of their job) and who also don’t mention they’ve actively coded in their spare time to stay current. A good candidate loves to code.
I check the résumé for any hints that tell me the person is an independent worker/thinker i.e. capable to tackle a chunk of work herself. This is not always possible, some candidates don’t even send an application letter. I tend to use a bit of gut feeling during this part of the interview process, somehow good candidates tend to stick out in various and subtle ways.
I grade the candidates (A, B, C) and sleep on it. During a hiring spree I do this every day, either grading candidates or conducting follow up calls or meetings.
After I have collected a couple of “A” candidates I’ll quickly set up a video call with each candidate. Hiring is like sales: the buyer is “in the market” for a new job so you have to act fast.
During call #1, which I deliberately time box to 30 minutes, I will check the following:
Again I grade the candidate and sleep on it.
If an “A” candidate is still graded A after the first call, I’ll set up a technical interview. Usually I ask one of the (lead) developers in my team to join the interview. Again I don’t leave much time between the previous call and the technical interview.
The technical interview lasts about an hour. During the interview we discuss a fictitious system, consisting of an API, web controllers, model, queue, workers, database, and 3rd party interfaces, and we discuss inheritance, at-least-once delivery, locking, fail-over, logging, monitoring, webhooks, security, and testing.
After the call my colleague and I compare notes. After we’ve slept on it we decide if the candidate is invited to come over to the office.
Note: usually between steps 2 and 3, but sometimes between steps 3 and 4, I discuss the salary requirements via email.
Provided the candidate is still graded A, and provided we can afford the candidate, she is invited to come over the office to meet the team.
Travel, hotel, and other expenses are paid but the candidate has to arrange a ticket and hotel herself. I do this deliberately, I expect a certain degree of worldliness.
The final meeting seldom leads to disappointments but it has happened that, again after sleeping on it, I decided not to close the deal. This is disappointing for both parties and something I loathe doing.
It’s important to use the same hiring and interviewing process over an extended period of time. It is the only way in which you develop a “baseline” view about candidates, hopefully enabling you to make better hiring decisions.