Pen and Paper in Coding Interviews: How to Code Without a Computer

In a pen-and-paper or whiteboard coding interview, the interviewer wants to see how you think, not whether your semicolons compile. Your job is to clarify the problem, sketch an example, outline the approach in plain words, write readable code, and then check it by walking through a test case by hand. Practising that exact routine with a pen is the fastest way to get comfortable. The rest of this post gives you the routine, a worked example, and a practice plan.

Why interviewers still ask for it

Some interviews are done on a shared editor or on a laptop, and some still use a whiteboard, a tablet or a sheet of paper, especially on-site. Without autocomplete or a compiler, the interviewer sees things an editor hides: whether you plan before you write, how you handle a case you did not expect, and whether you can explain a decision out loud. That is the point of it. Nobody expects perfect syntax. Small slips such as a missing colon are usually forgiven if you spot them, though you should confirm with the interviewer how strict they want you to be about syntax and which language to use.

A step-by-step routine

1. Restate the problem and ask questions. What are the inputs? Can the input be empty? Are numbers negative? Can there be duplicates? Is the data sorted? Write the answers in a corner.
2. Draw an example. Make one small input, and draw it: a list as boxes, a tree as circles and arrows. Work out the expected output by hand.
3. Talk through a simple solution first. Even a slow brute-force idea is a useful starting point. Then say what its cost is and how you might improve it.
4. Write the plan as pseudocode. Four to eight lines in plain English. This is where the interviewer can correct you cheaply. Our post on using pseudocode in technical interviews covers this step.
5. Write the code. Pick a language you know well. Use clear variable names and consistent indentation, and leave blank lines so you can insert a fix.
6. Trace it by hand. Run your example through the code line by line, with a small table of variable values. This catches most bugs.
7. Test the edges. Empty input, one element, duplicates, the largest case.
8. State the complexity. Time and extra space, in a sentence each.

Worked example: reverse the words in a sentence

Clarify. “Reverse the order of words, not the letters. Words are separated by spaces. What about extra spaces or an empty string?” Suppose the answer is: assume single spaces for now, but handle the empty string.

Example. "one two three four" becomes "four three two one".

Pseudocode.

split the sentence into a list of words
put one marker at the first word and one at the last
while the left marker is before the right marker:
    swap the two words
    move the markers toward each other
join the words with spaces

Code.

def reverse_words(s):
    words = s.split()
    left, right = 0, len(words) - 1
    while left < right:
        words[left], words[right] = words[right], words[left]
        left += 1
        right -= 1
    return " ".join(words)

Trace it on ["one", "two", "three", "four"]:

step	left	right	words after the swap
start	0	3	one two three four
1	0	3	four two three one
2	1	2	four three two one
end	2	1	loop stops, because 2 is not less than 1

Edges. One word: left = 0, right = 0, the loop never runs, and the word comes back unchanged. Empty string: split() returns an empty list, right is -1, the loop never runs, and join returns an empty string. Running the code gives:

four three two one
solo
''

That matches the table and the edge cases. Finally, the cost: one pass over the words, so O(n) time, and O(n) extra space for the list. Note that split() without arguments also collapses repeated spaces, which answers the “extra spaces” question as a side effect. Mention it.

Common mistakes

• Starting to write code immediately. You cannot erase on a whiteboard cheaply. Plan first.
• Going silent. If you stop talking for two minutes, the interviewer cannot tell stuck from thinking. Say what you are considering, even if it is “I am checking whether this loop skips the last element.”
• Cramming the board. Start in the top-left, leave space between lines, and keep a separate area for examples and diagrams.
• Skipping the trace. Writing code and saying “done” without running an example is the most common reason a correct idea ends with a wrong answer.
• Fighting for perfect syntax. If you forget a method name, say so, name what it does, and move on. “I would use a hash map lookup here” is better than five minutes lost on an API call.
• Leaning on shorthand the interviewer cannot read. Abbreviate result to res if you like, but keep names meaningful.

Working on a whiteboard

• Write big enough for someone across the room, and stand to the side so you do not block the board.
• Use straight, consistent indentation. Indentation shows the structure of the code, and it is easy to lose on a board.
• Leave a gap of a line or two between statements, so you can add a missed condition.
• Draw data structures. Arrows for pointers on a linked list or tree make bugs obvious.
• Use one colour for code and another for your trace, if you have two markers.

How to practise by hand

1. Pick a problem you have not seen. Set a 25-minute timer.
2. Solve it on paper, with the routine above. No editor, no running code.
3. Type your solution into an editor and run it with your own tests. Write down every difference between what you wrote and what works: a missed edge case, an off-by-one, a wrong method name.
4. Repeat with a different kind of problem each time: arrays, strings, a hash map, a linked list, a tree.
5. Once a week, practise with a friend who plays interviewer and interrupts with questions.

Try it on a classic such as Two Sum: given a list and a target, return the indexes of two numbers that add up to the target. On paper, the hash-map solution looks like this once you have drawn the example [2, 7, 11, 15] with target 9:

def two_sum(nums, target):
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return [seen[target - n], i]
        seen[n] = i
    return []

print(two_sum([2, 7, 11, 15], 9), two_sum([3, 3], 6), two_sum([1], 2))

Output: [0, 1] [0, 1] []. The case [3, 3] is worth tracing by hand: the first 3 is stored, and the second finds its partner before it overwrites the dictionary entry. If you want to see that approach explained one step at a time, there is a Two Sum lesson in the Python course on AlgoCademy.

Remote interviews

If your interview is in an online editor, the same habits apply. Write the plan as comments first, trace an example out loud, and test edge cases before you say you are done. If the editor has no drawing tool, ask whether you can use a notebook on camera, or write small ASCII diagrams in comments. For more on checking your own code with sample inputs, read how to dry-run code during a coding interview.