Karat Interview: Format, Questions and Scoring Rubric

How the hour is spent

Karat's own candidate page describes the hour like this:

• A brief introduction.
• About ten minutes of discussion questions — short questions in your stated area. Factual, quick, not a debate.
• About forty minutes of programming questions in the IDE Karat provides, with the Interview Engineer on the call.

The page does not set aside a slot for your own questions; if time is left at the end, use it. Karat also says plainly that there is no single Karat interview — the content depends on the company and the role.

The session is recorded. Karat sends the recruiter the video together with a summary of how you did on the questions, and the hiring company makes the decision. That means two audiences: the interviewer scoring you live, and whoever at the company rewatches the tape later.

The discussion questions are not a warm-up

The short factual segment catches people out because it feels like small talk. It is part of the score. If you said backend and Python, expect questions on the GIL, on how a dictionary resolves collisions, on what a database index costs on write.

Answer in two or three sentences and stop. A rambling four-minute answer to a thirty-second question costs you coding time you will want back later, and it reads as an inability to judge scope.

Why the problem keeps growing

Karat does not publish its question format, but candidate reports describe the same pattern again and again: a problem in several parts, where each part adds a constraint. Part one is comfortable. Part two adds a requirement. A later part can make your part-one structure wrong — a list that now needs to be a heap, a single pass that now needs a cache.

Knowing that in advance changes how you write part one. Keep it clean and factored, name things properly, and do not inline everything into one function you will have to unpick under time pressure. Karat's candidate page says the primary criterion is how successfully your code solves the problem, so working code for the parts you reach matters — and clean early code is what lets you keep moving when the next part arrives.

Say the things that get written down

Karat says it measures competencies on a structured rubric, and it names technical communication — explaining trade-offs and what is causing a bug — as one of them. Evidence means sentences the interviewer can write down. Three habits produce most of it:

• State the complexity before you are asked. "This is O(n log n) because of the sort, and O(n) space." That is one line, and it is exactly the kind of thing a rubric asks for.
• Ask about constraints and edge cases at the start. Input size, duplicates, empty input, whether the data fits in memory. Clarifying questions are part of problem solving, not a delay.
• Narrate the brute force before you optimise it. "The naive version is quadratic; let me get that working and then cut it down." If you run out of time, you still have working code and a stated plan.

Karat describes a good performance as working through the problems steadily, without getting stuck or lost for long stretches. Long silent stalls are the opposite of that, and they give the rubric almost nothing to hold on to.

If the company sends an automated round such as a Codility test instead, the logic flips: nobody hears your reasoning, and hidden test cases decide the score.

AI, languages and the redo

Karat says its library includes interviews that allow ChatGPT and interviews that do not, so whether AI is permitted is decided per company and per interview. Your invitation or the recruiter is the only reliable answer; do not assume either way. Karat also says it supports more than 100 languages and frameworks.

Karat describes a Redo: if you feel you did not perform your best, you can ask for one within 24 hours of the interview. The redo uses a new set of questions, and Karat sends both results to the company, which decides whether to move you forward. Ask your recruiter whether it is offered for your role.

For how Karat's rules and recording compare with other platforms, see what interview platforms actually log.

Practical details worth knowing beforehand

You code in the environment Karat provides — it calls it a fully tooled IDE — not in your own setup, so your plugins, snippets and personal shortcuts will not be there. Spend ten minutes the day before writing a linked list and a hash map outside your usual editor, so the difference is not a surprise on the day. If the Karat round is your first technical conversation, see also what a technical phone screen decides.

The session is recorded and you will be on screen. Have the desktop presentable, the notifications off, and one glass of water within reach: it is a fast hour, and it is the same hour whether or not you spent it explaining yourself out loud.

Scheduling the Karat interview

Karat’s candidate page says you can book the interview at a time that suits you, including weekends, evenings and lunch hours, and that 60% of its interviews are scheduled outside core business hours. Use that. The slot that matters is the one where you are rested and the room is quiet, not the first free hour after the invitation arrives.

Before the day, open the invitation and note three things: the language you named, the topic area for the discussion questions, and whether the rules for this company allow ChatGPT. Then test the camera and microphone in the same browser you will use, close everything that can post a notification, and keep the invitation email open in case you need the link again.

What a multi-part question feels like

Karat does not publish its questions, and we do not reproduce leaked ones. The example below is our own illustration of the pattern candidates describe, written so you can practise the habit rather than the answer.

• Part 1. You get a list of (user, page) visits. Return, for each user, the page they visited most often. A hash map of counts is enough; say the complexity, O(n) time and O(n) space, before you are asked.
• Part 2. Now return the longest run of pages that two given users both visited in the same order. The per-user counts from part 1 no longer help; you need each user’s ordered history, and a dynamic-programming table over two sequences.
• Part 3. Now do it for every pair of users. The quadratic pair loop is the obvious answer, and saying out loud why it is slow, and what you would index to avoid it, is worth more than silent typing.

The skill being tested is not the third part. It is whether the code from part 1 was clean enough that you spent your time on part 2, rather than on untangling part 1.

After the interview: results and the redo decision

Karat sends the recruiter the recording and a summary of how you did on the questions, and the hiring company decides the next step and contacts you. Karat does not publish a timeline for that, so ask the recruiter what to expect rather than reading silence as a no.

The redo has a short clock. Karat’s page says you request it within 24 hours of the original interview, you get a new set of questions, and Karat publishes both recommendations to the company, which decides whether to advance you. So decide the same evening: a redo is worth it if something outside the problem went wrong, such as a broken connection or a misread prompt you only saw afterwards, and less so if the questions were simply hard, because the company sees the first result too.

Sources

• Karat — Candidate Experience
• Karat — What do Karat technical interviews measure?
• Karat — Redo interviews
• Karat — The Karat Interview (FAQ: languages, ChatGPT)

Checked against these pages on 14 October 2026 and rechecked on 9 November 2026. The multi-part problem format comes from candidate reports, not from Karat, and the worked example above is ours.

How the app helps here

Related articles

Read next