# Coding interview practice: read code before you write it

**How should I practise reading code for a coding interview?** Coding interview practice works best when reading code comes before and beside writing it. Each day, trace what a short snippet prints, find the bug, put shuffled lines in order and say what a function does in one sentence, then write solutions in your own editor. In studies of students, those who wrote code well could usually trace and explain it.

Published 2026-10-10 by EdProcto. https://edprocto.com/guides/coding-interview-practice-reading-code-before-writing-it

A coding interview asks for written code, so coding interview practice tends to be all writing: one problem after another, each from a blank page. This guide adds the half that is easy to skip. Before and beside every written solution you read code: trace what a snippet prints, find the bug, put shuffled lines in order, and say what a function does in one sentence.

It is a plan for preparation, and it promises no offer and no pass. This guide is published by EdProcto, whose page [for candidates](https://edprocto.com/solutions/candidates) leads to the practice kits named below. The question shapes are set out in [code reading questions](https://edprocto.com/guides/code-questions-reading-writing-and-annotating-programs), and other employer tests in [how to prepare for a pre-employment test](https://edprocto.com/guides/how-to-prepare-for-a-pre-employment-test).

## Why practise reading code for a coding interview?

Practise reading because, in studies of students, those who wrote code well could nearly always trace and explain it, and tracing practice was followed by better writing.

- **The three skills travel together.** Lister et al. (2009) repeated earlier studies at a new university, in Python. Students who could not trace code usually could not explain it, and those who wrote reasonably well could usually do both.
- **Explaining counts beyond the first course.** Corney et al. (2014) had second-course students explain recursive code on data structures. Explaining at an abstract level correlated strongly with writing, and the authors recommend mixing reading tasks with writing.
- **Tracing practice moved writing.** Kumar (2013) set a code-writing quiz before and after a session of tracing problems, over three semesters. Where the scores differed significantly, the later one was higher. The gain was mainly in syntax, and the students who gained had spent 10% longer tracing.
- **The job is mostly reading.** Xia et al. (2018) logged 78 professional developers for 3,148 working hours: about 58% of the time went on understanding programs.

### What these studies cannot tell you

The learning studies are of students. Among 384 second-course students, Harrington and Cheng (2018) found that the gap between tracing and writing seemed to have closed, and ran the other way as often. Those who still had a gap in either direction tended to do poorly overall. For an experienced programmer, then, the drills are a check for a gap, not a ladder.

We found no study that tested reading practice as interview preparation, and we read every paper cited here in abstract only.

## What do technical interviews ask, and what does being watched do?

A technical interview asks you to solve a problem in code while explaining your thinking to someone who watches. Behroozi et al. (2019) define it as a problem-solving interview in which candidates write code; the developers whose online comments they studied complained of little relevance to real work, and of anxiety.

**What is marked.** Ford et al. (2017) analysed 70 evaluations of mock interviews, from interviewers at 9 software companies. The criteria included walking through the problem solving, applying past experience, and conversation beyond the code. They sometimes varied a great deal between companies, and candidates misjudged what was assessed.

**What being watched does.** Behroozi et al. (2020) randomly assigned 48 computer science students to a whiteboard problem in private or in front of an interviewer. Watched, performance fell by more than half, with significantly higher stress and cognitive load.

These are small studies of students. Their lesson for practice: say your reasoning aloud from the first week, and rehearse in front of someone before the day.

## Which five reading drills belong in the practice?

Five drills cover it, and each trains something the interviewer hears.

| Drill | What you do | What it catches | In EdProcto |
| --- | --- | --- | --- |
| Predict the output | Write what a short program prints, then run it | A wrong picture of a loop, a slice or a condition | The "Predict the output" [kit](https://edprocto.com/kits#computing) |
| Trace a call | Follow one call and give what it returns | A misread parameter or early return | [Read code](https://edprocto.com/templates/code_read) |
| Find the bug | From a call and its wrong result, name the line | Confusing what the code does with what it was meant to do | The "Find the bug" kits |
| Order shuffled lines | Put a working function's lines back in order | What must happen before what | [Reorder the code](https://edprocto.com/templates/reorder_code) |
| Say it in one sentence | State what the function is for | Missing the purpose behind the lines | [Annotate code](https://edprocto.com/templates/code_annotate) |

### Two habits that make the drills work

- **Trace on paper, to the end.** Cunningham et al. (2017) found that students who sketched a trace did better on code reading problems, and that an incomplete sketch did about as badly as none.
- **Treat finding as the skill.** In Fitzgerald et al. (2008), 21 second-course students found 70% of the bugs and fixed 97% of those they found. Arithmetic errors and wrong loop conditions were hardest.

The research on ordering lines is in [Parsons problems](https://edprocto.com/guides/parsons-problems-reordering-lines-of-code).

## A three-week practice plan

The plan puts fifteen minutes of reading before each writing session. The timings are ours, not a research finding.

| Week | Read first, 15 minutes | Then write, 30 minutes or more | By the weekend |
| --- | --- | --- | --- |
| 1 | Predict the output and trace a call, on paper | One easy problem a day in your own editor: study a worked solution, then solve its twin unaided | Write five tracing questions from your own code |
| 2 | Find the bug and order shuffled lines; retake whatever is due | One medium problem a day; trace your own solution by hand before you run it | Write five bug questions and say each fix aloud |
| 3 | Say it in one sentence, aloud; then mixed sets against a timer | Two problems a day, spoken as you write, one in front of a friend or a recording | One full mock interview |

**Why a worked solution first.** Atkinson et al. (2000), reviewing the research on worked examples, advise placing each example beside a matched practice problem and explaining it to yourself.

**When to skip it.** Kalyuga et al. (2003) showed that techniques which help beginners can lose their effect, or do harm, with experienced learners. On a topic you know well, go straight to the problem.

## How do you write your own tracing and bug-finding questions?

Write each question from short code you have run, around one idea.

1. **Choose code you may use.** Your own old solutions are best. For open source, read the licence first: GitHub (n.d.) says that without one nobody else may copy, distribute or adapt the code, though a public repository can be viewed and forked. Take snippets only where the licence file permits copying and changing, keep the notice it asks for, and leave an employer's code out.
2. **Cut it to one idea.** One function and one fixed call, a dozen lines at most by our rule of thumb.
3. **Run it and copy the output.** Never key a question from your own trace.
4. **For a tracing question, run the slip.** Change the code the way a tired reader misreads it, and use what that version prints as a wrong option.
5. **For a bug question, plant one bug.** A loop bound, a comparison, a reset value. Find one input that shows the bug and one that hides it, and put the failing call in the prompt.
6. **Write the reason** in a sentence or two.
7. **Build the set in EdProcto and wait.** Start from a [kit](https://edprocto.com/kits#computing) or the shapes below, and answer a few days later, once the code has gone cold.

## Two worked examples, with a candidate's answers marked

Both programs were run with Python 3.9, and each stated output is the interpreter's. Each mark described as by rule came from EdProcto's own marking code; the mark for the sentence is a reader's.

### Example 1: trace it, then say it in one sentence

```python
def squash(text):
    out = ""
    for ch in text:
        if not out.endswith(ch):
            out += ch
    return out

print(squash("aabbbac"))
```

What does this print? **A.** abc **B.** abac **C.** aabbbac

The candidate writes `out` after each character: a, a, ab, ab, ab, aba, abac. They pick B. Marked by rule: right, 1 of 1.

Asked what `squash` is for, they type: "It removes duplicate letters." The model answer is "It returns the text with each run of a repeated character cut to one." Against a rubric of one point for "repeats in a row" and one for what is returned, the sentence earns 1 of 2. `squash("abca")` returns `abca`: repeats that sit apart survive. The trace was right and the sentence loose, and an interviewer hears the sentence.

### Example 2: find the bug, then rebuild the fix

```python
def longest_run(values):
    best = run = 1
    for i in range(1, len(values)):
        run = run + 1 if values[i] == values[i - 1] else 0
        best = max(best, run)
    return best
```

`longest_run([4, 4, 7, 7, 7])` should return 3, the longest run of equal neighbours. It returns 2. Which line holds the bug: 2, 3 or 4?

The candidate suspects the loop of skipping the first item and picks line 3. Marked by rule: wrong, 0 of 1. The reason on the key: started at 0, the loop still returns 2. Line 4 resets `run` to 0 when a run breaks, yet the item that broke it already begins a run of one, so the reset must be 1. `longest_run([7, 7, 7, 4])` returns 3: with the longest run first, the bug hides.

Next the six lines of the fixed function arrive shuffled. The candidate places `best = max(best, run)` above the line that updates `run`. With "Partial credit" off, only the exact order scores: 0 of 2. With it on, 14 of the 15 pairs of lines are in the right order and one is reversed, so (14 − 1) ÷ 15 of the points: 1.73 of 2. Run in an editor, that order returns 2 for the same call, because the last item is never counted. Of all 720 orders, at any legal indentation, only the key passed our tests.

## How does EdProcto fit the reading half?

EdProcto is the best place for the reading half of this plan, because its study screen runs the routine the drills depend on: you commit to an answer, press "Check", and meet the right answer and its reason at once. In Example 2 the mark said wrong, and the reason taught the fix.

**Kits, under Computing and data.**

- "Predict the output" asks ten questions made by rule, new each time: tiny Python and JavaScript snippets whose printed result you type. "Big-O complexity" asks ten multiple-choice questions on the time complexity of common operations, binary search and merge sort among them. Both are rule-made, so both are free without limit on every plan.
- "Read the code (professional and workplace)" and "Find the bug (professional and workplace)" open with "Open with my material". Paste your own code and Procto AI drafts ten questions: the first kit on what a snippet prints or does, the second, in multiple choice, on which line is wrong or what the fix is.
- "Hiring: a software developer", among the [hiring kits](https://edprocto.com/kits#hiring), drafts ten four-option questions from a job description and the material you paste.

Procto AI is asked to keep to your material. Run every drafted snippet in your editor before you trust its key.

**Shapes for your own questions**, in a quiz set to "Study quiz".

- **Read code** takes one option and is marked by rule. Paste your snippet into "The code", or begin from a kit's draft and edit its snippet, options and key.
- **Reorder the code** takes the lines in the right order, one a line. Each line is kept without its indentation and shown shuffled, to be moved with up and down arrows.
- **Annotate code** has a box labelled "The code" and a "Language" field. You answer in a plain code box, and "Check" replies "Kept for a reader." with your model answer to compare. On the grading page, "Ask Procto AI" marks that answer against your rubric; this is part of the Tutor plan.
- **A typed output**, as a [One word](https://edprocto.com/templates/one_word) question, ignores capitals, outer spaces and double quotes, so `ABAC` matches `abac` and `true` matches `True`. Where the form matters, offer options. Switch "A slip still counts" off, or `bananas` passes for `banana`.

Every one of these is answered by reading. Writing and running stay in your own editor.

**What comes back.** The last page lists "What you don’t know yet" with a button to retry those questions. The set returns on the dashboard under "Due for a re-test", two days after a miss and a week after a clean run: see [re-tests that come due](https://edprocto.com/guides/re-tests-that-come-due-how-spacing-is-scheduled).

**The cost.** Every kit opens on a free account, which carries ten quizzes a month and 20 questions a month written by Procto AI, enough for two drafted sets. Learner raises that to 100 questions and lifts the limit on self-tests: see [pricing](https://edprocto.com/pricing).

## Quick questions

### Is reading code enough to prepare for a coding interview?

No. Reading finds gaps and trains the explanation; the interview still asks you to write. Do both every day.

### How long should coding interview practice take each day?

This plan uses 45 minutes: 15 of reading, then 30 or more of writing, a split of our own.

### Where do I write and run my solutions?

In your own editor, in the interview's language. EdProcto's code shapes cover reading, tracing, ordering and explaining.

### Where can I find free code tracing practice?

EdProcto's page [for candidates](https://edprocto.com/solutions/candidates) leads to the kits; "Predict the output" is free without limit on a free account.

## References

- Atkinson, R. K., Derry, S. J., Renkl, A., & Wortham, D. (2000). Learning from examples: Instructional principles from the worked examples research. *Review of Educational Research, 70*(2), 181–214. [https://doi.org/10.3102/00346543070002181](https://doi.org/10.3102/00346543070002181)
- Behroozi, M., Parnin, C., & Barik, T. (2019). Hiring is broken: What do developers say about technical interviews? In *2019 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)* (pp. 1–9). IEEE. [https://doi.org/10.1109/VLHCC.2019.8818836](https://doi.org/10.1109/VLHCC.2019.8818836)
- Behroozi, M., Shirolkar, S., Barik, T., & Parnin, C. (2020). Does stress impact technical interview performance? In *Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering* (pp. 481–492). ACM. [https://doi.org/10.1145/3368089.3409712](https://doi.org/10.1145/3368089.3409712)
- Corney, M., Fitzgerald, S., Hanks, B., Lister, R., McCauley, R., & Murphy, L. (2014). 'Explain in plain English' questions revisited: Data structures problems. In *Proceedings of the 45th ACM Technical Symposium on Computer Science Education* (pp. 591–596). ACM. [https://doi.org/10.1145/2538862.2538911](https://doi.org/10.1145/2538862.2538911)
- Cunningham, K., Blanchard, S., Ericson, B., & Guzdial, M. (2017). Using tracing and sketching to solve programming problems: Replicating and extending an analysis of what students draw. In *Proceedings of the 2017 ACM Conference on International Computing Education Research* (pp. 164–172). ACM. [https://doi.org/10.1145/3105726.3106190](https://doi.org/10.1145/3105726.3106190)
- Fitzgerald, S., Lewandowski, G., McCauley, R., Murphy, L., Simon, B., Thomas, L., & Zander, C. (2008). Debugging: Finding, fixing and flailing, a multi-institutional study of novice debuggers. *Computer Science Education, 18*(2), 93–116. [https://doi.org/10.1080/08993400802114508](https://doi.org/10.1080/08993400802114508)
- Ford, D., Barik, T., Rand-Pickett, L., & Parnin, C. (2017). The tech-talk balance: What technical interviewers expect from technical candidates. In *2017 IEEE/ACM 10th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE)* (pp. 43–48). IEEE. [https://doi.org/10.1109/CHASE.2017.8](https://doi.org/10.1109/CHASE.2017.8)
- GitHub. (n.d.). *Licensing a repository*. GitHub Docs. Retrieved October 10, 2026, from [https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)
- Harrington, B., & Cheng, N. (2018). Tracing vs. writing code: Beyond the learning hierarchy. In *Proceedings of the 49th ACM Technical Symposium on Computer Science Education* (pp. 423–428). ACM. [https://doi.org/10.1145/3159450.3159530](https://doi.org/10.1145/3159450.3159530)
- Kalyuga, S., Ayres, P., Chandler, P., & Sweller, J. (2003). The expertise reversal effect. *Educational Psychologist, 38*(1), 23–31. [https://doi.org/10.1207/S15326985EP3801_4](https://doi.org/10.1207/S15326985EP3801_4)
- Kumar, A. N. (2013). A study of the influence of code-tracing problems on code-writing skills. In *Proceedings of the 18th ACM Conference on Innovation and Technology in Computer Science Education* (pp. 183–188). ACM. [https://doi.org/10.1145/2462476.2462507](https://doi.org/10.1145/2462476.2462507)
- Lister, R., Fidge, C., & Teague, D. (2009). Further evidence of a relationship between explaining, tracing and writing skills in introductory programming. In *Proceedings of the 14th Annual ACM SIGCSE Conference on Innovation and Technology in Computer Science Education* (pp. 161–165). ACM. [https://doi.org/10.1145/1562877.1562930](https://doi.org/10.1145/1562877.1562930)
- Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E., & Li, S. (2018). Measuring program comprehension: A large-scale field study with professionals. *IEEE Transactions on Software Engineering, 44*(10), 951–976. [https://doi.org/10.1109/TSE.2017.2734091](https://doi.org/10.1109/TSE.2017.2734091)