You watched the solution. Then you opened an empty editor.

Think about how you actually write software.

You go quiet, stare at the same function, try one direction, delete half of it, check documentation and come back with a better idea. That is normal engineering.

Live coding removes most of that privacy. Now somebody is watching while you understand the task, choose a direction, write code, manage the clock, catch your own mistakes and expose enough reasoning for them to tell whether the mess on the screen is controlled or accidental.

For an introverted engineer, this can feel especially unnatural. Thinking silently may be how you have done good work for years. The interview suddenly asks you to do something you barely practise at work: speak while the thought is still forming.

That is why someone with ten years of production experience can look less comfortable than someone with three years who has trained for this exact room.

A lot of live coding advice tells candidates to keep talking.

That is close to useless because it does not tell you what deserves to be said.

Nobody needs a radio commentary on your keyboard. "Now I am creating a variable. Now I am adding an if statement." That gives the interviewer noise, not evidence.

What they need access to are the decisions.

"I'm going to get the happy path working before I abstract this."

"I see two possible ownership models here. I'm choosing this one because the lifecycle is simpler for the exercise."

"I don't remember the exact API. I know the behaviour I need, so I'm going to sketch it and come back."

"I could extract this behind a protocol, but with twenty minutes left that abstraction is not buying us anything."

That is useful narration. It tells the interviewer where you are, what you are optimising for and whether your unfinished code is unfinished on purpose.

A Senior engineer does not need to look perfect during live coding.

They need to look in control of imperfection.

This is another place where polished tutorials can give you the wrong mental model. The person in the video usually knows the path. Your interview will not feel like that.

You will make a mistake.

Good.

The interviewer now gets to see something much more interesting than whether you remembered an API.

Do you panic and start apologising? Do you keep digging because changing direction feels embarrassing? Or do you stop, inspect what happened and say:

"This is getting more complicated than the requirement deserves. I took the wrong boundary. I'm going to simplify it."

That sentence can tell me more than ten minutes of flawless typing.

Real engineers are wrong constantly. The valuable skill is recognising it before the mistake becomes architecture.

Live coding gives the interviewer a rare chance to watch that mechanism happen in real time.

YouTube, courses, books and walkthroughs are good ways to learn a pattern. The problem starts when consuming the pattern becomes the practice.

You can watch twenty implementations of pagination and still freeze when the empty file belongs to you. You can understand someone explaining state ownership and still struggle to choose a boundary without their finished code in front of you. You can follow a system design perfectly and discover that you cannot reconstruct it when one requirement changes.

The information needs another pass through you.

Your eyes see it. Your brain understands it. Your hands need to reproduce it. Your mouth needs to defend it.

That last half is where interview ability gets built.

If you have a live coding round coming, stop trying to make practice comfortable.

Open an empty project. Set the actual interview timer. Put the tutorial away. Read the requirement once, decide what matters first and start.

Speak when there is a decision worth exposing. If you forget an API, say what behaviour you need and keep moving. If the architecture becomes too heavy, simplify it. If something is ugly but correct and the clock is running, leave it ugly and explain the tradeoff.

You do not need a studio setup. Talk out loud to an empty room and notice where you suddenly go quiet. If you record one practice round, listen back to the reasoning, not the code.

Where did you go silent because you did not know what to do? Where did nerves make you over-explain? Where did you build something the task never needed? Where did you spot the mistake but refuse to change direction?

That is live coding practice.

This is the distinction I wish more experienced engineers understood before their first serious loop in years.

You probably do not need another hundred hours of engineering knowledge. You may need to make what you already know available on demand.

Can you reach the idea without the video? Can you implement it without the finished solution? Can you explain the tradeoff before someone supplies the vocabulary? Can you recover when the first idea fails?

Those are trainable skills.

But you cannot train them entirely by watching somebody else succeed.

That is why I wrote Share Your Screen.

The article you just read is platform-neutral. The book is not. Share Your Screen is for Senior iOS engineers, because it goes directly into the live iOS rounds: coding while somebody watches, narrating the decisions that matter, code review, system design, managing the clock, recovering when you stall and holding a technical position when the interviewer pushes back.

Knowing iOS and showing how you think with iOS under pressure are different skills.

The first one built your career.

The second one may decide the next job.

YouTube gave you recognition. The interview requires retrieval.