Interview Questions That Actually Reveal Something
I have been hiring engineers for roughly twelve years now. I have conducted somewhere around four hundred technical interviews. The first few years I asked the same questions everyone asks, then realized most of them were just performance art for both sides. What I found is that the question itself matters less than how you follow up. A candidate can recite textbook answers all day. What separates people who will actually do the work from people who sound good in a thirty-minute conversation usually shows up when you derail the script.
Great Interview Questions To Ask Candidates
Here is what I actually use now, and why they work better than the standard whiteboard problems. Start with a broken thing, not a perfect one. I hand candidates a small piece of production code that has a real bug in it. Not an artificial puzzle, not something contrived to test edge cases they will never encounter. Something that happened last Tuesday in our repo. I say nothing except "this is failing in staging, take a look."
The first thing I watch is whether they run the test suite before claiming to understand the problem. About sixty percent of people skip straight to reading the code and immediately start proposing changes. That is usually a red flag, not because they are incompetent, but because in my experience the people who jump into editing without reproducing the issue are the same people who push fixes that break three other things. I remember one candidate who spent twelve minutes debugging a race condition in Go. The actual issue was that a config file path was hardcoded to a Linux absolute path on a machine running macOS. They never checked which OS they were on. We did not hire them. The fix took forty-five seconds once someone looked at the CI logs. Ask about trade-offs, not right answers.
Get the Full Details
The question "how would you design Twitter?" is useless. Everyone has heard it. Everyone memorized a version. What I ask instead is something like "we have a system that works but is slowly becoming unmaintainable. What signals tell you it is time to refactor versus when to just add another team member?" This reveals whether the person has actually shipped software at scale or just built things that never had to handle real traffic. The counter-intuitive insight here is that the best candidates usually talk about not refactoring first. They mention metrics, failure rates, team velocity. They ask what the current pain actually looks like before proposing any solution. I once had a senior engineer propose a complete rewrite of a module that was merely slow, not broken. When I asked what the actual bottleneck was, they had no idea. We ran profiling. The bottleneck was a single N+1 query. The rewrite would have taken three weeks. The fix took twenty minutes.
Give them incomplete information. Most interview questions assume the candidate has all the facts. Real work rarely works that way. I deliberately withhold something. I tell them the API contract but not the database schema. I give them the error message but not the logs. What I am looking for is whether they ask clarifying questions or start guessing. People who guess confidently are usually dangerous. People who say "I do not have enough information to answer that well" are usually the ones who will save you from shipping something broken.
This approach cuts the interview process down from about 90 minutes to roughly 45 minutes while actually revealing useful signal. The downside is that it requires the interviewer to be prepared, which means you need good examples on hand. If you do not have a realistic problem ready, the candidate will sense it and the question becomes theater again. Watch how they handle being wrong. Sometimes I intentionally give a candidate a constraint that makes their first approach impossible. I do this because the way someone reacts when their plan falls apart tells you more than any correct answer ever could.
The people who get defensive or try to argue with the premises are usually the ones who will blame infrastructure when their own code is the problem. The people who say "okay, let me think about this differently" are usually the ones who will debug your production issues at 2 AM without complaining. I learned this the hard way. I hired someone once who aced every technical question but completely fell apart when requirements changed mid-sprint. Three months later they were the person who needed their work rewritten by someone else because they treated the initial spec like a contract instead of a starting point. Ask about something they recently failed at.
This is the question I wish I had asked earlier in my career. "Tell me about a mistake you made recently and what you learned from it" sounds soft until you realize most people have never actually reflected on failure in a useful way. The candidates who give vague answers about working too hard or making a typo are usually the ones who have never taken real ownership of a broken system. The candidates who describe a specific incident, the impact, and what they changed in their process are usually the ones who will prevent your next outage. The limitation here is that this question only works if you create psychological safety. If the candidate thinks you are looking for ammo to reject them, they will give you the socially acceptable answer and you will learn nothing. The workaround I use is to share a failure of my own first. It shifts the dynamic from interrogation to conversation almost immediately.
Let them interview you. The last twenty minutes of every interview I turn it over to the candidate. Most people ask the same three questions back. "What does the team structure look like?", "What is the tech stack?", "How do you handle on-call?" What I actually want to hear is whether they ask about things that reveal their priorities. The candidates who ask "what is the hardest technical problem your team solved recently?" or "when was the last time someone pushed back on a technical decision?" are usually the ones who care about the work itself, not just the title on the business card.
This approach usually takes about five minutes of preparation on the interviewer side but reveals signal that no number of coding problems ever could. The downside is that some candidates will not take advantage of it. That is fine. You learn something either way. The questions above do not guarantee you will hire the best person. Nothing does. But they do reduce the probability of making a bad hire by about forty percent in my experience, and they usually cut the total interview time in half. That is a reasonable trade-off even if you do not use all of them.
