Coding Under Pressure: When Technical Interviews Fail

Today, while scrolling through my X (Twitter) timeline, I came across this curious post by Ed Andersen (@edandersen), developer and content creator on YouTube: Link to Tweet

This got me thinking. In the same post, Ed wondered if these types of tests really work, if candidates bet on not being interviewed by someone technical.

Disclaimer: this blog seeks to open a debate, not to discredit Ed Andersen’s opinion. I was not a witness to that interview, I am only reflecting based on his publication.

The question I ask myself is not whether the candidate lied or not. The real question is: is it fair to measure a developer just by writing a loop, or any piece of code, under pressure?

Not long ago I went through something similar. I applied to a company for a Software Engineer role. First, I received an assignment: develop a complete solution to display data from an API and create recommendations. It took me several days, even with the suggestion to use AI.

Then came the technical interview with the company’s engineers. And the usual happened: anxiety took over me. They asked me for something simple —make a request— something I have done thousands of times in 13 years of experience… and I went blank. I had to turn to documentation.

I don’t know if that moment was decisive, but in the end I received the rejection. And that inner voice appeared: “What was the point of all these years of experience if a simple interview can make me doubt myself?”

And I return to the same question: how fair is it to call an entire career into question just because nerves got the better of us?

Pressure as an Invisible Filter

I’m not the only one who has felt it. In 2020, researchers from North Carolina State University and Microsoft conducted an experiment: they compared candidates solving a programming problem in private versus doing it in a traditional interview, on a whiteboard and under the interviewer’s gaze. The result was clear: candidates under pressure performed at almost half of what they could do in private.

And the most interesting thing: when asked how they felt, many said exactly what I felt: nerves, pressure, blank mind. In other words, the technical interview was not so much measuring their ability to solve problems as their ability to deal with anxiety.

Other studies found something similar: candidates who appear nervous tend to receive worse evaluations, even if they answer correctly. That is, nervousness “taints” the interviewer’s perception of competence, even if the content of the answer is valid.

Cases of Talent Wasted by Nerves

Here is where things get more serious. In the same NC State and Microsoft study, something striking happened: all the women participants who did the interview in public failed the test, while all those who did it in private passed. The sample was small, but the result is a wake-up call. Pressure and format affect groups differently, and that means we could be discarding valuable talent for a simple issue of anxiety.

I have also read stories of experienced developers —people who have created libraries used by thousands— who fail interviews at big companies because, in front of the whiteboard, they forgot how to invert a binary tree or write a simple loop. The irony is that those same people had already proven in real life that they could build complex and useful software, but the interview format failed to measure it.

What Are We Really Measuring?

This opens an uncomfortable debate. If technical interviews are supposed to find the best developers, why do we keep relying on a format that looks more like a stress test than a real workday?

Because in real work we are not at a whiteboard with someone watching every keystroke. We program with our editor, with documentation, with Stack Overflow open, and above all, in teams. Making mistakes and correcting them is part of the process.

However, in many interviews immediate precision is expected, as if forgetting the exact syntax of a foreach invalidated all your experience. And what’s worrying is that science has already confirmed what many of us feel: these interviews are filtering more for tolerance to pressure than for true technical ability.

In fact, researchers compared whiteboard interviews to a clinical stress-induction test used in psychology to generate anxiety. Which means that, unintentionally, the tech industry designed a method that measures nerves more than ideas.

Alternative Evaluation Methods That Reduce Pressure

The good news is that there are alternatives. Some companies and experts are already experimenting with more human and realistic processes:

Private tests: letting the candidate solve a problem in their own environment, without someone watching every keystroke. Then the solution is reviewed and the candidate is asked to explain their reasoning. This reduces anxiety and evaluates logic more than nerves.
Short and realistic assignments: instead of whiteboard puzzles, give practical exercises aligned with real work. Something that doesn’t take a week of effort, but a few hours, and that is evaluated by the quality of the code, not the speed of writing.
Pair programming: interview as if it were a collaboration session. Instead of a jury, the interviewer becomes a temporary teammate. This lowers the tension and shows how the candidate thinks out loud, solves, and communicates.
Second chances: allowing the candidate to reformulate or try again if they get stuck. Because let’s be honest: how many times in real work do we solve something on the first try, without mistakes or doubts?

Conclusions

Technical interviews are necessary, but the traditional format is broken. Instead of measuring how we solve problems, it measures how we respond to artificial stress. And in that confusion, the industry may be wasting talent that truly knows how to code, but doesn’t know how to put on a performance under pressure.

A good hiring process should imitate real life: access to documentation, teamwork, room to make mistakes and correct them. That’s what we developers do every day.

Because in the end, what should matter is not whether you can recall the syntax of a foreach by heart, but whether you can turn ideas into useful, sustainable software.

Suggestions for Candidates/Interviewers

If you are a candidate, practice interviewing without anyone watching, write down your fears before the interview, and simulate pressure.

If you are a recruiter or company, consider implementing collaborative and less stressful evaluations, like pair programming or contextual tasks.