Coding on a Whiteboard or Shared Doc

Write in larger blocks than you would on a screen. Indentation and punctuation become the main source of errors when there is no editor to catch them, so write whole functions rather than fragments and keep the structure visible on the page. Leave space to change your mind, because crossing out a block is harder than scrolling back.

def reverse_words(text):
    words = text.split()
    return " ".join(word[::-1] for word in words)


print(reverse_words("hello world"))
print(reverse_words("interview practice"))

The outputs are olleh dlrow and weivretni ecircep, so each word is reversed while the order of the words is preserved.

The mechanism is that the cost of a whiteboard is not the algorithm but the transcription. Your usual flow is think, type, see the result, adjust, and on a whiteboard you lose the see and adjust steps, so you have to replace them with talking. Narrating the intent of each block, and saying the base case out loud before you write it, catches the errors that the compiler would otherwise catch for you.

The trade-off to name is that speed matters less than correctness here, and candidates often lose points by writing fast and messy. It is better to write one clean block and explain it than to produce three blocks of dense code. The other practical advice is to write the signature and the tests first, since those are the parts you can write without thinking, and they fix the shape of everything that follows.

Debug by talking, not by rewriting. Restate the expected behaviour and the actual behaviour, then trace the values through your code with a concrete small example, writing down what each variable holds at each step. The error usually becomes obvious within two or three steps of that.

Use a smaller input than the one that failed. A failing case with five elements can usually be reduced to one or two, and small cases are easy to trace by hand. Also check the boundaries first, since an empty list, a single element and a list that is exactly the size of the window account for a large share of the bugs you will see.

The mechanism is that the bug is a wrong belief about the state, and tracing the state exposes it. On paper you cannot print a stack trace, but you can write the state down, and that is the same information.

The trade-off to name is that rewriting from scratch feels productive and usually is not, since you are likely to reproduce the same mistake because the mistake was in the thinking rather than in the typing. Asking the interviewer for a hint after a few minutes of tracing is also a good move, because it shows you can debug and it moves the interview forward. What looks bad is silently staring at the board or rewriting the same code twice with different variable names.

Clarify the problem until you could describe the input and output precisely, without ambiguity. Ask what the function should return when the input is empty, whether duplicates are allowed, whether the result must be sorted or stable, and what the size constraints are. The constraints matter more than people expect, because they decide the technique.

Then restate the problem in your own words and propose an approach in one or two sentences, including the complexity you expect. Only then start writing. This costs two minutes and removes the most common cause of a failed interview, which is solving a slightly different problem from the one that was asked.

The mechanism is that the interviewer's question is deliberately underspecified, and the gap is where the misunderstandings live. Asking about the edge cases is also how you demonstrate that you think about them, which is part of what is being assessed.

The trade-off to name is that over-clarifying looks like stalling, so the balance is to ask about two or three things and then move. A useful pattern is to state your assumption out loud and keep going, for instance saying that you will assume the input is non empty and handle the empty case defensively, which keeps the interview moving while still surfacing the assumption. A shared document makes the clarification even more valuable, because writing the examples down keeps the conversation anchored on the same thing.