Reference checks for technical hires that catch costly issues

Why coding rounds miss costly behavior

A candidate can solve a hard problem in 40 minutes and still create months of trouble after they join. Coding rounds show how someone thinks inside a narrow task. They do not show whether that person closes loose ends, asks for help early, or keeps promises when work gets messy.

Strong interview performance often hides weak follow-through. Some people do well because they know the format and have practiced it. On the job, the trouble shows up later. Tickets sit half-done. Handoffs break. Small issues keep coming back because nobody handled the boring parts.

Pressure is another blind spot. Most interviews are polite and controlled. The candidate talks to strangers for an hour, not to the designer who disagrees with them or the founder who changes scope late on a Friday. You rarely see how they react when a deadline slips, feedback feels unfair, or two priorities hit at once.

The costly patterns usually look small at first. Someone says "yes" too quickly, then misses dates. They switch focus and leave a trail of half-finished work. They defend weak decisions instead of raising risk early. They create friction with teammates, then blame everyone else. They write strong code but still need constant rescue on planning.

Founders pay for this after the hire, not during the interview. In a startup, one engineer with shaky ownership can pull a whole week off course. The team slows down, trust drops, and simple work starts taking twice as long because nobody knows what will actually get finished.

That is why reference checks matter for technical hires. A past teammate saw the real job, not the audition. Tests show skill. References show whether that skill turns into steady work, clear priorities, and sane behavior under pressure.

What you need to learn from a past teammate

A former teammate can tell you what the interview rarely shows: how the candidate behaves when the work gets messy. That is where startup hiring mistakes get expensive. Unclear tasks, shifting deadlines, and disagreement are normal. You need to know how this person acts inside that reality.

Start with ambiguity. Ask for a specific project where the goal was fuzzy, the spec changed, or nobody knew the right answer at the start. Listen for whether the candidate brought structure to the work. Strong people ask sharp questions, make a plan, and keep moving. Weaker ones wait for perfect direction or spend too long on the wrong thing.

Then ask who pushed work forward without reminders. Past teammates usually know this right away. The useful answers are concrete. They followed up on blockers instead of parking them. They kept others informed before anyone had to ask. They noticed when a dependency would slow the team down. They changed course when priorities shifted.

Deadlines tell you even more. Ask about a time a date slipped and what the candidate did next. You want to hear that they raised the risk early, narrowed scope, or offered options. If the story turns into blame toward product, design, management, or "the process," be careful. Good engineers miss estimates sometimes. Good teammates do not hide it until the last day.

Disagreement matters just as much as delivery. Ask what happened when the candidate strongly disagreed with a teammate or manager. Did they argue their point clearly, listen, and move on after a decision? Or did they get rigid, political, or quietly disengage? Calm disagreement is healthy. A trail of friction is not.

Specific stories beat broad praise. If someone says, "They were great," ask what they actually did when things got unclear, late, or tense. That is when a reference check becomes useful instead of polite.

When to ask for references and from whom

Ask for references late enough that the conversation means something, but not so late that you have already decided. The best moment is when both sides show real interest. You think the person could do the job, and the candidate wants the role enough to invest a little more time.

If you ask too early, strong candidates may feel you are digging into their background before you have earned it. You also waste time on people who may never reach the offer stage. For most founders, the best time is after the final interview and before the offer.

Who you ask matters more than how many people you call. Two solid references usually tell you more than four weak ones. Start with one former manager who can speak about ownership, follow-through, and judgment, and one former peer who worked beside them day to day.

That mix gives you two angles. A manager sees how the candidate handled goals, deadlines, and feedback. A peer sees what happened in the real work: who picked up messy problems, who created tension, and who helped the team move.

Pick people who worked closely with the candidate and did so recently. A teammate from the last one or two roles is usually better than someone senior from five years ago who only remembers the broad outline. Fresh examples are harder to fake and easier to compare with the role you need to fill now.

Skip references who mainly know the candidate socially. A former classmate, friend, or conference contact may like them a lot and still tell you almost nothing about how they act under pressure. You are not checking whether the person is pleasant over coffee. You are checking how they behave when priorities clash, code breaks, and nobody agrees.

If a candidate hesitates because their current employer does not know they are interviewing, that is normal. Ask for past managers or past peers instead. A reasonable candidate should still be able to name people who saw their work up close.

How to run the call step by step

Keep the call to 15 to 20 minutes. That is usually enough to learn how this person works with other people, handles pressure, and makes decisions.

Start with plain context. Tell the reference what role you are hiring for, what stage your company is in, and what work needs to get done in the next few months. A backend lead for a messy product team is different from a first engineer at a startup, and the reference will answer better if they understand the real job.

Set the tone early. Tell them you do not need praise and you are not looking for gossip. You want honest examples from real work so you can make a fair decision. A simple line works well: "I am trying to understand how this person works day to day. Specific examples help more than general praise."

Then move through the call in a steady order:

1. Ask how the reference worked with the candidate and for how long.
2. Ask what the candidate owned directly, not what the team owned.
3. Ask about one stressful project, one disagreement, and one trade-off they had to make.
4. Ask what the candidate did when priorities changed or deadlines slipped.
5. End with whether they would hire this person again for a similar role.

Keep your questions short. Ask one thing, then stop talking. If you stack three questions at once, most people answer the safest one and skip the part you actually needed.

Silence helps. After a short question, pause for a few seconds and let them think. People often give the most useful detail after the first answer, once they move past the polished version.

Write down exact phrases, especially around ownership and conflict. "Needed a lot of follow-up" means something different from "pushed back clearly and was usually right."

Close with one direct question: "If you had an open role tomorrow, would you hire this person again?" Then ask why. The yes or no matters less than how fast they answer and what example they choose.

Questions that reveal ownership, conflict, and priorities

A good reference call should get past "smart engineer" and into daily behavior. The most useful questions ask for specific moments, not broad praise.

If a past teammate pauses, thinks, and gives a real story, that usually means they worked closely enough to help you. If they stay vague, that tells you something too.

Ask for stories, not ratings

Numbers are easy to fake. Stories are harder.

Try questions like these:

• "What did they fully own that started messy and ended well?"
• "Tell me about a time you disagreed with them. What was the issue, and what did they do next?"
• "What kind of work did they push back on, and was that pushback fair?"
• "When two urgent tasks hit at once, how did they decide what to do first?"
• "Where did they need the most help from the team or manager?"

Each question checks a different risk. Ownership tells you whether they can carry work without constant follow-up. Conflict shows whether they stay calm, get rigid, or hide problems. Pushback tells you if they protect good priorities or just avoid unpleasant work.

The collision question matters more than many founders think. Most startup jobs are not hard because people lack skill. They get hard when deadlines clash, context changes, and nobody has enough time. You want to hear how the candidate chose, who they informed, and what trade-off they accepted.

Listen for the shape of the answer

Strong answers include details: what the task was, who disagreed, what changed, and what happened in the end. Weak answers stay at the level of personality. "Great communicator" means very little if the reference cannot describe one tense meeting or one missed deadline.

Pay attention when you ask where the candidate needed support. Everyone needs support somewhere. A useful reference will tell you whether that support was normal, like help with company context, or expensive, like needing constant pressure to finish.

One last test works well: "Would you hire them again for the same kind of role? Why, and under what manager?" The second sentence often gives you the truth. You may hear that the person did very well with clear goals but struggled when nobody set priorities. That is not always a rejection. It is a fit note, and fit notes save a lot of pain later.

How to read vague answers and mixed signals

A reference who knows the person well usually gives concrete moments. They remember a deadline that slipped, a disagreement about scope, or a time the candidate took charge without being asked. When someone stays vague, pay attention. "Smart engineer" or "good to work with" may sound positive, but those phrases tell you almost nothing unless the person adds details.

Tone matters as much as the words. Some people say polite things in a flat voice because they do not want to hurt the candidate. Others sound warm, then pause before every answer about ownership or teamwork. That gap matters. If the words sound fine but the energy feels careful, slow down and ask for an example.

One phrase deserves an immediate follow-up: "Great engineer, but..." Do not rush past the "but" because you like the first half. The second half often holds the expensive part of the hire. Ask what happened, who felt the impact, and whether the issue improved over time.

A few signals should make you ask another question:

• praise with no story behind it
• a long pause before simple questions
• soft wording like "can be direct" or "likes autonomy" when you asked about conflict
• repeated praise for coding, followed by silence on planning, communication, or priorities

Mixed signals are normal. One former teammate may call the candidate independent, while another says they needed a lot of direction. Write both down, then look for the pattern underneath. Maybe the person works well in clear systems but struggles in a messy startup. Maybe they do strong individual work but avoid trade-offs that affect the team.

Patterns across calls matter more than any single quote. If two or three people describe the same issue with different words, believe the pattern. "Missed handoffs," "kept work in their head," and "updates came late" all point to the same problem.

Reference checks are not about finding a perfect person. They help you spot behavior that will cost time, trust, or focus after the offer. If you hear a soft warning twice, treat it as real and decide whether your team can absorb it.

A simple startup example

A founder at a small SaaS company needs a first senior engineer. The candidate does great in the take-home test. The code is clean, the notes are clear, and the founder starts picturing this person leading projects within a month.

That is the risky moment. A polished exercise can show skill, but it does not show how someone acts when plans change, people disagree, or work gets messy.

Before sending the offer, the founder calls two references. One is a former peer who worked closely with the candidate on a product team. She says the candidate was smart and fast, but often kept building the original plan after product feedback changed the goal. The problem was not effort. It was judgment. The team had to pull work back more than once because the candidate treated feedback like noise instead of part of the job.

The second call is with a former manager. He says the candidate rarely made big mistakes, but escalated every small blocker. If a spec felt unclear, if another team answered slowly, or if a task had two possible paths, he asked for direction right away. In a larger company, that was manageable. In a startup, it can drain a founder's time fast.

Now the picture is different. The founder is no longer hiring a strong test performer. The founder is hiring someone who may need a lot of steering and may struggle when product priorities shift midweek.

That does not always mean "reject." It means the role has to match the behavior. If the company needs an owner who can sort through ambiguity, push back well, and keep moving, this is probably a bad hire. If the company instead needs a careful implementer with narrow scope and close product support, the candidate might still fit.

In this case, the founder passes on the original role and keeps looking. That decision stings for a day. A wrong hire would hurt for six months.

This is why references work best after a candidate impresses you. They do not confirm coding skill. They reveal the work habits that usually cost the most.

Mistakes that waste the reference call

A reference call stops being useful when you already made the hire in your head. Then it becomes a formality, not a decision tool. In a startup, that is expensive because bad habits around ownership or prioritization usually show up after the person joins, not during a coding round.

Run references while you can still change the plan, not after the team has celebrated the choice. If a reference says, "They were smart, but I had to chase them every week," you need room to act on that.

Another common mistake is accepting only hand-picked cheerleaders. Most candidates will send people who like them, and that is normal. You still need a wider view. One former manager, one peer, and one person they worked with outside engineering can tell you far more than three friendly endorsements.

The questions often fail too. "Were they good?" gets you a polite answer and almost nothing else. Ask for a specific moment instead. What happened when priorities changed? How did they handle a disagreement? What did they do when nobody told them the next step?

Founders also ruin the call by leading the reference toward the answer they want. If you ask, "They were pretty strong on ownership, right?" many people will agree just to keep things smooth. A better question is, "How much follow-up did they need on important work?" That pushes the person to describe behavior, not hand out praise.

A short silence helps here too. Ask the question, then wait. People often give the safe answer first and the useful answer second.

A simple example: a founder loves a backend candidate after a strong technical interview and asks two references, "Would you hire them again?" Both say yes. Later, the founder learns the candidate avoided messy work and pushed back on shifting priorities. A better call would have surfaced that early, before the offer went out.

Quick checks before you make the offer

Pause and compare your notes before you send the offer. A good reference call is not about collecting nice comments. It is about spotting behavior that will show up when deadlines slip, priorities change, and nobody agrees.

Do not decide from one polished story. Look for patterns across at least two people. If both references describe the candidate as calm under pressure, or both say they avoid hard conversations, that pattern matters more than any single glowing quote.

A short checklist helps:

• Two references should point to the same behavior, not two unrelated impressions.
• At least one person should give a specific example of ownership.
• Someone should describe how the candidate handles disagreement without making the team tense.
• You should hear that they can sort urgent work from noisy work.
• You should feel comfortable putting them into a chaotic week with real consequences.

Ownership is where weak candidates often get exposed. Nice people can still be slippery when work gets messy. You want one story where the person noticed a problem, made a call, kept others informed, and stayed with the issue until it was done. If nobody can name a real example, that is a warning.

Conflict matters for the same reason. Teams do not need someone who agrees with everyone. They need someone who can disagree, explain their view, and keep working with the group after the argument ends. If a reference says, "They were great, never had conflict," push a little. Real teams always have friction.

Prioritization is the last fast check. Ask yourself whether the references described a person who can handle urgent work without panic, blame, or constant escalation. In a startup, this shows up every week.

The final test is simple: would you trust this person in a messy week when a customer is upset, the roadmap changes, and nobody has full context? If the answer is not a clear yes, slow down and learn more before you hire.

What to do next with what you learn

A reference call only helps if you turn it into a hiring decision. Match every note to the real job, not to a general idea of a "strong engineer." A candidate might be excellent in a large team with clear structure, but this role may need someone who can make trade-offs fast, write clearly, and push work forward with little supervision.

Put your notes into three buckets: clear strengths, open concerns, and context. Context matters more than many founders expect. If a past teammate says someone struggled with priorities, ask what kind of environment they were in. A person who looked slow in a chaotic startup may do very well in a team with a tighter roadmap.

Do not treat unclear feedback as a silent rejection. Bring open concerns back to the candidate and ask directly. You are looking for how they explain the situation, what they learned, and whether their version matches the reference in a believable way. This step often tells you more than the original call.

If you still want to hire, reduce risk in the first 30 to 60 days. Change the start, not just the offer.

• Give the person a narrower first scope with one owner and one clear outcome.
• Set weekly check-ins around priorities, blockers, and decision quality.
• Write down what good ownership looks like for this role.
• Pick one project that shows how they handle conflict, trade-offs, and follow-through.

That is when a reference check stops being ceremonial and starts paying off. You are not trying to find a perfect person. You are trying to see where support, structure, or limits will help them do good work.

If the same issues keep showing up across hires, the problem may be your process. A simple scorecard, a standard reference script, and a short first-month plan can save a lot of money. If you want help tightening that process without adding much overhead, a Fractional CTO like Oleg Sotnikov at oleg.is can help make it fit a startup team.