The Gauntlet: How I Run Technical Interviews

Hiring top-notch engineers is imperative in today's fast-moving, complex startup world. While full-stack development once required knowledge of 1–2 programming languages, it now requires expertise in no less than 5 (Javascript, HTML, CSS, SQL/NOSQL, server-language of choice) in addition to a cadre of tools, utilities, patterns and practices. Screening candidates by phone is a key step of the hiring process and one in which I try to get a good understanding of their capabilities and skills. This post is an effort to share how I go about making this assessment in a phone interview. I’m sharing it so that future interviewees have a better feel for what might be coming, and so that peers can make suggestions on how I might refine the process even further.

What I’m Looking For

I want to assess two dimensions of skill, and understand if I can check a couple of checkboxes in the interview. Specifically:

• Where is this candidate strongest in full-lifecycle development?
  This assessment considers product development from concept to launch to maintenance phase. What phases of a software product has this candidate contributed before? Are they a ‘finisher’ who can help get a product through the last mile of development? Do they have the attention-to-detail necessary provide maintenance on an existing product? Are they good at building prototypes, but lose interest in the middle of the product when bug fixes and polishing features requires a lot of small blocking-and-tackling?
• Where is this candidate strongest in the stack?
  If you you think about modern applications as a layer-cake where clients (web or mobile), sit on top of platforms, which site on top of data stores, where will this candidate be able to contribute the most and the least? Only the rarest of individuals is as knowledgeable CSS3 best practices as they are about complex SQL joins, so this phase of the interviews seeks to identify where the candidate has ‘deep’ or ‘shallow’ knowledge. I start by asking which of the three layers they think they are strongest/weakest, and they press on knowledge in that area.

Here are some of the questions I might pursue:

Strong on Data Layer?

• Describe Data Normalization. How many levels can you describe? Why is this important?
• How many SQL JOINS can you name? When might you use one or the other?
• What types of SQL indexes are there? Why would you choose one over another?

Strong on Web Front-end?

• What Javascript frameworks do you like/dislike? (Lot’s of judgement can be assessed with this one)
• What is the difference between == and ===?
• What guidelines/best practices are important when crafting markup/CSS/Javascript code in applications where there are multiple contributors?
• Describe the lifecycle of Javascript component that leverages AJAX for data display?

Strong on Application/Platform Layer?

• Describe different types of Polymorphism (in Rails specifically if applicable)?
• How would you improve performance of a slow-rendering page?
• Describe some of the recent changes/improvements in your server-language/framework of choice?
• How do you approach testing/test automation?

As you can imagine I can quickly pick and choose on these questions to assess two-dimensions of the candidates technical capabilities, as well as getting a more subtle feel for the overall judgment. I believe that judgment is the critical differentiator between strong developers, and those with technology leadership potential. It’s the core indicator of potential to become Product Leads and eventually VP/CTOs. I will almost always hire a junior developer with strong technical judgment.

During the course of the interview I’m also looking to check two additional items from my mental assessment list. Specifically:

Tell me something I don’t already know. Technology is always changing, and I certainly don’t know it all. It’s always good to find a new trick or tip when interviewing a candidate. If I can learn something even minor in an interview, it makes a great impression.

Expand the capabilities of the team. The combined capabilities of my development teams is usually enormous. However, any time we can find a candidate with a slice of experience or expertise that will add to the collective capabilities of the team, it’s a huge advantage. A developer who has worked on a deep problem where our existing team only has intermediate knowledge, or who knows where all the nasty edge cases of a framework exist, or has contributed to an open source project we use are all huge wins.

One comment on interview anti-patterns: I’ve participated in both sides of interviews where an interviewer is consciously or unconsciously attempting to prove that he/she is the ‘smartest person in the room’. It’s a really easy thing to pull off (just ask about the one technical challenge you’ve been studying to solve for the last 2 weeks), and it doesn’t prove anything, while it belittles the candidate. It doesn’t make you smart, it makes you a bully — so be aware if you fall into that trap. If candidates are getting a lot of questions where they can’t provide sufficient answers it’s time to back off a bit, or maybe call the interview early, rather than continue on a path that won’t yield a win for either party. Candidates should be aware that the questions I’ve listed above aren’t intended to be ‘hard’ questions, they are required knowledge for any senior member of our development team.

Hopefully this post gives some new ideas to help you better prepare for your next interview, or hone your interviewing process. I’m always looking for tips and techniques to make this even better — so send them my way. If you think you’d like to join a team and go through the gauntlet, we are building awesome applications on Rails, Elasticsearch, React, iOS and Android — reach out and let’s talk.