Coding Interview Evaluation Criteria: The Real Rubric

Most candidates prepare for a coding round as though it were a pass or fail test of whether the code runs. It is not. The coding interview evaluation criteria on a real scorecard split one answer into four or five separate judgements, and "the tests passed" is only one of them.

That is why the most common story in this market is an engineer with four hundred solved problems and a rejection email. The problems trained one dimension. The interview scored six. Below is what those dimensions are, what a weak and a strong answer look like on each, and how to practise against them instead of against a problem count.

What is actually on an interviewer's scorecard

An interviewer is not grading a submission. They are writing a short argument to a hiring panel about how you would behave on their team, and the scorecard exists to stop that argument being "I liked them". So the form asks for a level per dimension plus the evidence for it — a line from the conversation that supports the number.

Two consequences follow, and both are counter-intuitive the first time you hear them.

First, unfinished code can outscore finished code. A candidate who states the approach, names the trade-off, gets the complexity right and runs out of time at the last loop has scored on four dimensions. A candidate who silently types a working solution in nine minutes has scored on one, and the interviewer has nothing to write in the evidence column.

Second, anything the interviewer had to extract from you is worth less than the same thing offered. "What is the time complexity?" answered correctly is a pass. The same sentence said unprompted is a signal about how you work when nobody is auditing you.

The coding interview evaluation criteria, dimension by dimension

The wording differs between companies, but the dimensions converge. For each one below: what is being measured, and the observable difference between a weak answer and a strong one.

Problem understanding

Measured by what you establish before you write anything. Can the input be empty? Are duplicates possible? Is the array sorted? Do you return the index or the value? Should the function mutate its argument?

Weak looks like restating the question back and starting to type. Strong looks like three specific questions whose answers would change the solution, then a one-sentence summary of the problem as you now understand it. The point is not politeness. A candidate who confirms the constraints cannot solve the wrong problem, which is the single most expensive failure in a forty-minute round.

Approach and trade-offs

Measured by whether more than one solution existed in your head before you chose. An interviewer wants to hear the brute force named and priced, then the improvement and what it costs.

"I could sort first and scan, which is O(n log n) and needs no extra memory, or I can hash as I go for O(n) time and O(n) space. Inputs are large and memory is cheap here, so I will hash" is a complete answer to this dimension in fifteen seconds. Jumping straight to the optimal solution scores lower than you would expect, because the interviewer cannot tell whether you reasoned to it or recognised the problem from practice.

Communication under questioning

This is the dimension candidates most often lose and least often practise. It is not measured by fluency; it is measured by what happens when someone pushes back. When the interviewer says "are you sure that handles duplicates?", does the explanation get clearer or vaguer?

The strong pattern is to restate the objection in your own words before answering it, then either defend the design with a reason or accept the correction and say what you are changing. The weak pattern is to keep talking in the same words, slightly faster, hoping the question goes away. Interviewers read the second as someone who will be hard to review code with.

Complexity reasoning

Measured by whether you can price your own solution and defend the price. Both time and space, stated unprompted, including the cost of the data structure you reached for rather than only the loops you wrote.

A level above that is knowing what would have to change to do better: "this is O(n log n) because of the sort; if the values were bounded I could count them and get O(n)". That sentence tells the interviewer you understand where the cost lives, which is the actual skill being tested.

Edge cases and verification

Measured by what you check without being asked. Empty input, a single element, duplicates, all-equal values, negative numbers, integer overflow on a sum, and the off-by-one at the boundary of your own loop.

The highest-value habit here is dry-running your code out loud on a small input before announcing you are done. It catches real bugs, and it demonstrates the thing interviewers are actually probing: whether you test your own work before handing it to someone else. Saying "it works" is not verification; walking an input through the loop is.

Code quality

Measured lightly, but measured. Interviewers read interview code the way they read a pull request, and the criteria are the same ones engineering organisations publish for their own reviews. Google's guidance on what to look for in a code review lists design, functionality, complexity, tests, naming, comments and style — and defines "too complex" as code that cannot be understood quickly by code readers. That definition is exactly what a reviewer applies to your whiteboard function.

Naming and readability

No offer has ever been lost to a loop variable called i. Marks do get lost to names that mislead — a variable called sorted that is not sorted, or result holding an intermediate. Pick names a reader would not have to correct.

Comments that say why, not what

The same principle Google applies to change descriptions — that a record of a change must communicate both what changed and why — is what makes an interview comment useful. A comment restating the line below it is noise. A comment recording the decision you made, such as why you chose a heap over a sort, is evidence for two dimensions at once.

What a 2 and a 5 sound like on the same question

Take a standard question: find two numbers in an array that sum to a target. Both answers below end with working code. They do not end with the same score. These are illustrations of the rubric levels, not transcripts of any real candidate.

The low-scoring version. Forty seconds of silence. Then "okay, I will use a hash map", then typing. At the end: "done, that works". When asked for the complexity: "O(n)". When asked about duplicates: "it should be fine".

That answer scores on correctness and almost nothing else. Problem understanding has no evidence, approach has no alternative, communication is three words long, and the duplicate question got an assertion instead of a check.

The high-scoring version. "Two quick things first — can the same element be used twice, and do you want indices or values? Assume indices and no reuse. Brute force is two nested loops, O(n squared) time and no extra space. If I store each value with its index as I scan, I get one pass at O(n) time and O(n) space, which is the trade I would take unless memory is tight. Edge cases I want to be careful about: an empty array, exactly two elements, and duplicate values where the pair is the same number twice. Writing it now." Then, after coding: "Let me walk through [3, 3] with target 6 — first iteration stores 3 at index 0, second finds the complement already present and returns [0, 1]. Good. Time O(n), space O(n), and the dominant cost is the map, not the loop."

That is about forty seconds of extra speech. It moves four dimensions from the bottom band to the top one, and none of it required knowing anything the first candidate did not know. This is the part that is learnable by repetition rather than by solving more problems — which is the whole argument for rehearsing out loud, and the reason we built an AI interviewer that asks follow-ups rather than a question bank.

How Taqari scores the same round

We publish our rubric because a score you cannot inspect is not feedback. The coding round is scored on four model-judged criteria, each on a nought-to-three scale:

• Correctness of approach — does the chosen algorithm solve the stated problem, including the edge cases the problem implies. Explicitly not "did the tests pass".
• Complexity reasoning — can you state the time and space cost of your own solution and defend it. Nought is no claim, or a wrong claim left uncorrected. Three is a correct claim offered unprompted, plus what would have to change to improve it.
• Communication under questioning — when the interviewer pushes, does the explanation get clearer or vaguer.
• Response to a hint — what you do with a nudge, which is frequently more predictive than where you started.

Everything factual sits outside the model. Test outcomes, runtime, submission count and session signals are computed by the pipeline and handed to the judge as context, never guessed by it. The engineering detail of that split — and why the overall number is arithmetic rather than a model's opinion — is in our write-up of the rubric that makes scoring reproducible. The scale is enforced as a closed set in the schema rather than a numeric range, because the supported JSON Schema subset does not enforce minimum and maximum.

What you see at the end of a session is a row per criterion with the evidence attached, in roughly this shape:

Complexity reasoning            2 / 3
  You stated O(n) time correctly at 06:14, unprompted.
  Space cost was not mentioned until the interviewer asked.
  To reach 3: price the data structure, not only the loops.

Communication under questioning  1 / 3
  Asked "does this handle duplicates?" at 09:02, you repeated
  the original explanation rather than addressing the case.
  To reach 3: restate the objection, then defend or revise.

The per-criterion split is the point. A flat seven out of ten tells you nothing you can act on this week. "Complexity 2, communication 1" tells you exactly which forty seconds of your next session to change.

Why levels are written as observations, not adjectives

"Good communication" is an adjective, and two readers will score it differently. "Restates the interviewer's objection in their own words before answering it" is an observation that either happened in the transcript or did not. Every level in our rubric is written that way, which is also what makes the feedback quotable back to you with a timestamp. When you write your own practice checklist, use the same test: if you cannot point at it in a recording, it is not a criterion.

Where the bar moves: service company to product company

If you are interviewing out of a service company in India, the dimensions do not change but their weights do. Service-company interviews often lean on what you have delivered and which stack you know. Product-company loops lean on how you reason about a problem you have not seen, because they are hiring for the next three years of unfamiliar problems rather than for a known project.

In practice that means three shifts worth preparing for:

1. Approach gets interrogated. Expect "why not the other way?" on a solution that already works. The answer is a trade-off, not a defence.
2. Your own project is scored like a design question. "Why Kafka and not a cron job?" is the same rubric dimension as the array question — alternatives, cost, decision.
3. Hints are part of the test. A good interviewer gives you one on purpose. Taking it gracefully scores; arguing with it to protect the first answer does not.

None of that requires a different problem set. It requires rehearsing the explanation layer on problems you have already solved.

How to practise against the rubric

Pick one dimension per week and let your overall score go wherever it goes. Four weeks, one change at a time:

1. Week one — baseline, unprepared. Two sessions, no warm-up, and write down your two lowest dimensions. The number will be worse than you expect; that is the measurement working.
2. Week two — the lowest dimension only. If it is communication, the single goal in every session is narrating the approach before typing. Ignore whether you finish.
3. Week three — add the clock. Keep the new habit and cap yourself at the thirty-five to forty-five minutes a real round gives you.
4. Week four — mix the rounds. Alternate DSA, system design and behavioural so you practise switching registers, which is what a real loop demands in a single morning.

Record yourself if you have nobody to practise with, and watch the first three minutes only. Almost everything this rubric rewards happens before you start typing. Our walkthrough of how to structure a month of practice covers the schedule in more detail.

What quietly costs you marks

• Silence. An interviewer cannot score thinking they cannot hear. A wrong idea said out loud outscores a right idea kept private, every time.
• Backtracking without saying so. Deleting six lines in silence reads as confusion. "That approach breaks on duplicates, I am switching to a map" reads as judgement.
• Waiting to be asked for complexity. Extracted answers are worth less than offered ones on every scorecard.
• Announcing done before testing. It converts a verification signal into a correctness risk, for no gain.
• Over-engineering. Google's reviewers are told to be especially vigilant about it; interviewers are no different. Solve the problem asked.
• Treating a hint as an insult. It is a scored opportunity, handed to you on purpose.

The bottom line

The coding interview evaluation criteria reward a narrated, priced, tested solution over a silent correct one — and that gap is almost entirely habit, not knowledge. If you have solved hundreds of problems and keep getting rejected after the round, the missing skill is very unlikely to be another pattern. It is the forty seconds at the start where you confirm the problem and name the trade-off, and the forty seconds at the end where you walk an input through your own code.

Both are rehearsable. Pick the dimension you score worst on, change only that for a week, and read the feedback more carefully than you read the score. You can run a free mock round and see the per-criterion breakdown for yourself before you book anything that matters.