How coding interviews work

By the Mockich team · Updated October 31, 2026 · 8 sources

A live coding interview usually runs 45 to 60 minutes around one or two problems: clarify and plan, write the code while explaining it, test it, then discuss complexity and a follow-up. The guides we read agree that four things are scored, under different names: communication, problem solving, code quality and testing. The failures they report most are coding before a plan, working in silence and declaring the code done without testing it.

Key points

State your plan and its complexity before you type. A brute-force plan said out loud is a better start than silence.
Talk through the decisions, not every keystroke. Both silence and a running commentary are reported as failures.
Test before you say you are done: walk an example through the code, then the edge cases.
A hint is not a fail. What gets noted is whether you understood it and moved forward.
Expect roughly 20 to 25 minutes of actual coding in a 45-minute round. Time is the dimension nobody names.

The usual shape of the round

The times below are for a 45-minute round as the guides describe it. Some rounds have two medium problems, others one problem with harder extensions; the steps are the same.

Step	Typical time	What happens
Introductions	About 2 min	Short and low in signal.
Clarify and plan	3 to 8 min	Restate the problem, ask about input size, format and edge cases, propose an approach with its complexity, and get a nod before coding.
Implement	15 to 25 min	Write the code and share the main decisions. The interviewer mostly stays quiet while you make progress.
Test and debug	5 to 10 min	Run an example through the code by hand or in the editor, then the edge cases. Find and fix your own bugs.
Complexity and follow-up	About 5 min	Time and space complexity, “can you do better?”, and a variant of the problem if time is left.
Your questions	2 to 5 min	You ask; the interviewer answers.

Sources: [2], [3], [4], [7]

What interviewers look for

No company publishes its coding rubric. The prep guides and the interviewer-facing guide we read list the same signals:

Communication: clarifying questions, the plan before the code, the reasoning while coding, and how you take a hint.
Problem solving: a systematic route from a working idea to a better one; more than one approach, with the reason for the choice, is a strong signal.
Complexity: accurate time and space, and what would change them.
Code quality and correctness: working code with clear names and a structure that covers the whole input range, not only the example.
Testing and debugging: normal, boundary and awkward inputs, and finding the cause of a failure with a hypothesis instead of random edits.
Using feedback: adjusting after a hint or new information, and treating the interviewer as a collaborator.
Time: a working solution early enough to test it and take the follow-up.

Sources: [1], [3], [4], [7]

The mistakes guides report most

Starting to code before clarifying the problem or saying the plan.
Working in silence, or narrating every keystroke instead of the decisions.
Not testing, testing only the happy path, or saying “done” with visible bugs.
Leaving out the complexity, or getting it wrong.
Changing code at random when a test fails.
Ignoring or arguing with a hint.
Freezing on an unfamiliar problem instead of breaking it into smaller parts.
Running out of time: starting the code late or chasing the optimal solution too early.

Sources: [1], [2], [4], [5]

How hints work

The interviewer-facing guide we read recommends preparing hints from the gentlest to the most direct, asking the candidate to explain their thinking first, moving one step at a time, and writing each hint down so the scorecard can separate your work from the interviewer’s. “What are you thinking?” is the usual first prompt.

The prep guides agree on what this means for you: a hint caps the top score, because needing no major hint is what the top band describes, but using a hint well protects the middle. Say when you are stuck, take the hint, and say what changed.

Sources: [4], [5], [7]

How the bar changes with level

Fewer sources cover levels in coding rounds than in system design, so treat this table as a tendency, not a rule.

	Junior and mid-level	Senior and above
Problem	Typical medium problems, sometimes two	One problem with harder extensions, or practical and concurrency work
Hints	Using a hint well is fine	Should need no major hint
Driving	The interviewer may prompt for the plan and the tests	You clarify the ambiguity and test without being asked
Beyond the function	Not expected	Scale, concurrency, failure, maintainability and monitoring

Sources: [3], [4]

AI-assisted rounds, and why one interview is noisy

Some companies now run coding rounds with an AI assistant allowed. The format is not settled; where it is used, the guides say the signals move to clarifying before prompting, owning the design and checking the generated code, including its complexity claims and edge cases.

One mock interview platform’s data, from a small 2016 sample, found that only about a quarter of candidates scored consistently from one interview to the next. A single round is a noisy measure: a trend over several rounds tells you more than one score.

Sources: [6], [8]

Go deeper on this round

Practise the round out loud

Mockich’s coding round has the same shape: approach, implementation, then testing and a follow-up, 45 min in all. Your code runs in the editor, Vera asks for your plan and its complexity, and gives at most three small nudges, never the answer. The report scores problem solving, code quality, complexity, testing and communication (plus production thinking at lead) and quotes what you said.

Start a free mock interview How the practice round runs Read a sample report

Sources

We read these public guides on 2026-10-30 and summarised where they agree, in our own words. They report typical practice, mostly from former interviewers; no company publishes its coding rubric, and formats differ between companies and levels.

[1] Tech Interview Handbook, Coding interview rubrics
[2] Tech Interview Handbook, Coding interview techniques
[3] Aced, Coding Interview Rubric: An Inside Look
[4] PracHub, Technical interview rubric: how companies score coding, design and communication
[5] Formation, 5 common mistakes engineers make in technical interviews
[6] Formation, AI-assisted coding interviews
[7] Metaview, How to lead a coding interview
[8] interviewing.io, Technical interview performance is kind of arbitrary. Here’s the data.