P-7.2 Reading Code and Pseudocode

What this is and why it exists

The written half of a screening test is nearly all one skill. Here is a short piece of code — what does it print.

That rewards paper speed rather than depth. And there is one technique that builds it, which is the dry-run table.

Pseudocode is the same skill with the syntax removed. Its conventions are worth ten deliberate minutes, because a reader who has never seen arrow assignment loses marks to notation rather than to reasoning.

The vocabulary

• Dry run — working a program by hand, without running it.
• Dry-run table — one column per variable, one row per pass of the loop.
• Pseudocode — an algorithm written without a real language's syntax.
• Arrow assignment — the textbook way of writing "put this value in that variable".
• Call tree — a drawing of which call made which other calls.

The mental model

The dry-run table is the whole technique, and it is worth taking literally. Draw one column for each variable and one row for each pass of the loop. Fill it in. What was a question you were holding in your head becomes arithmetic on paper that you can check afterwards. Almost everybody who is slow at these questions is trying to do them in their head.

Then work twenty output questions on arrays and control flow, and mark every wrong one. Twenty is enough to expose your own repeated mistake. It is nearly always an off-by-one at a boundary, or an assignment read as a comparison. The wrong answers are the useful half of the set, and the right ones taught you nothing.

Read the pseudocode conventions before you meet them under a clock. Indentation for blocks. Arrow assignment. Counting from one rather than zero. A paper that prints pseudocode assumes you know these, and ten minutes of reading removes a whole category of avoidable error. Losing a mark because you read an arrow as a comparison is a bad way to lose a mark.

Recursion needs a different tool, because tracing in your head fails there first. Draw the call tree. Each call is a node with its arguments; fill in what each returns on the way back up. The answer becomes something you can see rather than something you are trying to remember. The drawing takes less time than a third failed attempt at holding it in mind.

Finally, a round trip worth doing once. Turn one of your own functions into pseudocode, then write it back as code from the pseudocode alone. That tests whether you can separate what an algorithm *does* from the syntax it happens to be in. Which is exactly what a pseudocode question checks.

What you should now be able to explain or do

Build a dry-run table and use it instead of tracing in your head. Work twenty output questions and identify your own repeated mistake. Read pseudocode with its usual conventions, including arrow assignment and counting from one. Trace a recursive function by drawing the call tree. Convert one of your functions to pseudocode and back again.

Check yourself