Focuses on systematically finding, reasoning about, and testing edge and corner cases to ensure the correctness and robustness of algorithms and code. Candidates should demonstrate how they clarify ambiguous requirements, enumerate problematic inputs such as empty or null values, single element and duplicate scenarios, negative and out of range values, off by one and boundary conditions, integer overflow and underflow, and very large inputs and scaling limits. Emphasize test driven thinking by mentally testing examples while coding, writing two to three concrete test cases before or after implementation, and creating unit and integration tests that exercise boundary conditions. Cover advanced test approaches when relevant such as property based testing and fuzz testing, techniques for reproducing and debugging edge case failures, and how optimizations or algorithmic changes preserve correctness. Interviewers look for a structured method to enumerate cases, prioritize based on likelihood and severity, and clearly communicate assumptions and test coverage.
HardSystem Design
69 practiced
Design a scalable automated testing framework that can discover, run, and manage edge-case tests for a distributed message-processing system that consumes millions of messages per day, tolerates out-of-order delivery, and supports at-least-once semantics. Include synthetic load generation, fault injection (broker partitions, message drops, duplicates), deterministic replay for triage, and analytics to surface rare edge cases and flaky tests.
Sample Answer
**Clarify requirements**- Discover, run, manage edge-case tests for distributed message processor- Support synthetic load, fault injection (partitions, drops, duplicates), deterministic replay, analytics for rare/flaky cases- Scale to millions of messages/day, integrate with CI/CD**High-level architecture**- Test Orchestrator (Kubernetes) schedules test scenarios- Scenario DSL + Catalog describing message patterns, invariants, failure points- Load Generator cluster (Kafka/producer clients) producing synthetic and recorded traffic- Fault Injector (chaos mesh + custom probes) to simulate broker partitions, drops, duplicates- Deterministic Recorder/Replay: append immutable event stream with vector clocks + message IDs- Triage Service: isolating failing sequences, creating minimized reproducer- Analytics Pipeline: metrics (Prometheus), traces (Jaeger), logs (ELK), anomaly detector (Spark/Beam + ML)**Components & responsibilities**- Scenario DSL: parameterize timing, ordering, duplication, at-least-once semantics- Load Generator: throttle, partition keys, out-of-order delivery via delayed queues- Fault Injector: inject at network, broker, client level; can target partitions or random sampling- Recorder: capture (message id, payload hash, timestamp, partition, vector clock) to S3/replication log- Replay tool: deterministic replay honoring recorded timestamps and vector clocks- Flakiness detector: cluster runs, statistical significance, isolate nondeterministic tests**Data flow**1. Orchestrator picks scenario → Load Gen produces messages + Recording2. Fault Injector activates per scenario3. Processor outputs validated vs. expected invariants → Triage on failure4. Analytics aggregates rare patterns, surfaces candidate edge cases**Scalability & reliability**- Horizontal scale components; use Kafka topics for test control/recording- Sharding and sampling to limit storage; smart minimization to reproduce failures- Use idempotent instrumentation and backpressure-aware generators**Determinism & triage**- Use message IDs, vector clocks, and deterministic seeds for RNGs- Binary-search fault window + delta-replay to minimize repro traces**Metrics & surfaced insights**- Alert on increased flakiness score, rare invariant violations- Dashboards of failing message patterns, root-cause links to recorded traces**Trade-offs**- Full fidelity replay expensive; use sampling + targeted full-record when anomalies detected- Inject at multiple layers increases coverage but complexity; start with broker+client layersThis design balances scalable synthetic load, precise fault injection, deterministic replay, and analytics to discover and manage rare edge-case and flaky tests in a production-like message-processing environment.
MediumTechnical
94 practiced
Explain fuzz testing and contrast it with property-based testing: when would you apply each? Provide a concrete fuzzing approach for a URL parser (what mutations, corpora, and oracles you'd use), and describe how you'd triage and minimize a crash found by the fuzzer to produce a small reproducible test case for debugging.
Sample Answer
**High-level contrast (when to use each)** I treat fuzzing as a randomized, adversarial technique to discover crashes, memory-safety bugs, and protocol-parsing flaws by throwing many mutated inputs at the system. Property-based testing (PBT) is deterministic, specification-driven: it generates structured inputs to assert invariants or properties (e.g., idempotence, round-trip encoding). Use fuzzing for security/robustness and unknown edge-cases; use PBT when you have clear invariants to verify.**Concrete fuzzing approach for a URL parser (SDET view)**- Corpus: - Seed corpus of valid URLs (http, https, ftp, data:, file:), plus known-bad examples (missing scheme, huge query, long host labels). - Include component-level seeds: paths, queries, percent-encodings, IDNA examples.- Mutations: - Bitflips, byte insert/delete/replace, block duplication, truncation. - Grammar-aware mutations: swap components (put query into host), inject percent-encoding edge-cases, overlong UTF-8, embedded NULs, control chars, Unicode homoglyphs. - Size-based: extremely long host, path, query parameters.- Oracles: - Crash detection (segfault, OOM, ASAN/UBSAN). - Invariant checks: parsed URL when serialized should be stable (round-trip), IDNA normalization rules, scheme-specific constraints. Compare against a reference implementation for divergence (differential testing).**Triage and minimization workflow**1. Reproduce: run fuzzer with same seed/corpus + deterministic RNG to reproduce crash.2. Capture failing input and sanitizer stack trace (ASAN/UBSAN) and program state.3. Minimize: run delta-debugging (e.g., afl-cmin, or custom 1-minimize) to reduce input while preserving crash and sanitizer signature.4. Validate: run minimized case under debugger to get stable backtrace; attach to bug report with steps to reproduce, stack trace, and hypothesis.5. If non-deterministic, record execution trace or instrument harness to increase determinism.This approach balances broad coverage (fuzzing) with targeted correctness checks (PBT) and yields small, actionable reproductions for developers.
MediumTechnical
87 practiced
Design a comprehensive set of test cases to expose off-by-one bugs in both limit/offset and cursor-based pagination. List specific values for total item count, limit, offset/cursor states, and boundary scenarios (zero items, exact multiples of page size, last page smaller than limit, offsets beyond end). Explain test execution order and verification steps to ensure duplicates/omissions are detected.
Sample Answer
**Approach (SDET perspective)**Design tests for both limit/offset and cursor pagination to reliably trigger off-by-one errors by exercising boundaries, empty results, overflows and transitions between pages. Automate as integration tests against API and a direct DB fixture.**Test matrix (explicit values)**- Total items: 0, 1, 5, 10, 11, 20, 21, 50- Page limits: 1, 2, 5, 10- Offsets: 0, 1, limit-1, limit, total-limit, total-1, total, total+1- Cursor states: start (null), after item IDs: first-id, id at positions limit-1, limit, total-limit, last-id, invalid/expired cursor- Special sizes: exact multiple (total=10, limit=5), last smaller (total=11, limit=5)**Concrete cases (examples)**- total=0, limit=5, offset=0 → expect empty, no next cursor/next flag- total=1, limit=1, offsets 0 and 1 → page1 returns item, offset=1 returns empty- total=11, limit=5: offsets 0,5,10 → pages sizes [5,5,1]; verify no overlap/missing- limit=5, offset=4 → ensure page returns items 5..9 (off-by-one risks)- cursor test: iterate with cursor returned; for total=21, limit=10 expect pages [10,10,1]; invalid cursor → 400/404**Execution order**1. Seed DB deterministically (id and timestamp ordered).2. Run simple sanity: total counts for each seed.3. Sequential pagination sweep: start→repeat fetch next page until no-next; record all ids returned.4. Random-access offset checks: call specific offsets from matrix.5. Cursor-specific jumps: use cursor returned at boundary positions, also test replay/expired cursors.6. Negative/invalid inputs.**Verification steps**- Collect IDs from pages in order; assert concatenation length == total and set equality (no duplicates, no omissions).- Assert ordering matches expected sort (e.g., by id asc).- For limit/offset: validate returned range corresponds to SQL LIMIT/OFFSET semantics: items [offset, offset+limit-1].- For cursor: ensure cursor points to next (last returned id) and repeated fetch from same cursor does not skip or duplicate.- For offsets beyond end: expect empty result and no next.- For invalid cursors: assert appropriate error and no data.**Automation notes / assertions**- Use parametrized test harness (pytest/junit) to iterate matrix.- Capture response metadata: total_count, next_cursor, has_more.- Log failures with seed snapshot and exact API call parameters for reproducibility.
HardTechnical
81 practiced
You have limited CI time but want to maximize edge-case detection. Propose a prioritization strategy to select which edge-case tests run on every PR, which run nightly, and which run pre-release. Include metrics to score tests (risk, historical failure, runtime), ways to implement test selection (change-based selection, test impact analysis), and how to measure effectiveness of the strategy.
Sample Answer
**Overview — goal**Prioritize tests so short, high-risk edge-case checks run on every PR; heavier, lower-probability scenarios run nightly; full exhaustive suites run pre-release. Balance risk detection against CI time.**Scoring metrics (per test)**- Risk score (0–10): impact if defect reaches production (security, data loss higher).- Historical failure rate: failures per 100 builds (higher weight).- Runtime (seconds): cost to run.- Flakiness penalty: recent nondeterministic failures reduce confidence.Composite priority = (Risk * 0.5) + (HistFailure * 0.3) + (RegressionRecency * 0.1) - (RuntimeNormalized * 0.1) - (Flakiness * 0.2).**Selection tiers & policy**- On-PR (fast, high priority): top X% by composite score + tests touching changed files (change-based).- Nightly: next tier including longer integration and stateful edge-case tests; include mutation-based or chaos scenarios.- Pre-release: full suite, long-running simulations, canary pipelines.**Implementation approaches**- Change-based selection: map tests to files/services; run tests with touched components.- Test impact analysis: instrument code coverage during test runs to know which tests cover changed code.- Hybrid: always run high-priority smoke tests; for others, combine change-based + score threshold.- Tooling: lightweight test registry (metadata), CI orchestration that accepts test lists, automated coverage collector.**Measuring effectiveness**- KPI dashboard: mean-time-to-detect, escaped defects per release, test-suite ROI (CI minutes per defect found), false-negative rate (bugs found in prod that tests would have caught).- A/B evaluate selection vs. full-run on sample branches for a week to measure detection delta.- Track trends: increase in escaped defects or rising MTTR triggers lowering thresholds.**Leadership actions**- Align thresholds with product owners, set review cadences, and invest in flaky-test reduction and coverage mapping to improve selection accuracy.
MediumTechnical
91 practiced
Implement a Python function is_palindrome(s: str) and, before coding, list at least ten edge cases that must be tested (include empty string, single character, punctuation, unicode combining characters, case folding, whitespace, extremely long strings, surrogate pairs, non-BMP characters, and normalization forms). Then write pytest cases for three of those edge cases showing expected behavior.
Sample Answer
**Approach (brief)** Normalize Unicode (NFKC), remove combining marks, casefold for Unicode-aware case folding, strip out non-alphanumeric characters (ignore punctuation/whitespace), then check if cleaned string equals its reverse.**Edge cases to test (>=10)**- Empty string- Single character- Only punctuation/whitespace- Mixed case (case folding) — e.g., "RaceCar"- Unicode combining characters (e.g., "A\u030A" vs "Å")- Different normalization forms (NFC vs NFD)- Surrogate pairs / non-BMP characters (emoji, historic scripts)- Extremely long strings (performance/ memory)- Strings with only combining marks- Non-letter characters (numbers, symbols) — e.g., "12321"- Mixed-direction text (RTL + LTR)- Strings with zero-width joiners/space**Implementation**
python
import unicodedata
def is_palindrome(s: str) -> bool:
# Normalize and casefold
n = unicodedata.normalize("NFKC", s).casefold()
# Remove combining marks and keep letters/digits
cleaned_chars = []
for ch in n:
# skip combining marks
if unicodedata.category(ch).startswith("M"):
continue
cat = unicodedata.category(ch)
# keep letters (L*) and numbers (N*)
if cat.startswith("L") or cat.startswith("N"):
cleaned_chars.append(ch)
cleaned = "".join(cleaned_chars)
return cleaned == cleaned[::-1]
**Complexity**- Time: O(n) to normalize/scan + O(n) for reverse → O(n)- Space: O(n) for the cleaned buffer**Pytest examples (three edge cases)**
python
import pytest
def test_empty_string():
assert is_palindrome("") is True
def test_unicode_combining_equivalence():
# decomposed A + ring vs composed Å — single char palindrome
decomposed = "A\u030A"
assert is_palindrome(decomposed) is True
composed = "\u00C5" # Å
assert is_palindrome(composed) is True
# combined into a 3-char palindrome: Å b Å (decomposed)
assert is_palindrome("\u00C5b\u00C5") is True
assert is_palindrome("A\u030AbA\u030A") is True
def test_long_string_performance():
s = "a" * 10000
assert is_palindrome(s) is True
Unlock Full Question Bank
Get access to hundreds of Edge Case Identification and Testing interview questions and detailed answers.
