The pull request you would not approve

My code works and the tests pass. Can it still lose the round?

Yes, and that is what separates a production-style round from an algorithm round. Working code is what gets you scored at all; the score comes from whether another engineer could read it, test it, and extend it. Every before version on this page runs and passes the same cases as its after version, and every one of them would come back with comments. If you have never had your interview code reviewed, that is the gap this page is for.

Isn’t splitting one function into four more code, not less?

It is usually more lines and less to hold in your head, and the second thing is what is being scored. Count what a reader has to carry instead of counting lines: a forty-line function with four jobs has to be understood all at once, while four ten-line functions can be read one at a time and tested one at a time. The one case where splitting is wrong is when the pieces are not separable, so that reading the parts means jumping between them anyway. Then keep the function and give it a comment.

Are an Enum, a frozen dataclass and an injected clock over-engineering in fifty minutes?

No, and each one is cheaper than the mistake it prevents. An Enum is three lines and removes a whole class of typo. A frozen dataclass is four lines and replaces a tuple whose fields you would otherwise have to remember by position. A clock passed in as a parameter is one extra parameter and is the difference between a test that runs instantly and a test that sleeps. What does read as over-engineering is an abstract base class with one implementation, a registry, a factory, or a config object for two integers. Section 09 is about that line.

Should I write it clean from the start, or clean it up at the end?

Write the structure clean from the start and leave the bodies rough. Deciding the names, the boundaries and the return types is thinking work that does not get cheaper later, and it is what the interviewer is watching you do. Filling in a body is typing, and typing can be rushed. The one thing to genuinely defer is any abstraction you cannot yet justify: write the second implementation’s interface when the second implementation arrives, not before.

How do I find these in my own code in the last five minutes of a round?

Read it as a reviewer rather than an author, in a fixed order, which is what section 10 lists. The order matters because the cheap checks come first: does it run, can you read the names aloud, does each function do one job, is any state hidden, what is injected, where are errors raised, which cases did you test, and what would the next requirement touch. Say what you find out loud even when there is no time to fix it. Naming a weakness and choosing not to spend the clock on it reads as judgment, and finding nothing reads as not having looked.