My first real tech interview lasted twelve minutes. Not because I was brilliant and they fast-tracked me. Because twelve minutes in, the interviewer closed his laptop, smiled politely, and said "we'll be in touch." I walked out knowing I would never hear from them again. I did not.
Here is the part that stung: I had prepared. I had done the tutorials, solved the practice problems, read the blog posts about interview tips. I was ready for the interview I imagined. I was not ready for the one that actually happened.

What actually went wrong

The interviewer gave me a small task: take a list of user records and return the ones whose email domain matched a given company, sorted by signup date. Easy. I had done harder problems for fun.
I froze anyway. Not because I did not know the answer, but because I started narrating my thinking out loud the way the tutorials told me to, and the narration tangled with the thinking. I said "so I'll filter first, then sort, actually maybe sort first" while typing nothing. Three minutes passed. My screen was empty except for a function signature.
Then the interviewer asked the question that ended it: "Walk me through how you'd test this." I said something vague about unit tests. He nodded. He closed the laptop.
A week later I asked for feedback, expecting silence. To my surprise, he replied. Two sentences: "Your code knowledge is fine. You went quiet for three minutes and I had no idea what you were thinking, so I couldn't help you."
That was the whole failure. Not knowledge. Silence.

The fix I actually use now

I changed one thing about how I prepare, and it sounds stupid until you try it: I practise talking while I code, out loud, alone, in my room, feeling like an idiot.
Every practice problem now gets the full treatment. I read the problem out loud. I say what I am about to do before I type it. When I get stuck, I say "I'm stuck here because..." instead of going quiet. The first week it felt ridiculous. By the third week, the narration stopped fighting my thinking and started guiding it.
The second change: I stopped preparing answers and started preparing recoveries. Interviews go wrong in predictable ways — you blank on a method name, you misread the problem, your first approach fails. I practise the recovery lines: "Let me re-read the problem," "My first idea won't work because..., let me try this instead," "I don't remember the exact syntax, here's the logic and I'd check the docs for the method name." Saying those sentences calmly is a skill, and it is trainable.
The third change: I ask for the test question before they ask me. After I finish a practice problem, I write two tests for it. Just two. That habit meant that the next time an interviewer asked "how would you test this," I had a real answer instead of a vague one: "Empty list first, then one matching record, then a record with a subdomain that should not match."

What happened next

My second interview ran the full hour. I did not get that job either — someone with more experience beat me, fair enough. But the feedback was different: "Clear communicator, good reasoning, needs more depth on system design." That is a useful rejection. It tells me what to study next. The twelve-minute one told me nothing except that I had gone quiet.
Interviews are not exams. An exam measures what is in your head. An interview measures what you can show another person is in your head, under mild pressure, while talking. Those are different skills, and only one of them gets practised by solving problems alone in silence.
If you are preparing for your first interview, do the problems, yes. But do at least a few of them out loud, with a timer, talking to an empty room. It feels absurd. It is also the closest thing to the real event, and the real event is the one that counts.
Twelve minutes taught me more than twelve tutorials. I just wish it had not cost me a job to learn it.