Communication.

For me, communication is the real interview. Your interviewer can't grade what they can't see, so I make sure they can see all of it.

What I say out loud

I narrate everything, before I write a single line of code:

• Clarifying questions about the problem.
• Assumptions I'm making.
• Tradeoffs between the approaches I'm considering.

This is built into how I run every interview, using the REACT method.

If I run out of time, the interviewer has still heard the full plan and knows I would have finished it. Silence gives them nothing to go on.

My Google interview

I had two interviews, both 45 minutes. The first one I solved with time to spare. In the second, I got the approach right, spotted a bug in my own logic, worked out the fix out loud, and ran out of clock before I could type it.

That second interview still passed. Not because the code compiled, but because the interviewer could follow how I was thinking, I caught my own mistake, and I'd asked the right questions and explained before writing anything.

Practising it

Almost nobody practises this part. Most people grind problems alone in silence, then get into a real interview and go quiet at the exact moment they need to be talking.

So I explain problems out loud every time I practise, even when no one's listening. If I can't explain my approach in plain English before I code it, I don't actually understand it yet.

The other two things that helped me most here were mock interviews and using AI as my interviewer.