Why the interview takes the compiler away
Many intern interviews happen in a shared document or a plain online editor with no way to execute code. It feels like a handicap. Whatever the reason for the format, it helps the interviewer: without a run button, the interviewer sees how you convince yourself that code is correct.
Students used to an IDE often write code by trial and error, so coding without a compiler exposes a habit they did not know they had. They type something close, run it, read the error and adjust. That loop is fine at a desk and invisible in an interview. When the loop is gone, the only evidence of correctness is your reasoning, and that is what gets written down.
Small syntax slips usually matter much less than logic. A missing colon or a misremembered method name is rarely what decides the round. A loop that drops the last element is.
Write the test cases first
Before writing the function, write the cases you will check it against, as comments at the top. This takes a minute and does three jobs. It confirms you understood the problem, because the interviewer can correct a wrong expected output before you code it. It forces you to think about edge cases (empty input, one element, everything the same). And it gives you something concrete to trace afterwards.
Pick test cases that exercise different paths: a normal case, the smallest legal input and a case that hits the boundary of your loop. Three well-chosen cases beat ten similar ones.
Small functions with honest names
When you are writing code without a compiler, syntax highlighting or autocomplete, readability carries more weight. Name variables for what they hold (count, current, seen) rather than x and temp. Split the work into small functions if the problem has distinct steps, so you can trace each part on its own. If you cannot remember a library call, write a clearly named helper and say so: "I will call this is_vowel and assume it exists, then write it at the end if we have time."
A worked trace that finds a real bug
Take a common warm-up: run-length encoding, turning "aaabcc" into "a3b1c2". Here is the function with the test cases written first.
def run_length(s):
if not s:
return ""
parts = []
current, count = s[0], 1
for ch in s[1:]:
if ch == current:
count += 1
else:
parts.append(current + str(count))
current, count = ch, 1
parts.append(current + str(count))
return "".join(parts)
A common first draft omits the commented line. The loop only records a run when it sees a different character, so the final run is never recorded. Tracing "aaabcc" against the draft without that line shows it immediately:
| Step | ch | current | count | parts |
|---|
| start | - | a | 1 | [] |
| 1 | a | a | 2 | [] |
| 2 | a | a | 3 | [] |
| 3 | b | b | 1 | ["a3"] |
| 4 | c | c | 1 | ["a3", "b1"] |
| 5 | c | c | 2 | ["a3", "b1"] |
| loop ends | | c | 2 | ["a3", "b1"] |
Without the flush, the function returns "a3b1", not the expected "a3b1c2". You say "the c2 is missing, because the last run is never appended", add the line, and re-check the final row. Then trace "a": the loop body never runs, the flush appends "a1", correct. That second trace is cheap, and it proves the fix also handles the single-character edge case.
Tracing the code you wrote, not the code you meant
The failure here is a trace that confirms intentions instead of testing code. A candidate reads the loop, thinks "and then it records each run", and moves on. That is a summary of the plan, not a trace. A real trace reads each line as written and updates a value. It is slower, and it is the only version that catches the missing flush.
Keep the trace honest by writing variable values down in the document as you go, not just saying them. A small table or a comment line per iteration works. Writing values down also stops you skipping the final iteration and the step after the loop, which is where off-by-one and missing-flush bugs live.
Narrate the trace aloud, briefly. "Count is three, now b differs, so I append a3 and reset." The interviewer can follow, and if you go wrong they see exactly where. The live coding section of the nerves and recovery guide covers what to do when you freeze; this page is about proving code correct once you have written it.
When the interviewer finds the bug first
Sometimes they will say "are you sure about the last character?". Do not defend the code. Trace the input they hint at, find the line and fix it. Finding your own bug when pointed towards it is still a good signal. Insisting the code is correct without tracing it is not.
No compiler means your test cases and your trace are the run. Write the cases first, trace the code exactly as written, and include the step after the loop ends.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).