Debugging and Code Optimization Questions

Practical debugging skills and techniques for improving code performance and complexity. Topics include tracing and reproducing bugs, stepping through execution, reasoning about time and space complexity, refactoring for performance, and applying algorithmic optimizations. Candidates should be able to demonstrate logical debugging approaches and make safe, measurable performance improvements to working code.

HardTechnical

97 practiced

Describe how to reduce disk I/O bottlenecks in a data-processing pipeline that sorts very large files on disk. Discuss external merge-sort strategies, parallel I/O, SSD vs HDD trade-offs, buffer sizing, and relevant OS-level tuning (I/O scheduler, read-ahead).

Sample Answer

Start by framing the problem: sorting files larger than RAM requires minimizing costly disk I/O. The standard solution is an external merge-sort augmented by parallelism, smart buffering, storage choice, and OS tuning.

External merge-sort strategy- Phase 1 (run generation): Read chunks that fit in memory, sort in-memory, write sorted runs. Use multi-threaded in-memory sort (e.g., parallel quicksort) to utilize CPU while a single thread writes.- Phase 2 (k-way merge): Merge multiple runs in a single pass using a k-way priority queue. Choose k so that input buffers for each run + output buffer fit in RAM to avoid extra I/O passes. If k is limited, do multi-pass merging.

Parallel I/O- Overlap computation and I/O: use asynchronous I/O (AIO), prefetch reads while sorting previous chunk, and write runs in background threads.- Striping across multiple disks (RAID0) or using multiple file descriptors can increase throughput; coordinate merges to read from different devices in parallel.- For multi-core systems, dedicate threads for I/O vs CPU-bound work to avoid contention.

SSD vs HDD trade-offs- SSD: much higher IOPS and lower latency, favors many small random reads during k-way merge and supports smaller buffer sizes. But watch for write amplification and endurance—use large sequential writes where possible.- HDD: high sequential throughput but poor random IOPS. Favor larger, sequential reads/writes and reduce random seeks by increasing buffer sizes and merging runs to reduce passes.

Buffer sizing and layout- Allocate per-run read buffers sized to amortize seek/latency: for HDDs prefer larger buffers (MBs); for SSDs smaller buffers (hundreds of KB) may be sufficient.- Output buffer should be large enough to batch writes (tens of MB) to avoid small synchronous writes.- Choose k = min(number_of_runs, floor((available_RAM - output_buf)/per_run_buf)). Larger k reduces merge passes but increases memory pressure and cache misses.

OS-level tuning- I/O scheduler: on Linux use noop or deadline for SSDs to avoid unnecessary reordering; for HDDs deadline often helps; avoid cfq for high-throughput batch jobs.- Read-ahead: increase readahead for HDDs to exploit sequential patterns; for SSDs reduce aggressive readahead to avoid wasting I/O.- Filesystem: use ext4/xfs with large stripe and journal settings tuned for large files; consider direct I/O (O_DIRECT) to bypass page cache if you manage your own buffers to avoid double-caching.- AIO and io_uring: prefer io_uring for high-performance async I/O on modern kernels.- NUMA: pin threads and allocate buffers on local memory nodes to reduce cross-node latency.

Practical checklist- Maximize sequential access when on HDD; exploit parallel random I/O on SSD.- Overlap work and I/O with async pipelines.- Size k and buffers to fit RAM and minimize passes.- Test with realistic data sizes and use iostat, blktrace, perf, and fio to validate settings and identify hotspots.

This combination reduces disk waits, minimizes passes, and balances CPU, memory, and storage characteristics for efficient large-file sorting.

MediumTechnical

79 practiced

A hot Java code path uses exceptions to control normal flow (throwing/catching frequently), causing performance issues. Explain why exceptions are expensive in Java and propose alternative designs (Optional, result types, sentinel values) that improve both performance and clarity. Explain how to migrate incrementally.

Sample Answer

Exceptions in Java are expensive because creating a Throwable captures a stack trace (native calls, allocation) and throwing unwinds the stack—work that’s optimized for rare error paths, not tight loops. Using exceptions for normal control flow both hurts latency and obscures intent.

Better alternatives:- Optional<T> for possibly-absent values (clear API, no allocation on success).- Result/Either types (explicit success vs error) to carry data and error info without stack traces.- Sentinel values (null, empty collections, enums) when semantics are simple and documented.- Callbacks/visitor or state objects for polymorphic flows.

Examples:

java

// Optional instead of exception
Optional<User> findUser(String id) { ... }
User u = findUser(id).orElse(defaultUser);

// Result type
class Result<T> { boolean ok; T value; String err; }
Result<Order> r = orderService.tryPlace(order);
if (!r.ok) log(r.err);

Migration strategy (incremental):1. Profile and identify hot paths where exceptions dominate.2. Add new methods alongside old ones (findX vs getXOrThrow) so callers can migrate safely.3. Replace call sites in hot loops first—switch to Optional/Result.4. Add comprehensive tests and benchmarks comparing before/after.5. Once callers are migrated, deprecate/remove exception-throwing APIs.6. Use linting/PR checks to prevent reintroducing exception-driven control flow.

Trade-offs: Optional and Result improve clarity and performance but add API surface and require disciplined handling; sentinel values can be cheap but risk misuse if not documented.

EasyTechnical

91 practiced

Explain how to use an interactive debugger (gdb for C/C++, pdb for Python, or an IDE debugger for Java) to step through execution, inspect variables, evaluate expressions, and find the cause of a null-pointer or segmentation fault. Describe commands or steps you would run (including backtrace/core dump inspection, conditional breakpoints, and watchpoints) and why each step helps.

Sample Answer

Start by reproducing the crash reliably (smallest failing input). Then use an interactive debugger to observe runtime state.

gdb (C/C++):- Run: gdb ./app; run args… — starts under debugger so you can break at point of failure.- After crash: backtrace (bt) — shows call stack and frame numbers; helps identify where segfault occurred.- frame N; info locals; print var — inspect variables in the failing frame to find null pointers or corrupted values.- print /x ptr — view pointer value in hex to see NULL (0x0) or garbage.- set logging on — save session for later.- core dump: gdb ./app core; bt — if process already crashed, core lets you inspect same way.- break file:line or break func — set breakpoints earlier to step through suspicious code.- break lineno if condition — conditional breakpoints stop only when condition true (e.g., ptr == NULL).- watch ptr — watchpoints break when memory at ptr changes; useful to find when a pointer becomes NULL or overwritten.- step (s) vs next (n) — step enters function, next runs over it; use until you reach the problematic call.- finish — run to end of current function and return value.

pdb (Python):- Run: python -m pdb script.py args — start under pdb.- Commands: l (list), b file:lineno or b func, c (continue), s (step), n (next).- p var / pp var — print variable (pp formats nicely). Use where (w) for stack trace.- Conditional breakpoint: b lineno, condition — stops only when condition true.- breakpoints can be set at exception: import pdb; pdb.set_trace() or use -m pdb and run until exception.- To inspect object internals: p obj.__dict__ or dir(obj).- For segmentation-like crashes in native extensions, run under gdb.

IDE debuggers (Java, Python, C++ in IDEs):- Set breakpoints by clicking gutter; right‑click to add conditions or hit-count (> trigger on nth hit).- Use “Evaluate Expression” to run expressions or getters without modifying state.- Use Variables/Watch panels to monitor specific values; add watch expressions for derived checks.- Use step into/over/out and run-to-cursor to navigate.

Why each step helps:- Backtrace locates the crash site and call path; inspecting locals reveals null/invalid pointers.- Conditional breakpoints and hit-counts reduce noise and let you stop only when the bug manifests.- Watchpoints show who wrote or changed a value, exposing memory corruption or logic errors.- Core dumps let you debug post-mortem when reproducing under debugger is hard.- Stepping and expression evaluation let you validate assumptions about types, sizes, returns, and detect off-by-one or initialization bugs.

Common tips:- Compile with debug symbols (-g) and no optimizations (-O0) for clearer stepping.- Use ASAN/Valgrind to catch memory errors that precede a segfault.- Re-run with verbose logging if necessary, but prefer debugger for precise state inspection.

EasyTechnical

78 practiced

Describe how to use 'git bisect' to find the commit that introduced a regression when you have a failing test. Show the sequence of commands you would run and explain strategies for handling flaky tests during bisection.

Sample Answer

Start by confirming a reproducible failing test locally. Then use git bisect to do a binary search between a known-good commit and the first bad commit.

Commands (example):

# start bisect: mark bad (current) and a known-good commit
git bisect start
git bisect bad                     # current HEAD is failing
git bisect good v1.2.3             # tag/commit known to pass

# let git check out middle commits; run your test manually each step
# if test fails:
git bisect bad
# if test passes:
git bisect good

# when bisect finishes:
git bisect reset

Automate with a test script so bisect can run unattended:

# script must exit 0 on pass, 1 on fail, 125 to skip
git bisect run ./run_my_test.sh

Strategies for flaky tests:- Stabilize the test first (best): fix timing, mocks, or environment so results are deterministic.- Repeat runs per commit: wrap test in a loop and require N consecutive failures/passes before reporting result.- Use exit code 125 to skip when environment-dependent: `git bisect run` will skip commits returning 125.- Narrow scope: run only the single failing test or minimal reproducible scenario to reduce noise.- Capture logs/artifacts per-step to triage intermittent failures later.

Notes:- Keep the bisect script fast and isolated (no network, no long builds).- If multiple regressions exist, bisect finds one culprit at a time—repeat as needed.

HardTechnical

85 practiced

You are optimizing a search suggestion service that must return top-10 suggestions within sub-10ms latency. Describe data structures (tries, finite-state transducers), caching, partitioning, indexing, and how to support near-real-time updates to the corpus without breaking availability. Discuss personalization and multi-language concerns.

Sample Answer

Requirements & constraints:- Serve top-10 suggestions <10ms end-to-end; high QPS; near‑real‑time corpus updates; high availability; personalization; multi‑language.

Core data structures:- Compressed Trie / Finite-State Transducer (FST): store dictionary + output payloads (IDs, scores). FSTs are memory‑compact, fast prefix traversal, and support exact prefix match + ranked outputs. Use byte‑packed edges and perfect hashing where possible.- Additional in‑memory forward index: mapping suggestion ID → metadata (score, personalization features, display text).

Scoring & indexing:- Precompute static score (popularity, CTR) in FST payloads. For ranking combine static score + real‑time signals (recency, user score) at query time. Keep top-K candidates per node (e.g., top-50) to reduce merge cost when composing final top-10.

Caching:- L1: hot-query LRU (local per node) in-process for <1ms hits.- L2: shared Redis/Memcached for slightly wider cache (sharded). Cache both final top-10 responses and intermediate candidate lists.- Use cache TTLs tuned to update rate and invalidation on writes.

Partitioning & scaling:- Shard by prefix range (lexicographic) or hash(user_id) for personalization locality. Replicate shards across nodes (N replicas) for HA and read throughput.- Serve queries to a front‑end router that routes to the shard owning the prefix; for short prefixes that span many shards, maintain a small global hot-shard or replicate small popular prefixes to all nodes.

Near‑real‑time updates:- Use a two-tier index: immutable bulk FST built offline (fast, compact) + in‑memory delta layer (writes) implemented as concurrent trie or hashmap of new/updated entries.- On write: append to a write-ahead log, apply to delta layer immediately; asynchronously rebuild bulk FST periodically (minutes) from latest snapshot. Query merges results: traverse bulk FST + delta layer, then dedupe and re-rank. To avoid availability windows, switch new bulk FST atomically (versioned pointers).- For low-latency rebuilds, use incremental FST compaction or LSM-style levels to bound rebuild cost.

Consistency & availability:- Use quorum writes for persistent store; acknowledge quickly after WAL + delta applied to memory. Replicate deltas across replicas; on leader failover, replay WAL.

Personalization:- Keep user profile/features out of FST. At query time fetch candidate set (top-50) and apply lightweight ranking model (logistic/regression or shallow NN) that incorporates user features, context, device, locale. For extreme low latency, cache per-user short-term contexts and use model quantization or ONNX runtime with CPU microseconds latency.- For privacy, use hashed IDs and obey opt-outs.

Multi-language:- Use language-specific FSTs where script/word boundaries differ (CJK vs whitespace languages). Detect query language (fast classifier) and route to appropriate index. For multilingual queries, run on multiple language indexes and merge with language confidence. Normalize text with Unicode NFKC, fold accents as appropriate; keep separate analyzers for stemming/tokenization per language.

Trade-offs:- FST gives memory compactness and speed but is costly to rebuild; delta layer adds complexity but enables near‑real‑time updates.- Larger precomputed per-node top lists increase memory but reduce query-time work.- Personalization at rank-time keeps FST sharable across users.

Operational considerations:- Instrument tail latency, p99, cache hit rates. Use slow‑path tracing to catch expensive merges. Autoscale shards based on QPS and prefix hotness. Run A/B tests for ranking model changes; rollback via atomic pointer swap.

This design balances sub‑10ms reads via in‑memory FST + caches, supports real‑time updates with delta layers and atomic swaps, and enables lightweight per-request personalization and multi‑language support.

Unlock Full Question Bank

Get access to hundreds of Debugging and Code Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.