Everyone says they hire for taste and almost nobody says what they mean by it, so here is my working definition: taste is the ability to say what to leave out, and to explain the reason without appealing to authority or vibe.
That definition is useful because it is testable. You cannot interview for "good judgment" in the abstract, but you can hand someone a real artifact — a design, a schema, a document, a plan — and ask what they would remove. Three things happen, and each one is informative.
- Some people remove nothing, and explain why every element is justified. Usually careful, sometimes excellent, rarely decisive.
- Some people remove a lot, quickly, and cannot articulate a principle. This is preference, not taste. It works until it meets a case their instincts were not trained on.
- Some people remove two things and can tell you exactly what the artifact gives up by keeping them. That is the signal.
The third group has a trait the others lack: they hold the cost of every element in mind at the same time as its benefit. That is what makes taste transferable to a new domain, and it is why it survives contact with problems nobody on the team has seen before.
Two smaller notes. First, taste is domain-specific far more often than people admit — someone with immaculate judgment about interfaces may have none about pricing, and the confident transfer of taste across domains does real damage. Second, it is learnable, but only by people who get feedback on removals, and most organizations only ever give feedback on additions.