← Back to the blog

Interviewing for taste

Technical screens filter for craft. But the thing that actually separates senior engineers is taste — and you can, carefully, interview for it.

Technical screens filter for craft — can you write code that compiles, passes tests, and handles the obvious edge cases. That's table stakes. The thing that actually separates a senior engineer from a staff engineer is taste: the judgment to know when to add a layer of abstraction and when to leave the code alone, when a design is finished and when it's just been worked on for too long.

Quick answerYou can interview for taste, but not with a take-home or a whiteboard problem. The signals come from a portfolio walk-through, a critique exercise, and a trade-off conversation. Look for engineers who can defend their choices in their own work, identify what's wrong in someone else's, and articulate what they'd trade for what.

What we mean by taste

Taste in software is the sum of small judgments: how big a function should be, when a comment is needed, whether a new abstraction is earning its keep, where to put the seam between two systems, when a test is too brittle to be worth keeping. None of those have a right answer. Engineers with taste land on choices that age well; engineers without it produce code that's technically correct and operationally painful.

Taste is built by reading a lot of code, shipping a lot of systems, and being on call for the consequences. You can't teach it in a bootcamp. You can't fake it on a take-home. But you can recognise it in conversation if you know what to listen for.

Why it separates senior from staff

A junior engineer writes the code that solves the problem. A senior engineer writes the code that solves the problem and three near-future variants. A staff engineer writes the code that solves the problem and knows when not to write the code at all. The shift from senior to staff isn't about more technical skill — it's about better judgment under uncertainty, and judgment is what taste is.

The portfolio walk-through

Ask the candidate to walk you through a project they're proud of — ideally one with non-trivial technical choices. Not a blog post about it; the actual code, on a screen, with you asking questions. Spend 45 minutes. Listen for:

  • Choices, not features. They explain why they picked Postgres over DynamoDB, not just that the system uses Postgres.
  • Things they'd do differently.Self-aware regret about specific decisions is a strong signal. "I'd split this package" or "the cache invalidation here was wrong" beats vague humility.
  • Constraints they navigated. Real engineering happens under deadline, headcount, and budget pressure. Candidates who can narrate trade-offs cleanly have actually shipped.

Engineers without taste describe what the code does. Engineers with taste describe why it's shaped the way it is.

The critique exercise

Show the candidate a 200–400 line piece of real code from a previous project — pre-refactor, with known problems. Ask them to spend 20 minutes reading it, then walk you through what they'd change and why. The valuable signal is what they don't say. Engineers with taste prioritise: they tell you which of the five things they'd fix first, and why the other three can wait.

Watch for the candidate who wants to rewrite the whole thing. That instinct usually fades after the third on-call rotation, but if it hasn't, it's a yellow flag. Senior engineers learn to leave working code alone.

The trade-off conversation

Pick a real architectural question that has no clean answer:

  • Sync HTTP call vs message queue for an internal service-to-service workflow.
  • One service per team vs vertical slices in a shared monolith.
  • Database row-level security vs application-layer authorization.
  • Library upgrade pinned to LTS vs always on latest.

Ask which they'd pick and why. Then push back. The right answer isn't a side; it's the engineer's ability to articulate what they'd trade for what, and to update their position when you add new context. Engineers with taste argue for trade-offs, not ideologies.

What this isn't

Interviewing for taste is not interviewing for agreement. The point isn't to find candidates whose taste matches yours — it's to find ones who've developed taste at all. A candidate who would have made different choices than you, but defends those choices clearly, is a stronger hire than one who agrees with everything you say.

It's also not interviewing for confidence. Confident wrong answers are common; quiet right ones are not. Listen for the specificity of reasoning, not the volume.

If you're building out a senior engineering team and want to compare notes on hiring, we've interviewed a lot of engineers. Taste is the hardest signal to test for and the one that matters most after eighteen months.

★ ★ ★

End of article · Thanks for reading

Subscribe

More of this, once a month.