Interview Drills — Automation & API Awareness

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). These probe your growth edge: where automation fits, what's worth automating vs. not, the limits of automation, and what an API is and what API-level testing checks versus the UI. You don't need to code to ace these — interviewers are testing your judgment about automation, not your syntax. Practice thinking aloud and always tie back to cost, stability, and risk. The app can role-play these as mock interviews (see mock-interview.md).

The universal automation-judgment structure: Clarify what we're testing and how often → weigh value (how repetitive/high-risk) against cost (how stable, how hard to maintain) → decide automate vs. keep manual → name what humans still own. Use it on almost any "should we automate this?" question.

D1

difficulty: easy
concept: automation-and-apis What kinds of tests are worth automating, and what's better left to a human?
Framework: State automation's sweet spot (repetitive, stable, high-value checks) → give the prime example (regression) → name what humans keep (exploratory, usability, new features, judgment calls) → explain why the split exists (cost/maintenance vs. machine speed).
Model answer: "Automate the boring, stable, repetitive checks — above all regression: re-verifying hundreds of existing flows after every change, which is slow and mind-numbing by hand but takes a machine minutes. I'd keep humans on exploratory testing, usability, and brand-new features — anything that needs judgment or noticing 'that looks weird.' The reason is economics: scripts are expensive to write and maintain and only check what they're told, so you spend that cost where the check is stable and runs constantly."
Rubric: Strong answers name regression as the canonical automation target, reserve exploratory/usability/new work for humans, and justify the split with cost and judgment — not just "automation is faster." Weak answers say "automate everything" or can't explain why some testing stays manual.

D2

difficulty: easy
concept: automation-and-apis Explain what an API is to a non-technical person.
Framework: Give the plain definition (software talking to software) → use a concrete everyday example → offer a simple analogy → close with why it matters for what we build.
Model answer: "An API is how two pieces of software talk to each other. When a weather app shows the forecast, it doesn't measure the weather itself — it asks a weather service through its API and gets data back. The analogy I like is a waiter: the app gives its order to the waiter (the API), who takes it to the kitchen (another system) and brings back the food (the data). So whenever one app needs something another app has, an API is the messenger in between."
Rubric: Strong answers define it simply ("software talking to software"), ground it in a real example, and use a clear analogy without jargon. Weak answers recite "Application Programming Interface" with no plain-language meaning, or confuse an API with a database, a website, or a programming language.

D3

difficulty: medium
concept: automation-and-apis What does API-level testing check that UI testing doesn't, and when would you reach for each?
Framework: Define API testing (send a request, check the response — the data and logic directly) → contrast UI testing (driving the screens like a user) → name API testing's advantages (faster, more stable, catches problems closer to the source) → name what only the UI can verify → give a quick "use each when" rule.
Model answer: "API testing sends a request and checks the response — it verifies the data and business logic directly, beneath the visual interface. UI testing drives the actual screens, clicking and typing like a user. API tests are faster and more stable because there are no fragile buttons or layouts to break, and they catch a logic bug closer to its source. But only UI testing confirms that the user actually sees the right thing — labels, layout, that the button is even wired up. So I'd push as much logic-and-data checking as possible down to the API level, and reserve UI tests for verifying the experience the user actually gets."
Rubric: Strong answers explain that API tests check data/logic directly while UI tests verify what the user sees, note API tests are faster/more stable, and recognize the UI still catches things the API can't (rendering, wiring). Weak answers treat them as interchangeable, claim API testing replaces UI testing entirely, or can't say what each uniquely covers.

D4

difficulty: medium
concept: automation-and-apis A manager says, 'Let's automate everything so we don't need manual testers.' How do you respond?
Framework: Acknowledge the real value of automation (don't be defensive) → name its concrete limits (only checks what it's told; can't judge or notice "weird"; expensive to build; breaks when the product changes) → reframe the goal (automate the repetitive checks to free humans, not replace them) → state the healthy split.
Model answer: "I'm all for automation where it pays off — it's perfect for the repetitive regression checks. But 'automate everything' has real limits: a script only checks exactly what we told it, so it can't notice that a page looks broken or feels confusing the way a person can, and it's expensive to write and breaks whenever the product changes. The goal isn't to replace testers — it's to automate the boring, stable checks so humans are freed for the work that needs a brain: exploratory testing, usability, and new features. That's how we get both speed and coverage of the things automation can't see."
Rubric: Strong answers validate automation's value, then name specific limits (only-checks-what-it's-told, no judgment, maintenance cost, brittleness) and reframe automation as freeing humans rather than replacing them. Weak answers either fully agree (ignoring the limits) or reject automation defensively without acknowledging its real benefits.

D5

difficulty: hard
concept: automation-and-apis You inherit a brand-new feature with no automated tests and limited time. Which tests would you automate first, and which would you not?
Framework: Clarify (how stable is the feature? how often does it run? what's the risk if it breaks?) → automate the stable, high-value, repetitive paths first (core happy-path + critical regression, ideally at the API level for speed/stability) → explicitly defer automating volatile or judgment-heavy areas → keep exploratory/usability manual while the feature churns → name the trade-off.
Model answer: "First I'd ask how settled the feature is — automating a design that's still changing wastes effort, since scripts break when the product changes. With limited time I'd automate the stable, high-value, repetitive checks first: the core happy-path and the critical regression cases that we'll re-run on every build, and I'd push as many as I can to the API level because those tests are faster and more stable than clicking screens. I'd hold off automating anything still in flux or anything needing judgment. Exploratory and usability testing I'd keep manual for now — that's where a human catches the surprises in a new feature. The trade-off: I get fast regression safety on the parts that matter, and accept that the churny, subjective parts stay manual until they stabilize."
Rubric: Strong answers prioritize stable/high-value/high-frequency paths, prefer API-level where sensible, deliberately defer automating volatile or judgment-heavy areas, and keep exploratory/usability manual — naming the trade-off. Weak answers try to automate everything immediately (including an unstable new feature), ignore maintenance cost, or give no prioritization basis.

D6

difficulty: hard
concept: automation-and-apis Your automated regression suite is green, but a major bug still reached production. How is that possible, and what does it tell you about automation?
Framework: Explain the core limit (automation only checks what it was told — green means "the things we scripted passed," not "the product is bug-free") → enumerate plausible gaps (the scenario was never automated; it's a usability/visual issue no assertion covers; a stale script that no longer checks what it claims to) → draw the lesson (automation is a safety net for known cases, not a substitute for human exploration) → name the corrective action.
Model answer: "Green only means the checks we wrote passed — automation can't catch a case nobody scripted. The bug likely lived in a path we never automated, or it's the kind of thing a script can't see: a confusing or visually broken experience with no assertion guarding it, or worse, a stale test that's silently no longer checking what it should. The lesson is that a passing suite proves the known regression cases still work — it never proves the product is bug-free, because automation only checks what it's told and can't notice 'that looks weird.' My corrective action: add a regression test for this exact bug so it can't recur, and make sure we keep dedicated time for exploratory testing, since that's the human work that finds the cases the scripts were never going to."
Rubric: Strong answers nail the core insight — automation only verifies what was scripted, so green ≠ bug-free — cite realistic gaps (unscripted path, unassertable usability issue, stale test), and prescribe both adding a regression test and preserving human exploration. Weak answers blame the tools vaguely, claim the suite "should have caught it" without explaining automation's blind spots, or propose only "write more automation" with no role for human testing.