Which platforms run coding interviews, and how do they differ?

The invitation email usually names the platform, and that name tells you most of what the session will feel like. The platforms fall into four families.

• Live shared editors. CoderPad, CodeSignal's interview mode, HackerRank Interview (formerly CodePair), and similar pads open a document that both you and the interviewer can edit. Most of them can run code in a handful of languages; some employers deliberately turn execution off so you reason instead of trial-and-error.
• Plain shared documents. Some teams still send a Google Doc or an empty text pad over Zoom or Google Meet. No syntax highlighting, no run button, no tests; the interviewer reads your code the way a reviewer would.
• Timed online assessments. HackerRank, Codility, and CodeSignal deliver a fixed problem set with a clock and an automatic grader. Nobody is on the call; the platform records your session and scores hidden test cases.
• Interview-as-a-service vendors. Karat and comparable providers supply a trained engineer who runs a live technical interview on the vendor's own pad and writes the report the employer reads. The format is live, but the person across the call is not your future colleague.

Employers mix these. A typical loop starts with an assessment, moves to one or two live pad rounds, and ends with a design conversation on a whiteboard tool or a plain call. The platform-vetting topic covers the individual vendors in more depth.

Five properties decide how a session plays out, and they vary more between platforms than the problem difficulty does.

• Live or asynchronous. A live pad is a conversation; you can ask about constraints and get hints. An assessment is a silent exam; the only clarification is the problem statement.
• Code execution. Pads with a run button let you check a case before you claim it works. Plain documents and execution-disabled pads make you the interpreter, so you narrate what each line does.
• Visibility of your typing. On a live pad the interviewer sees every keystroke, pause, and deletion as it happens. Rewriting a function three times is visible; it is not necessarily bad, but silence while you do it is.
• Language and tooling. Most pads support the mainstream languages, but library access, autocomplete, and a debugger vary. Assessments often restrict you to the languages the grader supports.
• Recording and proctoring. Live rounds are commonly recorded for the debrief. Assessment platforms offer optional proctoring, which can mean webcam snapshots, browser tab-switch logging, or copy-paste flags; whether it is switched on is the employer's decision, and the invite rarely says.

The last property is the one to plan around. Treat any timed assessment as if proctoring is on unless the instructions say otherwise.

It is reasonable to worry that practice on one platform will not transfer to another. This section gives you a preparation routine per format, and the short version is that the coding skill transfers while the session habits do not, so rehearse the habits on purpose.

• For live pads: practice in a browser editor with no autocomplete, talk while you type, and write one small test case by hand before you run anything. If the pad has a run button, use it after you have explained your approach, not instead of explaining it.
• For plain documents: practice writing correct code without a compiler. Consistent indentation and short functions matter because the interviewer reads, not executes.
• For timed assessments: practice under a clock with hidden tests in mind: handle empty input, duplicates, and the largest allowed sizes. Read the whole problem set first and order the problems by expected effort.
• For vendor interviews: expect a standardized rubric. Interviewers from Karat-style providers score communication and problem decomposition explicitly, so state your plan before you code.

A backend engineer interviewing for a senior role at a payments company gets three different invitations in one week: a CodeSignal assessment, a CoderPad round with execution enabled, and a final round in a shared document. She rehearses each format once, and the only thing she changes between them is how much she narrates. The mock interview tool on SubcueAI is a convenient way to rehearse the narration part out loud.

Only in the formats where someone is talking to you. SubcueAI's native macOS and Windows desktop app captures both system audio and your microphone, so it hears the interviewer's question on Zoom, Google Meet, or Microsoft Teams and shows suggestions in a floating overlay that exists only on your own screen. Its browser extension Side Panel does the same for calls that run in a browser tab on Chrome or Edge, capturing the meeting tab's audio only, so it hears the interviewer and never transcribes you. Neither surface joins the call as a bot or injects anything into the meeting page or the coding pad; the Firefox build of the extension supports mock practice only.

That scope has clear edges. A timed assessment has no conversation, so an assistant that listens has nothing to work with, and proctored assessments that log your tabs or watch your webcam are outside what SubcueAI is for. On a live pad, sharing your entire screen would put the overlay on the shared feed; share the pad's window or nothing. Recorded rounds and employer-managed devices are also out of scope. Aaron Cao, founder of SubcueAI, designed the overlay as a local window rather than a meeting participant for exactly this reason: it should never become part of what the platform records. Setup steps for each surface are on the tutorial page, and the security page explains what is captured and what is not.