Question 1

Tell me about your project and the framework you built.

Accepted Answer

You cannot walk into this one unprepared — it appears in nearly every interview and sets the first impression. The structure (2 minutes): (1) context — the product, team size, your role; (2) stack and architecture — Playwright + TS, POM, fixtures, API client, CI; (3) scale — how many tests, how long, when they run; (4) your personal contribution; (5) results with numbers; (6) an honest weakness. The most important rule: in the Action part say "I", not "we". "We have a POM" says nothing — "I built the POM and the fixture layer, and moved login off the UI with storageState" shows you. This isn't about modesty: the interviewer is hiring you, not the team, and needs to know what you can do. Numbers are mandatory: "regression went from 2 days to 40 minutes", "PR feedback is under 10 minutes", "140 UI + 60 API tests". A description without numbers isn't memorable. The final item — an honest weakness — is the strongest part and the one most candidates skip: "We have no component tests, so some UI detail is verified at E2E level — the suite is heavier than it needs to be." Being able to critique your own work is a middle+ signal, and it also steers the conversation onto technical ground you've chosen. A preparation tip: write this answer out and rehearse it aloud once, with a timer. Improvising this particular answer almost always comes out scattered.

Question 2

Tell me about your hardest experience with flaky tests.

Accepted Answer

Build this story with STAR and make sure it shows a systematic approach — not scattered fixes. Situation: the state of the suite and, most importantly, the impact. "14 tests failed randomly" is a technical fact; "the team had stopped looking at red" is the real size of the problem. Don't omit the second. Task: the measurable target you set yourself — "flaky rate under 1%". Action — this is where the process shows: (1) I measured first — parsed the last 30 runs' reports and ranked tests by failure frequency (I didn't start from a guess); (2) grouped root causes via traces — shared data, a race with an animation, an external service; (3) quarantined immediately to unblock the team, each with a ticket; (4) fixed causes, not symptoms — data isolation and condition-based waiting instead of adding retries; (5) proved it with --repeat-each=20 --retries=0; (6) built a system so it can't return — CI computes the flaky rate and fails the pipeline above 1%. Result with numbers: "from 8% to 0.4% in five weeks" plus the behavioural change: "the report is read again; the following quarter the suite caught two real regressions". Add the Learned part — it closes the story: "quarantine early" and "measure before fixing — my initial guess was wrong". Admitting your own guess was wrong makes the answer more credible, not less.

Question 3

How do you learn a new tool or technology?

Accepted Answer

This question matters more than it looks: automation moves fast, and the team wants to know whether you have a learning system. "I google it" is not a system. My approach: (1) start with the official docs — blog posts and video courses go stale fast and are often shallow; (2) find a small real task — not a toy example but a concrete problem from my own project; learning sticks far better on a genuine problem; (3) try to understand why it works that way, not just how to use it — that's what matters when something unexpected happens; (4) write it up or share it with the team — explaining immediately exposes the gaps in your understanding; (5) learn its limitations too — knowing what a tool does NOT do matters more than knowing how to use it. Then I give a concrete example — the most important part of the answer: "When I moved from Selenium to Playwright I first read the locator and auto-waiting sections of the docs, then ported five existing Selenium tests — that's where the real differences showed; that's when I learned strict mode and --ui. A week later I gave the team a 30-minute demo, which also tested my own understanding." Without an example the answer stays generic and unconvincing; with one it becomes a story.

Question 4

"Tell me about a bug you let slip" — how should you answer this?

Accepted Answer

This question tests honesty and self-criticism, not technical skill. There are two wrong paths and both hurt: "it's never happened" (unconvincing — every QA misses bugs) and blaming someone else ("the developer didn't tell me"). The right structure: (1) a concrete case, not overly dramatic but real; (2) taking responsibility without hunting for excuses; (3) how it was found and what you did — the quality of the reaction often matters more than the mistake; (4) what SYSTEM change you made — the most important part. An example: "During regression I only checked currency conversion in the payment flow for AZN; a rounding error on USD payments reached production. My mistake was that I hadn't considered currency variations while writing the test cases — I'd assumed the logic was identical. After a customer complaint the hotfix took a day. Then I did two things: covered the conversion logic with a data-driven test at API level (all currency pairs), and more importantly added a 'variation dimensions' item to our test-design checklist: currency, language, role, device. In the next sprint that checklist caught a similar gap during refinement." Why this answer works: the mistake is real, responsibility is taken, the outcome is concrete, and above all a systemic fix was drawn from an individual error. That last move is one of the key indicators of the middle-to-senior transition.

Question 5

What questions should you ask at the end of an interview?

Accepted Answer

"I have no questions" is one of the weakest possible answers — it reads as indifference and spoils the interview's final impression. Keep 3-4 ready; you don't need to ask them all, but you need to have them. Technical/role questions: (1) "What's your biggest pain point in automation right now?" — the best question: you learn the real situation while showing you want to solve problems; (2) "What state is the existing suite in — how many tests, flaky rate, how long in CI?" — the question itself signals what you consider important; (3) "Is test code reviewed, and by whom?" — this reveals the team's quality culture; (4) "How do QA and developers collaborate — does QA take part in refinement?" Role and growth: (5) "What does success look like in the first three months?" — this clarifies expectations and shows you're outcome-oriented; (6) "How is technical growth supported in the team?" Questions to avoid (at this stage): asking only about salary, holiday and remote work. These matter and must be discussed — but with HR or at the offer conversation, not at the end of a technical interview. A tactical tip: take notes throughout and ask something based on what you heard ("you mentioned the nightly suite is sometimes unstable — has the cause been identified?"). That lands far more strongly than reading from a prepared list, because it shows you were genuinely listening.

Question	What's actually being assessed	The trap
Tell me about your project	Whether you can speak in context; whether your own contribution is visible	Saying only "we" — nobody learns what you did
What was your hardest bug?	Your investigation method and persistence	Describing the bug and skipping the process
Have you had a conflict with a developer?	How you resolve disagreement	"Never" — unconvincing; or blaming the developer
Tell me about a mistake you made	Self-criticism and ability to learn	A fake flaw ("I work too hard") or blaming someone else
How do you learn a new tool?	Whether your learning has a system or is random	"I watch YouTube" — with no concrete example
Why are you changing jobs?	Professional motivation; attitude to a former employer	Badmouthing a former employer/manager — one of the strongest negative signals
Do you have questions for us?	Your interest and what you consider important	"No" — reads as indifference

Behavioural and experience questions