The interview process is one of the first and most crucial steps in hiring someone. In this post, I want to share my philosophy for hiring great engineers who are not just technically skilled but also strong team players. My issue with most traditional interview processes is their excessive focus on technical abilities. While technical skills are essential for building a successful engineering team, the overall performance of the team is more nuanced than just the sum of each individual's skills. Although it's challenging to assess someone's personality in a few hours of interviews, we, as hiring managers, must strive to understand the candidates' needs and motivations. I divide the interview process into three stages:
Stage 1 - Let’s Meet
The first stage is the ideal time to understand the candidate's background, motivation, and preferred working style. I usually begin by describing our current team setup, our methods of working, our strengths, and the values we seek. Then, I ask the candidate a series of questions about their past experience, steering clear of technical details to focus more on processes, problem-solving, and handling unknowns. I’m curious about the candidate's experiences, as they often provide insights into how they tackle problems. A good question for a senior developer, for example, might be, “How do you ensure that multiple teams are not duplicating work?” This helps gauge if the candidate is ready to tackle problems larger than the current sprint's user stories. After discussing their background, we move to questions about work habits and behavior in the workplace. Instead of asking generic questions like “Are you a good team player?”, I prefer to ask more thought-provoking ones, like “Describe a team you wouldn’t want to work with,” or inquire why they are seeking a new job, followed by related questions. Understanding a candidate's motivations is crucial - I believe in the principle of 'Start With Why’. When answering questions, it's important to be patient and provide a complete picture. Transparency and honesty are key. Mention any challenges, like a less-than-ideal CD pipeline or struggles with Scrum. Candidates with the right attitude understand that not everything is perfect and that engineering involves trade-offs.
Stage 2 - Let’s Work
Often referred to as the technical interview, this stage diverges from the typical format. Searching “C# interview questions” online might bring up basics like “value type vs. reference type” or “how garbage collection works.” While these are good questions, they can be crammed overnight. Instead, I prefer giving the candidate a more realistic experience, akin to daily work. We might start with a piece of poorly written code and work together to refactor it, discussing the reasons behind each decision. This approach lets me see how the candidate behaves in practical situations and how they handle uncertainty. Tools for remote pair programming, like Visual Studio Live Share, are incredibly useful for this. After code refactoring, we discuss system design problems, focusing on the candidate's experience with the technologies they've used. For instance, if a candidate mentions using Kafka, I might ask how they handle bad messages since Kafka doesn’t have a dead-letter queue (DLQ) by default. This stage is as much a conversation as it is an interview, allowing both parties to showcase their skills. Like in a sports team, if a candidate sees strong engineering during the interview, they are more likely to want to join the team.
3 - Strategy
The final stage involves meeting with the VP of Engineering. After the first two stages, the candidate should have a good understanding of the team dynamics. Meeting with the VP allows them to grasp the company’s broader strategy. I always encourage candidates to ask questions about our vision. While the team operates with a degree of autonomy, its boundaries are often set by higher management.
4 - Next steps
In upcoming posts, I'm gonna focus on how to source candidates and close the process.