Why did you accept that code? The design, test and simplicity checks

In this article

1. Before you start
2. Why interviewers ask this
3. Accepting code from first principles
4. The Staff-level answer
5. The rubric
6. Three variants of this question
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is part of the interview process and applies to the AI-assisted coding round format.

Why interviewers ask this

Accepting code is a decision, and an interviewer who asks why you made it wants to know whether you decided on purpose. In a round where an assistant suggests code, a candidate who pastes the suggestion and moves on leaves the interviewer unable to tell understanding from luck. The question separates a candidate who owns a result from one who only forwards it.

A weak answer says "it looked right" or "the tests passed." A strong answer names the checks, the evidence from each, and what was left for later. The same question can come up in a take-home assignment review or an online assessment follow-up, wherever code you did not write line by line is on the screen. How a given company scores it varies, so treat this page as advice on a strong answer, not a report of any rubric.

Accepting code from first principles

Code health

Code health is the overall quality of a code base, meaning how easily a team can read, change and trust it, which a review tries to improve over time instead of only stopping new breakage. A change that leaves the code base better than before improves code health, even when the change is small.

Acceptance check

An acceptance check is a question you answer about a change before you accept it, such as whether it fits the design, does what was intended, is simple enough and has tests that could fail. It makes the decision rest on evidence instead of a feeling that the code looks fine.

Over-engineering

Over-engineering is a kind of complexity that makes code more generic than the task needs or adds functionality nobody needs yet. It costs every future reader time and gives the system nothing in return today.

In plain words

Think of signing a delivery note. Before you sign, you check that the box is the one you ordered, that it is not damaged and that the contents match the list. Your signature says you did those checks. The analogy breaks in one place: a box that looks intact is usually fine, but code can look fine and behave wrongly, so checking code means running it.

Google's engineering practices guide (archived November 2025) states the goal of a review: the overall code health of the code base should improve over time. It adds that "there is no such thing as 'perfect' code—there is only better code." So the bar is not perfection. Check the design first, then the tests, then the complexity. Accept only when the change improves the code, or revise it.

Step 1: Check that the change fits the design

The first check is whether the change fits the design of the code around it. The Google guide says the most important thing to cover in a review is the overall design of the change.

The input is the suggested code and the code next to it. Ask where the new function lives, whether something in the project already does the same job, and whether the change belongs in this task at all. The output is a yes or a reason to revise: use the existing helper, move the code, or drop the part you did not ask for.

An assistant can suggest a new helper when it lacks the context of one that already exists elsewhere. You can see the whole project, so this check is yours. You now know whether the code belongs; the next step asks whether it works.

Step 2: Check that the tests would fail if the code were wrong

The second check is whether the tests, and any run you do yourself, would fail if the code were wrong. The Google guide asks whether the change does what the developer intended and notes that tests do not test themselves: "a human must ensure that tests are valid."

The input is the code and its tests. First run them. Then ask which inputs the tests never touch. An edge case is an input at the boundary of what the code must handle, such as an empty list or a single element. A whole class of input the tests never touch, such as even-length lists, matters just as much. Pick inputs where you already know the right answer and run the code on them.

The output is evidence. "The tests passed" is only evidence if those tests could have failed. The worked example below shows a suggestion that passes both of its own tests and is still wrong.

Step 3: Check that the code is simple enough to explain

The third check is whether the code is simple enough that you can explain every line. The Google guide says "too complex" usually means "can't be understood quickly by code readers," and it names over-engineering as a particular kind of complexity.

The input is the code that passed steps 1 and 2. Read it as the next person would. If a line needs a comment you cannot write, or the code handles cases nobody asked for, revise it or ask the assistant for a smaller version.

The output is the decision. The guide says to favor approval once a change definitely improves overall code health, even if it is not perfect, and that nothing justifies accepting a change that clearly worsens it. So accept it, with any small naming issues named and left, or revise it. You now have the full sequence the diagram below shows.

1 · Design fit2 · Tests can fail3 · Simple, then decideReplay

Step-by-step description

1. Does the change fit the code around it?
2. Would the tests fail if the code were wrong?
3. Can you explain it? Accept or revise.

• Check the design first, then the tests, then the complexity.
• Accept only when the change improves the code, or revise it.

Worked example: a function that passes its own tests

A suggested median function can pass both of its own tests and still be wrong for even-length and empty lists; this example is illustrative. An assistant is asked for a function that returns the median of a list and raises ValueError on an empty list. It suggests this code with two tests. The median is the middle value of the sorted list, or the mean of the two middle values when the length is even. The function sorts the list and takes the element at the middle position.

def median(v):
    s = sorted(v)
    return s[len(s) // 2]          # suggested version

def median_fixed(v):
    if not v:
        raise ValueError("empty list")
    s = sorted(v)
    n = len(s)
    m = n // 2
    return s[m] if n % 2 else (s[m - 1] + s[m]) / 2

The suggested version is right for lists of odd length, because one element sits in the middle. For even length the median is the mean of the two middle values, and for an empty list the code fails with an IndexError instead of a clear message. The suggestion's two tests both use odd-length lists.¹

The buggy version passes both of the AI's own tests. The buggy version passes one of the five added edge-case checks. The fixed version passes all five added edge-case checks.¹ Three of the five added checks use non-empty even-length lists, the very case the suggestion's tests skip. In the table, 15.0 equals 15 in Python; the fixed function returns a decimal number whenever it averages two values.

Text description of the diagram

• The buggy version passes both of the AI's own tests.
• The buggy version passes one of the five added edge-case checks.
• The fixed version passes all five added edge-case checks.

What you say in the round is that the tests only covered odd lengths, so you added even-length and empty cases, found the wrong result and fixed it. That one sentence is the evidence an interviewer wants. A strong answer also says what you asked the assistant for and what you changed from its suggestion, which shows your own judgment beyond the tests.

The Staff-level answer

It is Staff-level because it names the evidence for each check, admits what the first pass missed, and states the small issue it chose to leave. The spoken structure is: the decision, three checks with evidence, the trade-off you accepted, and ownership. Practice it out loud once so the order comes without notes; the interview skills page covers delivery.

The rubric

Three variants of this question

Why did you reject that code?

Rejecting is the same review with the opposite result: name the check it failed, such as a design mismatch or a missing edge case, show the evidence, and say what you did instead, whether that was asking for a revision or writing the part yourself.

How do you know the suggested code is correct?

You do not know it is correct in general; you know it passes the checks you chose. Say which inputs you ran, which edge cases you added and where your confidence stops, as in the even-length case above.

What would you change about the code you accepted?

Name one real improvement and why you left it: a clearer name, a smaller helper, a missing test. It shows you judged the code as better, not perfect, which fits the guide's point that reviewers should favor approval once a change definitely improves code health.

Common mistakes

• "The tests passed, so it is fine." (wrong) Tests only count if they could have failed. (right) "The tests passed, and I added even-length and empty cases that would have caught a mistake."
• "The assistant wrote it, so the choice was its." (wrong) Whoever accepts the code makes the decision. (right) "I accepted it, so I own it." The Google guide says a reviewer has ownership and responsibility for the code they review; applying that to code you accept from an assistant is our inference, not something the guide says about AI.
• "It is perfect." (wrong) No code is, and the claim sounds careless. (right) "It improves the code; I left one small naming issue."
• "I read it once and it seemed fine." (wrong) Some problems, such as edge-case and design problems, show up only when you run the code or think hard about it. (right) "I read it, ran it, then tried inputs where I knew the answer."

Follow-up questions

Would you have accepted it if all the tests had passed?

Not on that evidence alone. Tests do not test themselves, so you still ask which inputs they miss and try a few where you know the answer, then check design and complexity.

What if you are short on time?

Shrink the checks, do not skip them: run the code on one known input, check the one edge case most likely to break, and name what you did not check. The Google guide says developers must be able to make progress, but also that nothing justifies accepting a change that clearly worsens code health; its only exception is an emergency.

Who is responsible if accepted code has a bug?

The person who accepted it: deciding the code was good enough means owning the fix. This is an inference from the review standard, which gives the reviewer ownership. The same habit matters in an AI engineer interview and in forward deployed and applied AI engineer rounds, where you ship what you accept.

How much of the code do you need to read before accepting it?

All of it that you will put your name to. If a line is too complex to explain, that is a reason to revise it, not to skip it.

Sources

1. The Standard of Code Review - Google Engineering Practices — Google (google/eng-practices on GitHub), 21 Nov 2025
2. What to look for in a code review - Google Engineering Practices — Google (google/eng-practices on GitHub), 21 Nov 2025