The goal of an interview is to determine if a candidate is going to increase the productivity and happiness of a team. For developers, two criteria are particularly important: an exemplary ability to communicate both technically and non-technically, and demonstrated technical skill in areas important to the team. Allowing a candidate to speak openly about a project they’ve worked on covers both of these criteria thoroughly. It’s my go-to interviewing strategy.
The initial conversation with a prospective developer should be used to get a sense of their passion and confidence with respect to developing software. What kind of projects have they worked on in the past? Have they worked primarily alone or on teams? Do they have any open-source work (passion projects)? If something sounds interesting or relevant, ask for more information - the more they can explain without getting lost in details, the better! It means they’re satisfying the exemplary communication criteria. A sense of overconfidence, rudeness, or confusion are all red flags.
If all goes well, ask the candidate if they can provide source code for a project they’ve worked on. If so, collect it and send it to the technical interviewer. If the candidate is willing to share multiple projects, try to collect the one that will be most easily understood by the technical interviewer - projects written in the programming language used by the company, for example. If a candidate cannot provide open-source code to a project, that’s fine - a modified technical interviewing strategy will have to be used, but a lack of access to open code is certainly not a deal-breaker from a hiring standpoint.
Assuming source code to the candidate’s project of choice has been provided, the technical project walkthrough can begin. Make sure you and the candidate have a copy of the source code to the project on hand. Have the candidate explain how the system works at a very high level. Let questions flow naturally from here, drilling down into the specifics of the program.
Does the candidate find a portion of their project particularly interesting? Prompt them for more details. What parts of the system are brittle, and how can they fix those components? How would the program be tested? How would the project be extended to implement a new feature? Ask them to review sections of their own code. The most important thing is to let the conversation happen organically. Red flags at this stage include difficulty or inability to back up design decisions, misunderstandings of overall architecture or subsystems, too fast-and-loose logical reasoning, and defensiveness when giving suggestions.
A project walkthrough is a friendly alternative to traditional interviewing strategies. Allowing a candidate to “live” in a comfortable mental space (their own project) assists with confidence level and ease of communication. Large skill gaps between candidate and interviewers is not a problem. Junior interviewers can learn a lot from senior candidates. How any candidate reacts to feedback from the interviewer is a good indicator of what it will be like to work with them, regardless of skill levels. A good candidate will be excited to talk about their passion projects, which gives the interviewer opportunity to learn about something new. I’ve personally found this strategy extremely effective in both weeding out poor developers and finding great ones. It’s much more enjoyable than a whiteboard interview, too!