The anxiety is mostly unfamiliarity with the format, not a lack of skill. Practise thinking out loud until it is routine, use a fixed structure so you always know the next step, and expose yourself gradually: recording, a friend, pair programming, then real rounds. Comfort comes from repetition, not reassurance.
What people tell me
On my own I can solve problems and build things reasonably well. But as soon as someone is watching, whether it is a live coding round, a pair programming session or even a teacher looking at my screen, my mind goes blank. I forget simple syntax, my hands shake a little, and I start rushing. Afterwards I solve the same thing easily. I am worried this will stop me getting hired or make me look weak at work.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Solving alone and solving while watched are different skills. The second one is trainable.
- A fixed structure (restate, example, approach, code, test) gives your mind something to hold when it goes blank.
- Narrating your thinking turns silence into collaboration and takes pressure off getting it right instantly.
- Build exposure in steps: record yourself, then a friend, then pair programming, then real rounds.
- Interviewers and teammates mostly want to see how you think, not a perfect answer in one pass.
This is a separate skill, not a flaw in you
Many capable engineers go blank when someone watches them code. Your brain is doing two jobs at once: solving the problem and monitoring how you look while solving it. The second job eats the working memory the first one needs. That is why simple syntax disappears and why the same problem is easy an hour later.
The good news is that being watched is a skill like any other. People who seem calm in live coding usually are not braver than you. They have done it enough times that it no longer feels like a threat.
Give your mind a script to follow
When anxiety hits, the worst part is not knowing what to do next. A fixed routine solves that. Use the same five steps every time:
- Restate the problem in your own words and confirm it.
- Work a small example by hand, including one edge case.
- Describe an approach before writing code, even a slow one.
- Write the code while narrating what each part does.
- Test it by walking through your example and the edge case.
If your mind goes blank, you always know where you are in the list and what the next step is. That alone reduces panic.
Think out loud, deliberately
Silence is where anxiety grows. You feel the other person waiting and start judging yourself. Talking fills that space and changes the dynamic from exam to conversation. Useful phrases to have ready:
- "Let me think through a small example first."
- "My first idea is a simple version that is slower. I will get that working and then improve it."
- "I am not sure about the exact method name. I will write what I mean and check it after."
- "Give me a moment to think about this edge case."
These are not tricks. They are what experienced engineers say in real pair programming sessions every day.
Build exposure in steps
Jumping straight into high-stakes rounds is like learning to swim in the sea. Build up gradually:
| Stage | What you do | How often |
|---|---|---|
| 1 | Record your screen and voice while solving a problem out loud | 3 times a week for two weeks |
| 2 | Solve with a friend or classmate watching, then swap roles | Weekly |
| 3 | Pair program on a real project, taking turns driving | Weekly |
| 4 | Mock rounds with someone you do not know well | Every two weeks |
| 5 | Real rounds and code reviews at work | As they come |
Watching your own recordings is uncomfortable, and extremely effective. You will notice you look far calmer than you felt.
Handle the physical side
Anxiety is partly physical, and a few simple things help:
- Slow your breathing for thirty seconds before starting. Longer exhales than inhales.
- Write things down. Moving thoughts onto paper or a comment frees working memory.
- Have water nearby and give yourself permission to pause.
- Before a round, solve one easy warm-up problem so your first attempt of the day is not the one being watched.
Change what you think is being judged
People often believe the evaluator wants a perfect solution typed fluently in one go. In reality, most interviewers and senior teammates are looking at whether you clarify the problem, reason step by step, handle being stuck, and respond to hints. A candidate who gets stuck, says so, and works through it calmly often does better than one who silently produces a correct answer.
At work, pairing with a senior engineer is not an exam either. They are usually trying to help you or to get something done together.
What to do if you freeze anyway
It will still happen occasionally. When it does, say it plainly: "I have gone blank for a second, let me go back to the example." Then return to step two of your routine. Naming it takes the power out of it, and most people watching will respect the recovery more than they notice the freeze.
A self-check after each practice session
After every recorded or observed session, score yourself from one to five on each line and write one sentence about the lowest score:
| Check | What a 5 looks like |
|---|---|
| Clarified the problem | Restated it and asked at least one question before coding |
| Kept talking | No silence longer than about thirty seconds without saying what you were thinking |
| Recovered from a blank | Named it and went back to the example |
| Tested the solution | Walked through a normal case and an edge case |
Track the scores for a month. The anxiety itself may not fall quickly, but the scores will rise, and that is what the person watching actually sees. For more on what happens after a round that goes badly, see how to recover after failing a technical interview.
If you are still stuck
Read Fifteen problem shapes and the move that solves each to make problem solving feel more familiar, and What actually changes in your first two years as an engineer for what being evaluated at work really looks like. If you want someone to look at your specific situation and practise with you, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- Fifteen Problem Shapes and the Move That Solves EachThe usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.