The 3 interview questions strong candidates still get wrong
Interview preparation is a two-edged sword. The more you rehearse, the easier it becomes to deliver a polished answer that misses the point of the question.
I saw this scenario being played out across nearly two decades of interviews. A candidate sits down, hears a question they’ve prepared for, and delivers exactly the story they rehearsed. The story is clean, but the answer misses the point of the question, it answers a different question, or, even worse, it raises a significant red flag.
What makes this problem hard to spot from the candidate’s seat is that everything feels like it’s working. The preparation has paid off in the moment. The answer comes out smoothly, and the interviewer might even nod along as they take notes.
But what the candidate can’t see is what’s happening on my side. The polish on their answer doesn’t help them the way they think it does. I’m trying to figure out whether they understood what I was asking, and a perfectly presented delivery of the wrong answer just makes it more glaringly obvious.
The cost of the problem shows up too late, maybe a week later, when the rejection arrives, with no specific feedback. The candidate replays the interview over and over in their head and can’t figure out what they did wrong. Because, in their memory, nothing went wrong.
Below, I discuss the best way to answer the three interview questions that most commonly trip up candidates.
1. “Tell me about a time you disagreed with a teammate or manager.”
When you put a group of smart, motivated people in a room, you are bound to get disagreements. Some are big and consequential, for example, architectural calls that will shape a system for years or deprioritization fights that will change a roadmap. Some are small, everyday disagreements.
Both types of disagreement are a part of normal engineering work. After asking you the question, the interviewer will be looking to see which kind you’ve chosen to discuss.
The most common failure mode is to pick the smallest, lowest-stakes example. The candidate will describe a trivial dispute about library selection, or naming conventions, or differing coding style preferences. They go small and inconsequential because they’re worried that telling a real story might make them look difficult or political.
But that’s exactly the type of answer that gets flagged.
The note in my head when I hear that kind of answer is simple: this candidate doesn’t disagree on anything that matters. In an environment where engineers are expected to push back on architecture decisions, design trade-offs, and product priorities, this person would likely default to consensus on the things we’d want them to fight for.
Once you’ve heard a few of these answers, you can spot the setup before the candidate finishes the second sentence.
The second failure mode is the inverse of the first. The candidate tells a story about a disagreement they “won” by being persistent until the other person gave up, or by framing their position as the obviously only correct answer all along.
That story flags for a different reason. It tells me the candidate doesn’t know how to operate in environments where multiple smart people can see a problem differently. Their approach to resolving disagreements is one of attritional warfare. The trouble is, at scale, that approach breaks teams.
The third failure mode manifests when the candidate can’t think of a real disagreement at all. Their team just hummed along nicely. Everyone got along, and there wasn’t really any conflict.
That story flags too, because it tells me that either the candidate wasn’t paying attention or they don’t have the discernment to recognize simmering disagreements. Or that they were so peripheral to the work that the disagreements happened without them.
The question is asking something more specific than most people realize. Can you hold a strong position, genuinely engage with another person’s reasoning, and arrive at a resolution that your team can act on? The disagreement itself is just the entry point into the discussion that the question seeks to generate.
The strongest answers I heard all followed a clear arc. The candidate had a real point of view based on context that the other person didn’t possess. They surfaced their concerns directly rather than going through back-channels. They listened to the counterargument, sometimes updating their position in response, and they either persuaded the other person, got persuaded by the other person, or disagreed-and-committed cleanly. Whichever way it landed, the team kept moving.
What to do
Pick a disagreement with real stakes. Maybe a technical decision that shaped a project’s outcome, a design tradeoff with downstream consequences you’d be proud to discuss, or a deprioritization that you pushed back on. Steer away from cosmetic or stylistic disagreements unless they’re proxies for something more substantial.
Your strongest stories will explain why a smart, well-intentioned person saw the problem differently. If your story makes the other person sound foolish, the interviewer is going to wonder how you would talk about your colleagues when they’re not in the room.
End on a resolution. Don’t leave the story hanging. Either you changed your mind, they changed theirs, or you disagreed and committed. The story isn’t done until the team is moving again.
Looking for concrete examples? I have a lot of them, both for this question and the ones the rest of this article doesn’t cover.
My book Technical Behavioral Interview: An Insider’s Guide covers 130+ behavioral interview questions, with 72 example stories calibrated from entry-level to principal. There’s a full chapter on Earning Trust and Dealing with Conflict, where this question lives, as well as chapters on the eight other competencies that companies assess.
If this article is useful and you want the full version, the book is on Amazon.
2. “What’s your biggest weakness?”
The reason this question catches even prepared candidates off guard is that the advice typically given on how to answer it is mostly bad. ”Pick a strength and disguise it as a weakness,” that sort of thing, so that’s what they rehearse, and that’s what they deliver.
The interviewer has heard it many times. By the time you’re a few words into your rote “I tend to be a bit of a perfectionist” humblebrag, they’ve already filed the answer under “Candidate didn’t take the question seriously.”
That’s the most common failure mode for this question, and the one most candidates don’t realize they’re committing. The disguised strength. “I work too hard,” “I care too much,” “I’m too detail-oriented.” These were once novel answers a long time ago, but they aren’t anymore. And the polish on the delivery makes the problem worse rather than better, because it tells me you’ve practiced this answer enough times to have rendered it even more useless than it already is.
The second failure mode is the opposite: candidates who take the question so literally that they hand over a real disqualifier. A senior IC might admit they don’t like being challenged on their designs. A tech lead might admit they avoid difficult conversations. A manager candidate might admit they struggle to give critical feedback.
The interviewer didn’t ask you to disqualify yourself, and most candidates aren’t trying to do that, but the lack of judgment demonstrated in choosing what to share is itself a flag.
The third failure mode is the vague answer with no real specifics. “I want to get better at communication.” “I’m working on managing my time.” There’s no story behind it, no example to back it up, and no evidence the candidate has done anything about the weakness. The flag here is that the candidate hasn’t really thought about themselves with any rigor. And that’s worse than picking the wrong weakness.
The question is asking three things at once:
Can you assess yourself accurately?
Can you talk about your shortcomings without getting defensive?
Are you actively doing something about the weakness you named?
Most candidates answer only one of these and assume that’s enough.
The strongest answers I’ve heard share a common shape. The candidate names a real weakness that has affected their work, gives at least one specific example of when it cost them or their team something concrete, and then spends most of the answer on what they’ve changed since. There’s usually a recent example to back it up.
The candidates who succeed in answering this common question are the ones who take it seriously enough to prepare an answer with real substance.
What to do
Pick a real weakness that has affected your work. Avoid theoretical weaknesses, disguised strengths, or personality traits you secretly think are strengths. The weakness should have a cost that you can point to. At a minimum, you can pull from feedback you’ve received in performance reviews or 1:1s. This will give your answer concrete grounding without requiring you to self-diagnose under pressure.
Most of your answer should be about the improvement. Be specific about what you’ve changed and when, and have ready a recent example of the new behavior in action.
3. “Tell me about a project you’re proud of.”
This question sounds like an invitation. Tell us about your best work. Most candidates treat it as a chance to showcase the most technically impressive thing they’ve done.
That’s the trap.
The interviewer is trying to learn something about you that the rest of the loop hasn’t shown, and the project you pick is part of how they learn it. Technical complexity is one possible angle into that signal, but it’s only one of many.
The most common failure mode is the project narrator. The story tends to come out as a timeline. First, we ran into this problem, then we tried this approach, then we shipped this thing. By the time the candidate finishes, I’ve learned the chronology of a project and very little about how the candidate operated inside it. What gets lost in the timeline format is everything the interviewer is trying to evaluate. The decisions you made, the judgment you exercised, what you owned, and what you handed off. All of it sits underneath the recap rather than driving it.
The second failure mode is choosing a project based on what you think is impressive about it. The problem is that not everybody is impressed by the same things. The part that took you the most effort might not be the part that lands. The technical detail you’re most proud of might not be the one the interviewer cares about. Candidates who talk about their project in this way can often finish the story wondering why the interviewer wasn’t more engaged.
The third failure mode is choosing a project that is irrelevant. The candidate picks something they’re emotionally attached to for personal reasons that don’t translate to the role. Maybe a volunteer side project they’re sentimental about, or an undergraduate thesis that meant a lot at the time.
These sorts of examples can land if they happen to demonstrate the right competency, but candidates tend to pick them out of attachment rather than fit. The interviewer hears about the side project and wonders why, of all the work the candidate has done, this is the one they chose.
The strongest answers I’ve heard do two things at once. They match the project to the competencies the company is hiring for, and they put the candidate at the center of the story. The candidate is the one driving the story, not riding along inside of it. The project provides the setting; the candidate carries the story. Even if the technical content is less impressive than what the candidate could have chosen, an effective story tells the interviewer something specific about how this person operates.
What to do
Choose a project that demonstrates the competency most relevant to the role. Read the job description for clues about what the company values most, for example, ownership, delivery, technical depth, collaboration, or something else. The most technically impressive project in your career will be the wrong choice if it doesn’t map to what the company is evaluating.
Before the interview, workshop your story with a trusted friend. Tell it to them or a peer who doesn’t know the project, and watch what they react to. The parts they ask follow-up questions about are the parts you should be leading with. The parts where they tune out are usually where you’ve buried the lede.
Open with a one-sentence headline that tells the interviewer what made the project significant. A clear thesis up front helps the interviewer follow the rest of the story. Buried ledes and slow builds risk losing them before you get to the payoff.
The Throughline
Across all three questions, the same pattern shows up. The interviewer isn’t grading you on the surface content of your answer. They’re listening for what it signals about you. Whether you can think clearly when the pressure’s on, and what you reveal about yourself in how you frame your own story.
Polished, prepared answers aren’t enough on their own. The thing that separates strong answers from weak ones is whether the candidate engages with the question that has been asked, not the question they had hoped to be asked.
The fix is to spend less time rehearsing answers and more time on what each question is evaluating. Once you can hear the question the way the interviewer is asking it, the right story will be easier to find, and you will no longer be trapped by your own answers.