Most engineering interviews are optimized for skill. The candidate solves a problem in a language they know, in a window of time, under the eyes of a stranger. This tells you, roughly, whether they can code. It tells you almost nothing about whether they should.
Skill is what an engineer can do. Taste is what they choose to do when nobody is watching. The two are correlated but not identical, and the second is the one that determines what your codebase looks like in three years.
What taste looks like in code
Taste shows up in the small choices. The variable names. The error messages. The willingness to delete a function that was clever but confusing. The instinct to simplify a design after it works, not before. The refusal to add a feature that would fit but wouldn't belong.
None of these are visible in a coding interview. All of them are visible in a codebase, and they compound. A team with consistent taste produces a codebase you can read. A team with mixed taste produces a codebase you can only survive.
The unfortunate truth is that skill floors have risen — most engineers you interview today can competently produce working software — while taste floors have not. The delta between a tasteful engineer and a merely competent one has widened, and it is now, for many teams, the single biggest differentiator in hiring.
How to actually hire for it
Interviewing for taste is harder than interviewing for skill, and the industry has not converged on a good process for it. Some things we have found useful.
The most reliable signal is a real code sample the candidate wrote, alone, over more than a day. Not a homework assignment for the interview — those are gamed. Something they wrote for themselves, for their own reasons, that they are willing to walk you through. What they chose to name things. What they chose to abstract. What they chose to leave rough. All of it is taste, visible directly.
The second is a design conversation about a system with no clean answer. Not a system design interview with a rubric. A real, ambiguous problem, discussed as a peer conversation, where the candidate has to make and defend judgment calls. Watch how they hold uncertainty. Watch what they refuse to commit to prematurely. Watch which considerations they surface unprompted.
The third is a review of code they didn't write. Give them something plausibly bad and ask them to critique it. The critique will tell you what they value, what they notice, and what they consider beneath comment. This is the closest thing to a direct measurement of taste that we have found.
What we deliberately don't do
We do not do algorithmic whiteboard problems. They measure the wrong thing and select against the kind of engineer we want. The engineers who thrive under that format tend to be the ones who have most recently prepared for it, which is a demographic weakly correlated with the ones who will build good software with us over the next five years.
We do not do timed take-homes designed to stress-test candidates. They select for people willing to be stress-tested, which is not a proxy for anything we care about.
We do not do panels of five hour-long interviews in one day. It is a bad experience, it produces exhausted candidates and exhausted interviewers, and the signal is worse than a smaller number of longer conversations.
The cost of taste-first hiring
Hiring for taste is slower than hiring for skill. The candidate pool is smaller. The evaluation is more subjective. The disagreements between interviewers are sharper. The false-negative rate is probably higher than a purely skill-based process would produce.
We accept all of this. The alternative — hiring quickly for skill and hoping taste emerges — has been tried repeatedly across the industry, and the results are legible in the codebases those teams inherit from themselves five years later. We would rather move slower and inherit a codebase we recognize.
A closing note
Fewzon is small. We are going to stay small for as long as the work allows it, and possibly longer. Every hire we make is going to have a disproportionate effect on what the team becomes, and taste is the property that shapes that effect more than any other.
If you have read this far and something in it resonates, we would like to hear from you. Our email is at the bottom of the page.