CoderPad interview: what the pad records, and how to use it

CoderPad, CodePair, and which one you were actually sent

These are different products from different companies and people confuse them constantly. CoderPad is its own platform; CodePair is HackerRank's live interview environment. The link in your invitation settles it — a coderpad.io address is one, a hackerrank.com address is the other.

Functionally they rhyme: a shared editor, an interviewer watching in real time, code that runs, a timer that does not stop for your setup problems. The differences are in the details — supported languages, key bindings, whether there is a file tree or a shell — which is a reason to open the right one before the day rather than during it.

There is also a second CoderPad product worth distinguishing. CoderPad Screen is the asynchronous one: a take-home style assessment with no interviewer present, which you complete and submit. If your invitation has a deadline rather than a calendar slot, prepare for it like an online assessment, not like a live round.

What the pad records

This is the part most candidates learn afterwards. The pad keeps a playback of the session: every keystroke, every language switch, every deletion, in order. At debrief the interviewer can replay how the solution appeared rather than relying on memory.

Pastes from outside the pad are treated separately. They appear as marked events on the playback timeline — a marker the reviewer can click to jump straight to the moment code arrived from somewhere else. Depending on configuration, the interviewer can also receive a notification when a candidate pastes or leaves the browser tab.

The practical consequence is not dramatic, it is just worth knowing: sixty lines that appear in one instant read differently from sixty lines that were typed. If you do bring in something you wrote earlier, say so out loud — "I'm pasting a helper I wrote while we were talking" costs you two seconds and removes the entire ambiguity.

The editor: languages, autocomplete, key bindings

• Languages. Thirty-odd, including Java, Python, JavaScript, TypeScript, Go, C++, Ruby, SQL. Some pads are configured with a file tree and a shell for a closer-to-real-project session.
• Autocomplete. Yes, for selected languages, and no, it is not your IDE. Treat it as a convenience that might help, never as the thing that will remember an API signature for you.
• Key bindings. The settings panel offers standard, Vim and Emacs bindings, plus tab width and theme. Set these in the first thirty seconds, not at minute twenty when a mis-set tab width has already mangled a Python block.
• What is missing. Your plugins, your snippets, your linter, your muscle memory for jumping to a definition. Everything you rely on without noticing is the thing that costs you here.

Open the sandbox before the interview, not during it

CoderPad publishes a free sandbox — the same editor, without an interviewer on the other side. Fifteen minutes in it is the single cheapest preparation available for this round.

Do exactly what you will do on the day: pick your language, set your key bindings, write a fifteen-line function, run it, read the output pane, make it fail, read the error. The goal is not practice at coding. It is making sure that nothing in the environment is new while somebody is watching you.

Run the code early and often

The pad executes, and that is its main advantage over a whiteboard round. Use it the way you use a terminal.

• Run a stub in the first two minutes. A function that returns a constant, executed once, confirms the runtime works and the output pane is where you think it is.
• Run after each small step rather than writing forty lines and hoping. The interviewer is watching a process; a process with green checkpoints in it looks like competence.
• Keep a tiny test case at the bottom of the pad and re-run it as you go. It is free, and it catches the off-by-one before the interviewer has to point at it.

Say the approach before you type it

Because the session is replayable, silence is not neutral — it is recorded. Two sentences before you start writing do more for the debrief than a clever line of code: what you are about to do, and why that approach rather than the obvious one.

The same goes for the moment you get stuck, which is normal and expected. "This is O(n²) and I think a hash map takes it to linear, let me restructure" is evidence of engineering. Five silent minutes of deleting and retyping is evidence of nothing at all.

The last five minutes

Stop adding features. Run your code against an empty input, a single element, and the largest case you can construct by hand. State the complexity out loud — time and space — even if nobody asked. Then say what you would do with another twenty minutes: the test you would add, the edge case you know is unhandled, the refactor you would make.

Interviewers write that sentence down. It is the difference between somebody who stopped because the clock stopped and somebody who knows exactly what state their code is in.

How the app helps here

Read next