The practical coding round

How is a production-style coding interview different from an algorithm round?

The problem is bigger and the algorithm inside it is smaller. An algorithm round hands you one function and watches whether you find the fast way to fill it in. This round hands you a small system with several operations and watches how you build it, and the structure you need is usually a dict, a list, a deque or a heap. What changes is that the interviewer now reads your code the way they would read a pull request: whether the names come from the problem’s own vocabulary, whether each method is short enough to hold in your head, whether they can see why the state is shaped that way, and whether the next requirement lands as an addition or a rewrite.

How many tests should I write in a production-style coding interview?

Enough that every rule you have stated out loud is proved by one, which in fifty minutes is usually five to eight. Write them as you go rather than at the end: one for the normal path as soon as the first method works, one at each boundary you can name (the exact instant something expires, the exact limit), and one for each input you decided to refuse. A test written before the method is finished is not wasted time, it is the target the method is aimed at. If the editor has no test runner, eight lines of your own are enough, and this page shows them as a file the build runs.

Should I use classes in a production-style coding interview?

Use a class when the problem has state that several operations share, which is most of the time in this round. A meter, a store, a ledger and a board all own state, and putting the rules next to the state they protect is what stops the callers from having to know them. Use a plain function for anything that reads no state, and a frozen dataclass for values that are only data. What loses marks is the other direction: an abstract base class with one implementation, a registry with one entry, a config object holding two integers. An interface earns its place at the moment a second implementation arrives, not before.

What if I run out of time?

Land on a working, tested, smaller version rather than a broken larger one, and say which rule you dropped and how you would add it. That is the reason for the build order on this page: at every stage there is a program behind you that runs, so at any minute you can stop, run the tests, and describe the rest. The recovery move at minute thirty is to cut scope, never to cut the tests, because code nobody has run is worth less in this round than a rule you named and did not implement.

How much design should I do up front?

About five minutes, and it should produce four things you can say in a sentence each: the entities, what each one owns, the public methods, and the one rule the state always keeps. That is enough to start typing, and short enough that being wrong about it costs little. Fifteen minutes of design with nothing on the screen is one of the most common ways this round is lost, because a diagram is hard to grade and you have spent a third of the clock. Say the shape, invite a correction, then start on the thinnest path.