CoderPad Interviews: How a Live Pair Session Is Scored
CoderPad looks like a stripped-down editor in a browser tab, which leads people to prepare for it like an automated test. It is the opposite. There is a human watching in real time, the session is designed around that, and the things that move the score are almost all behavioural.
What the interviewer sees
They see your keystrokes as you make them, in the same document. Not a submitted result — the whole path. That includes the line you wrote and deleted, the twenty seconds where nothing happened, and text that appears all at once rather than being typed. Many teams also review a session playback afterwards, so a second person may watch the same recording later.
This is not surveillance so much as the actual product: the round exists to show how you work. Once you internalise that the process is the deliverable, most of the right behaviour follows naturally — and one wrong behaviour becomes obvious. A block of finished code materialising in the pad reads unmistakably differently from code being written, and it invites exactly the follow-up questions you would least like.
The environment, concretely
You pick a language and the pad runs it — real execution, real output, not just syntax checking. Depending on the language you get a REPL-style panel, and for database rounds a working SQL sandbox with a seeded schema. There is a drawing or whiteboard mode that is genuinely useful for sketching a data structure or a request flow before you code it, and almost nobody uses it.
What you do not get is your IDE: expect limited autocomplete, no project structure, no debugger, no test runner. Print statements are your debugging tool. Knowing this in advance is most of the preparation — the surprise is what costs time, not the limitation.
Run the code early and often
The single most common self-inflicted wound is writing forty lines and then running them for the first time. You get a wall of errors with nine minutes left, and the interviewer watches you panic-fix syntax instead of demonstrating anything.
Write five lines, run them. Add the loop, run it. Print the intermediate structure to prove it holds what you think it holds. This is how experienced engineers work anyway, it produces constant visible progress, and it converts one large failure at the end into several small corrections that read as competence.
Say the approach before you type it
Thirty seconds of “I am going to build a frequency map first, then a single pass to find the answer — that should be linear time and linear space” does more for your score than the next ten minutes of typing. It gives the interviewer something to grade, it lets them redirect you cheaply if you are heading somewhere wrong, and it makes your silence afterwards legible as work rather than as being stuck.
When you do get stuck, say so specifically: “I know I need the previous index here and I am trying to decide whether to store it in the map or keep a separate variable.” Interviewers are usually allowed to hint, and a precise statement of the blocker is what lets them do it without giving away the answer. A vague silence gets you nothing.
The last five minutes
Leave time to walk your own code once, out loud, with a small input. Say the complexity. Name one thing you would do differently with more time — a test you would add, an edge case you are aware you have not handled, a place you would extract a function. Candidates who close this way consistently score above ones who type until the interviewer stops them, even with identical code in the pad.