Most Tech Interviews Suck — The Only 4 Questions That Matter

Recently, a former employee of mine interviewed at a tech company in SF. He’s one of the best developers I know. After multiple hours of writing code at a whiteboard, he didn’t get the job. They’d be lucky to have him but the questions they asked were fundamentally flawed.

I’ve interviewed hundreds of candidates across multiple companies, and I’ve learned that all you need is the right 4 questions.

Question #1: When you enter your email and password into gmail… what happens next?

The correct answer to this question can easily take over an hour to explain… while an inexperienced developer is confident in their answer after only a few minutes. You might explain the OSI model in an HTTP request and how data traverses the global internet. You may detail a physical infrastructure design and how you’ve been thoughtful about security and DDoS prevention. You may mention API design and an approach to versioning you’ve used in the past. You may discuss the pros/cons of various forms of encryption and how to fetch/cache information from a datastore in performant ways. You may touch on exception handling, logging, and analytics. The list goes on. This right answer to this question proves you have a deep understanding of the internet which is almost impossible to learn from a book.

Question #2: Can you build this? You have 1 hour.

For the majority of startups, except the 0.0001% who have reached 50M+ users, I’m a strong believer in hiring generalists. If your tech team has grown beyond 15 people, I suggest you break into small multi-functional teams with specific KPI goals and the autonomy to make technical and business decisions quickly. This means that any developer on any team has to be capable of any task. I’ve found you learn a lot about a candidate by watching them build a small app from scratch.

So you’ve been asked to bring your own laptop. Sitting beside you, I point you to a JPEG and a JSON url. The photo is of a Amazon search results page listing products, images, prices, descriptions, etc. From an empty directory, you next task is to spend 1 hour to build the experience in the JPEG with the data in the JSON.

Depending on your background, you may chose to build a native mobile app or a web app. Either is fine. Please know that I’m learning about you from the moment you start typing on the command line. What shell are you using and how it is configured? How do you setup a quick dev environment? What piece of the problem do you attack first? Do you write tests? Unlike writing code on a whiteboard, I could care less if you search for something in Google during your interview. You know why? Because you’re likely to actually use Google on the job and I want to see if you’re any good at it.

Ohh btw, I didn’t tell you… but the JSON url I give you is littered with edge cases. It has data that doesn’t fit nicely in the UI, it is hundreds of items long, it has image URLs that resolve 20% of the time, and more. The url is hosted on a live machine and it itself throws an occasional error. Sorta like real life. :)

Watching you build something from scratch tells me so much about you and your proficiency/speed as a developer. I’m evaluating the process, not the final product. Plus, I don’t really expect you to finish... because I also want to watch you cut scope, take shortcuts and/or get stressed out when you don’t complete it.

Question #3: Why do you want to work here?

This question has no wrong answers, but there are many answers that aren’t enough. Don’t tell me you like some software stack that we use. We may change it. Don’t tell me you like someone on our team already. If they leave someday, so will you. Don’t tell me you like our neighborhood and it’s an easy commute. We may move. Don’t tell me you think our product is “doing really well” right now. I’ve heard them all.

Instead, what I’d love to hear is deep understanding of our product and our market. I’d love to hear your ideas and why you’re excited to make our product better and our business more successful.

Remember that I’m hiring you to build products not write software. It’s a very important distinction. You’ll make hundreds of micro decisions every day about what and how to build products and I want to know that you understand our business and will put that as your first priority.

Question #4: Want to grab dinner with the team?

Bring a handful of people from across the company to every candidate dinner. It’s a great opportunity to decide if this person fits your company’s culture and if you enjoy spending time with this person outside of the office. Why? Because the strength of the personal relationships within your team are what help get you through the highs and lows of startups. Also, make sure folks act in a way that you want to represent your company. Someday in the future, especially if they are wearing your company’s schwag, you want to be proud of their behavior because they are always representing your company. I can share horror stories of when that didn’t occur… even immediately after an interview.

Also, get back to the candidate the next day. They deserve the quick response.

The above interview process isn’t perfect. It doesn’t fit every company or every role. That said, it’s far superior to asking a candidate to write some silly recursive sorting problem on a whiteboard from memory.

If you interview people who build products, what did I miss?

UPDATE: after much feedback online:

1) Of course the candidate is told in advance about a meal with the team. It can be lunch or dinner based on schedules. Also, I’m not promoting brogrammer culture by asking a candidate to meet for a meal. Culture fit is important. That is the goal.

Not because you share the same background, ethnicity, gender, personality, sexual preference, etc… but you share the same values. A meal is a more relaxed setting to really get to know someone.