Code Quality, Error Handling, and Defensive Programming Questions

Direct answer

I'd start from the feature's purpose and reasonable user intent to infer what "invalid" should mean, then combine the standard technique, equivalence classes and boundaries on every field, with exploratory testing that deliberately tries inputs a real user or an attacker might realistically produce. I'd document each finding as a question for the developer or product owner rather than assuming my own guess is the spec.

Structured elaboration

• Infer intent from context: what is this field for, and what would a reasonable value look like; that gives you the "valid" class even without a written spec.
• Apply the standard techniques anyway: equivalence partitioning and boundary values still apply, you're just deriving the classes from context and common sense instead of a requirements document.
• Explore adjacent surfaces: unicode, extremely long strings, leading or trailing whitespace, copy-pasted content with hidden characters, concurrent submissions, browser back-button resubmission, the gaps a developer commonly misses while focused on the happy path.
• Log every ambiguous case as a question, not a silent judgment call: what should happen with a very long input in this field is a legitimate open question to raise with the team, not something to unilaterally decide.

Worked example

Testing a new "apply coupon code" field with no written spec, I'd try an empty string, a valid-looking but nonexistent code, a code with trailing whitespace, the same code submitted twice rapidly, a code belonging to an expired promotion, and an extremely long string. If a very long input crashes the page instead of showing "invalid code," that's a clear defect regardless of the missing spec; if the whitespace-trimming behavior is unclear, I'd raise it as an open question rather than guess.

Trade-offs and pitfalls

Spending unlimited time exploring every conceivable input isn't practical under a deadline; risk-based prioritization, what's most likely to be hit by real users, what's most costly if wrong, has to bound the exploration. The pitfall of exploratory testing without a spec is treating your own assumption about correct behavior as ground truth and filing "bugs" that are actually undocumented, intentional behavior.

What the interviewer probes next

Whether the candidate distinguishes "this crashes, definitely a bug" from "this behavior seems off, but I should confirm intent," since conflating the two either creates noise or lets real bugs slide as maybe-intentional.

Direct answer

Use equivalence partitioning to group inputs into classes that should behave the same way, then pick one representative from each class plus the boundary between classes, instead of testing every possible value. Keep the suite maintainable by treating validation rules as data the test runner reads, not hardcoded assertions, so a rule change is a one-line diff.

Structured elaboration

• Equivalence classes: for age, a valid class (say 18-120), too-young, too-old, non-numeric, and empty. For email, valid format, missing @, missing domain, empty string, extremely long string. For phone, valid length/format, wrong country code, letters mixed in, empty.
• Boundary values: test the edges of each class (17 vs 18, 120 vs 121) because off-by-one errors cluster there.
• Control combinatorial growth: don't cross every field's negative cases with every other field's; test one field's negative cases while the rest stay valid, and reach for pairwise combinations only if fields genuinely interact.
• Maintainability: express the rules as a data-driven table (field, rule, valid/invalid examples) that the test suite reads from, or at least keep the table next to the validator in source control, so a rule change updates one place.

Worked example

For an age field valid from 18 to 120: test 17 (just below), 18 (valid boundary), 120 (valid boundary), 121 (just above), 0, a negative number, "abc", and an empty string. That is 8 cases covering all 5 equivalence classes (valid, too-young, too-old, non-numeric, empty) and both boundaries, not an exhaustive sweep of every possible age.

Trade-offs and pitfalls

Testing every combination of three fields' negative cases creates a combinatorially large, slow, brittle suite; testing only the happy path plus one negative case misses real bugs. A common pitfall is hardcoding the limits (18, 120) directly into test assertions, so the suite keeps "passing" even after the business rule changes to 21 and quietly stops testing anything meaningful.

What the interviewer probes next

Whether the candidate treats test data as a maintenance liability and not just a way to hit line coverage, and whether they would catch a rule change that makes existing tests pass for the wrong reason.

Direct answer

Severity and priority are two different axes: severity is about impact, a crash is more severe than a confusing message, while priority also factors in frequency and user-facing cost, so I weigh how bad it is when it happens against how often it happens and who it affects. A rare crash can still outrank a common cosmetic issue if it causes data loss, but a common confusing message generating a high volume of support tickets might be the more urgent fix in practice.

Structured elaboration

• Severity axis: does it crash the app, corrupt data, or expose sensitive information (high), versus a confusing but recoverable message (low to medium).
• Frequency axis: how many users actually hit this input in practice; a rare edge case matters less in absolute impact even if individually severe.
• Business context that changes the answer: is the crash on a path used by a tiny fraction of users doing something unusual, or is it on the checkout flow; is the confusing message generating support tickets or silently confusing users who give up.
• Write it up so the decision is legible: file both with clear severity and frequency reasoning, how you triggered it, how common that input is in production if you can estimate it, so the team makes the priority call with real information, not just your gut.

Worked example

The crash happens when a user pastes an emoji into a field that isn't emoji-aware, likely hit by a tiny fraction of users. The confusing error message appears whenever a session expires mid-form, which happens to a meaningful share of users daily. Even though the crash is more severe in isolation, I'd flag the confusing message as higher priority to fix first because of how often it's hit, while still filing the crash as high severity so it doesn't get lost.

Trade-offs and pitfalls

Always fixing by severity alone ignores real-world impact and can spend a release cycle on a bug almost no one will see; always fixing by frequency alone risks leaving a rare but data-corrupting bug in production. The pitfall in bug reports is conflating severity and priority into one field, hiding the reasoning from whoever makes the final call.

What the interviewer probes next

Whether the candidate treats this as a real trade-off requiring context, rather than reciting "always fix crashes first," since a good QA engineer pushes back on oversimplified rules with actual reasoning.

Direct answer
A boundary check catches a specific class of bug (accessing an index, offset, or value outside the range the code actually handles correctly) at the moment it happens, instead of letting it silently produce wrong output or crash somewhere unrelated later; three concrete examples: array/list indexing, pagination offsets, and numeric limits.

Structured elaboration and worked examples

• Array indexing: the bug is an off-by-one or attacker-controlled index reading past the end of a buffer or list. The defensive check: validate 0 <= index < len(array) before accessing, raising a clear IndexError/custom exception instead of either crashing with a cryptic native error or, in an unsafe language, reading adjacent memory. A unit test: assert_raises(IndexError, get_item, [1,2,3], 5).
• Pagination offsets: the bug is a negative or absurdly large offset/limit from a client, which can either error confusingly deep in a SQL driver or, worse, silently return zero rows and look like 'no data' rather than 'bad request'. The defensive check: clamp or reject offset < 0 and cap limit to a sane maximum (say 1000) before it reaches the query layer. A unit test: assert paginate(items, offset=-5, limit=10) raises ValueError.
• Numeric limits: the bug is an integer overflow or an out-of-domain value (a negative quantity in an order, a percentage over 100) silently producing a nonsensical result instead of an error. The defensive check: validate the value's range explicitly before using it in a calculation. A unit test: assert_raises(ValueError, apply_discount, price=100, percent=150).

Trade-offs and pitfalls
Each of these checks is cheap individually, but the value comes from applying them CONSISTENTLY at every place the boundary is actually crossed (every array access from external input, not just the ones you happen to remember); a single unguarded pagination endpoint added six months later by someone who didn't see this pattern reintroduces the exact bug class. Treat these as patterns to lint for or wrap in a shared utility function, not as one-off checks to remember individually.

Direct answer

Add a schema-validation step at the ingestion boundary, using something like JSON Schema or Pydantic, that runs on every real response as part of the pipeline, not just at test time, so drift fails fast with a clear error instead of silently flowing downstream. Pair that with a scheduled contract test against the live upstream, not just mocked fixtures, so the team learns about a breaking change before a batch job does.

Structured elaboration

• Define the contract explicitly: required fields, types, and value constraints, not just "the response was 200 OK."
• Validate at the boundary: check every real response against the schema as it enters your system, and quarantine records that fail rather than letting a type mismatch propagate through several transformations before it's hard to trace back.
• Contract-test against the real upstream, scheduled independently of your own deploys: mocked fixtures will happily keep passing forever after the real API changes, because the mock never changes.
• Version and alert on schema changes, even for fields you don't currently use, since today's ignored field can become tomorrow's dependency.

Worked example

A pipeline ingests a partner's product feed where "price" was always a decimal like 19.99. The partner changes their API to a nested object with an amount in cents and a currency code. A schema check asserting price is a number fails immediately with "price: expected number, got object" and quarantines the batch, instead of the pipeline coercing the object to a missing value and silently loading zero-priced products.

Trade-offs and pitfalls

An overly strict schema that rejects any unknown extra field creates noisy failures every time upstream adds something unrelated; a good contract distinguishes fields you depend on from fields you ignore. Mock-only contract tests give false confidence because the mock and the real API can drift apart silently for months.

What the interviewer probes next

Whether the candidate distinguishes a test that checks your own parsing code from a test that checks the upstream contract itself.