Debugging
debugging
Foundations
Debugging by Tracing
Most beginners debug by staring at their code and hoping the bug reveals itself. Engineers who ship working software do something different: they trace execution one line at a time, watch each variable, and pinpoint the exact moment the program's state stops matching their mental model. That motion is a learnable, repeatable skill. **Debugging by Tracing** turns that skill into a structured workflow. You will define what program state actually is (the values of every variable plus the current line of execution), practice walking through a function step by step recording each change, and learn to use loop invariants (conditions that must hold before and after every iteration) to verify correctness without running the code. You will work through a systematic process of reproduce, trace, locate, fix, and verify, and you will see the most common beginner pitfalls including off-by-one errors, uninitialized variables, and misordered swaps. In **How to Read Code (JS & Python)**, you practiced tracing variables through `for` and `while` loops and stepping through function calls on the call stack. This lesson takes that same tracing motion and aims it at a specific goal: finding the line where a bug first introduces wrong state, instead of just understanding what correct code is doing. With Tier 1 essentials behind you, you will be ready to dive into the data structures track starting with **Arrays & Strings**, where every algorithm you write will benefit from being traceable and provably correct.
Not Started
0%
Behavioral Interviews
Solving Complex Technical Problems
Complex-problem questions are the technical-depth probe at the heart of every senior engineering interview. They test whether you can decompose a hard, novel problem under uncertainty, validate hypotheses cheaply, and demonstrate technical depth without over-explaining. This lesson defines what actually counts as 'complex' (scale, novelty, blast radius, time-pressure, multi-component coupling), walks through the four-phase arc (decompose, hypothesise, validate, iterate) you can apply to any technical-depth answer, covers when to mention specific technologies (yes when relevant, no when flexing), and provides fully worked model STAR answers for the prompts you will hear most. After this lesson you will be able to take any genuinely hard problem from your career and tell the story so the rubric reads depth, structure, and judgement simultaneously.
Debugging & Production Incident Stories
Production-incident questions are the operational-judgement probe. They test whether you can act calmly under live pressure, separate mitigation from root-cause work, and tell a blameless story that distinguishes systems-level lessons from individual blame. This lesson defines incident-grade storytelling (timeline craft with explicit T+0 / T+5 / T+30 markers), draws the line between fix, remediation, and prevention, walks through blameless-postmortem language you can use in the room without sounding rehearsed, and provides fully worked model STAR answers for the prompts you will hear most. Every model answer in this lesson focuses blame on systems and processes, never on people or teams. After this lesson you will be able to take any real incident from your career and shape it into an answer that scores on calm, judgement, and operational maturity simultaneously.
Community
N+1 Queries: Detection and Prevention
What an N+1 query is, why ORMs hide them, the four ways to fix them, and the simple logging change that has caught every N+1 I have shipped since I added it.
The tcpdump One-Liner I Actually Remember
A small Python wrapper around the only tcpdump invocation I can recall under pressure, plus a parser that turns its line-buffered output into JSON so I can pipe it to jq.
A Tracer Decorator With Arg Redaction (Python)
A `@trace()` decorator I bolt onto Python services when the production logs go quiet at the wrong layer. Logs entry, exit, duration, and exceptions, with secret-arg redaction baked in.
React useEffect: The Five Mistakes I Stopped Making
useEffect is for synchronizing with external systems, not for sequencing state. Five concrete mistakes I keep finding in PRs, with the fixes that replaced them.
The 30-Line Debug Print I Keep in My Dotfiles
A pretty-printer for Python objects that I paste into every new project. Shows types, depth, and truncates long containers, so I stop reaching for `pprint` mid-incident.
Resolving a Production Stack Trace Against a Source Map
When a minified Sentry stack only points at `bundle.js:1:140183`, this is the zero-dep VLQ decoder I drop in to map every frame back to a real source line.
useState Batching and the Stale Closure Trap
React batches state updates, and that interacts badly with closures over old state. The functional updater form fixes most cases, but knowing why is what saves the rest.