Interviewing the interview

Irrespective of industry, finding the correct talent is a difficult task when growing a team. Managers want new employees who are high performing, fit well within the team culture, and bring fresh ideas to innovate in the product space. Recruiting goes to work pulling together a set of candidates who they think fit the criteria of the team. Once those candidates are identified and brought in for interviews, the real challenge begins.

Before we continue, lets focus on the tech industry - specifically software engineering. To date, I have been involved in close to 100 interview "loops" for Microsoft.

Teams allot a candidate 3-5 interview slots (typically including a "behavior" interview over lunch) to identify the if this candidate best exemplifies the three vectors described above. Demand is high enough for software engineering positions that the competition is intense - One of the interview rounds during your day report negative feedback? Better check LinkedIn for the next opportunity!

Each "round" of the interview is simple to describe - the candidate sits with an engineer on the team and works through the following script (*):

  1. Brief discussion over the candidate's resume
  2. One tidbit from the resume is selected for problem description, challenges, learning, etc.
  3. Challenge 1: Design (Unless the candidate is a new to the industry in which case this becomes an extra coding challenge).
  4. Challenge 2: Coding
  5. Questions about the team/role

(*) This script is subject to change - For example, I've seen teams do separate interviews for coding and design.

What I want to focus on is the coding challenge. Typically, this is presented as a puzzle - the candidate needs to quickly identify the correct algorithm/data-structure to use when solving said puzzle. The candidate also needs to do this quickly while under stress (trying to impress a new company is stressful, right?) and while trying to involve the interviewer.

Too slow? I will give you a hint (uh-oh).

Too fast? I assume you have seen the problem before (uh-oh).

Somewhere in between but not involving me enough? I assume you won't fit in with our team (uh-oh).

My issue with this interview style is that it has nothing to do with day-to-day work as a software engineer. Described differently - my manager has never asked me, on the spot, to code some brain puzzle during our daily scrum while everyone watches.

I want to take this a step further - I argue that this style inhibits diversity (but this is a topic for another post).

Rather than continue to list out the reasons why I dislike this common interview practice, I would rather propose another! I present to you: The Practical Interview (COMING SOON - name subject to change).