Top 30 Debugging Interview Questions and Answers
30 multiple-choice questions on Debugging, drawn from 30 bites out of the 104 tagged Debugging on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
Why does the card say the tutorial uses active exercises rather than passive video?
Show the answer
Answer: b · To build debugging instincts and reduce reliance on guessing and type casting
The card emphasizes that junior developers often guess and cast their way out of TypeScript errors, and active exercises are meant to build debugging instincts instead. Option A describes the Gitpod integration, which is a deployment convenience, not the pedagogical reason for choosing active exercises over video.
Read the full bite: Matt Pocock Tutorial Covers Ten TypeScript Errors
Question 2 of 30
Which pitfall is explicitly warned against when applying the 5 Whys technique?
Show the answer
Answer: c · Attributing the problem's origin to individual human error rather than systemic flaws
The card explicitly states, 'The footgun is blaming people instead of asking why the process allowed the error,' emphasizing that the technique should focus on systemic process failures, not individual fault. While stopping at exactly five 'Whys' can be a misuse, the primary 'footgun' highlighted is the misdirection of blame.
Read the full bite: 5 Whys: Find the Root Cause, Not the Symptom
Question 3 of 30
Analytics report a 30% drop in conversions, but backend sales are stable. The drop is uniform across all segments. What is the most plausible explanation for this discrepancy?
Show the answer
Answer: d · A new, un-instrumented sales channel was introduced, such as phone orders.
This is a classic data loss scenario, where events happen but are not tracked. A new, un-instrumented channel explains why backend totals are stable while analytics totals drop. An attribution model change (C) would only reallocate conversions between channels, not change the total count.
Read the full bite: Sudden metric drop, no recent deployments. What's the cause?
Question 4 of 30
A key metric suddenly drops. Which initial action best demonstrates a systematic debugging approach?
Show the answer
Answer: d · Compare the metric against a reliable backend source and segment the data by relevant dimensions.
Option D outlines the critical first steps of establishing a source of truth and segmenting data, which are essential for systematically narrowing down potential causes. Option A is a premature, specific technical check that should only occur after initial validation and pattern identification.
Read the full bite: How would you debug a sudden drop in a key metric?
Question 5 of 30
Why can the host run strace against a container process even though strace is absent from the container image?
Show the answer
Answer: c · The container shares the host kernel, so the host PID can be traced directly
Containers are host processes under a shared kernel, so tracing the mapped host PID works from outside; nothing is injected into the image and strace is not hidden inside it.
Read the full bite: Trace a container process's syscalls from the host
Question 6 of 30
A conversion metric drops suddenly with no recent deployments. Segmenting reveals an identical percentage loss across all devices, channels, and geographies. What does this pattern most strongly indicate?
Show the answer
Answer: d · A global instrumentation problem such as a broken tag or attribution change
A uniform percentage loss across every dimension is the hallmark of a global instrumentation break such as a missing tag or attribution change. The most tempting distractor is a business regression, but jumping to product or marketing causes without first reconciling frontend events against backend transactions treats the metric as ground truth before validating data integrity.
Question 7 of 30
When a production model performs poorly, how does ML Metadata primarily facilitate debugging?
Show the answer
Answer: b · It enables tracing the model's complete lineage, including the exact data, code, and hyperparameters used for its training.
Option B accurately describes ML Metadata's core debugging function: tracing a model's lineage back to its training inputs and processes. Option D is tempting due to the 'git blame' analogy, but ML Metadata tracks artifacts and executions, allowing identification of the code version used, not automatic flagging of specific code changes.
Read the full bite: ML Metadata: The Logging Layer for ML Pipelines
Question 8 of 30
Why is docker exec -it preferred over docker attach when opening a shell to debug a running container?
Show the answer
Answer: d · exec starts a new process, leaving PID 1 untouched, while attach can kill it on Ctrl-C
exec spawns a separate process so the main process is unaffected, whereas attach connects to PID 1's stdio and Ctrl-C can terminate it; attach is not deprecated and exec does run inside the container.
Read the full bite: Debug a running container with the Docker CLI
Question 9 of 30
When a user reports a frustrating workflow timeout, which investigation approach best validates the complaint through engineering rigor?
Show the answer
Answer: b · Reproduce the exact workflow, then inspect logs and traces for latency spikes while segmenting by the user's environment.
The card prescribes reproducing the exact workflow first, then querying specific traces and logs segmented by environment to validate the issue. Option D tempts because it is data-driven, but aggregate dashboards hide user-specific pain points; A jumps to an unverified fix, and D substitutes more anecdotes for technical evidence.
Question 10 of 30
Which telemetry design best separates user abandonment from backend payment failures?
Show the answer
Answer: b · Send periodic visibility heartbeat pings with checkout_id and correlate with server-side gateway response events
Heartbeat pings let you distinguish tab closure from temporary backgrounding, and correlating with server gateway responses isolates hard declines from user intent. A single checkout_failed event collapses distinct failure modes into one unactionable metric, while relying on page unload events alone misses a large share of mobile exits.
Read the full bite: How do you instrument client and server to debug payment drop-offs?
Question 11 of 30
Paused in LLDB with a UIView named header and an Int named count, which commands yield a human-readable view summary and the raw typed integer value?
Show the answer
Answer: c · po header and p count
po header invokes description or debugDescription for a human-readable summary, while p count prints the raw value with type info and creates a persistent variable. Option B is tempting because p is a general evaluator, but it would likely output the UIView's pointer or struct layout instead of its friendly description.
Read the full bite: What LLDB command prints a UIView description versus an Int?
Question 12 of 30
In a long pre-training run, the loss suddenly spikes. Which action should you take FIRST before applying any mitigation?
Show the answer
Answer: c · Check the gradient norm logs to confirm whether a gradient explosion occurred
The card emphasizes checking gradient norm logs first to confirm an explosion before deciding on recovery actions like rollback or hyperparameter changes. Option A is tempting because rolling back is a crucial recovery step, but doing so before confirming the root cause is premature and skips the diagnostic phase.
Read the full bite: What causes sudden loss spikes in long pre-training runs?
Question 13 of 30
Why does a symbolic breakpoint on UIViewAlertForUnsatisfiableConstraints help debug Auto Layout in UIKit?
Show the answer
Answer: c · It resolves to a runtime address without needing UIKit source code and lets you trace back to your code
A symbolic breakpoint stops on a function by name inside closed-source UIKit without requiring source code, and the backtrace reveals which of your methods added the conflicting constraints. Distractor D is tempting because both breakpoints halt execution, but exception breakpoints catch all thrown exceptions broadly, whereas a symbolic breakpoint is precisely targeted to a specific function entry.
Read the full bite: Explain symbolic breakpoints and debug Auto Layout with one
Question 14 of 30
After establishing a baseline for a build time regression, what is the most effective next step before applying optimizations?
Show the answer
Answer: b · Decompose the pipeline into discrete stages and measure each stage's wall-clock time
The card stresses measuring each stage to find the actual bottleneck before applying optimizations. A applies parallelism prematurely, B suggests a wasteful platform migration without diagnosis, and D targets micro-optimizations instead of structural issues.
Read the full bite: Your build times increased significantly. How do you investigate and optimize?
Question 15 of 30
After discovering a divergence between client order_completed events and backend orders, what is the most appropriate immediate first step?
Show the answer
Answer: d · Run a time-bound join on user ID and order ID to compute daily deltas segmented by platform
The correct approach begins with phase-one quantification: joining both systems to measure the gap direction and scale before applying fixes or deep tracing. Tracing orphaned events is a phase-three activity that is inefficient without first knowing whether client events exceed backend records or vice versa.
Read the full bite: What causes client order_completed events to diverge from backend records?
Question 16 of 30
In which scenario would log analysis be least effective compared to alternative monitoring tools?
Show the answer
Answer: a · Understanding the end-to-end journey of a single request across multiple microservices.
Log analysis is less effective for understanding a request's journey across multiple services because distributed tracing provides a more structured view for this specific task. The other options are explicitly mentioned as effective use cases for log analysis, such as troubleshooting errors, business intelligence, and performance monitoring.
Read the full bite: Log Analysis: Reading Your System's Story
Question 17 of 30
When debugging an OutOfMemory (OOM) error in a Spark job, what is the most effective initial approach?
Show the answer
Answer: c · Analyze the Spark UI and logs to pinpoint the failing stage and investigate data skew or inefficient code.
The card emphasizes a systematic debugging approach starting with diagnosis using the Spark UI and logs to identify root causes like data skew or inefficient code, before considering resource tuning. Immediately increasing executor memory is highlighted as a red flag, as it doesn't address the underlying problem.
Read the full bite: How do you debug out-of-memory errors in a Spark job?
Question 18 of 30
A Spark job fails with Out-of-Memory errors, but only on a few specific executors during a large join. What is the most effective initial diagnostic step?
Show the answer
Answer: a · Inspect the Spark UI's stage details to check if a few tasks are processing significantly more data than others.
The first step is always diagnosis. Since only a few executors are failing, this strongly suggests data skew, which is confirmed by inspecting task metrics in the Spark UI. Increasing memory or changing configurations without confirming the root cause is an inefficient, brute-force approach.
Read the full bite: Diagnosing Out-of-Memory Errors in a Spark Job
Question 19 of 30
After reproducing a background battery drain issue with Energy Log on a physical device, you see Location Services pinned at high power. Which approach is most appropriate?
Show the answer
Answer: d · Align the spike with background tasks or signposts, implement a targeted fix, and validate with a second Energy Log
Correct answer C follows the full diagnostic loop: correlate the Instruments spike to a specific app action with timestamps or signposts, apply a targeted fix, and prove improvement with a new Energy Log. Option B is tempting because lowering location accuracy is a legitimate optimization, but doing so preemptively without correlating the spike to a specific background task skips root-cause analysis and may not address the actual drain.
Read the full bite: How would you use Energy Log to investigate battery drain?
Question 20 of 30
After reliably reproducing an Android app crash, what is the most efficient next step to identify the root cause?
Show the answer
Answer: b · Examine the Logcat output for a "FATAL EXCEPTION" and its associated stack trace.
The card emphasizes that after reproducing a crash, the immediate and most efficient next step is to check Logcat for the "FATAL EXCEPTION" and its stack trace, which provides the critical initial clue to the crash location. Adding Log.d() statements is an inefficient "shotgun debugging" approach, and setting a breakpoint is typically done after analyzing the initial Logcat output if more detail is needed.
Read the full bite: How do you debug an app crash in Android Studio?
Question 21 of 30
After isolating a fatal exception in Logcat, where should you typically set your first breakpoint to debug the root cause?
Show the answer
Answer: a · At the deepest frame in your source code before system or library calls
The deepest frame in your source code is the closest point to the failure under your control, letting you inspect the exact variable state; stopping at the top line often lands inside framework code and misses the actual buggy call site.
Read the full bite: App crash: debug with Logcat and breakpoints in Android Studio
Question 22 of 30
After identifying the exact line causing a crash from the Logcat stack trace, what is the most effective next step to understand the root cause?
Show the answer
Answer: b · Set a breakpoint a few lines before the crash and run in Debug mode to inspect variable states.
Setting a breakpoint allows you to interactively inspect the program's state right before the error, revealing the unexpected values causing the crash. While adding Log statements can work, it is a slower, iterative process compared to the interactive debugger.
Read the full bite: How would you debug an app crash in Android Studio?
Question 23 of 30
A view's runtime appearance differs from its XML declaration. What key information does the Layout Inspector's Attributes Pane provide to diagnose this?
Show the answer
Answer: b · The final, resolved value for each attribute and the exact source from which it was inherited, such as a style.
The Attributes Pane is crucial because it shows the final, resolved value of an attribute and its origin, which often differs from the static XML due to styles or themes. The 3D model is a feature of the Layout Display, not the Attributes Pane.
Read the full bite: Which tool inspects the view hierarchy to debug layouts?
Question 24 of 30
Under which scenario would using a breakpoint likely be counterproductive for debugging?
Show the answer
Answer: b · Diagnosing a race condition that is highly sensitive to execution timing.
The card states that breakpoints should be avoided for 'issues that are highly timing-dependent, like race conditions,' because pausing the program can alter its behavior and make the bug disappear. The other options describe ideal use cases for breakpoints, such as inspecting variable states or understanding code flow.
Question 25 of 30
A view is clipped at runtime but looks correct in the Layout Editor. What does the runtime inspection tool surface that the static preview cannot?
Show the answer
Answer: a · Live bounds, visibility states, parent-child relationships, and 3D layer visualization
Layout Inspector connects to a running process and reveals live bounds, visibility states, and 3D layering that static previews cannot. The Layout Editor only displays authored XML, so it will not expose runtime measure or constraint errors that cause clipping.
Read the full bite: Which Android Studio tool inspects view hierarchy and what does it show?
Question 26 of 30
Which Android Studio tool would you use to diagnose why a button isn't clickable due to a suspected overlapping view?
Show the answer
Answer: b · Layout Inspector, using its 3D view to identify overlapping elements.
The Layout Inspector's 3D view is specifically designed to visualize the z-order of views, making it ideal for identifying overlapping elements that might be intercepting touch events. While the Android Profiler can help with general unresponsiveness, it does not visualize UI overlap.
Read the full bite: How do you debug a running app's view hierarchy?
Question 27 of 30
Which UI issue is the Xcode View Debugger uniquely suited to diagnose?
Show the answer
Answer: d · A button failing to respond to taps because an invisible view is covering it.
The View Debugger is designed to reveal the visual hierarchy, including invisible views that might be intercepting touches, as highlighted in the canonical example. It is not for debugging application logic (like incorrect text or network issues) or dynamic animations.
Read the full bite: Xcode View Debugger: Uncover Hidden UI Bugs
Question 28 of 30
In the Android Debug Bridge (ADB) architecture, what is the main role of the 'server' component?
Show the answer
Answer: b · To manage communication between the client and the device's daemon.
The card states the server's role is to manage communication between the client (on the dev machine) and the daemon (on the device). Option A describes the daemon, while option C describes the client.
Question 29 of 30
According to the Five Whys technique, when should an investigation typically conclude?
Show the answer
Answer: b · When further "Why?" questions no longer provide useful, actionable insights into a foundational process or system flaw.
The card states that you stop when asking "Why?" no longer yields a useful, actionable answer and you've identified a foundational process or system flaw. Option A is a common misconception, as the card clarifies that "five" is a guideline, not a strict rule.
Read the full bite: Five Whys: Find the Root Cause, Not Just the Symptom
Question 30 of 30
When automating nightly APK deployments on a headless CI server, which characteristic of ADB makes it suitable for this task?
Show the answer
Answer: b · It is a client-server program whose command-line client can run without Android Studio or any IDE
ADB is defined as a standalone client-server command-line tool in the Android SDK Platform Tools, so it can script builds and deployments without an IDE present. The distractor calling it an Android Studio plugin reflects a common misconception, while JDWP is actually the separate protocol used for Java breakpoint debugging, not ADB operations.
Read the full bite: What is ADB? Describe two common commands and what they accomplish.
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.