Good interviews vs. great interviews

I have interviewed hundreds of candidates and have been interviewed more times than I’d like to admit. From my experience, most interview loops under-emphasize building the candidate’s understanding of the team, role, and company they’re interviewing for during interviews and instead defer this to the later “selling” stages of the process. I think this is a missed opportunity.

The approach I use to gauge interview quality starts by evaluating them in two dimensions. The first dimension is the strength of signals the interview provides to evaluate key competencies for the role. The second is how effectively the interview provides signal to candidates about the role, team, and company.

  • Good interviews focus on a specific set of competencies and yield a strong signal for interviewers to inform a hire/no-hire decision. Many interviews fall into this category.
  • Great interviews also maximize signal for the candidate about the role, their future team, and the company. These are gold.
  • Sell interviews may not yield a lot of signal to interviewers, but deliver a lot of signal to the candidate. These are necessary, but should be saved for later stages of the loop.
  • Weak interviews provide low signal in both dimensions. Replace these as soon as possible.

Interview loops with good interviews produce confident hire/no-hire decisions. Interview loops with great interviews also leave candidates with a deeper understanding of the opportunity, areas of ownership, and ideally, the confidence to accept an offer without much selling if they reach that stage.

Minor tweaks can produce great interviews

During a coding interview with a team working on routing at Uber I was asked: given a set of places and routes between places, write a function that determines if a route exists between a specified start and destination. This is a straightforward graph traversal question, but framing the problem using places and routes, instead of nodes and edges, gave me a deeper appreciation for the team’s mission.

Interviews that explore yet-to-be-solved problems are also very powerful. For example, I love Notion and think it’s a great product, but the search functionality is quite slow for workspaces with a large corpus. Instead of being asked generic design questions, candidates interviewing at Notion could be asked to design a search index for Notion workspaces to build an understanding of product and technical challenges.

Identifying weak interviews

Weak interviews can do more harm than good because they leave candidates with a negative impression of your company. One basic smell test is to ask: are there any interviews in your process that leave candidates confused about why the questions asked are relevant to the role? Ask candidates for feedback after they complete the interview loop. Some candidates will shy away from providing negative feedback (they’re trying to get hired after all) so it’s effective to directly ask questions like “what was your least favorite interview?”

Another approach is to score each interview on signals that are important to candidates. Potential priorities like future team, company and culture, product, technical challenges, and role are important factors to consider for engineering interviews. This will help you identify weak interviews that need improvement.

Assign a 0 to 3 rating for each signal and focus on the lowest scoring interviews.

This framework has served me well for both technical and non-technical interviews. That being said, great interview topics aren’t effective without amazing interviewers. Perhaps that’s a topic for a future post, but for now I’ll leave you with this excellent post about the interview skills ladder.

If you tried any of the strategies above, I’d love to hear how they worked for you.

Ownership is a requirement

One of the cultural values at Tecton is “be an owner, not a renter.” We’ve iterated on these values as the company has grown, but this particular value has been set in stone since the day I joined.

Ownership means taking initiative and treating your sphere of influence as if it’s a business and you’re in charge. Being an owner is a mindset that transcends title, role, or equity.

I care about ownership more than anything else when building a team. Owners are better engineers, build better products, and push the team forward. Growing companies have more problems to solve than people to solve them and any “that’s not my responsibility” attitude is damaging.

There are easy ways to probe for ownership signals when interviewing candidates. The simple question “tell me about a time you went above and beyond in your current role?” usually yields telling responses. But don’t stop there. Dig deeper. Why? What prompted their actions? What was their individual contribution? What was the outcome? What would have happened if they didn’t take any action?

For junior hires, I look for signals of them doing something without being asked. For example, independently fixing a bug they unexpectedly found. For more experienced hires, the scope can be larger and take many shapes. Several years ago I worked on Google Photos. I later learned the entire product was nearly shelved in favor of focusing on Google+. Google Photos was saved by an independent effort by a product and design lead to design and pitch a prototype using an 80 inch TV turned on its side to simulate an iPhone — ownership at its finest.

Each member of a team, especially at a startup, plays a critical role in the company’s path to success. The cost of non-owners is too high and they should be avoided.