The QA loop tests how you think about what could break
Sergei Skrylkov, Founder, Trippi · facts checked against the product on 2026-09-30
A QA loop is not a quiz on testing terms, although it contains one. What interviewers actually grade is coverage thinking — how many ways you can find for something to fail, and how you decide which of them matter before a release. The spoken exercises (“how would you test this?”) reward candidates who structure out loud, and punish those who list cases in the order they think of them.
The loop, round by round
Recruiter screen — 20–30 minutes
Manual or automation, which tools (Playwright, Cypress, Selenium, Postman), which kind of products, salary.
Testing fundamentals — 45 minutes, a QA lead
Terms and techniques — severity and priority, boundary values, the test pyramid — plus a first “how would you test…”.
“Test this” exercise — 45 minutes, spoken
A login page, a pen, a lift, a search box. Graded on structure and on the cases nobody else thought of. The general mechanics are on the technical interview page.
Automation round — 60 minutes, shared editor
Write or review an automated test, fix a flaky one, or design a framework. See the coding interview page for talking while you type.
API testing — 30–45 minutes
Status codes, contract checks, negative cases, sometimes in Postman live.
Behavioral — 45 minutes, a developer lead or manager
A bug that escaped, a disagreement with a developer, a release you stopped.
A take-home is common: a test plan and bug reports for a small demo application, discussed in the next round.
Ten questions, and what each one tests
| Question | What it tests | What a strong answer does |
|---|---|---|
| “How would you test a login page?” | Coverage thinking | Groups cases — functional, negative, security, accessibility, different browsers — before listing any. |
| “Severity versus priority — give an example where they differ.” | Triage | A typo in the company name: low severity, high priority. A crash in a rare admin screen: the opposite. |
| “Describe this bug as you would report it.” | Clarity | Title, steps, expected, actual, environment, evidence — spoken in that order. |
| “A test passes locally and fails in CI one time in ten.” | Flaky tests | Measures the rate, looks for timing and shared data, quarantines with an owner. |
| “What would you automate first, and what never?” | Return on automation | Stable, repeated, high-risk paths first; one-off and visual judgement stays manual. |
| “The developer says it is not a bug, it is a feature.” | Working with developers | Goes back to the requirement and the user, brings in the product owner, keeps it about the product. |
| “The release is tomorrow and you found a bug. What now?” | Risk judgement | States impact and workaround, then lets the owner decide with facts — not silence and not panic. |
| “How do you test an endpoint that creates an order?” | API testing | Happy path, validation, duplicates, auth, status codes, and what is in the database after. |
| “Explain boundary value analysis.” | Technique | An example: age 18–65, so test 17, 18, 65 and 66. |
| “Tell me about a bug that escaped to production.” | Ownership of process | Why the tests missed it and what was added so they would not again. |
Worked example: the flaky test
Almost every automation round reaches this question, because every team has flaky tests and most candidates answer “add a retry”. The interviewer wants a diagnosis before a fix. Here is the kind of structure a card offers.
Example of a card’s shape — written for this page, not a screenshot
The line it grew from
“One of your UI tests passes on your machine but fails in CI about one time in ten. What do you do?”
Points to speak from
- 1Measure first: run it many times in CI and compare the failures — same step, same error, same time of day.
- 2Check the usual causes: a fixed sleep instead of waiting for a state, test data shared between tests, an order dependency.
- 3Quarantine it with a ticket and an owner rather than retrying until it passes, so the suite stays trusted.
Which framework and which wait function — that part is yours. The card does not see the test code.
If English is your second language: testing words with two meanings
| What you hear | The trap |
|---|---|
| “Severity” and “priority” | In several languages they translate to the same word. In QA they are two different axes. |
| “Regression” | In QA: something that used to work and broke. In statistics: a model. Context decides. |
| “Smoke test” vs “sanity test” | A quick check that the build works at all, and a narrow check that one fix works. Teams use them loosely. |
| “Edge case” vs “corner case” | One extreme condition, and two or more extremes at once. |
| “Happy path” | The normal flow with valid input. The next question will be about unhappy paths. |
| “Repro steps” | Reproduction steps — what someone else does to see the bug. |
| “Blocker”, “showstopper” | A bug that stops the release. |
| “Sign off” | Give formal approval that testing is done. |
“How would you test a pen?” sounds like a joke to many non-native speakers. It is not. It is the same coverage question with the product removed, and it is graded seriously.
What Trippi Cue does in a QA loop, and what it cannot
Trippi Cue is a Chrome extension. Clicked in the call’s tab in Google Meet, Zoom on the web or Teams on the web, it listens to that tab’s audio — never your microphone, and no bot joins. The interviewer’s lines appear as they are recognised, with a translation if you choose. When a question is addressed to you, a card follows with two or three points — for a “test this” question, usually the groups of cases to walk through, so the answer has a structure before it has a list. You can also type your own question mid-call.
Limits, plainly: it does not see the application under test, the test code, the bug tracker or anything on the shared screen. It cannot run a test. It does not hear your own voice, so it cannot tell you which cases you already said. It works in browser tabs only.
FAQ
QA engineer, specifically.
What is asked in a QA interview?+
Testing fundamentals, “how would you test this” exercises, bug reporting, API testing, and for automation roles a coding round with a test framework.
How do I answer “how would you test a login page”?+
Start with groups — functional, negative, security, accessibility, compatibility, performance — then give two or three cases in each. Ask about requirements first.
Manual QA or automation — which interview is harder?+
Automation loops add a coding round. Manual loops go deeper on exploratory testing and on the “test this” exercises.
Can Trippi Cue see the app I am asked to test?+
No. It hears the call’s audio only. If the interviewer describes the app, that description is what it works from.
Is there a take-home in QA interviews?+
Often — a test plan and a few bug reports for a demo app. The next round usually asks you to defend them.
Read next
Structure first, cases second — while they are still asking.
Trippi Cue is in the Chrome Web Store. One click on the icon when the call begins, and nothing before that.