Predict Python output. Pass technical interviews.

A trace table is a row-by-row log of every variable change as the interpreter executes your program. In technical interviews, it replaces guesswork with a repeatable system: line number, event (assignment, condition, loop tick), and new values.

Start by writing column headers for each name that appears in the snippet - include loop indices and parameters. Execute one line at a time. When you hit a function call, open a sub-table for that frame and return to the caller only after you resolve the return value.

Interviewers reward candidates who narrate scope: locals vs globals, when a name is rebound, and whether two variables alias the same list. Practice until your table explains stdout character-for-character, including newlines and spaces.

PyTrack simulates this exact skill with generated dry-run challenges so you build muscle memory before your next phone screen.

Slicing appears innocent but drives many wrong answers. Trick one: s[::-1] reverses without mutating the original. Trick two: s[-1] is the last character; s[:-1] drops only the final character.

Trick three: a step of zero raises ValueError - interviewers slip this into try/except traces. Trick four: s[1:1] is always empty; s[1:2] is one character. Trick five: nested slicing on substrings like s[2:][:-1] rewards careful order of operations.

When tracing, copy the string value after every slice into your table. Slices create new strings; they never modify the source. Combine slicing with loops and you get classic FAANG warm-up questions.

Memorized templates assume clean inputs and familiar APIs. Live screens swap in generators, context managers, or mutable default arguments to test whether you truly understand execution.

Dry-running forces you to simulate the interpreter: short-circuit booleans, lazy iterators, and exception unwinding. These details decide correct stdout when no IDE is available.

Strong candidates pair pattern knowledge with tracing discipline. Use LeetCode for algorithm families; use trace practice for Python fluency. PyTrack focuses on the second half so you are not caught off guard by a 15-line script question.

Treat [f(x) for x in iterable if cond] as: create empty list, for x in iterable, if cond then append f(x). The comprehension has its own scope in Python 3 - the loop variable does not leak.

Nested comprehensions expand from inside out. [a for b in x for a in b] processes the leftmost clause as the outer loop. Write the nested for-loops on scratch paper before filling your trace table.

Side effects matter: calling mutating methods inside f(x) can change shared objects elsewhere. Always note whether the iterable is consumed once or referenced again after the comprehension.

Default argument values are evaluated once at function definition time, not on each call. A default list is shared across every invocation that omits that argument.

In a trace table, mark the default object at definition time. When the function body appends to the default, record the mutation on that single list object. The next call without arguments continues from the same list.

The fix - use None and assign inside the body - is standard, but interviews test recognition, not refactoring. Expect follow-ups: tuples as defaults, frozen dataclasses, and copy vs reference.

Open with a restatement of the problem and your plan: 'I will trace variables top to bottom and call out when scope changes.' Silence is costly; steady narration builds trust.

Use signposts: 'Before line 7, i is 2 and acc is 5.' After tricky lines, pause and verify with the interviewer. If you revise an earlier value, say so explicitly - corrections with reasoning score higher than silent errors.

Reserve the last five minutes for edge cases: empty input, single element, or an off-by-one loop bound. PyTrack's timed practice pairs well with recording yourself to tighten delivery.

Each recursive call gets a new row group: parameters at entry, base-case check, then either return or another call. Do not merge frames - depth errors come from losing track of which n belongs to which call.

Work bottom-up on returns: only after the deepest call resolves can you fill the return column for its caller. Tail recursion still uses the same table; Python does not optimize it away in interviews.

Memoization adds a cache column. Before recursing, check whether arguments were seen; on return, store results. Tracing cache hits prevents double-counting work in complexity follow-ups.

Since Python 3.7, dicts preserve insertion order in language semantics; interview questions still test whether you mutate while iterating. Adding keys during a for loop over keys can raise RuntimeError or skip entries depending on timing.

dict.keys(), .values(), and .items() are dynamic views - they reflect later mutations. Snapshot with list(d) if you need a stable iteration for tracing.

Unpacking with ** merges rightmost wins for duplicate keys. In traces, expand merges stepwise and record the final key set before any loop consumes the dict.