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.

MediumTechnical

36 practiced

As a senior SDET mentoring a junior teammate who struggles to debug intermittent race conditions in tests that only fail on CI, describe a coaching plan. Outline debugging steps to teach, exercises or small projects to build intuition, mental models for concurrency, and practical tooling to use during pairing sessions.

Sample Answer

**Coaching plan (high level)** I’d run a 4-week plan with pairing + incremental autonomy: week 1 pair on fundamentals and one failing CI job; week 2 pair-debug a reproducible mini-case; week 3 solo ownership with daily check-ins; week 4 retro and doc the patterns. Goal: move from “mystery flake” to repeatable root cause investigations.

**Step-by-step debugging checklist to teach** - Reproduce: run same CI image, env vars, container, test shard. - Binary search: narrow to smallest failing test/commit. - Instrument: add structured logs, timestamps, thread IDs, and deterministic seeds. - Isolate: run single-threaded, disable parallelism, or mock external systems. - Detect: run with race detectors / sanitizers appropriate to stack (ThreadSanitizer, Go race, Java -Djava.security.manager off for tests). - Control scheduler: use deterministic schedulers or stress tools, run many iterations. - Root cause: verify happens-before, shared mutable state, time-of-check/time-of-use. - Fix + verify: add proper sync, retries, idempotence; re-run under sanitizer and CI.

**Exercises & small projects** - Build a tiny producer/consumer service that occasionally fails; add a race then fix with locks/atomics. - Create a flaky test repo: one test that fails under parallel runs; have the mentee diagnose with logs and sanitizers. - Implement a deterministic test harness that injects delays and schedules.

**Mental models for concurrency** - Happens-before ordering vs. real-time order. - Atomicity, visibility, and ordering (reads/writes, memory barriers). - Time-of-check/time-of-use and shared mutable state as common anti-patterns. - Fail-fast vs. eventual consistency trade-offs.

**Tooling for pairing sessions** - Local CI replica (same Docker image, env). - Structured logging (correlation IDs, thread IDs). - Race/sanitizers: ThreadSanitizer, Go race detector, Java concurrency stress tools (JCStress). - Debuggers/record-replay: rr for deterministic replay, gdb/lldb for native, IDE thread views. - Test runners with stress options (–count, –repeat); flaky-test dashboards and CI artifact links. - Lightweight chaos: tunable latency injectors, mocked network faults.

I’d pair through one real flaky CI job end-to-end, coach the mental models while using the tools above, then assign a small replication exercise to build independence.

EasyTechnical

39 practiced

Explain integer overflow: why it happens, differences between languages (for example C/Java vs Python), common bugs caused by overflow in real systems, and three practical testing techniques an SDET can use to detect overflow-related bugs across system boundaries (including serialization and DB storage).

Sample Answer

**Brief definition & why it happens**Integer overflow occurs when a computed value exceeds the representable range of a fixed-size integer type so bits wrap or saturate. It happens because hardware/types allocate N bits; arithmetic ignores "mathematical" infinity and either wraps (modular) or triggers undefined/checked behavior.

**Languages differences**- C/C++ (signed): overflow is undefined — can silently wrap or be optimized away. Unsigned integers wrap modulo 2^N.- Java: signed integer overflow wraps modulo 2^N (defined behavior).- Python: integers are arbitrary-precision — no overflow for normal ints (they grow), though fixed-size C extensions or serialization can reintroduce limits.

**Real-system bugs**- Security: buffer sizes computed with overflow lead to under-allocation and remote code execution.- Financial: summing transactions overflows and yields incorrect balances.- Distributed systems: sequence number wrap causes stale/duplicate message processing.Example: allocating malloc(size) where size = count * element_size overflows to small value → heap overflow.

**Three practical SDET testing techniques**1. Boundary fuzzing across system boundaries - Generate values at, just below, and above type limits (e.g., 2^31-1, 2^31, 2^31+1) and feed through APIs, serialization (JSON/Binary), and DB writes. - Automate using property-based tests or fuzzers to cover combinations (counts, sizes, indices).

2. Cross-layer contract tests with explicit type constraints - Create tests that serialize large integers, store/retrieve from DB columns (INT, BIGINT), and assert round-trip equality and error handling. - Include schema-mismatch scenarios (app sends 64-bit to 32-bit column) and verify graceful failures/logs.

3. Mutation and fault-injection tests for arithmetic paths - Inject extreme inputs into business logic (transaction sums, counters), mock lower-level libraries to force wrapping, and assert invariants (non-negative balances, monotonic counters). - Use static analysis/taint tools to find arithmetic-to-memory sinks and write focused tests.

**What I’d automate**- A CI job that runs boundary-fuzz suites, cross-layer contract checks (serialization ↔ DB), and reports regressions with reproducible seeds and failing payloads.

HardTechnical

41 practiced

Design an automated process that detects and quarantines flaky tests in a large test suite. Specify detection heuristics (frequent intermittent failures, non-deterministic patterns), automatic re-run policy, quarantine criteria, notification strategy, and actions (bisect commits, mark tests flaky). Explain an algorithm to bisect and find the offending commit when flakiness starts appearing and how to surface reproducible cases to developers.

Sample Answer

**Approach (high level)** As an SDET I'd build a CI-side Flakiness Detector service that observes test results, applies heuristics, triggers automatic reruns, and quarantines tests while surfacing reproducible cases and doing bisection when relevant.

**Detection heuristics**- Track per-test history (last N runs): failure rate, streaks, time-of-day, platform matrix.- Flag candidates when: failure rate in window > 5% and failures are non-deterministic (passes and fails interleaved), or >3 single-run intermittent failures across different commits/builds.- Weight by environment churn (new infra/config) to avoid false positives.

**Automatic re-run policy**- On first failure: run immediate N reruns (e.g., 3) on same commit/worker; if any pass, mark as “intermittent” for that build.- If failures persist across K builds (e.g., 3) and reruns, promote to quarantine.

**Quarantine criteria & actions**- Quarantine when: intermittent pattern + reproducible on reruns OR failure across multiple CI agents/environments.- Quarantined tests are skipped in presubmit by default but run in a dedicated flaky-suite nightly.- Mark tests in test metadata (flaky=true) and annotate blame info.

**Notification strategy**- Create an issue/alert automatically with: failure logs, stack traces, failing commit(s), agent/environment metadata, recent pass/fail timeline, links to artifact and test run.- Directly notify owning team via configured owners file + Slack/email with priority and remediation steps.- Provide dashboard with trending flaky tests and SLA.

**Bisect algorithm to find offending commit**1. Confirm flakiness started at commit range [good, bad] using build history (last known good commit where test passed deterministically).2. Use binary search across commits: pick midpoint commit C, run deterministic runs (repeat M times on isolated stable worker). If test fails deterministically on C -> move bad= C; else good = C.3. Continue until range small (1–2 commits). If nondeterministic, require multiple repeat runs per commit to reach confidence (use statistical threshold, e.g., p-value or require >80% failure across 10 runs).4. If bisection hits merge commits or large changes, instrument with git bisect or per-file blame to narrow potential authors.

**Surfacing reproducible cases**- Capture minimal failing artifacts: exact test binary, environment snapshot (container image, OS, deps), seed/random-state, input data, logs, heap/dump if applicable.- Provide a reproducible job link and a “reproducer” script that can be run locally (docker-compose or hermetic container) to reproduce with same seed/env.- Attach deterministic failure traces and explain steps to reproduce in the auto-created issue.

**Practical notes & trade-offs**- Balance false positives by tuning thresholds and requiring cross-agent confirmation.- Keep quarantine reversible: auto-unquarantine if test passes consistently for M builds or after fix PR with CI validation.- Store telemetry for ML later to improve heuristics.

This design minimizes CI noise, accelerates root cause discovery, and gives developers deterministic repro artifacts to fix flaky tests efficiently.

EasyTechnical

43 practiced

A backend intermittently returns HTTP 500 when uploading a 30MB JSON payload, but only occasionally. As an SDET, list methodical debugging steps to reproduce and isolate the cause. Include instrumentation you'd add (profiling, thread dumps, GC logs), synthetic test designs for size and concurrency variations, and checks for buffering/streaming, proxy limits, and serialization failures.

EasyTechnical

33 practiced

A bug report says the React web app 'form submit fails silently when all fields are left blank'. As an SDET, outline a step-by-step approach to reproduce, isolate the root cause, create automated regression tests, and propose a fix. Include specific environments/tools you'd use to gather evidence (browser devtools, network traces, server logs, automated headless browsers) and how you'd validate the fix across browser types and mobile.

Sample Answer

**Step-by-step approach (SDET perspective)**

**1) Reproduce**- Environment: Chrome 118, Firefox 119, Safari 17 on macOS; Windows Chrome; Android Chrome, iOS Safari. Use staging branch + latest backend.- Steps: open form, leave all fields blank, click Submit. Record screen and devtools console, Network tab, and server logs.- Tools: Chrome DevTools (Console, Network), HAR export, Wireshark if needed, Sentry/ELK for server errors, BrowserStack for device coverage, OBS for video evidence.

**2) Isolate root cause**- Check client-side validation: inspect event handlers, React state, HTML5 validation attributes.- Reproduce with React devtools to see state changes on submit.- Verify network activity: is a request sent? If no request, bug likely client-side; if request returns 4xx/5xx, inspect payload and server logs.- Run unit tests on form validation logic (Jest + React Testing Library) to find failing assertions.

**3) Create automated regression tests**- Unit: Jest + React Testing Library test that submitting empty fields triggers validation messages and prevents network calls (mock fetch/axios).- E2E: Playwright tests (headful + headless) that cover desktop browsers and mobile emulation. Example checks: - Assert validation UI appears - Assert no outbound request or correct server error handling- Integrate into CI (GitHub Actions) to run matrix across browsers.

**4) Propose fix**- If client-side: add/restore validation (form.onSubmit should preventDefault, validate state, show errors).- If server-side: return proper 4xx with JSON error and ensure client shows error.- Code example: ensure submit handler returns on failed validation.

**5) Validate fix**- Run unit and E2E suites locally and in CI across Chrome/Firefox/Safari and mobile via BrowserStack or Playwright mobile emulation.- Verify logs, HAR, and video evidence; close bug with links to green test runs and artifacts.

**Key deliverables:** reproduction steps, logs/HAR/video, failing tests, PR with fix, automated tests added, CI green badge.

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.