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

43 practiced

You are building automated end-to-end tests for a report that includes user-entered free-text filters. Name security and edge-case checks you must include (e.g., SQL injection, extremely long strings, special characters) and describe how to simulate them in tests safely.

Sample Answer

Situation: When building E2E tests for reports that accept free-text filters, you must validate both security and robustness so reports remain correct and safe in production.

Checks to include (security + edge cases)- SQL injection patterns: "' OR 1=1; --", "UNION SELECT ...", boolean / tautology payloads.- XSS and HTML injection: "<script>alert(1)</script>", "<img src=x onerror=...>" — ensure UI escapes/sanitizes.- Extremely long strings: multi-KB/MB input to catch truncation, UI breakage, DB/storage limits.- Unicode / multi-byte / RTL: emojis, CJK, combining characters, bidirectional override (U+202E).- Control / non-printable chars: null (\0), newlines, tabs, carriage returns.- Special SQL/wildcard chars: %, _, backslash, quotes, semicolons.- CSV / Excel injection: leading = + - @ to prevent formula execution when exporting.- Regex / ReDoS payloads: pathological patterns if filters are passed to regex engines.- Edge numeric and date formats: invalid date strings, large numeric values, negative/zero where positive expected.- Concurrent / rate limits: repeated rapid submissions to catch throttling/DoS.- Permission checks: filter values that should hide sensitive rows — ensure RBAC enforced.- Error-handling: inputs that would cause internal server errors — assert graceful failure (400/422, not 500).

How to simulate safely in automated tests- Use isolated test environment: run against a staging DB snapshot or read-only replica; never run destructive payloads on production.- Use synthetic data and test users: create confined test accounts and datasets that contain no PII.- Transaction rollback or ephemeral DB: wrap test operations in transactions and roll back, or use ephemeral containers/fixtures.- Parameterize payloads: maintain a curated list of payloads (escaped) and drive tests programmatically.- Verify behavior, not exploit: tests should assert that inputs are treated as data (e.g., query executed returns expected filtered rows), UI displays escaped text, HTTP status codes are correct, and no stack traces appear.- Monitor logs and metrics: assert no SQL errors, no unhandled exceptions, and no slow queries triggered by malicious payloads.- Use safe payload markers: include identifiable but harmless tokens like "TEST_INJECTION_1" combined with injection patterns so logs/alerts are traceable.- Limit resource impact: for long-string or ReDoS tests, set timeouts and size caps in test runner to avoid destabilizing staging.- Automate export checks: generate CSV/XLSX and assert leading-chars are escaped or prefixed (e.g., prepend a single quote) rather than executed by spreadsheet apps.- Include remediation assertions: for SQL/XSS, assert that prepared statements / parameterized queries are used (indirectly via absence of effect), or that output is HTML-escaped in DOM.

Example test flow (UI automation)- Fill filter input with payload "' OR 1=1; -- TEST_INJECTION_1"- Submit and assert: only expected rows for the test user return (no full-table leak), HTTP 200, and no DB errors in logs.- Fill with "<script>TEST_XSS</script>" and assert DOM shows escaped text (textContent contains token; innerHTML does not contain executable script).- Export report after entering "=cmd|' /C calc'!A0" and assert exported cell value is quoted/escaped.

Why these matter- BI reports often summarize sensitive data; injection or malformed inputs can expose data, crash services, or execute unwanted code when exported. Automated tests that simulate these cases in controlled environments prevent regressions and give stakeholders confidence.

Outcome metrics to track- Number of failed cases prevented, security findings fixed, test coverage of payload types, and staging stability (no test-induced incidents).

This approach ensures tests validate both functional correctness and safety without risking production systems.

MediumTechnical

35 practiced

Design a robust approach for handling late-arriving transactions and duplicate events in a nightly ETL that builds a daily metrics table used by dashboards. Include detection, deduplication, reprocessing windows, idempotent writes, and how dashboards should expose data freshness to end-users.

Sample Answer

Requirements & goals:- Ensure daily metrics reflect accurate, non-duplicated transactions despite late-arriving data.- Minimize dashboard downtime, make freshness and uncertainty visible to users.

Design overview:1. Ingestion & detection- Capture each transaction with a globally unique business key (order_id, txn_id) + source_event_id + event_timestamp and ingestion_time.- Persist raw events in a landing/raw table (append-only) for audit and replay.- Add a “source_hash” (hash of key+payload) to detect identical payload replays.

2. Deduplication- At transform time, dedupe using (business_key, source_event_id, source_hash) choosing deterministic precedence by event_timestamp then ingestion_time.- Maintain a transactional “master_keys” table with last_seen_event_timestamp and last_seen_hash to allow fast existence checks and prevent duplicates.

3. Reprocessing & late-arriving windows- Define two windows: - Near-late window (e.g., 48–72 hours): nightly ETL marks affected days as “dirty” and reprocesses those partitions incrementally. - Long-tail corrections (e.g., 30 days SLA): schedule backfill jobs for rarer late events; keep raw data to support arbitrary replays.- Use partitioned tables by event_date; ETL builds daily metrics into date-partitioned metrics table and, when reprocessing, overwrite partitions atomically.

4. Idempotent writes & atomicity- Write metrics with upsert semantics keyed by (metric_date, dimension_keys). Use transactions or atomic partition swap: - Compute metrics to a staging partition, validate, then swap/replace the target partition to ensure idempotence and prevent partial updates.- Maintain a change_log table recording partition version, job_id, processed_time for audit and rollback.

5. Monitoring & validation- Row counts, distinct key counts, and hashes compared between raw and transformed data per day. Alert on large deltas.- Keep lineage metadata so you can trace metric back to raw events.

6. Dashboard UX for freshness & confidence- Expose a “data as-of” timestamp and processing status per dashboard and per key metric (e.g., “fresh as of 2025-12-05 03:00 UTC; finality expected after 2025-12-07 03:00 UTC”).- Show a freshness banner and a confidence indicator (e.g., preliminary vs final) or highlight recent dates still within the reprocessing window.- Allow users to filter by “finalized” vs “preliminary” data for reports.

Operational notes / trade-offs:- Keeping raw data longer increases storage but enables replays and audits.- Shorter windows reduce reprocessing cost but may surface more “preliminary” data to users.- Prioritize deterministic keys and idempotent writes—these simplify recovery and make dashboards reliable.

This approach balances accuracy, auditability, and UX by combining robust dedupe, controlled reprocessing windows, idempotent partition updates, and transparent freshness indicators for end users.

MediumTechnical

36 practiced

Provide three concrete examples of informative empty states for dashboards where a KPI returns no data (e.g., conversion rate undefined, no transactions in period). For each example include: suggested messaging, visual cues or placeholders, troubleshooting steps for users, and backend metrics to collect to detect the empty state.

Sample Answer

Example 1 — Conversion rate undefined (no visits or no events)- Suggested messaging: "Conversion rate unavailable — no qualifying visits or conversion events in the selected period."- Visual cues/placeholders: Gray KPI card with a dashed border, an icon of an empty graph + short tooltip "No data". Show an example formula: "Conversions / Visits" with both values blank or zero-highlighted.- Troubleshooting steps for users: 1. Verify date range and filters (segment, channel). 2. Confirm event tracking is enabled for conversions (link to tracking docs). 3. Try expanding to a longer timeframe or removing segment filters. 4. Contact analytics/engineering with an event ID and sample session.- Backend metrics to collect: - Raw counts: total visits, conversion events, unique users per period. - Tracking health: event ingestion rate, error/drop rates, event schema mismatches. - Recent deploys/changes to analytics tags and their timestamps.

Example 2 — No transactions in period (revenue/transactions KPI empty)- Suggested messaging: "No transactions recorded for this timeframe. Revenue metrics require at least one transaction."- Visual cues/placeholders: Large illustration of an empty storefront, CTA button "Check transaction log"; show expected monthly baseline (dashed faint line) to set expectation.- Troubleshooting steps: 1. Confirm payment gateway and order pipeline status (link to system status). 2. Check transaction data source selection (prod vs. sandbox). 3. Validate ETL/daily import succeeded; inspect most recent load timestamp. 4. Export raw orders for the period to verify.- Backend metrics to collect: - Transaction ingestion count, ETL job success/failure timestamps, queue/backfill backlog. - Payment gateway success/failure rates, rejected orders count. - Last successful update time for orders table.

Example 3 — Funnel step empty (e.g., no users reached step N)- Suggested messaging: "No users reached this step. Either this step wasn't triggered or filters exclude events."- Visual cues/placeholders: Funnel diagram with the step faded out and tooltip "0 users"; include sample events expected at this step.- Troubleshooting steps: 1. Validate instrumentation for the funnel event (event name, properties). 2. Temporarily remove filters/segments to see if any users appear. 3. Check recent releases that modified the flow or A/B experiments. 4. Run a live debug session or use a replay/logs to confirm event firing.- Backend metrics to collect: - Event counts per step, event latency, schema drift alerts. - Percentage of users entering funnel vs. expected baseline. - Feature-flag/A-B experiment toggles correlated with step failures.

Across all examples, include a small link on the empty-state card to "Report an issue" that auto-populates context (dashboard id, timeframe, applied filters) to streamline triage.

HardTechnical

44 practiced

You must onboard 10 new data sources into the analytics warehouse next quarter. Design a QA plan to validate schema compatibility, data completeness, edge-case handling (NULLs, new codes), performance impact, and release gating. Include automation, manual checks, stakeholder signoffs, and rollback plans.

Sample Answer

Overview: I'll run a staged QA program (dev → test → canary/prod) combining automated checks, targeted manual validation, stakeholder signoffs, and clear rollback gates so BI deliverables remain reliable while onboarding 10 sources in one quarter.

1. Requirements & Inventory (week 1)- Catalog each source: owner, update cadence, primary keys, expected schema, nullability, allowed code sets, volume/peak.- Define SLAs (latency, freshness), business-critical tables, and downstream dashboards impacted.

2. Automation tests (run in CI on every ingest)- Schema compatibility: - Auto-compare incoming schema vs expected (column presence, types, nullable). Fail build if breaking change. - SQL example: SELECT COUNT(*) FROM information_schema.columns WHERE table=... and diff expected.- Data completeness: - Row-count delta vs historical baseline and source-reported counts. - Key uniqueness checks: duplicate primary keys.- Edge-case handling: - NULL rate per column; threshold alerts (e.g., >5% for critical fields). - New/unknown codes: lookup against allowed value tables and surface unknowns.- Data quality rules expressed as SQL/dbt tests; run nightly and on ingest.- Performance impact: - Record ingest times, query latencies for representative BI queries; compare to baselines and alert if >20% regression.

3. Manual checks (for each source, test phase)- Spot-check 5–10 representative records across partitions/dates; validate against source samples.- Business logic sampling: validate 3–5 key dashboard metrics computed from new source.

4. Staged rollout & gating- Dev → Test (automated + manual 1) → Canary (1–2% of dashboards/users) → Full Prod.- Release gates: - All automated tests pass - NULL/new-code thresholds within limits or remediated - Performance within agreed bounds - Stakeholder signoffs received- Signoffs: - Data owner: confirms mapping & business rules - BI product owner: approves dashboard metric parity - SRE/DBA: approves performance and capacity - Compliance (if PII)

5. Monitoring & alerting post-release- Real-time monitors for freshness, row counts, NULL spikes, new codes.- Dashboards showing QA metrics per source; automated pager if critical.

6. Rollback & remediation plan- Soft-fail: Pause consuming pipelines and switch dashboards to last-known-good table snapshot (time-partition fallback).- Hard-rollback: Restore previous table snapshot or switch dataset alias to previous stable table; communicate RTO/RPO per SLA.- Postmortem and permanent fix within defined SLA.

7. Timeline & automation tools- Use dbt + CI (GitHub Actions), Airflow for orchestration, Great Expectations or custom SQL tests, monitoring via Grafana/Datadog, alerting Slack/pager.- Deliverable cadence: onboard 3–4 sources per month with first month focused on hardest/most critical.

Metrics to show success: percent of automated tests passing pre-release (target 100%), incidents per source in 30 days (target 0–1 low), dashboard metric parity rate (>=99%).

HardTechnical

41 practiced

Describe a structured root cause analysis framework you would use for complex recurring data inconsistencies in KPIs. Include steps for data collection, hypothesis generation, statistical validation of hypotheses, correlation with deployments/config changes, and artifacts you would produce in a postmortem.

Sample Answer

Framework: I use a structured, hypothesis-driven RCA tailored for KPI/data pipelines: Define → Collect → Hypothesize → Test → Correlate → Remediate → Document.

1. Define the problem & scope- Specify KPI(s), time window, deviation magnitude, and business impact.- Create reproducible query or dashboard view that demonstrates the inconsistency.

2. Data collection- Snapshot raw source tables, ETL logs, schema/version, transformation SQL/LookML, and dashboard query text for the affected window.- Collect metadata: row counts, null rates, datestamps, job runtimes, partition stats.- Pull monitoring signals: data pipeline alerts, DB slow queries, failed jobs, and infrastructure metrics.- Export relevant samples (raw rows) for manual inspection.

3. Hypothesis generation (structured)- Use categories: data source, ingestion, transformation logic, aggregation/joins, dashboard/reporting layer, data model changes, and external events.- For each, write concise hypothesis statements (If X then Y) and expected observable signatures.

4. Statistical validation- Compute baseline distributions (rolling means, seasonality) and z-scores for the anomaly window.- A/B style breakdowns: compare affected vs unaffected cohorts (by time, region, user segment) using t-tests/chi-sq for categorical changes.- Run delta diagnostics: row-level lineage joins to identify missing/duplicated keys; use sampling and hashing to detect set differences.- Apply change point detection (e.g., CUSUM) to confirm timing.

5. Correlate with deployments/config changes- Align anomaly timestamps with deploy logs, DB migrations, schema changes, and config updates; compute temporal correlation and lead/lag.- Prioritize hypotheses that co-occur with changes and have matching signatures (e.g., schema rename → null spikes).- If needed, replay transformation on a snapshot to reproduce.

6. Remediation & verification- Short-term: revert config, fix SQL, or add mitigation filters.- Long-term: tests (unit lineage tests), schema contracts, monitoring (row counts, null thresholds), and CI for LookML/SQL.- Verify by rerunning pipeline and confirming KPI returns to baseline with statistical tests.

7. Postmortem artifacts- Executive summary (impact, timeline, owner, severity).- Timeline with events and evidence (charts of KPI, deploys, pipeline logs).- Hypotheses table: hypothesis, tests run, result, confidence level.- Root cause narrative and technical diff (SQL/LookML changes).- Action items with owners and due dates (short/long-term).- Repro recipe and automated checks added (unit tests, alert thresholds).

This approach ensures reproducibility, quantitative confidence, and operational fixes to prevent recurrence.

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.