16 Signals

Why Proof Beats Opinion

Hiring should rely on real work evidence, not résumés or subjective interpretation.

8 min read
16 Signals
16 Signals ResearchResearch

Hiring still runs on interpretation. Engineering does not.

Modern engineering has become something you can observe.

Not perfectly, not completely—but enough that decisions are rarely made in the dark anymore. Systems emit signals: logs, commits, pull requests, deployments, incidents, rollbacks. Work leaves traces.

Hiring, however, still behaves as if none of that exists.

It continues to rely on interpretation layered on top of interpretation: résumés, interviews, and narratives about past work that someone has to reconstruct in their head.

That gap—between observable engineering and inferred hiring—is where most of the noise comes from.

Résumés were designed for a world without visibility

The résumé was never meant to be a precise record of work. It was a workaround.

When you could not see what someone actually built, you needed substitutes:

job titles, company names, years of experience, and carefully written summaries of impact.

These signals were not wrong. They were just incomplete. They existed because there was no alternative.

But the nature of engineering has changed.

Today, real work is no longer hidden behind the curtain. It is distributed across systems that record it by default. You can see how a service evolved through commits. You can trace decisions through pull requests. You can observe ownership through incidents and production changes.

The work is there. The question is whether hiring is willing to look at it.

The cost of “looking good” has collapsed

Something else changed along the way: the cost of presentation.

It is now extremely easy to make work look better than it was.

A résumé can be rewritten in minutes. A project can be reframed into stronger language. Weak contributions can be bundled into “ownership.” Strong but messy work can be cleaned up until it looks less significant than it actually was.

None of this is malicious. It is just the natural result of tools that make communication easier.

But it creates a subtle distortion: hiring systems often end up rewarding the quality of the story, not the quality of the work behind it.

And once that happens, the signal starts to drift.

People who are good at explaining their work outperform people who are good at doing the work. Clarity becomes confused with capability. Narrative becomes confused with evidence.

Titles stopped meaning what we think they mean

At some point, job titles became too broad to carry real meaning.

“Senior Engineer” can describe someone who owns a distributed system at scale—or someone who has never touched production infrastructure. “Tech Lead” can mean architectural authority—or coordination responsibility. “Backend Engineer” can span everything from API glue code to system design at scale.

The problem is not dishonesty. It is compression.

A title is a label applied after the fact, across very different contexts. It tells you where someone sat in an organization, not what they actually did inside it.

And when hiring leans too heavily on titles, it starts mistaking context for proof.

Interviews are not a replay of reality

The interview is often treated as the moment where everything becomes clear.

But in reality, it is a very small and very artificial slice of time.

A candidate is asked to reconstruct years of work in under an hour. They rely on memory, framing, and communication under pressure. The interviewer relies on interpretation, intuition, and comparison to other candidates they have seen.

What emerges is not a reconstruction of past engineering. It is a performance about past engineering.

And like any performance, it captures something real—but not everything that matters.

It shows how someone thinks out loud. It shows how they structure ideas. It shows how they handle ambiguity in the moment.

But it does not show the long arc of ownership, the accumulation of decisions, or the actual behavior of systems they worked on.

Hiring ends up redoing the same work repeatedly

When you look at a typical hiring process, something becomes obvious: the same questions are asked again and again, just in different forms.

A résumé is read. Then re-read. Then discussed. Then questioned in a screening call. Then revisited in a technical interview. Then reinterpreted in a final round.

Each step is trying to solve the same underlying problem: *what did this person actually do?*

But because the process starts without direct evidence, every stage is forced to reconstruct context from scratch.

Time is spent not on evaluating depth, but on rebuilding history.

The real issue: interpretation comes too early

Most hiring systems follow a quiet but powerful sequence:

first the résumé, then the interpretation, then the interview, then the decision.

The problem is not interpretation itself. The problem is when interpretation happens before evidence is fully understood.

Once a narrative forms early, everything that follows tends to reinforce it. Strong candidates get over-attributed. Weak signals get rationalized. Missing information gets filled in unconsciously.

The system becomes consistent—but not necessarily accurate.

A better sequence is simpler:

first evidence, then interpretation, then interview, then decision.

Not because humans should be removed from the process, but because humans should not be forced to guess before they have seen enough.

Proof is not about certainty. It is about grounding

When we say “proof” in this context, we are not talking about mathematical certainty or automated judgment.

We are talking about something more practical: decisions anchored in observable work rather than narrative alone.

Proof, here, simply means that claims about a candidate can be traced back to something real—something that exists outside of memory, language, or interpretation.

It does not eliminate judgment. It gives judgment something stable to stand on.

What 16signals actually changes

16signals is not trying to replace hiring decisions or score people into categories.

It is trying to change what those decisions are based on.

Instead of starting with a résumé and building a story around it, it starts with engineering artifacts and builds a structured view of what is actually visible.

It surfaces what is clearly demonstrated in the work. It highlights what is implied but not confirmed. It makes explicit what is missing entirely. And it turns those gaps into questions rather than assumptions.

The output is not a verdict. It is a map of evidence.

And importantly, that map is traceable. Every signal can be linked back to real work, not abstract interpretation.

How evidence changes the nature of interviews

The difference becomes obvious in practice.

Without evidence, interviews tend to stay broad. Candidates are asked to describe system design experience in general terms. They are asked how they think about scalability, or how they handle complexity. The conversation floats above the actual work.

With evidence, the conversation changes shape.

Instead of asking what someone *usually does*, you can ask why a specific system was redesigned. Instead of asking how they think about trade-offs in theory, you can ask what trade-off changed between two real versions of a system they worked on. Instead of asking about ownership in abstract terms, you can ask what they personally changed in a concrete refactor.

The interview stops being a search for context and becomes a validation of known work.

Evidence also limits overclaiming

One of the quiet failures of résumé-driven hiring is how easily language expands beyond reality.

People do not lie in most cases. They generalize. They compress. They describe impact in ways that sound larger than what is actually visible.

“Led architecture” can mean many things. “Built scalable systems” can mean almost anything. “Owned infrastructure” can range from deep responsibility to peripheral involvement.

Evidence forces those phrases back into shape.

It does not punish ambition. It simply asks: what can actually be seen?

And just as importantly, it allows for something often missing in hiring systems: the ability to say “we don’t know.”

Missing evidence is not a negative signal. It is a boundary condition. It means the system should not guess.

“Insufficient evidence” is not a failure state

In most systems, uncertainty is treated as something to eliminate.

But in hiring, uncertainty is unavoidable. The goal is not to pretend it does not exist. The goal is to handle it honestly.

If there is not enough signal to support a conclusion, the correct output is not a forced score or a hidden penalty. It is simply: insufficient evidence.

That is not avoidance. It is discipline.

It prevents weak signals from being inflated into false confidence. It prevents absence of data from being misread as absence of ability. And it keeps the responsibility where it belongs: in the interview, where clarification is possible.

Better input produces better interviews

When evidence is structured properly, interviews change in a very practical way.

They become less about discovery and more about validation.

Instead of spending time uncovering what someone might have done, you spend time understanding what they actually did. Instead of covering basics repeatedly, you focus on decisions, trade-offs, and ownership boundaries.

The interview becomes sharper, more specific, and more grounded in reality.

Not because it is more aggressive, but because it starts from a better place.

What proof does not replace

None of this removes the human side of hiring.

Communication still matters. Judgment still matters. Cultural alignment, adaptability, and real-time problem solving still matter.

What changes is not what is evaluated, but what it is based on.

Proof does not replace judgment. It removes the need for guesswork about the past so that judgment can focus on the present.

The final shift

Engineering already moved toward observability. Systems are expected to explain themselves through signals.

Hiring has not fully made that shift yet.

As a result, it still spends too much time reconstructing what could already be observed.

Proof is not about removing humans from hiring. It is about changing the order in which decisions are made.

Work first. Evidence first. Interpretation after.

Not to make hiring mechanical—but to make it honest.