The Reference Check Framework for Engineering Talent

What you actually need to know

• Reference checks are skipped because they feel awkward. That awkwardness is protecting bad hires, not good ones.
• The goal is not to confirm what you already believe. It is to surface the constraint, the working style problem, or the communication gap that the interview did not show you.
• A reference who knows they are being recorded or quoted will say almost nothing useful. A reference in a casual fifteen minute call with three specific questions will often say everything you need.
• The question that surfaces real information is always the third one. The one that asks what kind of project you would not put this person on.
• Every good candidate should be able to give you two references who will speak specifically and positively about their work. A developer who hedges on references has a reason.

The core argument

Most reference checks go like this. You call the number. You ask if the person was a good employee. They say yes. You ask if they would recommend them. They say yes. You thank them and hang up. You have learned nothing you did not already know. The check becomes a box, the box gets ticked, and the hire goes forward on the basis of the interview alone.

The interview alone is not enough. Interviews are optimized for performance. The candidate is prepared, motivated, and showing you the best version of how they think. References are not performing. They are describing a working relationship from memory. The gap between those two data sources is where the real information lives.

The reason most reference checks yield nothing is that the questions are designed to be answered easily with a yes. "Was she a good team member?" Yes. "Would you work with him again?" Yes. Those questions are unanswerable with a no without causing social damage to the reference. So the answer is always yes. The question design is the problem.

The fix is to ask questions that have a real answer even in the positive case. "What kind of project would you not put them on?" is answerable honestly without being unkind. A reference who says "I would not put them on a project with ambiguous requirements because they need a clear spec to do their best work" has just told you something specific and useful. That answer protects you and does not defame the candidate. Those are the questions that work.

The three question framework

Question one. Would you hire this person again, and into what kind of role? The key word is "and." A reference who says "yes, I would hire them again as a senior backend engineer for a well defined greenfield build" has given you a qualified yes with real shape to it. A reference who says "yes, absolutely" and stops there is answering the social version of the question. Push for the second clause.

Question two. What would you want to know before working with them that you wish you had known at the start? This is not a gotcha question. It is a question every person can answer honestly about anyone they have worked with closely. The answer reveals the reference's real experience of the working relationship. A developer who took two weeks to get up to speed but then was exceptional. A developer who needed more context than they asked for before starting work. A developer who was brilliant individually but struggled in pair programming sessions. All of that is useful data.

Question three. What kind of project would you not put them on? This question does more work than the other two combined. It is impossible to answer with empty praise. A thoughtful reference will think for a moment and give you something real. And that real thing is exactly the constraint you need to evaluate before making the hire.

How to set up the call

Keep it to fifteen minutes. Tell the reference at the start that you are going to ask three questions and that their honest answers are more useful than polished ones. Most people relax when they hear that. Tell them you are not recording the call and that feedback is for your decision making, not the candidate's file. Then ask the questions in order, with enough silence after each one to let the answer develop naturally.

The pause matters. Most references will give a first answer and then, in the silence, add the thing they were editing in their head. The edited addition is almost always the most useful part.

What it requires

The total time investment for two references is about ninety minutes. That is the cost of the best information you will have before making a hire that will cost you tens of thousands of dollars to undo if it goes wrong.

What to look for in the reference call

• Specificity. Vague positivity is a social response. Specific details about projects, challenges, and working style are real information.
• Qualified enthusiasm. A reference who says "they are exceptional for X kind of work" is giving you more than one who says "they are exceptional."
• Unsolicited context. References who add context you did not ask for are often telling you the thing they most wanted you to know.
• Hesitation on the third question. A pause before "what kind of project would you not put them on" usually means the answer is forming honestly. Let it form.
• Consistency across references. If two out of three references mention the same strength or the same constraint, you have a real pattern.

Expert opinion

The reference checks that have changed my mind about a hire were never the ones that gave bad reviews. They were the ones that gave such specific, qualified positive reviews that I understood exactly what I was getting. A reference who tells me the developer is exceptional at owning a system independently but needs to be pulled into conversations rather than proactively joining them has just given me a working manual. That is worth more than any technical interview.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A founder I work with was close to making a senior hire for a critical infrastructure role. The technical interview was strong. The two trial days were clean. But one of the references, when asked the third question, said something that stopped the call. "I would not put them on a project where the deployment process is manual and requires coordination with other teams. They are excellent when they own the system end to end. When they need someone else to merge or deploy, they get frustrated and that frustration shows."

The role in question involved exactly that kind of coordination. The deployment pipeline required sign off from the infrastructure team. The founder would never have known that constraint from the interview. The reference gave it in sixty seconds.

We restructured the role to give the developer more end to end ownership and reduced the cross team dependency. The hire worked out. But the insight came from the reference check, not from anything else in the process. The vetting framework post covers the full evaluation structure that this reference check fits into, and the three strikes rule for developer relationships covers what to do when the working relationship reveals what the references predicted.

Common mistakes in reference checks

1. Asking only yes or no questions. They produce yes answers every time.
2. Calling references after the offer is made. At that point you are not using the information, you are collecting it for the file.
3. Only collecting references the candidate recommends without probing for a peer reference. Managers and peers see different versions of the same person.
4. Treating one qualified answer as a pattern. One reference who mentions a constraint is a data point. Two who mention the same constraint is a pattern.
5. Not following up with the candidate on concerns that came up. If a reference flagged something real, the candidate deserves a chance to address it.
6. Skipping the call entirely because you liked the interview. Interview performance and reference quality are measuring different things.
7. Taking backdoor references at face value without context. An informal opinion from someone who left the company on bad terms is not the same as one from someone who left well.
8. Assuming international references are less valuable. A former manager in a different country has the same information about how someone works as one down the street.

A 30 day hiring plan

1. Week one. Build the reference collection into your hiring process as a mandatory step before any offer. Not a checkbox. A real call with the three questions.
2. Week two. Ask candidates to provide one manager reference and one peer reference. Not a list of five. Two good ones.
3. Week three. Conduct calls for your current finalist candidates. Take notes. Listen for the pause before the third answer.
4. Week four. Synthesize across references and across candidates. The pattern across two references is more reliable than any single answer.

For the broader evaluation structure this framework sits inside, the 10 questions every non technical founder must ask before hiring a developer covers the interview side. For evaluating public work before you even schedule the first call, the project done in public signal covers the filter that comes earlier in the funnel.