How to write clean code (under a clock)
The Clean Code module in this course covers the full discipline - names, functions, comments, formatting, classes, all of it, at the depth a real codebase deserves. An interview is not a real codebase. You have 60-90 minutes, a small program nobody will maintain past the call, and an interviewer reading over your shoulder in real time. The bar shifts from "production perfect" to "clean enough that a stranger can follow it while it's still being written." That's a lower bar in some ways and a stricter one in others - you don't get days to let it settle, you have to get it right the first pass.
The four things that actually matter in the time you have
Meaningful names. This is the highest-value, lowest-cost habit available under time
pressure - it costs zero extra minutes to write checkOutBook instead of doTheThing, and
it's the difference between an interviewer who can follow your code by reading it and one who
has to keep asking you what a variable means. numAvailable beats n. remainingCapacity
beats cap. You are narrating your own design out loud through your names whether you mean
to or not.
Small, single-purpose methods. A checkOut method that validates the member, finds a
copy, updates the loan count, and creates the checkout record all in one twenty-line block is
harder to reason about live than four five-line methods that each do one of those things and
call each other. It's also easier to fix live - if the interviewer asks "what happens if the
member already has five books out", you can point at canCheckOut(member) instead of
re-reading twenty lines to find where that check should have gone.
Shallow nesting. Three or four levels of nested ifs inside a loop is hard to type
correctly under pressure and hard for anyone watching to track. Prefer early returns and
guard clauses: check the failure conditions first and return, so the method's main body reads
as the happy path with no indentation creep.
Consistent, unhurried formatting. Consistent indentation, blank lines between logical groups, one convention for braces and naming throughout. This one is nearly free - it's a habit, not a design decision - and its absence is the single fastest way to make correct code look sloppy to someone skimming it at speed.
Try it yourself: picture a processReturn method you just typed for a store's
return-processing feature - three nested ifs checking the receipt, the item condition, and
the return window, all inside one twenty-line block. Rewrite it in your head as guard clauses
and smaller named methods before you'd call it done.
What to deliberately not spend time on
Comments explaining what the code does (the code should say that itself via names), a fully generalized error-handling layer, defensive checks for inputs that can't occur given what the interviewer told you, and reformatting code you already wrote just to make it prettier - all of these cost minutes you don't have, for a payoff the interviewer isn't grading. If you want the deeper reasoning behind each of these calls, that's what the full Clean Code module is for; here, the only question worth asking every few minutes is: could the person reading this right now follow what I just wrote, without asking me?