The candidate had aced every technical interview. Her algorithm solutions were elegant. Her system design demonstrated deep understanding of distributed systems. Her code was clean and well-documented. Everyone on the technical interview loop gave strong-hire recommendations.
Three months after she started, she was on a performance improvement plan.
"She's brilliant technically," her manager told me, "but she can't work with anyone. She dismisses feedback as coming from people who don't understand the problem as well as she does. She argues with product managers about requirements instead of finding solutions. Her teammates have started routing questions to other engineers because she makes them feel stupid for asking."
The hiring team had assessed what she could do. They had failed to assess how she would do it. Technical skill is necessary for engineering success, but it's not sufficient. The behavioral interview is where you assess the skills that actually predict long-term success: communication, collaboration, conflict resolution, growth mindset, and judgment.
Most companies do behavioral interviews poorly—generic questions, superficial answers, no clear evaluation criteria. At SmithSpektrum, after advising over 100 companies on interview design, I've learned that the behavioral interview, done well, provides signal that technical interviews miss entirely[^1].
Why Behavioral Interviews Matter
Technical interviews test what candidates know and what they can do. Behavioral interviews test who candidates are and how they work. Both matter, but in different ways.
Technical knowledge is relatively visible. You can see it in their code, in their design discussions, in their answers to technical questions. You can assess it directly. If they can't code, you'll find out in the coding interview.
Behavioral patterns are hidden until you ask. You won't discover that a candidate handles disagreement poorly by watching them code. You won't see that they blame others for failures by asking about system design. You won't learn that they struggle with ambiguity by discussing algorithms. These patterns emerge through careful questioning about past behavior.
The research on interviewing supports this distinction. Unstructured interviews—casual conversations with no consistent questions—have weak predictive validity. Technical assessments have moderate validity for technical performance. Structured behavioral interviews, where every candidate answers the same questions and answers are evaluated against consistent criteria, have strong validity for job success.
The best signal comes from combining technical and behavioral assessment. A strong technical candidate with weak behavioral signals is a hiring risk. A strong behavioral candidate with technical gaps might be worth developing. The combination tells you what they can do and whether they'll do it effectively on your team.
The Fundamental Question
Every behavioral interview question is a variant of the same fundamental question: "Tell me about a time when..." You want specific past behavior, not hypothetical future behavior. What someone did reveals more than what they say they would do.
"What would you do if a teammate disagreed with your technical approach?" invites an aspirational answer—what they think they should do, what sounds good, what they imagine an ideal engineer would do.
| Behavior Category | Strong Signal Question | What to Listen For | Red Flag Response |
|---|---|---|---|
| Collaboration | "Tell me about working with a difficult colleague" | Empathy, problem-solving | Blame without self-reflection |
| Ownership | "Describe a project that failed" | Accountability, learning | No failures or all external blame |
| Growth | "What skill are you actively developing?" | Self-awareness, initiative | Nothing specific or genuine |
| Conflict | "When did you disagree with a decision?" | Constructive disagreement | Never disagrees or always right |
| Impact | "What's your biggest achievement?" | Scale, clarity on contribution | Vague or team credit taken personally |
"Tell me about a time when a teammate disagreed with your technical approach" demands a real story from their past. They can't fabricate details on the fly. The specific choices they made reveal their actual patterns.
This distinction matters because past behavior predicts future behavior far better than stated intentions. The engineer who says "I believe in seeking feedback" but whose stories never include actually seeking feedback is telling you something important. The candidate who describes handling conflict poorly but "learning from it" might have learned—or might repeat the pattern at your company.
Listen for the STAR elements in their answers: Situation (the context), Task (what they needed to do), Action (what they specifically did), Result (what happened). Complete answers include all four. Incomplete answers often skip the Action—they describe what the team did without clarifying their individual contribution—or skip the Result, ending the story without explaining what happened.
Questions That Reveal Collaboration
Collaboration is essential because engineering is a team sport. Even the most brilliant individual contributor works with others—other engineers, product managers, designers, stakeholders. Candidates who can't collaborate effectively create drag on the entire team.
"Tell me about a project where you had to work closely with people outside engineering—product managers, designers, stakeholders. How did you approach that collaboration?"
Strong answers show genuine respect for non-engineering perspectives. The candidate describes seeking to understand what product managers need, working through disagreements constructively, and finding solutions that work for everyone. They talk about communication adjustments—presenting technical constraints in business terms, understanding the pressures other roles face.
Weak answers show engineering superiority. The candidate describes educating non-technical people, pushing back against requirements, or doing what engineering thought was best despite objections. They position themselves as the expert surrounded by people who don't understand.
"Describe a time you had to rely on someone who wasn't delivering what you needed. How did you handle it?"
This question reveals how candidates navigate interpersonal difficulty. Strong answers show empathy and problem-solving: they sought to understand why the other person was struggling, offered to help, escalated appropriately when needed, and focused on the problem rather than blame. Weak answers show blame and frustration: the other person was incompetent, nobody would listen to the candidate's complaints, they had to do the work themselves.
"Tell me about a time you helped a struggling teammate."
Engineering teams need members who lift each other up. Strong answers describe genuine investment in others' growth: spending time to understand the person's challenges, providing meaningful help, celebrating their improvement. Weak answers describe minimal effort ("I answered their questions when they asked") or frame helping as a burden that cost the candidate productivity.
Questions That Reveal Conflict Handling
Conflict is inevitable in engineering work. Technical disagreements, resource competition, personality clashes, stakeholder pressure—every team experiences friction. What matters is how people handle it.
"Tell me about a time you disagreed with a technical decision your team made. How did you handle it?"
This question reveals whether candidates can disagree constructively and commit after decisions are made. Strong answers show the candidate presenting their perspective clearly, listening to counterarguments, and ultimately supporting the team's decision even if they disagreed. They might mention what they learned from having their view changed, or how they committed to making the chosen approach successful.
Red flags include: refusing to let go of disagreement after a decision was made, undermining the decision through behavior, framing the story as the team being wrong and the candidate being vindicated later. These patterns indicate someone who won't be a good team player when they don't get their way.
"Describe a conflict with a coworker and how you resolved it."
Every engineer has had interpersonal conflict. What matters is how they navigated it. Strong answers show emotional intelligence: recognizing their own contribution to the conflict, seeking to understand the other person's perspective, finding resolution through direct conversation. Weak answers externalize blame entirely: the other person was the problem, the candidate was blameless, there was no resolution because the other person wouldn't change.
"Tell me about a time you received feedback you disagreed with."
This probes receptivity to criticism. Strong answers show the candidate genuinely considering the feedback, even when their initial reaction was defensive. Maybe they came to agree with it; maybe they didn't. But they engaged with it thoughtfully rather than dismissing it. Weak answers show dismissal: the feedback was wrong, the giver didn't understand, the candidate ignored it because they knew better.
Questions That Reveal How They Handle Failure
Failure is inevitable in engineering. Systems break. Projects miss deadlines. Decisions turn out to be wrong. The question isn't whether candidates have failed—it's whether they learn from failure and take appropriate ownership.
"Tell me about a project that didn't go as planned. What happened and what did you learn?"
Strong answers show honest reflection on what went wrong and why, including the candidate's own contribution to the problems. They describe specific lessons learned and how they've applied those lessons since. The failure isn't portrayed as entirely external; the candidate takes ownership where appropriate.
Weak answers externalize blame entirely: the timeline was unrealistic, the requirements changed, other people didn't deliver. The candidate positions themselves as a victim of circumstances rather than a contributor to outcomes. They don't describe genuine learning because they don't believe they did anything wrong.
"Describe a mistake that affected your team or customers. How did you handle it?"
This question specifically asks for a mistake they made, not a project that failed. Candidates who can't think of a mistake they've made are either lying or lack self-awareness. Strong answers describe taking responsibility for the mistake, communicating appropriately, fixing the immediate problem, and implementing changes to prevent recurrence. They're not defensive; they're reflective.
Questions That Reveal Judgment Under Ambiguity
Engineering work is often ambiguous. Requirements are unclear. Trade-offs are uncertain. Multiple approaches seem viable. The ability to make good decisions without complete information is essential.
"Describe a time you had to make a decision without complete information. How did you approach it?"
Strong answers show a deliberate decision-making process: identifying what information was most important, gathering what they could, making a reasonable decision under uncertainty, and monitoring to adjust if needed. They're comfortable with uncertainty and have methods for navigating it.
Weak answers show either paralysis (couldn't make a decision, waited indefinitely for more information) or recklessness (made decisions without thinking, got lucky or didn't). Both patterns indicate poor judgment under ambiguity.
"Tell me about a project where requirements changed significantly. How did you handle the changes?"
Every engineer has experienced shifting requirements. Strong answers show adaptability: understanding why requirements changed, adjusting approach accordingly, communicating impact clearly. They don't take changes personally or complain about stakeholders who changed their minds. Weak answers show rigidity or resentment: requirements shouldn't change, stakeholders don't know what they want, the project would have succeeded if only people hadn't kept changing things.
Running the Interview Well
The quality of behavioral interview signal depends on how you run the interview. The same questions yield different insight depending on how you probe and evaluate.
Take notes throughout. You'll need specifics when you evaluate the candidate, and memory is unreliable. Write down key quotes, not just impressions. Record what they said, not how you felt about it.
Probe when answers are incomplete. "Can you give me a specific example?" when they speak in generalities. "What was your individual contribution?" when they describe team outcomes. "What was the result?" when they describe actions without outcomes. "Walk me through your thought process" when you want to understand their reasoning.
Stay neutral throughout. Don't react positively to good answers or negatively to concerning ones. Your reactions will shape their subsequent answers. A neutral, curious demeanor gets more honest responses than visible evaluation.
Give them time to think. Behavioral questions require retrieving specific memories, which takes time. Silence is acceptable. Don't rush to fill it or move on to the next question. The pause often produces better answers than the initial response.
Ask follow-up questions on concerning answers. If they describe handling conflict poorly, ask about another conflict. One bad example might be unrepresentative; a pattern of bad examples reveals who they are.
Evaluating What You Hear
After the interview, evaluate each answer against a consistent rubric. Without a rubric, interviewers default to gut feel, which is unreliable and often biased.
A simple four-point scale works: 4 (strong) means clear specific example, appropriate actions, good outcome, learning demonstrated. 3 (good) means solid example, reasonable actions, acceptable outcome. 2 (concerning) means weak example, questionable judgment, or missing elements. 1 (poor) means no example, clear poor judgment, or red flags.
Score each dimension independently. A candidate might handle conflict well but struggle with failure. Collapsing everything into a single rating loses signal.
Calibrate with other interviewers. If you rated collaboration as concerning and another interviewer rated it strong, discuss the specific examples and reasoning. Maybe they probed differently and got better examples. Maybe you interpreted the same example differently. The calibration conversation often produces better signal than any individual assessment.
Document the specific evidence for your ratings. "Rated collaboration as concerning because in both examples, the candidate blamed teammates for not delivering rather than describing how they worked through the problem." This documentation matters for hiring decisions and for legal defensibility.
The engineer who aced technicals but couldn't work with anyone? A thoughtful behavioral interview would have surfaced the pattern. Her stories would have shown dismissing feedback, arguing with product, and positioning herself as the expert surrounded by people who didn't understand.
The signals were there. Nobody asked the right questions.
References
[^1]: SmithSpektrum interview design research, behavioral interview analysis, 2020-2026. [^2]: Google re:Work, "Structured Interviewing." [^3]: Laszlo Bock, "Work Rules!" 2015. [^4]: HBR, "The Science of the Interview," 2024.
Designing behavioral interviews for your engineering team? Contact SmithSpektrum for interview design and training.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum