How do you interview a developer? How can you tell if they are skilled at their craft without hiring them and working with them?
Traditional methods are:
- The technical screen: Leetcode, whiteboard coding, etc. These are biased, some people don't like them, they don't fully match the real world.
- The resume / reference check: you don't do a technical screen, but use references as proxies for ability. I know that X is at great developer, so her friend Y must be great too. They worked at A, which seems like a hard place to work, so if they were good enough for there, maybe they will work out here.
- Trial period / trial project: the company gives the candidate real work, or a toy take-home project to work on. They are paid for it. Eliminates people that just aren't interested in this, requires some upfront work, and puts the company in an expert position of a teacher that has to grade assignments.
I'd like to suggest a third option, which is a strange informal version all. I refer to it in my own mind as shop talk.
After a phone screen, you have the candidate walk through a project that they have worked on. They get some time (20 minutes at least) to show the project's code and walk you through its structure and anything they want to highlight. The project could be what they are working on now at their current job, it could be an open source project they worked on, it could be something they wrote on their own time. For people that don't have time, or for people earlier in their career, the project could be something they did in a bootcamp or university.
Ideally, the candidate can show source code on their machine within their IDE, tools, etc. In a lesser version of this, they draw out how the system works on a whiteboard and provide pseudocode for a key part of the application.
Because you don't give them much structure and let them talk for a while, it is up to them to guide how they show and tell. This has some advantages for them: they get to highlight the parts they want to, they can prepare, and because they are talking for a bit it reduces interview anxiety. It has some advantages for the company as well: because they are forced to explain the system, it tests their technical acumen while also showing their communication skills.
After they are done showing, and/or throughout, the team gets to ask them questions about the project. The team should be coached on how to do this well. The point of this exercise is not a code review in the traditional sense, but more of a conversation. Shop talk.
- Can you show us the database design for this?
- Do you know of any other approaches or frameworks for MVVM you could use if you didn't use this one?
- What would you do next on this project if you had more time?
- What was the hardest part for you when you were working on this?
The discussion has to reach a point at which the candidate has explained the project well enough that the team understands it to ask good questions. If that hasn't happened, then there is a problem.
- Some people simply don't have any code they are allowed to show, or want to show.
- If the team asks bad questions, the exercise can turn into having a few of the same disadvantages of whiteboard interviews - can be an exercise in ego, can focus on arbitrary technical details that aren't core to the job role, etc.
- It puts the candidate in a more comfortable, real-world setting.
- This is a very efficient method if you are hiring for a specific skillset. If you are hiring a Swift programmer and see them flying around XCode using keyboard shortcuts as they describe the project, this is a competence signal that means something more than "yeah, I know Swift" or "yeah I can answer some esoteric language question".
- Engineering is an exercise in tradeoffs, and tradeoffs need context. Without a real project that the candidate understands it is hard to create a valid scenario out of thin air to provide this context. But with this approach, the candidate knows the problem well already, and it puts pressure on the team to think up smart questions. Since there are typically more than 1 interviewer and only 1 candidate, it puts the pressure in the better place to absorb it. They can ask about different decisions and tradeoffs once they understand the project.
There is another advantage that is harder to express, and it is the reason I call this approach Shop Talk rather than Show & Tell or Project Review or something more corporate. It puts developers, on both sides of the table, back into their normal mode. An interview is an atypical situation in which you try to talk about technical challenges away from a real world scenario. Even a toy project presentation puts everyone in a more natural setting. It's just a group of people, talking about some code. After it's over, both sides have an idea what it would be like to do that full-time, and isn't that the point of an interview?
- Candidate brings project they have worked on.
- Candidate walks team through it, highlighting what they want to, on a screenshare.
- Team asks the candidate about the project, seeking first to understand it.
- Team asks the candidate about the project and ways it could grow or change, seeking first to understand the engineering tradeoffs in play.
Try it out and adjust; it has worked well for me in the past.
If you are looking for true advice from someone who understands the struggle of remote work and has helpful advice, check out Navigating Remote Work.