Edge cases

Edge cases are states that are not the happy path but will happen in production: empty lists, validation failures, unauthorized access, partial data, timeouts, concurrent edits, localization gaps, mobile constraints, and degraded dependencies.

| Category | Examples to name in interviews | |----------|-------------------------------| | Empty / null | No items, first-time user, deleted parent | | Errors | Invalid input, upstream 5xx, rate limits | | AuthZ | Wrong role, expired session, cross-tenant leak | | Concurrency | Double submit, stale read, lost update | | Degraded | CDN down, feature flag off, read-only mode |

Strong requirements documents or verbal answers group edge cases by user-visible behavior, not only by HTTP status code.

On interviews: for "invite teammate", list duplicate invite, revoked invite, SSO-only tenant, seat limit, and email bounce.

Common pitfalls: only designing for the demo account; ignoring idempotency; treating loading as infinite spinner without timeout messaging.

The trade-off is breadth of edge-case analysis versus shipping a thin slice that still handles the highest-risk states.

Checklist:

• List empty, error, and permission paths.
• Name concurrency and idempotency needs.
• Cover slow, offline, and degraded service behavior.
• Prioritize by user impact and likelihood.