I froze on a CSS flexbox question once. The interviewer asked me "what does flex: 1 do?" — and I went blank. Flexbox. Something I'd used literally hundreds of times in production. I knew it, obviously, but in that moment my brain just... stopped. I started throwing out different possible answers in a super chaotic way, jumping between explanations, trying to say anything that would confirm I'm good enough for this position. After that part of the interview they told me they don't want to move forward.
The thing is — I knew flexbox. I'd shipped production layouts with it. But under pressure, that knowledge was locked somewhere I couldn't reach.
This isn't a knowledge problem. It's a performance problem. And the fix isn't more studying.
Your brain literally works differently under pressure
Here's a simplified version of what happens when you freeze — I'm a frontend developer, not a neuroscientist, so take this with a grain of salt. When you're in a stressful situation, your brain switches into survival mode. Quick reactions over deep thinking. Great for running from danger. Terrible for explaining how a load balancer works.
Two things happen:
Your thinking capacity drops. The part of your brain responsible for reasoning and putting thoughts into words gets fewer resources. Your brain decides "we don't need the complex thinking right now, we need to survive." Except you DO need the complex thinking — that's the whole point of the interview.
Your memory retrieval gets blocked. The stress hormones make it harder to pull information from memory. The knowledge is there. You just can't access it.
Same knowledge, different context. That's the entire explanation for why you can tell your friend exactly how event delegation works over lunch and then blank on it with an interviewer watching.
Your brain is doing too many things at once
When you code normally, you think about one thing: the problem. In an interview, you're running like six parallel threads:
- Solving the actual problem
- Monitoring what the interviewer thinks of you (are they nodding? frowning?)
- Choosing the right words to sound competent
- Managing your internal panic
- Deciding what to say next vs. what to skip
- Wondering if you should ask a clarifying question or if that makes you look like you don't know enough
Working memory can hold roughly 4 things at a time. When 2-3 of those slots are occupied by anxiety and self-monitoring, you've got maybe 1-2 slots left for the actual technical problem. You're trying to explain distributed systems with the mental capacity of someone who just woke up from a nap.
"I'm not an anxious person" — it doesn't matter
I was interviewing a candidate for a Senior Frontend Developer position recently. First 30 minutes — genuinely impressive. Clear explanations, honest about which decisions were his vs. the team's, asked clarifying questions when he wasn't sure how to respond. All great signs.
Then we got to the technical part. Something shifted. The same person who was articulate 10 minutes ago started giving short, vague answers. Like watching a different candidate.
He could have done the job. I'm fairly sure of that. But I also couldn't fully override what I saw in the technical portion, even knowing it was probably nerves. That's the uncomfortable thing about being on the interviewer side — you can suspect someone is freezing up, but you can't just assume the good performance is the "real" one and the bad performance is the anomaly. You don't have enough data. So the freeze costs them.
This isn't about being an anxious person. It's about a specific skill that almost nobody practices: explaining technical concepts clearly while someone is evaluating you. When you code normally, you think, pause, Google something, backtrack, try again. Nobody watches. In an interview, everything is visible and there's a timer running. Completely different skill.
The "study more" trap
When developers freeze in interviews, the natural reaction is to study more. Read another system design book. Do 50 more LeetCode problems. Watch more YouTube explanations.
This makes things worse in a specific way: it builds confidence without building the skill you actually need. You walk into the next interview thinking "I really know this stuff now" and then freeze again. That's more demoralizing than the first time, because now you can't even blame lack of preparation.
I actually started wondering at some point whether I was just bad at interviews as a personality trait. Like maybe some people are wired for it and I'm not. That's not true, but it felt true after the third time I studied hard and still choked.
The gap between knowing something and owning it is where interviews are won and lost. Cramming doesn't close it. Only sustained practice under some kind of pressure does.
What actually works: getting used to the discomfort
The freeze response gets weaker with repetition. Your brain learns that "someone is evaluating me" is not actually a life-threatening situation — but it needs to learn this through experience, not through reading about it.
For interviews specifically, this means practicing verbal explanation under conditions that feel at least a little pressured:
The 60-second drill
Pick a concept you know well. Set a timer for 60 seconds. Explain it out loud as if you're in an interview.
Try it right now with "How does HTTPS work?" Go.
If you actually did it, you probably noticed something: you either rushed through the TLS handshake, forgot to mention certificate validation, or spent too long on DNS and ran out of time before getting to encryption. The 60-second constraint forces you to make decisions about what to include and what to skip — which is exactly the skill you need in interviews.
Do this daily with different topics. The timer is important because it creates just enough pressure to simulate the real thing.
Record yourself (yes, it's uncomfortable)
Record yourself explaining a technical concept, then play it back. You'll hate it. That's the point.
Most developers who try this discover they use way more filler words than they thought, and their explanations jump around without clear structure. I recorded myself explaining WebSocket vs. SSE once and realized I spent the first 30 seconds saying essentially nothing — just throat-clearing before the actual content started.
A rough structure that helps: what problem it solves, how it works, what the tradeoffs are. But honestly, just recording and listening back teaches you more than any framework.
Practice with interruptions
Have a friend (or use a tool) give you a question, then interrupt you 20 seconds in with a follow-up. "Wait, can you go deeper on that part?" or "What happens if X fails?"
Interruptions are where most freezes happen in real interviews. You had a plan in your head for how to explain something, someone breaks it, and suddenly you're lost. Training with interruptions builds the ability to adjust on the fly.
Build up gradually
Start low-pressure and work up: explain to yourself in an empty room, then record yourself, then explain to a friend, then do a mock with someone you don't know. Each step adds social pressure. Jumping straight from solo study to a real interview is like never running more than 1km and then signing up for a marathon.
The pre-interview warmup (most people skip this)
Athletes warm up before competing. Musicians play scales before performing. Developers open their laptop and hope for the best.
10 minutes of warmup before an interview makes a noticeable difference. Just explain a couple of concepts out loud — something easy first (how does a hash map work?), then something moderately complex (what happens when you type a URL into a browser?). Finish with some rapid-fire retrieval: name 4 HTTP methods, 3 differences between SQL and NoSQL.
The point is to walk in with your "explaining brain" already running. Cold-starting it on the first real question is a recipe for freezing.
When you freeze anyway
Even with preparation, you'll still freeze sometimes. The goal is recovery, not prevention.
Name it internally. Just thinking "ok, I'm stressed right now, that's why I can't think" actually helps. Labeling the emotion reduces its intensity. Sounds too simple. Works anyway.
Buy time. "Let me think about how to structure this." Not stalling — giving your brain a moment to come back online.
Say one true thing. Don't try to give the perfect answer. Just say one true statement. "At its core, this is about managing concurrent access to shared state." That single starting point often unlocks the rest. Or it doesn't, and you've at least said something correct while your brain catches up.
Draw something. Shifting from verbal to visual thinking can bypass the freeze entirely. I've seen candidates who couldn't articulate an architecture grab a marker and suddenly become fluent.
This takes weeks, not days
The freeze response doesn't disappear after one practice session. Expect a 3-4 week ramp if you practice daily.
Week 1: Daily 60-second drills on concepts you already know. Focus on structure and getting comfortable hearing yourself speak.
Week 2: Start recording yourself. Review and notice filler words, trailing off, and disorganized explanations.
Week 3: Practice with another person. A friend, a study partner, or a tool that gives you questions and evaluates your spoken answers — the point is that it can't be purely self-directed anymore. You need at least some discomfort of having an audience. Practicing alone is valuable, but at some point you need to add social pressure.
Week 4: Mock interviews or rapid-fire sessions with someone you don't know well. If you've been doing daily practice, the freeze response should be noticeably weaker by now.
The goal isn't to eliminate nervousness completely — some level of alertness actually helps you perform better (it's called the Yerkes-Dodson effect if you're curious). The goal is to bring it down from "I can't think" to "I'm focused."
The real bottleneck isn't knowledge
Most interview prep assumes you don't know enough. That's rarely the actual problem. The problem is the gap between what you know and what you can say under pressure.
I froze on flex: 1. A senior developer I interviewed fell apart on questions he clearly knew the answers to. Same pattern. The knowledge was there. The ability to deliver it was not.
The fix is opening your mouth and practicing out loud, repeatedly, until your brain stops treating "explain how a load balancer works" as a threat. Pick one concept. Set a 60-second timer. Explain it out loud right now. Notice where you stumble.
Top comments (0)