The Live Coding Round, Run From Shared Pad to a Tested Solution

You have a live coding round booked in a shared browser editor, with an interviewer watching your keystrokes as you type them. This guide is for candidates in that exact seat: not the take-home, not the panel, not the one-way video, but the human-watched round scored on visible reasoning rather than a correct final answer. It gives you a minute-by-minute operating procedure for the pad itself - setup, phase budget, narration cadence, and stall recovery - so you leave with a working, explained, tested solution instead of silent half-code.

What the live coding round actually is, and what it scores

A live coding round is a scheduled session, usually 45 to 60 minutes, where you write code in real time while one or more interviewers observe. The thing most candidates get wrong is treating it like a take-home with a shorter deadline. It is not. It is scored on your problem-solving process, and the process is visible.

Interviewers in this round assess a spread of dimensions, not a single pass or fail:

• Problem-solving: how you break the problem down and move toward a solution.
• Communication: whether you can explain what you are doing while you work.
• Code quality: structure, naming, and whether the code is readable.
• Testing and debugging: whether you verify your own work and diagnose failures.
• Time management: whether you finish, and whether you protected testing.
• Adaptability: how you respond when the interviewer changes a requirement mid-round.

No published source puts a numeric percentage on any one of these, so I will not invent one. But the direction is consistent across sources: a correct but silent solution scores worse, because silence makes the interviewer guess at your competence while talking shows systematic thinking. The practical consequence is blunt.

A working brute force narrated at minute 20 beats an unfinished optimal solution typed in silence at minute 45.

There is a second, less obvious reason visible reasoning wins: the round outlives the room. The pad records every keystroke, paste, and language switch into a scrubbable playback timeline that reviewers open at debrief. Replaying pads across reviewers is now common practice to reduce subjective bias, which means a person who was never in your session re-judges you later. Visible iteration survives that replay. A clean final paste with no narration does not explain itself.

The phase budget: why 45 minutes is really 35

A 45-minute round is really about 35 working minutes once the intro and closing questions are removed, so budget it like a sprint. This single fact is why most candidates run out of time before testing: they plan against 45 and the clock quietly ate 10.

Published frameworks agree on the shape and disagree only at the edges. Here is how the main ones carve up the slot.

Two things are stable across all of them. Coding gets the bulk of the time, and testing is protected with its own block. The disagreement is only whether clarify runs about 3 or about 7 minutes, and whether you discuss complexity during planning or after testing. Pick one and move; the indecision costs more than the choice.

The hardest edge of the budget is the minute-12 rule: your first real line of code should be down by minute 12, or you are behind. It is the checkpoint that tells you clarify and planning are over. If you are still asking questions at minute 12, the bottleneck is hesitation, not missing information.

What changes in a shared pad versus your local setup

The biggest time leaks come from the pad's missing tooling, not from the algorithm. Your muscle memory is built for a local IDE, and the shared pad takes most of it away. Knowing this before you start means you waste zero minutes discovering it live.

A few concrete adjustments follow from this table. Your step debugger is gone, so plan to debug with print statements and by tracing values aloud. Project-wide search is gone, so keep your solution compact enough to read in one screen. Your keybindings revert to defaults, so do not fight the editor. And every keystroke is visible as you type, which is the point of the round, not a glitch.

CoderPad's editor does support common conveniences such as autocomplete, bracket closing, multiple cursors, and code folding, but features vary by language. The safe assumption is minimal tooling. Do not assume a specific feature exists because a colleague had it; configuration varies by employer and even between rounds at the same employer. Your invitation and the recruiter are the authority.

The recording, the AI policy, and why pasting backfires

The pad keeps a full record of your session, and that record distinguishes typed text from pasted text. CoderPad Interview records every keystroke, paste, and language switch into a timeline reviewers scrub at debrief. Playback uses yellow markers for external paste events and orange markers for IDE focus-loss, the moments your browser was no longer on the editor. These are review signals a human reads, not automatic verdicts; CoderPad's own docs note that leaving the IDE or pasting does not always equal cheating. But you do not want to be the session a reviewer has to interpret.

On AI: CoderPad's AI Assist is available on all pads by default, and the organization setting only controls whether it starts on or off, not whether it exists. The interviewer can toggle it on or off for your individual pad, and your invitation remains the authority on external tools. That is the whole policy you need. Do not bring your own hidden assistant. A hidden AI tool converts an invisible advantage into a visible marker, because playback shows the signature: long pauses followed by uniform fast typing, then a paste event.

It is worth separating the two CoderPad products, because advice written for one does not apply to the other. CoderPad Interview is the live shared pad with keystroke replay saved afterward, and it has no full-screen enforcement and no documented webcam recording beyond the optional call. CoderPad Screen is the timed, unattended assessment: it enforces full-screen, can block pasting, runs a plagiarism check, and may take webcam snapshots. The round this guide covers is the live Interview. If your invitation describes a timed unattended test, you are in Screen, and the rules are stricter.

The procedure: run the round end to end

Run the round in seven phases, in order, with fixed time for each. The spine is: set up safely, clarify fast, get buy-in on a plan, code while narrating, test by hand, and discuss complexity. The numbers below assume a 45-minute Interview round.

Two phase notes. During clarify, stick to two or three meaningful questions; the goal is only to remove ambiguities that would change the approach, not to demonstrate thoroughness. During planning, the sentence that earns buy-in sounds like this: "Brute force is nested loops, O(n squared) time. I think I can get to O(n) with a hash map. Shall I go with that?" Then wait for the explicit yes before typing.

How to narrate without narrating keystrokes

Narrate decisions and reasons, not keystrokes. The common failure is explaining what you are coding - "now I'm writing a loop" - instead of why, which feels like talking out loud but carries no signal. A simple test: does each sentence contain a because? "I'm using a hash map here because I need O(1) lookups by key" is a decision. "Now I'm typing a for loop" is not.

Keep narration in structured bursts, not a continuous stream. A burst is: state the decision, write the block, then run and report. Continuous narration of every line is noise and slows your typing; silence over about 30 seconds reads as stuck. The rhythm you want is a short spoken decision, a quiet stretch of typing, then a spoken result.

Catching your own error aloud is one of the strongest positive signals you can send. Saying "Wait, that's wrong - if I do it that way I'd be modifying the input, let me use a copy instead" shows exactly the self-correction the role requires. Do not hide the correction and silently retype; say it.

Decision: "I'll [do X] because [reason tied to the constraint]."
[type the block for that decision]
Run: "Let me run this on the example."
Result: "That returns [Y], which tells me [Z]. Next I'll handle [edge case]."

How this goes wrong, and the false positives that hide it

Most of these failures feel productive while you are committing them, which is why they are worth naming. The table below pairs each with the check that catches it in the moment.

A few deserve more than a row.

Clarify runs long. The understand phase tends to overrun. If questions keep coming and no approach forms, the bottleneck is hesitation, not missing information. Commit to assumptions out loud and adjust later. The minute-12 line is your tripwire.

Silent coding. Many engineers need to think before they speak, and in an interview that creates long pauses that look like uncertainty to a watcher. You do not have to narrate while thinking hard, but you do have to break the silence: "Give me a few seconds to work through the indexing here" keeps the channel open.

Debugging by re-reading. When a test fails, re-reading the code in silence looks careful and persuades no one. Instead, run the failing case, state what the result tells you, form a hypothesis, and make a targeted change. Visible debugging is more persuasive than silent editing, and strong candidates diagnose rather than randomly changing code.

The minute-38 panic rewrite. Candidates lose time coding before the approach is agreed, debugging by re-reading, and then rewriting from scratch near the end. After minute 30, do not start a fresh approach. Patch what you have; a working patched solution beats a half-finished rewrite.

Recovering out loud when you stall

The recommended move when you stall is to narrate it, not go silent, because the narrated recovery is itself the scored skill. The role is collaborative problem-solving, so visible recovery maps directly onto what the job requires. This is why a narrated stall can outscore a silent correct answer.

A stall that scores well has a shape. Take a step back, describe where you are stuck, state what the ideal situation would look like, and say what you need to do to convert where you are into that ideal. Then, if you are still blocked, ask whether you are heading in the right direction. Asking for a hint is far better than silence, and interviewers generally hold a hint ready for exactly this.

"Let me step back. Right now I have [current state].
What I actually want is [ideal state].
The gap is [the specific missing piece].
I'm considering [option A] or [option B] - am I heading in the right direction, or is there an angle I'm missing?"

Narrating your uncertainty is not weakness; it is the signal that you know how to keep making progress when you do not have an immediate answer. The contrast is stark: the poorly scored stall is silent or involves randomly changing code hoping something passes. The well-scored stall names the problem and works an example by hand.

Practice so the round is muscle memory

Practice timed mocks in a bare editor with autocomplete off, narrated aloud, with playback review, over roughly two to eight weeks. The protocol that recurs across sources is specific: do at least two timed mock interviews in a blank editor, time yourself, and practice talking through your thinking out loud. A fuller target is six full timed mocks of 45 to 60 minutes each in a sandbox with no autocomplete and no external hints.

The CoderPad Sandbox is free in a browser tab and runs more than 30 languages, which makes it the closest thing to the real environment. Spend 10 to 15 minutes in it before any scheduled interview to check keybindings and confirm language and runtime versions. One operational detail: sandbox tabs are deleted after one hour of inactivity, so save anything you want to keep. Autocomplete covers nine languages and triggers on a dot or Ctrl+Space, and you can disable it in Settings - do, because the real round gives you little of it.

On volume, aim for roughly 50 to 75 problems across about 15 patterns, narrated and timed, rather than silently grinding 500. A 6-week shape moves to medium and hard problems in weeks three and four, starts a 40-minute timer per problem, and runs at least two live spoken mocks per week. Treat each mock like the real thing: record your mistakes, fix them, and redo the same pattern until your explanation is clean.

If you want to pressure-test your narration against people who actually run these rounds, study how practitioners describe them. Refolk can surface the right people to learn from without a cold scroll through platform marketing pages.

Keeping this current

The mechanics of the pad change faster than the method. Re-check three things before each round rather than trusting a value you remembered. First, the AI policy: AI Assist is on by default but toggled per pad, so your invitation and the recruiter, not a blog post, tell you what is allowed. Second, the product: confirm whether you are in the live Interview or the unattended Screen, because full-screen enforcement, paste blocking, and plagiarism checks only apply to Screen. Third, the tooling: open the sandbox and verify your language's autocomplete and runtime version, because features vary by language and configuration varies by employer.

The method underneath is stable. Protect testing, land the first line by minute 12, narrate decisions with a reason, and when you stall, say so out loud and keep moving. Refolk can build your resume and tailor it to each posting so you reach the live round warm, but the round itself is yours to run - and run well, it is the clearest signal a hirer has that you solve problems the way you will solve them on the job.