Coding Interview Red Flags: Why Correct Code Still Gets You the No Hire

You solved it. The algorithm was right. You got the complexity correct. You finished with four minutes left and even added a comment explaining the invariant. The interviewer said "great job, thanks so much," and hung up. Three days later: rejection email.

This happens constantly. And nobody tells you why.

The interviewer was watching something that had nothing to do with whether your code ran. Every behavior you showed got filtered through one question the hiring committee asks later: "What's the worst case if we hire this person?" The behaviors below are the ones that answer that question badly. Not exotic, unreasonable things. Normal things. Things you've probably done.

Companies Optimize Against Bad Hires, Not Missed Hires

Hiring at scale is a risk calculation, not a talent search. A false positive (bad hire) costs months of wasted salary, team friction, and political capital to fix. A false negative (missed good hire) costs them one job req that someone else fills. The incentives are not symmetric, and companies know it.

The practical result: interviewers aren't just asking "could this person do the job?" They're asking "what does this behavior predict about how they'll act on my team every day?" A behavior that seems minor in isolation becomes a red flag the moment it maps to a specific recurring failure mode. That's the lens for everything below.

They Started Coding Before They Understood the Problem

The most common mistake in the first three minutes. The candidate reads the problem, nods, says "okay I think I got it," and starts typing. Two minutes later they're refactoring because a core assumption was wrong. Five minutes later the interviewer is watching someone dig themselves out of a hole they created in the first sixty seconds, and both of them know it.

What the interviewer writes down: "design-as-you-go." Every major refactor is a lost signal. Once you've written 80 lines going the wrong direction, a course correction is expensive, disruptive, and visible.

What this predicts: a teammate who ships code without design review, who codes first and asks questions later. Google's rubric explicitly marks "jumped right into coding without properly explaining" as a Communication score of 2 (Concerning). The rubric doesn't say "wrong answer." It says: we watched you not think before acting.

The fix is embarrassingly simple. Spend five minutes on approach before touching code. Talk through your assumptions out loud. Ask one or two clarifying questions about input format, edge cases, constraints. You don't need a whiteboard. You need enough planning that the interviewer knows where you're going before you start.

Silence Is Bad. Half-Thoughts Are Almost Worse.

Everyone knows "don't go silent." But most people replace silence with something nearly as damaging: the half-thought.

"Hmm, I wonder if I could use a heap here... no, never mind." Then silence.

An analysis of 600 technical interviews on interviewing.io found half-thoughts as a distinct problem category. The candidate is vocalizing partial ideas and finishing the reasoning internally. The interviewer still can't follow the decision-making process, still can't tell which approaches got considered and rejected, still has nothing to write down. You're narrating a movie with the volume at 10% and expecting the audience to follow the plot.

Full silence gets you a Google Communication score of 1: "stayed silent for much of the interview." Half-thoughts don't do much better. The write-up ends up reading "candidate seemed to be solving but I couldn't tell how." Which is just silence with extra steps.

Complete your thoughts out loud. If you're considering an approach, say why you're considering it, and say why you rejected it. That takes five seconds and transforms the session from a code-watching experience into a collaboration. The interviewer can engage, redirect, confirm. Silence leaves them watching you stare at a screen.

Ten or fifteen seconds of quiet is completely fine if you signal it: "Let me think through this for a moment." That's not silence, that's a human focusing. The red flag is extended muteness with no window into your reasoning.

Anatomy of a developer's browser: The thing I am working on, I seem to have run into an issue, Stack Overflow has failed me, Official API Documentation, God Damnit, This is not my fault

Your internal experience during the interview vs. what the interviewer actually sees

How You Take a Hint Answers a Question You Didn't Know Was Being Asked

Interviewers give hints for two reasons: to keep the interview moving when you're stuck, and to test how you take direction. Most candidates understand the first reason. Almost nobody thinks about the second.

When an interviewer suggests a different approach and you respond with "actually, I think my way works," you've just answered the coachability question. Badly. In front of someone who is filling out a form about you.

Defensiveness toward hints is the single behavior most likely to get explicitly documented in the write-up. "Candidate argued when redirected" is a memorable line. "Candidate integrated the hint quickly and ran with it" is what you want. The difference in the hiring committee read is significant, because the committee is imagining how you'll respond to a code review comment six months from now.

Hints aren't the interviewer telling you you're wrong. They're the interviewer telling you what they want to see. Respond the way you'd respond to a senior engineer suggesting an approach in a design discussion: acknowledge it, think through it out loud, and either adopt it or explain clearly why your approach is better. The second option is fine. The knee-jerk defensive dismissal is not.

If you're genuinely unsure whether they're correcting you or probing, ask: "Are you pointing me toward a different approach, or checking if I can defend this one?" That's collaborative. That's what gets written up positively.

"That Should Work" Is a Red Flag

You finish the code, say "and that should work," and look at the interviewer. This is a problem.

Meta and Amazon both include testing as an explicit scored dimension. The rubric line is direct: "Did not even test code against typical cases."

Testing before the interviewer asks demonstrates something specific: you verify your own work before shipping it. Catching your own bug is a positive signal. Having the interviewer catch it because you declared done is a negative one. Not because bugs are disqualifying, but because the behavior tells a story.

Gayle McDowell's analysis is worth internalizing: bugs in interviews are common and rarely cause rejection by themselves. The panic fix does. A candidate who spots a bug and immediately starts patching symptoms without finding the root cause is demonstrating exactly the debugging habit that creates production incidents. The flailing isn't invisible. Stop. Identify why the bug exists. Fix the cause, not the symptom.

Programmer cat quiz: What to say when the client says 'it doesn't work'? A) Somebody must have changed my code, B) I haven't touched the code in weeks, C) It worked yesterday, D) It works on my machine

Option D is also the wrong answer in an interview when the interviewer runs your test case

Run your code against the given example. Then one edge case: empty input, single element, all duplicates, negative numbers. You don't have to catch everything. You have to show that checking is a habit.

You Just Wrote This Code. You Should Know What It Does.

"It's O(n), I think. Maybe O(n log n)? Pretty fast though."

This sounds like uncertainty about complexity. What the interviewer hears: "I wrote this, and I don't know what it does."

Vague complexity analysis reads as an engineer who doesn't reason about cost, which predicts performance problems in production. If you're building something that processes millions of events and you can't articulate why your approach is O(n log n) instead of O(n²), you'll introduce that kind of problem into real systems.

The bar isn't perfection. Reason out loud: "This is one pass through the array, so O(n) time. The hash map is O(n) space in the worst case." If you're genuinely unsure, derive it: "One outer loop, O(n). Inside that, a hash map lookup, O(1) amortized. Total: O(n)." That's the habit. Trailing uncertainty after a flimsy guess is not.

You Don't Have to Handle Every Edge Case. Name Them.

Around 50% of candidates ignore the first stated requirement of a problem. They see a problem about arrays and build a solution for the happy path. Empty array? Never mentioned. Single element? Didn't come up.

Edge cases aren't about catching every obscure input. They're about demonstrating that you think systematically about the full input space. An engineer who only thinks about the success path writes code that fails in ways they didn't anticipate.

Say it out loud before coding: "I'm going to handle the main case first. Off the top of my head, I'm thinking about empty input, negative values, and integer overflow." That sentence takes ten seconds and covers you entirely. The interviewer knows you know these cases exist. They'll tell you which ones to implement.

The red flag isn't missing an edge case. It's not thinking about the input space at all.

Every Red Flag Becomes a Line in Your Write-Up

Each of these behaviors has a downstream effect candidates don't see. The interviewer completes their assessment after the call. Hiring committees spend roughly two or three minutes reviewing it. They read narratives, not raw scores.

"Candidate jumped to code without discussion, struggled to explain their approach after the fact, and argued when I redirected them" is a complete story. It doesn't matter that the code eventually worked. The write-up establishes a pattern, and patterns stick.

The behaviors that generate strong write-up evidence: narrating your approach before coding, completing your thoughts out loud, integrating hints graciously, verifying your code before declaring done, reasoning through complexity, and naming edge cases. None of these require you to be faster or smarter. They require you to act the way you'd act on a real team.

SpaceComplexity runs voice-based mock interviews with rubric-based feedback, which means you get explicit signal on the communication and process dimensions that written practice entirely misses. That's where these habits get built.

If you want to practice the behaviors that build a strong write-up, see the guide on communicating your approach during the interview and how to respond when you're stuck. The mechanics of taking hints well are in what interviewers actually want when they redirect you.