A Karat round is a 60-minute structured video interview inside Karat's own browser platform, run by a contracted Interview Engineer rather than anyone from the company you applied to. The shape is fixed: a few minutes of introduction and consent, roughly half an hour on one data structures and algorithms problem delivered in progressively harder parts, a short block of questions about your experience, then a wrap. It is recorded, and the assessor writes a summary for the employer, so what you say aloud is evidence in the same way your code is.
The hour, clock position by clock position
Timings move by a few minutes between client programmes, and your invitation email is the authority on your slot. What holds across them is the ordering, and the fact that the coding block is protected. Overrun early and you do not get extra time at the end, you get less time to solve.
| Clock | What happens | What the assessor is recording |
|---|---|---|
| 0:00 to 0:05 | The Interview Engineer joins, confirms the recording notice, checks audio and the editor. Often a one-line prompt about your background. | Little that is scored. Your chance to ask whether the editor runs code, and whether the interviewer can share feedback at the end. |
| 0:05 to 0:40 | The coding problem, pasted into the editor or read out, then unfolded in stages. You write in the language you chose when booking. | The bulk of the rubric: clarifying questions, the approach you stated before typing, complexity, edge cases, whether you tested, how you took a hint. |
| 0:40 to 0:50 | Two or three short questions about your experience. A project you owned, a technical disagreement, a decision you would now make differently. | Concrete specifics, scored far more briefly than the coding block. Some client formats move this segment to the front of the hour. |
| 0:50 to 0:57 | Your questions. The assessor can answer about Karat and the process, rarely about the team, the salary or the product. | Usually nothing. |
| 0:57 to 1:00 | The feedback window and wrap. Some programmes give you a spoken read on how it went, or a pointer on what to practise. In others the assessor is not permitted to say. | Nothing further. The write-up is completed shortly after the call, while the session is fresh. |
Why one problem arrives in parts
Preparing by grinding unrelated problems trains the wrong muscle. The common design is one problem opened in stages, so the interviewer can find your ceiling without setting up a fresh context each time. Karat's question sets are client-specific and confidential, so treat the following as the shape, not the content.
Part one: the honest version
A contained task you should finish in ten minutes or so. Parse the input, count the thing, return the list. It confirms you can write correct code at all, and gives the rubric something to mark if the rest goes badly. Do not gold-plate it.
Part two: a constraint moves
Duplicates are now allowed. The input arrives out of order. A second parameter appears. The question is whether your first solution bends or has to be thrown away, so a structure chosen deliberately in part one pays here.
Part three: scale or efficiency
The input no longer fits comfortably in memory, or the operation has to run faster than your nested loop. This is where complexity talk stops being a ritual, because the escalation is engineered to break a quadratic answer.
Part four: the discussion
Often unwritten. How would you test this, what breaks on malformed input, what changes if it runs in production. Reached only if the earlier parts moved quickly, and answered in speech rather than code.
Two consequences follow. Partial credit is real, so a clean part one plus articulate reasoning through part three beats a mangled attempt at everything. And when the interviewer offers a hint, take it: the rubric has a line about responding to guidance, and defending your own approach past that point reads as the failure the line exists to catch.
The write-up is the deliverable, not your code
This is the detail that should change your strategy. The person on the call does not work for the company hiring you. They mark the rubric and write a summary the employer reads, often before anyone opens the recording, and sometimes instead of opening it. Your hour becomes a page of somebody else's prose.
That page is built from things you said. An assessor cannot write "considered a hash map and rejected it on memory grounds" if you only thought it. So make the reasoning quotable.
- State the shape before you type. "I will do this in one pass with a dictionary keyed on the user ID, which is linear time and linear space." One sentence, and it fills three rubric lines at once.
- Name the brute force, then discard it aloud. "The obvious answer is comparing every pair, quadratic, too slow at the sizes you described, so I am sorting first." Nobody can record a trade-off you passed over in silence.
- Announce edge cases as you handle them. Empty input, single element, all duplicates. Said aloud, each becomes a line in the notes. Handled quietly inside a boundary condition, they may be missed entirely.
- Narrate the debugging. "That is off by one because my loop ends at length rather than length minus one." A recovery you explained is a positive note. The identical fix, made wordlessly, looks like flailing.
- Say what you would test. If the editor does not execute code, walk a small example through your function by hand and speak the intermediate values. That dry run is often the strongest thirty seconds of the hour.
The mirror image holds too. Long silences are not neutral here. They are gaps the assessor has to characterise, and the honest characterisation is that the candidate went quiet for four minutes.
Timing traps that quietly cost the round
- Ten minutes of clarifying questions. Two or three sharp ones about input format and constraints score well. A full requirements interrogation, on a problem that will change twice anyway, is time you never get back.
- Optimising part one before part two exists. You do not know which way the problem will escalate. Working code first, then the improvement the interviewer asks for.
- Assuming the editor behaves like your IDE. Karat's is an in-browser editor. Autocomplete, imports and whether you can run the code vary by setup, so ask in the first five minutes, not at minute thirty.
- Treating the experience block like a full behavioural round. Ten minutes, two or three answers. A ninety-second version with one concrete result fits. A five-minute story arc does not.
Where OfferPilot AI is the wrong tool for this call
Our overlay is excluded from screen capture at the operating system level, so it does not appear in a screen share or a recording. On a Karat round that property matters far less than it sounds.
- A live human is present for the full hour, watching your video feed. Capture exclusion has no effect on a person looking at you.
- Capture exclusion hides the overlay from screen sharing and screen recording only. It does not defeat webcam monitoring, lockdown browsers, a proctor watching in person, eye tracking or a second-device camera.
- Karat's editor is part of the recorded session, so code that appears faster than a person types is visible on playback.
- The format rewards continuous, self-generated speech. Anything that interrupts your explanation while you read text works against the exact thing being scored.
- Windows 10 and 11 only. No macOS, no Linux, no mobile, no browser extension.
The tooling earns its place in the fortnight before the invitation lands. Code Copilot returns an optimal solution with the intuition, a dry run and the Big-O, close to the vocabulary a Karat rubric listens for, so practising with it trains the narration and not only the answer. The company Q&A generator builds a bank for a given company and role, and the interview questions library covers the short experience block. Karat runs practice programmes of its own, and a rehearsal on the real platform beats any article about it, this one included.
The short version
One hour, hard stop. Five minutes of setup, about thirty-five on one problem that gets harder in stages, ten on your background, the rest on questions and a possible feedback window. A third-party assessor marks a rubric live and writes the summary the employer reads. On this platform the trace of your thinking is the artifact, and the code is the evidence that the thinking was right.