Reference Check Questions That Surface Engineering Performance

A standard reference call confirms that someone worked somewhere, for some length of time, in some role. It does not tell a hiring manager what that person actually built, owned, or carried across the finish line. Most reference conversations produce vague praise because the questions invite vague praise: ask "How was it working with this person?" and you get a social answer, not a performance answer.

That weakness matters more in engineering than almost anywhere else in a company. The 2025 DORA report documents that elite performing teams deploy code far more frequently than low performers, with lead times measured in under an hour, compared to months for the weakest teams. A single engineer hired into the wrong role, or hired without the judgment the job actually requires, can pull a team toward that slower end of the spectrum. The consequences of a mis-hire in engineering dwarf the consequences of a mis-hire in most other functions, because the output gap between a strong engineer and a weak one is not a modest percentage but closer to an order of magnitude.

At the same time, the credentials a hiring manager is supposed to trust have gotten easier to fake. A 2025 Checkr survey of U.S. managers found that nearly one in three had personally interviewed a candidate who turned out to be using a fake identity, and a majority suspected AI-generated misrepresentation of qualifications somewhere in their hiring pipeline. A credential-confirming reference call leaves a hiring manager exposed on both sides: false positives, where polished candidates who shipped very little slip through, and false negatives, where quiet contributors who interview poorly but produce elite work get passed over. Human-verified references, done right, are one of the few checks left that can catch both.

What a reference call reveals beyond interviews and resumes

A resume reports outputs. An interview reveals communication skill and how well someone prepared for that specific hour. A reference call is the only stage in the process where a third party who actually managed the candidate's day-to-day work gives a live, reactive account of what that work looked like.

That distinction changes what questions should even be asked, because a reference can describe behavioral patterns no resume captures: how the candidate handled conflict, whether their stated accomplishments reflect genuine contribution or proximity to someone else's work, whether the former manager would stake their own reputation on hiring them again. For engineering roles specifically, a reference call can reach evidence no structured interview reliably reaches: how a candidate approached code review beyond asking "does it run," whether they raised the output of the people around them, how they held up when a deadline collapsed.

Reference check guidance from one widely used vendor framework frames the core objectives this way: verify the accuracy of what a candidate claims, assess actual job performance and competence, understand behavioral traits, identify strengths and development areas, and evaluate team and cultural fit. Those are five distinct categories of information, and none of them come from a resume or a 45-minute interview loop. A reference call is a different instrument built to extract different evidence. Built for a generic office job rather than an engineering one, the wrong questions keep that evidence from surfacing. The instrument works. The questions usually don't.

The one question that predicts more than any other

If a hiring manager has time for exactly one question, it should be this: would you rehire this person? Anything short of an immediate, unqualified yes deserves a follow-up, because the gap between "yes" and "yes, probably" is where the real signal lives.

U.S. U.S. Office of Personnel Management guidance states that reference checks as a method predict job performance better than years of education or years of experience, and that this rehire question is the single most predictive question within a reference check. That is a strong claim, and it earns its strength by shifting the reference from describing the candidate to making a personal commitment. Describing someone costs nothing. Predicting whether you'd want to work with them again, and saying so out loud, costs something.

The value sits less in what gets said and more in how it gets said. Listen for the pause before the answer. Listen for the hedge: "yes, for the right role," "probably," "in a different structure." Each of those is a soft no dressed up as a yes; a direct question about performance competence would rarely reveal it, because competence questions invite rehearsed answers. A commitment question invites an honest one. Ask whether there is a type of environment where this person would not thrive. That question lets a reference be honest about fit without asking them to criticize the candidate directly, which most references are reluctant to do. Both questions are diagnostic tools, not scripts to recite. The discipline is in reading the response, not just collecting it.

Questions that separate genuine contribution from proximity to someone else's output

Engineering resumes have a structural problem: they report team accomplishments as if they were individual ones. A candidate can legitimately write that they "shipped" a product they had only marginal involvement in, and nothing on the resume will contradict that. The most common failure mode in an engineering reference check is accepting that framing at face value.

The fix starts with a different question. Instead of "how was it managing this person," the question to ask is: can you give two examples of how this person accomplished their main priorities? That phrasing forces the reference to describe actual job performance. From there, push further: which parts of that project would not have happened, or would have happened differently, without this person specifically? Who else was central to that work, and how did their contribution compare? A complementary question moves from narrative to evidence entirely: can you give a specific metric that improved as a direct result of this person's work? An inability to answer that question is itself informative.

This is the exact problem that systems built around evidence of actual work, rather than titles or brand-name employers, are designed to solve. Lantern's hiring approach treats resume claims as hypotheses to test rather than facts to accept, and reference questions that drill into ownership and decision-making are the mechanism that tests them. The goal in every one of these questions is the same: reconstruct where the candidate's hands actually were on the project, not where their name appeared in the project's retrospective.

Questions that reveal how an engineer performs under pressure and at the edges of their competence

How an engineer behaves on a normal Tuesday tells a hiring manager very little. How they behave when a system is failing at 2 a.m., when a deadline is collapsing, or when a technical decision is genuinely contested, tells a hiring manager almost everything.

Ask the reference to describe a time a project this person was leading went sideways; find out what they actually did about it. Ask how they handled it when they disagreed with a technical direction the team had chosen. For a clearer read on seniority, ask whether this person ever pushed back on a requirement or a deadline they believed was wrong, and what happened as a result. A strong engineer usually has a track record of productive disagreement somewhere in their history. The absence of any example at all, when asked directly, is a flag.

Ask how they responded when their code or design was criticized in review. That answer reveals whether a candidate treats review as a way to learn or as a threat to defend against, and those are two very different engineers to manage. One more question rounds this category out: what is the hardest technical problem this person ever brought to you for help? That answer reveals both the ceiling of their independent capability and whether they know how to ask for help productively, which is its own distinct skill.

Questions that test code quality standards and engineering craft, not just delivery

Delivery is the baseline every engineer is expected to clear. What separates strong engineers from average ones is what they treat as the standard above delivery, a standard most reference checks never ask about.

Ask how this person approached code review: what did they look for beyond whether the code worked? A strong answer touches readability, maintainability, security, performance, and test coverage. A weak answer stops at functional correctness and goes no further. Ask whether this person ever refactored code they weren't required to touch, and why. That question surfaces whether someone treats the codebase as a shared resource worth improving or purely as a vehicle for their own output.

One of the sharpest questions in this category is also one of the least asked: how did their code hold up six months after they wrote it? Did it need significant rework? That is a lagging indicator only a reference who stayed on the codebase after the candidate left can answer, and it tells you something interviews structurally cannot: whether the code was built to last or built to pass review. Close with a question about artifacts: did they leave documentation, tests, or runbooks that the team actually used? Operational artifacts are a proxy for whether someone thought past their own tenure on the project.

Questions that surface whether a candidate raises the team around them

An engineer who delivers strong individual output while suppressing collaboration, absorbing credit, or creating dependencies becomes a net negative at sufficient seniority, even if their own commits look excellent. The opposite pattern, the quiet multiplier who makes everyone around them better without ever putting that fact on their own resume, is one of the most systematically undercredited profiles in hiring.

One underused question reveals this directly: has this person ever taught you something? Have you learned anything new from working with them, and if so, what? That question gets at intellectual generosity and knowledge distribution, properties of engineers who raise team output in addition to their own. Ask whether junior engineers on the team got better at their jobs because of working with this person, and how. A specific, named example is a strong signal. A vague "they were always helpful" is not, and that contrast is usually obvious the moment the reference starts talking.

Ask what the team lost when this person left or moved to a different team. That question inverts the usual framing and forces the reference to describe the dependency this person created, which reveals both their impact and whether that impact was built to last past their presence. Ask directly whether this person made it easier or harder for others to do their work. References answer that one honestly, because it does not ask them to criticize the candidate directly, just to describe an effect.

This is exactly the category of candidate that keyword-matching and credential-pattern tools tend to miss, because multipliers rarely write "raised team velocity" on a resume. A reference check, run with the right questions, is one of the few mechanisms left that catches this contributor before the job goes to someone louder and less effective.

Calibrating the reference's rating scale before it tells you anything

Before diving into substantive questions, establish the reference's frame. Ask how many engineers they've directly managed or worked closely with over their career. Ask, among that group, where this candidate ranks. That single pair of questions converts a vague superlative into a relative position, which is the only form a superlative is actually useful in. Calibration also means asking about the reference's own context: team size, deployment velocity, the technical complexity of the work. "They shipped a lot" means something very different on a three-person team shipping small features than on a thirty-person team shipping distributed systems.

The same calibration problem appears across an entire hiring loop, not just within a single reference call. One interviewer on a panel might default to "excellent" for anyone who didn't cause an obvious problem; another might reserve "excellent" for the rare candidate who genuinely changed how they thought about the role. Without a shared rubric across the loop, the same reference call, repeated to three different people, produces three different hiring signals. Calibration is the step that makes every answer gathered above actually mean something consistent.

Timing the reference check so it informs the decision

A reference check conducted after a hiring manager has already fallen for a candidate stops functioning as a performance audit. It turns into a ratification ritual, a box checked on the way to a decision that was already made. Every question in this piece only does its job if the call happens while the decision is still genuinely open.

The industry standard timing is post-conditional-offer and pre-start-date, and that sequence balances a few things at once. Pin's 2026 reference check best practices note that checking references after an offer reduces discrimination risk, improves efficiency by focusing the check on a candidate who has already cleared every other stage, and increases candidate cooperation, since references are more willing to speak once an offer is already on the table. For executive or senior engineering roles, where the stakes of a mis-hire climb even higher, running preliminary checks during the final interview round is a reasonable option given how much is riding on the outcome.

A reference check should never be the last box checked after every other decision has effectively been made. It belongs inside the final evaluation loop, feeding the decision. Strong candidates are almost always weighing competing offers at the same time, and a reference process that drags on past the final round while a candidate waits sends its own signal about how the company makes decisions, one that does not favor the company. Standardizing the question set, the same questions across every reference for one candidate and across every candidate for a given role, turns these calls into something comparable.

None of that structure requires turning the reference call itself into something templated and lifeless. The call is a genuinely valuable human moment, a former manager speaking candidly about someone they worked with, and it deserves a real conversation, not a script read verbatim. What deserves the rigor is everything around it: scheduling it at the right moment, synthesizing notes consistently, checking what one reference says against what another says about the same candidate. Handling that logistics layer well is what lets the human part of the call, the judgment, the listening for a hedge, the follow-up question that wasn't planned, stay entirely in human hands. The questions matter. The discipline of asking them at the right time, to the right person, against a calibrated scale, is what makes them mean something.