Question 1

How should you prepare for a rapid-fire round?

Accepted Answer

The key to preparation is rehearsal, not memorisation — compressing what you know into 30 seconds is a separate skill, and you only get it by saying things out loud. My approach: (1) I build a list of the 25-30 most frequent questions (auto-waiting, locator strategy, fixtures, storageState, flakiness, the pyramid, page vs context, iframes, new tabs, sharding, mocking); (2) I write a 2-3 sentence answer for each — writing forces the thought into shape; (3) I rehearse aloud and time myself — anything over 40 seconds gets trimmed; (4) I attach one concrete example to each answer, because the example is what separates understanding from recitation. The most common mistake I see in practice: a long answer to a simple question. Talking for three minutes about "what is auto-waiting" doesn't look knowledgeable — it shows you couldn't read the question's level. I also map out my weak areas in advance and prepare an honest answer for them: "I haven't used that; here's how I imagine it works..." Having that sentence ready beforehand is what stops you inventing something under stress.

Question 2

Mid rapid-fire you realise you gave a wrong answer. What do you do?

Accepted Answer

I correct it immediately and calmly: "One moment — I'd like to go back to the previous question, what I said wasn't quite accurate. The correct answer is..." It's worth understanding why this is a strong move: the interviewer has almost certainly already noted the error. By returning to it yourself you demonstrate two things — first, that you genuinely understand the topic (you spotted the mistake); second, that you can admit being wrong. The second quality matters more in teamwork than the first, and it's scored separately in interviews. What not to do: (1) knowingly move past it — every later answer then falls under suspicion; (2) apologise at length and put yourself down — one sentence is enough, then move on; (3) get rattled and lose your rhythm — one mistake doesn't decide an interview, but a collapse in composure can. The same principle applies in live coding: saying "I went the wrong way here, let me back up" isn't weakness, it's an engineering reflex.

Question 3

The interviewer starts digging with "why?" on one of your answers. What does that mean?

Accepted Answer

This is almost always a positive signal, and many candidates misread it. There are two likely reasons: (1) the interviewer is checking whether you have real depth in this area — meaning your answer was interesting enough to be worth probing; (2) they're personally interested in the topic and want a professional conversation. Either way it's an opportunity, not a punishment. Rapid-fire rounds don't dig — being dug into means you've already cleared the bar. The right behaviour: (1) don't get defensive — the question isn't an attack; (2) open up your reasoning: "I make this call because...", and name the trade-offs; (3) give a concrete example — one real case from a project instantly doubles the answer's strength; (4) state the boundary when you reach it: "beyond that I'm not certain, but I'd expect..." One subtle point: sometimes the chain of "why?" is deliberately pushed to your limit to see where you stop. So you will eventually reach an "I don't know" — and that's the planned outcome, not a failure. Getting there composed is the correct behaviour.

Question 4

"Why choose Playwright over Selenium?" — build a 30-second answer.

Accepted Answer

The structure: 3 advantages + 1 honest concession + a context sentence. That format shows both knowledge and balanced judgment, and it fits in 30 seconds. Model answer: "Three main reasons: first, auto-waiting — it removes the biggest source of flakiness at the root; second, speed — the WebSocket protocol and parallelism by default; third, the tooling — the trace viewer turns CI failure investigation into minutes, and API testing is built in. Selenium's strengths are still the breadth of language and browser support and the existing ecosystem around large legacy suites. In our context — a JS/TS stack and a modern web app — Playwright clearly won." Why this structure works: (1) the reasons are concrete and technical (not "it's better"); (2) you acknowledge the competitor's strengths — a signal of balanced judgment that most candidates skip; (3) the final sentence shows a context-driven choice: tools are picked by context, not by fashion. The most common mistake: disparaging Selenium ("it's outdated", "it's slow"). The interviewer may have spent ten years with it — and in any case a categorical stance reads as inexperience.

Question	Model answer (20-30 seconds)
What is auto-waiting in Playwright?	Before every action Playwright waits for the element to be actionable: visible, enabled, stable, receiving events. That's why you never need `sleep`.
Difference between a `locator` and an `ElementHandle`?	A locator is lazy — it re-resolves the element on each use, so it survives DOM updates. An ElementHandle binds to a specific DOM node and goes stale; it isn't used in modern code.
Difference between `toBeVisible()` and `isVisible()`?	`expect(...).toBeVisible()` is a web-first assertion — it waits until the condition holds. `isVisible()` returns a boolean for that instant without waiting — using it as a condition in a test is a flakiness source.
What is strict mode?	When a locator matches more than one element Playwright throws — preventing a silently wrong pick. Fix: refine the locator, use `filter()`, or `first()`/`nth()` when it's intentional.
Difference between `page` and `context`?	A `context` is an isolated browser profile with its own cookies and storage; a `page` is one tab inside it. Two different users need two contexts, not two tabs.
What is storageState for?	It logs in once in setup and writes cookies/localStorage to a file; all tests start from that state. Saves 5-10 seconds per test.
Where does fixture teardown go?	In the code after the `await use(...)` line. It runs even when the test fails — which makes it the most reliable place for cleanup.
What is sharding?	Splitting the suite across machines: `--shard=1/4`. Four machines cut total time roughly fourfold. Requirement: fully independent tests.
How do you reach an element inside an iframe?	I switch into the frame with `page.frameLocator('iframe[title="..."]')`; ordinary locators work inside. A plain locator doesn't cross the frame boundary.
What do you do when a new tab opens?	I arm `context.waitForEvent('page')` BEFORE the click, then click and `await` the new `page` object.
How do you test file upload?	`setInputFiles('path/to/file')` — no OS dialog involved. For a custom button hiding the input, I intercept `page.waitForEvent('filechooser')`.
How do you call an API in Playwright?	With the `request` fixture: `await request.post('/api/orders', { data })`. I use it instead of the UI for test-data setup — faster and more stable.

Question	Model answer
Difference between `==` and `===`?	`===` performs no type coercion; `==` does (`'1' == 1` → true). Always `===` in tests.
What is a Promise, what does `async/await` do?	A Promise is the eventual result of an operation. `await` waits for it to settle and keeps the code readable as a sequence. The Playwright API is fully async — a forgotten `await` silently makes the test falsely green.
Difference between `let`, `const`, `var`?	`const` and `let` are block-scoped; `var` is function-scoped and hoisted — I don't use it. Default to `const`, use `let` when the value changes.
What does TypeScript give you in test code?	Errors caught before running, IDE autocomplete (a big difference for the Playwright API), types for fixtures and test data. It also enables typed lint rules like `no-floating-promises`.
What is a flaky test?	A test that passes and fails without code changes. Typical causes: race conditions, fixed sleeps, shared data. Its worst damage is killing trust in the suite.
Difference between smoke and regression?	Smoke — a fast check of the most critical flows (is the build usable at all?), on every PR. Regression — broad coverage confirming existing functionality still works, usually nightly.
What is the test pyramid?	Many fast unit tests, a moderate number of integration/API, few E2E UI. The principle: verify at the lowest possible level.
Difference between `merge` and `rebase` in Git?	`merge` preserves history and creates a merge commit; `rebase` rewrites commits for a linear history. Rebasing a shared branch is dangerous.

Technical rapid-fire questions