Reading Code and Stack Traces Aloud

Many .NET interviews now include a live-review round: they show you code or a stack trace and watch you think. The skill being tested is not spotting the bug in four seconds — it's narrating a disciplined read so the interviewer can follow your reasoning. Silence reads as confusion even when you're thinking well. Practice talking while you read.

Narrating a stack trace

Work it top-down and say what you're doing: "The exception type is ObjectDisposedException, the message mentions the DbContext, and the top frame in our code — skipping the framework frames — is OrderService.GetHistoryAsync. So something is using a context after its scope ended." That's the pattern: exception type → message → first frame in our namespace → hypothesis. Mention that with async code the trace can be reshuffled by the state machine, so you anchor on your own namespaces, and that an AggregateException or inner exception is where the real story usually hides — always say "I'd unwrap the inner exception first."

The bugs they plant

Live-review snippets recycle a small set of classics. Rehearse spotting and naming each:

• Null dereference — a value from model binding, FirstOrDefault, or config used without a check. Say where null enters, not just where it explodes.
• Off-by-one — <= against .Count, or paging math that skips/duplicates a row at the boundary. Walk the edge case aloud: "with exactly 10 items, page 2 would…"
• Disposed context — a DbContext captured by a lambda that outlives the request, or a query returned as IQueryable and enumerated after the scope closed.
• Race condition — check-then-act on shared state (if (!cache.ContainsKey)… Add), or a non-thread-safe collection touched from parallel code. Say the word interleaving.

If you can't find a bug, verify aloud instead: inputs, boundaries, error paths, disposal. Structured checking beats a lucky guess.

Critiquing code politely

You may be asked to review a teammate's PR-style snippet. The tone test matters as much as the technical one. Use questions and shared ownership: "What happens here if the list is empty?" rather than "this is wrong." Anchor comments to effects ("this will run one query per order — at 1,000 orders that's a slow page") not style taste. Concede uncertainty when real: "this might be fine if the caller guarantees non-null — is that documented?" And say something genuinely good about the code first; reviewers who only find faults are exhausting teammates, and interviewers know it.

Red flags

• Reading silently for a minute, then announcing an answer with no visible reasoning.
• Declaring a bug confidently without tracing the path that triggers it.
• Sneering at the planted code ("who wrote this?") — you just failed the culture check.

Practice prompts

1. Take any recent exception from your own logs and narrate it aloud, top frame to root cause, in under 90 seconds.
2. "This action calls .Result on an async service method. What could go wrong, and how would you phrase the review comment?"
3. Write a three-sentence polite review comment for a loop that queries the database on every iteration.