Coding Interviews Without a Compiler: How To Trace and Check Your Code

A coding interview in a shared document, on paper, or on a whiteboard removes the feedback you normally get from running a program. Syntax mistakes stay quiet. An incorrect branch can look convincing until you trace it. The useful preparation is to practice making your assumptions, state changes, and correctness checks visible.

Start by confirming the format. Then use a repeatable sequence: define the contract, explain the approach, write real code when required, trace representative cases, and state what you have and have not verified.

Confirm the rules before changing your preparation

Interview environments vary. Amazon's preparation guidance recommends practicing outside an integrated development environment. Microsoft's technical interview guidance describes a tool where candidates can compile and run code and says to use code rather than pseudocode. Neither statement should replace the instructions for your particular round.

Ask the recruiter or coordinator:

• Will the editor run code, provide autocomplete, or show syntax errors?
• Which programming languages and standard libraries are permitted?
• Is the expected output executable code, pseudocode, or a design sketch?
• Are documentation, notes, search, or AI tools permitted?
• Will I implement a function, a complete program with input parsing, or a component in an existing project?

Practice with those restrictions. A round that requires Java is not the place to discover that you have rehearsed every collection operation only in Python. Follow the stated resource policy; do not quietly open a second editor or assistant because the provided environment feels unfamiliar.

State a contract you can actually check

Before coding, clarify the inputs, output, valid ranges, mutation rules, and important edge cases. Choose questions that could change the implementation.

For an original practice exercise, suppose you must return the index of the first value that appears for a second time while scanning an integer list from left to right. Return -1 when nothing repeats. The input is a valid list, and the function must not modify it.

This wording matters. In [8, 3, 3, 8], the answer is 2: the second 3 is the first repeat encountered. The task is not to return the original index of whichever value eventually repeats. Agreeing on that example prevents a correct implementation of the wrong requirement.

Explain the invariant before writing the loop

An invariant is a statement that remains true as the algorithm advances. It gives you something more precise to verify than “this loop seems right.”

For the exercise, the invariant is: before processing index i, the set seen contains exactly the distinct values at earlier indices. If the current value is already present, this index is a repeat. Because the scan proceeds left to right, returning immediately gives the earliest repeat index.

def first_repeat_index(values):
    seen = set()
    for index, value in enumerate(values):
        if value in seen:
            return index
        seen.add(value)
    return -1

For a list of n ordinary integers, this uses expected O(n) time with average constant-time hash-set operations and O(n) additional space in the worst case. State the hash-table assumption instead of promising unconditional constant-time lookups.

When extra memory is prohibited, a nested scan of earlier values is a simple alternative with O(n²) time and O(1) extra space. Sorting would change the ordering information the question asks about unless you preserve and reason about original indices. Choose an alternative because it meets a confirmed constraint.

Trace the code you wrote, not the algorithm you intended

Use a small state table on your working surface. For [8, 3, 3, 8], write the current index, value, set before the check, and action:

1. Index 0, value 8, empty set: no match; add 8.
2. Index 1, value 3, set contains 8: no match; add 3.
3. Index 2, value 3, set contains 8 and 3: return 2.

Notice the order: membership is checked before insertion. If you accidentally insert first, the current value will always be present and the function can incorrectly return 0. Read your actual lines while tracing so you catch this kind of divergence.

Then test cases that challenge different assumptions:

• [] should return -1: the loop never runs.
• [4] should return -1: seeing a value once is not a repeat.
• [4, 4] should return 1: the earliest possible repeat.
• [1, 2, 3] should return -1: no early return.
• [1, 2, 1, 2] should return 2: stop at the first repeat encountered.
• [-2, 0, -2] should return 2: zero and negative values do not need special sentinel handling.

A few traced examples do not prove correctness for every input. Combine them with your invariant, termination argument, and an explanation of why the returned answer satisfies the contract.

Use three review passes when you cannot execute

Contract pass: Check that the function returns the requested thing and handles the agreed input domain. Verify whether it mutates input or changes required ordering.

State pass: Inspect initialization, update order, boundary conditions, early returns, and the final return. For recursion, check the base case and progress toward it. For graph traversal, check when a node becomes visited.

Language pass: Check variable names, indentation or braces, function signatures, collection methods, types, and language-specific behavior. In languages with fixed-width integers, consider overflow where the input range makes it relevant.

This order keeps you from spending the entire review polishing syntax while missing a wrong return value or an infinite loop. Reserve time for all three.

Recover from a syntax gap or discovered bug

If you forget a library method, identify the narrow uncertainty. Do not pretend that an invented API is known to work.

“I know the operation I need, but I am uncertain about this library's exact method name. May I check the permitted documentation, or would you prefer that I implement the operation directly?”

If pseudocode is allowed, label it clearly. If executable code is required, keep working toward valid code in the permitted language. A tool-free environment does not automatically relax that requirement.

When a trace reveals a logic bug, state the failing input and the reason for the correction:

“On the two-element duplicate case, I return the wrong index because I update the set too early. I will move the membership check before insertion, then retrace the empty, single-element, and duplicate cases.”

Correcting a concrete error is useful evidence of your reasoning. Avoid rewriting everything unless the approach itself cannot satisfy the constraints.

Practice without feedback, then restore feedback

For each practice session, select an unfamiliar problem within a topic you have studied. Spend about five minutes clarifying the contract, fifteen to twenty minutes explaining and implementing a solution, and ten minutes tracing and reviewing it. Adjust those limits to your actual interview format.

After the simulated round, run the unchanged code locally. Compare compiler or runtime failures with what your manual review missed. Classify each error as a contract misunderstanding, algorithm mistake, state-update bug, syntax gap, or missed test case. Fix the recurring category instead of merely increasing the number of problems solved.

Keep both kinds of practice. Tool-free sessions build tracing and recall; normal coding sessions verify that your reasoning produces working programs. For interviews built around a runnable repository, use the practical coding interview guide to practice building, testing, and debugging in that environment.

Finish with an accurate verification statement

End by summarizing the contract, complexity, and checks performed. If you could not run the program, say that directly.

“The function returns the first repeat index without modifying the list. It uses expected linear time and linear extra space. I traced empty input, no-repeat input, and two duplicate patterns, and checked the update order. I have not executed it in this environment; running those cases would be my next verification step.”

Recent September 2026 accounts of writing code in Notepad and pen-and-paper coding rounds show why this preparation can matter. They are individual reports, not evidence that all employers use the same format. Confirm your own round and practice the skills it actually requires.