How Coding Interviews Are Scored: Inside the Rubric

If you think a coding interview is graded on whether your code passes the test cases, you are optimizing for one quarter of the score. Across FAANG-tier companies, interviewers grade you on roughly four dimensions, and only one of them is about the code sitting in the editor when time runs out. Coding interview evaluation rubrics can be split broadly into four dimensions: communication, whether the candidate makes clarifications and explains while coding; problem solving, whether they come up with a sound approach and analyze trade-offs; technical competency, how fast and accurate the implementation is; and testing, whether the code was checked for common and corner cases and bugs were self-corrected. We run mock interviews all day, and the single biggest surprise for strong coders is how much of the score lives outside the syntax.

This is a walkthrough of the actual rubric, how each dimension is scored, how those scores turn into a hire or no-hire decision, and how to practice against it instead of guessing.

The four dimensions every rubric shares

The terminology differs by company, but the buckets are stable. Google, for example, scores coding rounds on named categories rather than a single number. Google scores coding rounds across four areas: Algorithms, Coding, Communication, and Problem Solving, and only one of them is primarily concerned with the code sitting in the editor at the end of the interview. Map those onto the generic rubric and the pattern is obvious: two of the four categories (Communication and Problem Solving) are about how you think and talk, not what you type.

Here is how the dimensions translate in practice:

Dimension	What the interviewer is watching for
Communication	Clarifying questions, narrating your approach, responding to hints
Problem solving	Recognizing the problem type, comparing approaches, stating complexity
Technical competency	Correct, clean implementation without flailing on syntax
Testing	Dry-running the code, finding your own bugs, handling edge cases

The reason this matters: writing a clean solution without explaining the reasoning routinely scores lower than narrating a slightly imperfect solution while proving each step correct, which changes how you should prepare. The interviewer can only grade the thinking that reaches the conversation. Silent solving fails communication and partially fails problem solving, because the grader cannot tell whether you decomposed the problem or just pattern-matched from memory.

How scores become a hire decision

Most rubrics use a 1 to 4 scale per dimension. Candidates can receive a score of 1 to 4 in each category, with 4 being the best possible score. Companies then either sum the per-dimension scores or assign one overall score. There are two general methods of scoring: provide a score for every dimension and sum them into an overall score, or provide an overall score based on overall performance across dimensions.

That overall score maps to a recommendation band: strong no-hire, no-hire, lean hire, hire, strong hire. At Google specifically, each interviewer grades on a scale of 1 to 4, where 3 is the threshold for hire versus no hire. The final call is not a raw average. Google reviews applicants through a hiring committee to reduce bias, rather than letting a single interviewer decide. One weak round does not automatically sink you, and one brilliant round does not automatically save you; the committee reads the written feedback across the loop.

The practical takeaway: consistency across four rounds beats one heroic performance. A candidate who scores a solid 3 everywhere usually clears the bar more reliably than one who alternates between 4 and 2.

What each dimension looks like on a real problem

Abstractions are easy to nod at, so take a concrete question from our bank: "Minimum Moves to Spread Stones Over Grid," a 3x3 grid where you move stones between cells to reach one per cell. It looks like a greedy problem and traps people who grab the nearest neighbor.

Communication: You ask whether moves are limited to adjacent cells (they are, cost is Manhattan distance) and confirm the grid always contains exactly nine stones. Skipping this is the most common way to lose a point on an otherwise fine solution.
Problem solving: You recognize that greedy nearest-neighbor is wrong and that this is an assignment problem, solvable by permuting the surplus cells against the empty cells or by min-cost matching. Stating that trade-off out loud is the point.
Technical competency: You implement it cleanly, whether by brute-forcing permutations of a small set or by backtracking, without getting lost in index bookkeeping.
Testing: You dry-run a case where one cell holds three stones and two cells hold zero, confirming the distances sum correctly.

The same four-lens read applies to harder tickets like "Domino and Tromino Tiling" or "Number of Ways to Stay in the Same Place After Some Steps," where the dynamic programming recurrence is the whole problem-solving score. If you write the recurrence on the board and explain the state before coding, you bank the problem-solving points even if you fumble a modulo later. On a staff-level question like "Find Critical and Pseudo-Critical Edges in Minimum Spanning Tree," the graders weight problem decomposition even more heavily, because there is no way to reach the answer without articulating the Kruskal-based approach first.

A useful mental model: the follow-up is often where the score is decided. The initial question establishes a baseline and the follow-up reveals how stable it is; a solution that worked when data fit in memory may need a different shape once that assumption disappears, and interviewers learn a great deal from how candidates respond when the problem moves underneath them. Practicing follow-ups is undervalued by most candidates.

Behavioral rounds are scored too

Coding is not the only rubric in the loop. Amazon is the clearest example: every onsite is anchored to its Leadership Principles, and one interviewer is a trained Bar Raiser from outside the hiring team who is there specifically to hold the line on quality. Just as Google uses a committee and a 1 to 4 grading scale to review applicants without bias, structured evaluation exists to keep any single interviewer from dominating the decision.

Behavioral answers are graded on whether they contain a real signal, not on how polished they sound. Interviewers listen for specific situation, task, action, and result, which is why the STAR structure exists. If you want the mechanics, our guide on the STAR method for software engineers breaks down what a scoreable answer looks like. For Amazon specifically, the company breakdown covers how the Bar Raiser round differs from the rest of the loop.

The rubric is shifting in 2026

The four dimensions are not going away, but AI-assisted interviews are adding a fifth axis: how well you direct and verify a model. Google and Meta both piloted AI-assisted formats this year. Meta evaluates candidates on four criteria in its AI-assisted format: problem solving, code quality, verification, and communication, and Meta lets candidates choose from multiple AI models while Google's pilot specifically requires Gemini. Notice that verification is now called out explicitly, which used to be folded into testing.

The failure mode graders punish is over-reliance. Candidates who appeared to rely heavily on AI without demonstrating their own understanding have received negative feedback, and communication remains a core evaluation criterion, so you should practice explaining why you are prompting a certain way, what you expect back, and how you are validating the output. In other words, the AI does not remove the rubric; it raises the weight on problem solving and verification because typing speed no longer separates candidates.

How to practice against the rubric

Stop grading your practice on "did it run." Grade each of the four dimensions separately, out loud, on every problem:

Narrate before you type. Force yourself to state the approach and complexity before writing a line. This trains the communication and problem-solving scores together.
Rehearse the follow-up. After solving, change one constraint (unbounded input, streaming data, updates to the structure) and re-solve. This is where scores separate.
Test without being asked. Dry-run at least two cases, including one edge case, every single time. Testing is the dimension candidates most often skip under time pressure.
Get scored feedback. Solo practice cannot tell you how your explanation lands. Running timed sessions with per-dimension feedback on our practice platform closes that gap, and browsing questions by company lets you match the rubric weighting to your target.

The candidates we see clear the bar are rarely the fastest coders. They are the ones who make all four dimensions visible on every problem.

FAQ

Is passing all the test cases enough to get a hire recommendation?

No. Correct code typically satisfies only the technical competency dimension, which is one of four. Correct code written fast is one of four criteria; interviewers also score problem decomposition, verification, and communication. A working solution with no explanation and no testing often lands below the hire threshold.

Do all companies use the same rubric?

The wording differs but the structure is remarkably consistent. Across top tech companies, coding interview evaluation criteria do not differ to a great extent; the exact terms may differ, but the dimensions evaluated are roughly similar. Google uses Algorithms, Coding, Communication, and Problem Solving; the generic FAANG rubric uses communication, problem solving, technical competency, and testing. They cover the same ground.

How much does one bad round hurt me?

Less than you fear, because decisions are made by committee across the whole loop. Google reviews candidates through a hiring committee, with each interviewer grading on a 1 to 4 scale where 3 is the hire threshold. Consistent 3s across four rounds usually beat a mix of 4s and 2s.

Should I use AI in an interview if it is allowed?

Use it, but stay in control and verify everything. Candidates who appeared to rely heavily on AI without demonstrating their own understanding have received negative feedback. Treat the model as a fast pair programmer whose output you must justify, not as an answer key.