30 Interview Questions to Ask Developers (and What Good Answers Sound Like)

The most common interview mistake isn't asking hard questions. It's asking different questions of every candidate, then comparing gut feelings afterward. Structured interviews — the same core questions, in the same order, scored against the same criteria — predict on-the-job performance far more reliably than free-form conversation, and they make it much harder for bias to fill the gaps.

Here are thirty questions worth asking, grouped by what they're actually testing, with notes on what separates a strong answer from a weak one.

Screening round

The goal here is fit and motivation, not technical depth. Five questions is plenty.

1. "Tell me about something you've built that you're proud of." Listen for specifics: constraints, decisions, trade-offs. Strong candidates go deep on one thing; weaker ones list technologies.
2. "Walk me through your last project — what was your specific contribution?" The tell is pronouns. Candidates who only say "we" and can't isolate their own work often haven't done much of it.
3. "Why are you looking, and what do you want from the next role?" You're checking whether what they want is something you actually have.
4. "What's your understanding of what we do?" Two minutes of preparation is a low bar. Candidates who cleared it are more likely to still be engaged at offer stage.
5. "What compensation range are you targeting, and when could you start?" Ask early. Discovering misalignment in week five wastes everyone's time.

Technical depth

Depth beats breadth. You're testing whether they understand what they've used, not how much they've touched.

6. "Pick something on your CV and teach it to me." Letting them choose removes the trivia lottery and shows you how they explain. Depth of understanding surfaces fast.
7. "What's the longest you've spent tracking down a bug? How did you eventually find it?" Listen for methodology — hypotheses, bisection, instrumentation — rather than luck.
8. "What would you change about the last codebase you worked in?" Good answers are specific and unemotional. Pure venting, or "nothing," are both warning signs.
9. "How do you decide what to test?" You want a risk-based answer, not a coverage percentage or a dogma.
10. "Tell me about a technical decision you got wrong." The strongest engineers answer this easily and concretely. Difficulty here often means limited ownership.
11. "What's something you used to believe about software that you've changed your mind about?" Reveals whether experience has actually updated their thinking.

System and design thinking

Use problems from your own product. Realistic beats abstract.

12. "Design [a real feature from our product]. Start by asking me questions." The questions they ask are the signal. Jumping straight to a solution is the red flag.
13. "How would you approach [an actual problem your team faced recently]?" You already know what's hard about it, which makes evaluating the answer much easier.
14. "An endpoint got ten times slower after a release. How do you find out why?" Tests debugging in production: metrics, tracing, recent changes, bisecting.
15. "How would you migrate [a real system] with no downtime?" Sequencing, dual-writes, backfills, rollback plans — and whether they think about rollback at all.
16. "Where does this design break first if traffic triples?" Good engineers identify their own bottlenecks without being led.

Collaboration and communication

For most teams this predicts success better than raw technical ability, and it's the area most often skipped.

17. "Describe a technical disagreement with a colleague. How did it end?" Listen for engagement with the other position. "They were wrong and eventually realised it" is not a good answer.
18. "How do you approach code review — as author and as reviewer?" Tests whether they distinguish blocking issues from preferences.
19. "Explain a technical trade-off to me as if I were a non-technical stakeholder." The ability to compress without condescending is rare and valuable.
20. "Tell me about a time you pushed back on a deadline or a requirement." You're checking whether they can say no constructively, with alternatives.
21. "How do you get up to speed in an unfamiliar codebase?" Practical answers — tracing a request end to end, reading tests, shipping something small — signal someone who'll onboard quickly.

Ownership and judgment

The difference between an engineer who closes tickets and one you can hand a problem to.

22. "Tell me about a production incident you were responsible for." Ownership, honest diagnosis, and a systemic fix. Blame-shifting here is disqualifying.
23. "When have you shipped something you knew was imperfect? How did you decide?" Tests pragmatism. Engineers who can't ship anything unfinished can be as costly as those who ship everything.
24. "What do you do when you're blocked?" You want a timebox and then escalation — not silent struggling for three days.
25. "Tell me about something you improved that nobody asked you to." Initiative, and whether they can spot problems without a ticket.
26. "How do you know when a piece of work is actually done?" Tests and docs and monitoring, or "it works on my machine"?

Questions that surface risk early

Ask these near the end, when there's enough rapport for honest answers.

27. "What kind of work do you actively not want to do?" If it's most of this job, better to know now.
28. "In what kind of environment do you do your worst work?" More revealing than asking about their best.
29. "What would your last manager say you should develop?" Self-awareness. "I work too hard" is a non-answer.
30. "Is there anything about the role as described that concerns you?" Surfaces objections while you can still address them — and often saves an offer.

How to actually run it

• Assign questions to rounds so interviewers aren't unknowingly duplicating each other.
• Score against defined criteria immediately after, before discussing with anyone. Group discussion first is how one confident voice overwrites four independent judgments.
• Take notes on what they said, not how they made you feel.
• Leave real time for their questions. What a candidate asks is itself signal, and the strongest candidates are evaluating you hard.

What to stop asking

• Brainteasers and puzzles. They measure exposure to puzzles.
• Trivia with a single memorized answer. Everyone has a search engine at work.
• "Where do you see yourself in five years?" Nobody answers honestly.
• Anything about family, age, health, nationality, or plans to have children. Beyond being unlawful in most jurisdictions, it tells you nothing about the work.
• Whiteboard algorithms for a role that never touches them. You'll select for interview practice rather than the job.

The takeaway

Structure is the whole game: the same questions, asked of every candidate, scored independently before anyone confers. Use their real work and your real problems as the material, weight collaboration and judgment as heavily as technical depth, and treat what candidates ask you as data too. A consistent process gives you comparable answers — and comparable answers are the only kind you can actually decide on.

Find candidates worth interviewing — post your role on JobsList.dev.