Four minutes in, he had the optimal solution. Clean, correct, linear time. I asked what happens if the array comes in empty. He said, "It won't be." I asked how he knew. He said, "Because the problem says it's a list of numbers."
We finished twenty minutes early. I wrote my notes before he'd logged off, and they were not good notes.
I've spent years on the interviewer side of the table, and the interview horror stories that stick with me are almost never the ones where somebody couldn't code. Those are boring and sad. The ones I still think about are the candidates who were clearly strong and torched themselves on something that had nothing to do with their ability to write software.
TL;DR
- Most interview rejections of strong engineers are risk decisions, not skill decisions.
- One interviewer's specific concern outweighs three vague yeses, because nobody wants to be the person who vouched for the bad hire.
- The four most common self-inflicted kills: no collaboration signal, arguing with the premise, one-inch resume lies, and trash-talking your current employer.
- Screen sharing is a live confidentiality test that nobody warns you about.
- Fix: narrate your thinking, flag disagreements in 30 seconds and move on, and only claim what survives three "why" questions.
What do interview horror stories actually teach you?
They teach you that hiring is a risk-reduction exercise wearing the costume of a talent search.
Here's the mechanic nobody explains. At debrief, four interviewers sit down with their notes. Three say some version of "yeah, solid, seemed fine." One says "I have a specific concern: he dismissed the edge case I raised and then repeated the same mistake in the follow-up." That fourth person wins. Every time.
Not because the process is unfair, but because "solid, seemed fine" is unfalsifiable and "here is the exact moment it went wrong" is evidence. Vague positives lose to specific negatives. If you understand only one thing about interviewing, make it that.
So the goal isn't to be impressive. It's to give nobody a sentence they can write down.
Why did the fastest candidate get rejected?
The guy from the opening. He was genuinely quick, and he lost because he produced zero collaboration signal.
Speed is worth almost nothing on its own. What I'm scoring is what happens when reality pushes back, because that's 90% of the job. When I hand you an edge case, I am not testing whether you know that arrays can be empty. I am running a tiny simulation of a code review. Your answer tells me what you'll be like when a teammate says "hey, I think this breaks under load."
"It won't be" is a complete answer to that simulation. It just isn't the answer you want.
The version that passes takes eight seconds: "Good catch, empty input would return zero here, want me to guard it or is that out of scope?" Same knowledge, entirely different data point.
Is it bad to disagree with the interview question?
Disagreeing is fine. Litigating is fatal.
I once gave a candidate a deliberately simplified caching problem. She said, correctly, that no real system would be built this way. She was right. She then spent twenty minutes explaining what she would build instead, refused to work inside the constraint, and we never got to any code.
Every interviewer has watched a good engineer do this. It reads as: this person cannot execute inside constraints they didn't choose. Which is, unfortunately, a fair description of most of the job.
The move is a thirty-second flag, then compliance. "In production I'd reach for a real cache with TTL and eviction. I'm assuming you want the naive version to see the logic, so I'll build that." You get full credit for the insight and zero penalty for the detour. Say it and move on.
What happens if you screen share something private?
You fail a test nobody told you was running.
I have watched a candidate share their entire desktop and reveal a folder from their current employer's private repo. I've seen a Slack notification land mid-answer, in a preview large enough to read. I've seen a browser tab bar that included another company's interview scheduling page, which is not fatal but is deeply awkward for everyone.
Nobody says anything in the moment. It goes in the notes.
The logic is brutally simple: how you treat your current employer's confidential material is a live demo of how you'll treat ours. Nobody has to argue that point in a debrief. They just describe what they saw.
Share a single window. Quit your chat apps. Log out of your work accounts in that browser profile, or use a fresh one. This takes two minutes and eliminates an entire category of rejection.
Why does a small resume exaggeration end an interview?
Because interviewers dig exactly one level deeper than you expect, and small lies have no second floor.
A candidate's resume said he'd "designed and built" a real-time notification pipeline. I asked why he chose that queue over the obvious alternative. He gave a decent answer. I asked what the retry semantics were when a consumer died mid-message. Silence. Then: "I'd have to check with the team."
He hadn't built it. He'd been on the team that built it, which is a completely respectable thing to have done and would have scored fine if he'd said it.
The failure wasn't the knowledge gap. It was the reveal that the resume was slightly inflated, which forces me to re-check every other line on it. One inch of exaggeration costs you the credibility of the whole document.
Test yourself: for every claim on your resume, can you survive three consecutive "why did you do it that way" questions? If not, downgrade the verb. "Contributed to," "worked on," and "owned the client side of" all score fine. Getting caught does not.
Does complaining about your current job hurt you?
Yes, and worse than candidates expect.
One guy spent ten minutes on his current manager. The stories were, I'd guess, entirely true. Some of them were genuinely bad. It didn't matter, because I wasn't hearing a report about his manager. I was hearing a preview of how he'd describe us in eighteen months.
There's also a subtler read. Ten minutes of grievance with no self-assessment says this person sees themselves as a passenger in their own career. That's a hiring risk on a level that has nothing to do with the manager being a jerk.
Two sentences is the budget. "The team reorganized around work I'm not excited about, and I want to get back to distributed systems." Honest, forward-facing, done.
My own interview horror story
Mine is the dumbest kind: I answered a question nobody asked.
Given a small parsing problem, I decided the interesting version was a general, extensible, plugin-shaped parser. I spent thirty-five minutes building an architecture for it, narrating happily. At minute forty I had elegant scaffolding and not one working line of parsing.
The interviewer's note, which I later heard secondhand, was something like: builds infrastructure before solving the problem. I've thought about that sentence for years, mostly because it was accurate about me at that job too.
Solve the small version first. Make it work. Then say "here's how I'd generalize this if it needed to scale," and you get every point I was trying to earn, with a working solution attached.
So why do good engineers become interview horror stories?
Because they optimize for looking capable when the interviewer is measuring how safe they are to hire. Nearly every rejection I've written for a technically strong candidate came from the same shape of moment: a dismissed edge case, a twenty-minute argument with the premise, a leaked screen, a resume claim with nothing under it, ten minutes of grievance, or a beautiful abstraction with no working code inside it. None of those are skill failures. They're all a specific sentence somebody gets to write down and read out in the debrief, and one specific sentence beats three vague compliments in every hiring room I've ever sat in. Give them nothing to write, and your actual ability gets to do the work.
What's the one that got you? I'll go first: the parser. Still bitter.
Top comments (0)