Edge Case Handling and Debugging Questions

Covers the systematic identification, analysis, and mitigation of edge cases and failures across code and user flows. Topics include methodically enumerating boundary conditions and unusual inputs such as empty inputs, single elements, large inputs, duplicates, negative numbers, integer overflow, circular structures, and null values; writing defensive code with input validation, null checks, and guard clauses; designing and handling error states including network timeouts, permission denials, and form validation failures; creating clear actionable error messages and informative empty states for users; methodical debugging techniques to trace logic errors, reproduce failing cases, and fix root causes; and testing strategies to validate robustness before submission. Also includes communicating edge case reasoning to interviewers and demonstrating a structured troubleshooting process.

HardTechnical

57 practiced

Explain how integer arithmetic semantics in JavaScript differ from languages with fixed-width integers and how this affects edge-case handling for crypto, hashing, and binary protocol code in Node.js. Provide defensive strategies (e.g., BigInt, Buffer arithmetic) to avoid precision and overflow bugs.

Sample Answer

JavaScript uses IEEE-754 double-precision floats for Number. That means integer values are exactly represented only up to 2^53-1 (Number.MAX_SAFE_INTEGER). Languages with fixed‑width integers (e.g., 32/64-bit signed/unsigned) use two’s complement and wrap on overflow — deterministic bit patterns and semantics critical for crypto, hashing, binary protocols.

Consequences for crypto/hashing/binary protocols:- Values >= 2^53 lose integer precision, corrupting counters, nonces, offsets, or large integers.- Bitwise operators in JS coerce operands to 32‑bit signed integers, so they implicitly truncate and sign‑extend — unexpected for 64‑bit protocols.- No automatic modular wrap like uint32/uint64: arithmetic on Number doesn’t model two’s‑complement overflow behavior.- Subtle bugs: incorrect endianness conversions, broken hashes, or signature verification failures.

Defensive strategies1) Use BigInt for integer correctness (arbitrary integer precision, predictable two’s‑complement-like operations when you implement masking).Example: 64‑bit arithmetic and modular masking

javascript

// 64-bit unsigned add modulo 2^64
function add64(a, b) {
  const MASK64 = (1n << 64n) - 1n;
  return (BigInt(a) + BigInt(b)) & MASK64;
}

2) Use Buffer/TypedArray + manual carry for low-level binary math (explicit byte operations avoid float rounding):

javascript

// add two 64-bit little-endian buffers into out
function add64LE(aBuf, bBuf) {
  const out = Buffer.alloc(8);
  let carry = 0;
  for (let i = 0; i < 8; i++) {
    const s = aBuf[i] + bBuf[i] + carry;
    out[i] = s & 0xff;
    carry = s >>> 8;
  }
  return out;
}

3) Use BigInt or specialized libs for crypto math: bn.js, big-integer, long (for 64-bit), or libs that implement constant-time ops.4) Avoid Number for counters, offsets, or protocol integers >= 2^31; validate ranges (throw if > MAX_SAFE_INTEGER).5) For hashing/signature primitives use vetted libraries (crypto, libsodium) — let native code handle bit-precise operations.6) When interoperating with fixed-width types, explicitly mask and document endianness and signedness. Prefer DataView for reading/writing integers:

javascript

const dv = new DataView(buf.buffer, buf.byteOffset);
dv.setBigUint64(0, 123n, true); // little-endian

7) Testing and fuzzing: unit tests for boundary values (2^53-1, 2^32-1, carry boundaries), and property tests to match reference implementations.

Summary: Treat Number as a floating‑point convenience, not a substitute for fixed-width integer semantics. Use BigInt, explicit Buffer/TypedArray arithmetic, and trusted native crypto libraries to avoid precision and overflow bugs.

EasyTechnical

58 practiced

You see a failing unit test that asserts foo([]) returns 0, but production logs show a NullPointerException originating from the same function. List 8 plausible root causes (environment, test setup, concurrency, data differences, etc.) and outline the first 5 concrete commands or steps you would take to trace the failure down to the code line.

MediumSystem Design

42 practiced

Design a validation and test harness for CSV uploads in a data pipeline. Requirements: handle malformed rows, missing columns, huge files without OOM, Unicode/encoding issues, duplicate rows, and provide granular error reports to users (including line numbers and sample data). Describe components, storage, streaming approach, retries, and failure handling.

Sample Answer

Requirements (clarify): validate CSV uploads for correctness and schema, handle malformed rows/missing columns, huge files without OOM, Unicode/encoding issues, duplicate rows, produce granular error reports (line numbers, sample data), support retries and robust failure handling.

High-level architecture:- Frontend upload service (presigned URL) → Object storage (S3) → Validation/Test Harness Service → Metadata DB & Report store → Notification / UI.

Components:1. Ingest: accept file, store raw file in S3, create job record (id, schema, options).2. Stream validator workers: use a streaming parser (e.g., Python's csv with incremental IO, Java OpenCSV streaming, or Apache Commons CSV) that reads S3 object via range/streaming API to avoid OOM. Process file in chunks/row-by-row.3. Schema & rules engine: validates column presence, types, custom rules; normalizes encodings (detect BOM, try UTF-8, fallback to Latin-1) and emits unicode errors per row.4. Duplicate detection: maintain a configurable rolling hash (e.g., XXHash) per row and a probabilistic dedupe store (Bloom filter + backing store like Redis for session or DynamoDB for exact checks) to flag duplicates without storing entire file.5. Error collector: accumulate per-row errors with line number, offending sample, error code, and severity. Store errors paginated in a report store (S3 JSONL or a DB). Cap stored samples per job; summarize counts/first N examples.6. Checkpointing & retries: process in idempotent chunks (by byte-offset or row-range). On failure, retry chunk; maintain job state in metadata DB so workers can resume. Use at-least-once processing + idempotency keys to avoid double-reporting.7. Backpressure & scaling: place jobs on a queue (Kafka/SQS). Autoscale workers based on queue depth and file size. For very large files, split by byte ranges and validate in parallel (but ensure row-boundary alignment).8. Failure handling & user feedback: categorize failures (fatal e.g., header missing -> reject; recoverable e.g., row parse error -> skip and report). Provide immediate lightweight test-run that validates headers and encoding before full run. Expose progress, error summary, and downloadable detailed report with line numbers and sample rows.

Data flow:- User uploads -> S3 -> create job -> header/encoding quick-check -> enqueue job -> streaming workers read ranges -> validate rows -> write per-chunk summaries and errors to report store -> update job state -> final consolidated report.

Trade-offs:- Bloom filters reduce memory but may false-positive duplicates; use exact store for critical dedupe.- Parallel range reads increase throughput but require careful row-boundary handling.- Persisting every error row can grow large; store detailed samples only for first N and aggregate counts.

Operational notes:- Monitor encoding failure rates, error counts, worker latency. Provide SLA for report availability. Add schema preview and dry-run mode for users.

This design ensures linear memory usage, resumability, precise error reporting with line numbers/sample data, duplicate handling, and scalable processing.

EasyTechnical

39 practiced

List ten common causes of flaky (intermittent) tests in unit and integration suites (examples: timing, randomness, shared global state, external services, resource leaks). For each cause, suggest a concrete mitigation that can be applied in a CI pipeline to reduce flakiness.

Sample Answer

1) Timing / race conditions — Mitigation: Add deterministic waits and explicit synchronization (e.g., await/Promise, condition variables). In CI enforce using timeout-safe test helpers and fail-fast on timing anomalies; run with increased logging and repeat flaky tests with longer timeouts.

2) Randomness (non-deterministic seeds) — Mitigation: Seed RNGs from a fixed value in CI and log the seed on failure so tests can be reproduced.

3) Shared global state / singletons — Mitigation: Isolate tests by resetting globals between tests or run tests in separate processes/containers in CI (parallel shards each get fresh process).

4) Order dependency — Mitigation: Randomize test order locally but enforce CI runs that shuffle order every run; detect order-dependent failures and require isolation fixes.

5) External services / network instability — Mitigation: Use service virtualization or stable test doubles (mock servers) in CI; for integration tests, run against local test instances in controlled networks and retry transient network calls with capped backoff.

6) Resource leaks (file descriptors, threads) — Mitigation: Run tests under resource monitors in CI, enforce limits, and leak-detection tooling; fail builds if counts grow across tests.

7) Time-sensitive tests (clock/date) — Mitigation: Use clock abstraction and freeze time in tests; CI sets consistent timezone and NTP-synced environment.

8) Flaky dependencies (third-party libs changing) — Mitigation: Pin dependency versions in CI, use lockfiles and reproducible builds; run dependency update jobs separately with extra validation.

9) Environment differences (OS, locale, permissions) — Mitigation: Use containerized, hermetic CI images that mirror production; run matrix builds for supported environments and fail when deviations occur.

10) Parallelism / shared resource contention — Mitigation: Limit parallelism for tests touching shared resources, use unique temp dirs/ports per test or orchestrate resource provisioning in CI (ephemeral DBs, namespaces).

Apply: add automated flakiness detection (re-run failures automatically), collect failure metadata (logs, seeds, traces), and make fixing flakiness part of CI gating before merges.

HardTechnical

40 practiced

A distributed batch job occasionally produces inconsistent floating-point aggregates (different runs yield slightly different sums). Propose deterministic aggregation techniques, numerical stability improvements (e.g., Kahan summation), and testing strategies to detect and prevent these inconsistencies in batch and streaming contexts.

Sample Answer

Situation: In distributed batch/streaming systems, non-deterministic task ordering and floating-point rounding produce slightly different aggregates across runs. The goal is deterministic, numerically stable aggregates and tests to detect/prevent regressions.

Deterministic aggregation techniques- Make reduce order deterministic: partition keys and sort records within partitions (or use stable hash + deterministic task assignment) so order of summation is reproducible.- Use deterministic tree-reduction: combine partial results in a fixed binary-tree order (e.g., by partition id, then index) rather than reducing in arbitrary arrival order.- Use associativity-preserving transforms: transform values into a commutative/associative representation (see compensated sums below) so merge order doesn't change result.- Use exact integer/fixed-point or arbitrary-precision (BigInteger/BigDecimal) when possible for monetary or critical sums; deterministic across runs.

Numerical-stability improvements- Kahan (compensated) summation for single-stream improvements:

python

def kahan_sum(nums):
    s = 0.0
    c = 0.0
    for x in nums:
        y = x - c
        t = s + y
        c = (t - s) - y
        s = t
    return s

- Pairwise (divide-and-conquer) summation: recursively split list and sum halves — reduces error and parallelizes cleanly.- Use multi-word accumulators (Kulisch accumulator) or 128-bit/long double if available for much higher exactness.- Use compensated mergeable structures: keep (sum, compensation) per partition and merge them with a deterministic algorithm (add compensations carefully).- For streaming, use mergeable compensated-sum objects so checkpoints and restores maintain deterministic state.

Testing and detection strategies- Unit tests: compare naive sum vs compensated vs high-precision reference (BigDecimal / mpfr) on pathological inputs (large dynamic range, alternating signs, many tiny values).- Property-based tests (Hypothesis): generate random arrays with controlled exponent ranges; assert difference to high-precision <= tolerance.- Determinism regression tests: run same job N times in CI (or with shuffles) and assert identical serialized aggregates. If exact equality impossible, assert within deterministic epsilon.- Differential testing: compare batch vs streaming results and vs reference high-precision implementation.- Fuzzing: randomize partitioning/task ordering in test harness to detect order-dependence.- Long-running golden tests: store golden outputs and fail CI if aggregates drift beyond threshold.- Explainability checks: log partial aggregates from partitions and verify merge order and intermediate values.

Practical considerations & trade-offs- Exact/deterministic (BigDecimal/Kulisch) costs CPU/memory — use only where required (money, billing).- Compensated/pairwise gives good accuracy at low cost and parallelizable; still floating-point but more stable.- Choose tolerances meaningfully: absolute vs relative tolerances; use ULP-based assertions where appropriate.- For streaming, ensure checkpoint/restore serializes accumulator state deterministically.

Result / recommendation- For most distributed sums: use deterministic partitioning + pairwise or mergeable Kahan per partition, merge in fixed tree order, and add CI tests that compare to a high-precision reference and re-run determinism tests under randomized task ordering. For financial/exact domains, use fixed-point or arbitrary-precision accumulators despite higher cost.

Unlock Full Question Bank

Get access to hundreds of Edge Case Handling and Debugging interview questions and detailed answers.

Join thousands of developers preparing for their dream job.