Cohesyve · Practice for candidates
Preparing for a QA Engineer role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
QA hiring has shifted decisively towards engineers who can automate, reason about risk and influence quality upstream rather than only executing test cases. A typical process runs from CV screen to recruiter call, then a practical exercise — often writing test cases for a feature or automating a scenario — then technical interviews on your approach, and finally a conversation about how you work with developers. The candidates who struggle are usually those who can describe testing activities but not explain what they chose not to test and why. This page walks each stage in turn.
The hiring process, stage by stage
Application and CV screen
Reviewers look for the balance of manual and automated work, the tools and languages you use, the type of product and whether you have influenced quality beyond finding bugs.
How to prepare: Make the automation stack and the proportion of automated work explicit. Replace 'tested the application' with what you were responsible for and what changed — escaped defects, release confidence, cycle time. Link a repository if you have automation you can share.
Recruiter screen
A short call confirming level, tooling and expectations. Often clarifies whether the role is embedded in a delivery team or part of a central function.
How to prepare: Prepare a plain description of what you owned on your last team and how releases worked. Ask whether QA sits in the delivery team, who writes the automated tests, and whether the role includes release ownership. Have your range and notice ready.
Practical exercise
Usually one of three formats: write test cases for a described feature, find defects in a provided build, or automate a short scenario. Scoring rewards prioritisation and reasoning over exhaustive lists.
How to prepare: Practise producing a prioritised set of cases with the risk rationale attached, not a flat list. For automation exercises, rehearse a clean, stable structure with explicit waits and no brittle selectors. State your assumptions in writing.
Technical interview
A discussion of your exercise plus questions about test strategy, flakiness, coverage and where automation stops paying. Sometimes includes reviewing someone else's test code.
How to prepare: Be ready to justify what you excluded from testing as clearly as what you included. Rehearse a position on the test pyramid, flaky test triage and how you decide when a manual check is the correct answer.
Final interview with the engineering or QA lead
Covers influence and relationships: how you raise quality concerns, what you do when a release is pushed despite an open risk, and how you work with developers who test their own code.
How to prepare: Prepare a story about escalating a risk that was overruled and what happened, one about a defect that escaped and how you responded, and one about improving a process rather than a test.
What to study
Test design and risk prioritisation
The core QA skill is deciding what deserves attention, since no team can test everything and interviewers want to see your reasoning.
Automation practice
Automation is now assumed at most levels, and interviewers check whether you write maintainable tests or accumulate a brittle suite.
Test strategy across layers
Where a check belongs is a judgement question, and answering it well distinguishes an engineer from a test executor.
Debugging and defect reporting
A poorly investigated defect costs developer time, and interviewers often assess this directly with a provided build.
Quality in the delivery process
Senior QA roles are judged on preventing defects, not just detecting them, so process vocabulary matters.
Cohesyve for candidates
Practise a QA Engineer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Rebuild the fundamentals of test design and automation you rely on.
- •Take a feature you know and produce a prioritised test plan with written rationale
- •Build a small automation suite against a public site or API, focusing on stability
- •Revise the test design techniques you use least, usually decision tables and state transitions
- •Rewrite your CV so automation share and outcomes are visible in the first lines
Two weeks out
Practise the reasoning aloud, since that is what the interview scores.
- •Do two timed test design exercises and force yourself to state what you would not test
- •Practise a five-minute walkthrough of a defect from discovery to reproduction
- •Prepare stories about an escaped defect, an overruled risk and a process improvement
- •Review someone else's automation code and note what you would change
The final week
Rehearse the real exercise format under time pressure.
- •Complete one full practical exercise from a cold start, timed strictly
- •Prepare an automation project skeleton so setup does not consume your budget
- •Re-read anything you have already submitted and prepare its defence
- •Draft your questions about who owns quality and how releases are decided
The day before and the day of
Settle your approach and remove friction.
- •Test your tooling, screen share and any environment access provided
- •Decide your opening sequence: clarify scope, state assumptions, then prioritise by risk
- •Re-read the job advert and note whether the role leans manual, automation or strategy
- •Write down the two things you most want to be remembered for
Questions to expect
“Here is a login feature. How would you test it?”
What they're really asking: Do you work from risk and structure, or do you produce an unordered list of everything you can think of?
How to answer: Clarify the scope first — is this a new build, does it have multi-factor, what are the account states. Then work in layers: core functional paths, boundaries and invalid input, security concerns, then usability and accessibility. Finish by naming what you would deprioritise and why.
“A test suite is flaky. What do you do?”
What they're really asking: Do you treat flakiness as a real defect signal or as noise to be silenced?
How to answer: Say you would first quantify it — which tests, how often, and whether failures cluster around specific behaviour. Separate causes: timing and waits, shared state, genuine intermittent product bugs. Describe your quarantine policy and the deadline you would attach so quarantined tests do not become permanent.
“When is automating a test not worth it?”
What they're really asking: Do you understand automation as an investment with maintenance cost, or as an unqualified good?
How to answer: Give the criteria you actually use: how often the path runs, how stable the interface is, how expensive the failure would be, and how brittle the automation would be. Give a real example where you chose an exploratory or manual check instead and what that decision saved.
“A developer says your bug is not reproducible. How do you respond?”
What they're really asking: How do you handle disagreement, and is your investigation rigorous enough to stand up?
How to answer: Describe returning to the reproduction rather than the argument: environment, data state, version, timing. Explain how you narrow to the minimum reliable steps and what evidence you attach. Mention a case where the difference turned out to be environmental and how you documented it so it did not recur.
“Tell me about a defect that reached production.”
What they're really asking: Do you take ownership, and do you fix the process rather than just the bug?
How to answer: State what escaped and its impact plainly. Then explain the gap that allowed it — an untested path, an assumption in the requirements, a gap between environments — and the specific change you made afterwards. Avoid attributing it entirely to developers or to time pressure.
“The team wants to release and you have an open risk. What do you do?”
What they're really asking: Can you communicate risk in terms a decision-maker can act on, rather than blocking or capitulating?
How to answer: Describe framing the risk as likelihood, impact and detectability rather than as an objection. Offer the options: release with monitoring, release behind a flag, release without the affected path, or delay. Say who owns the decision and how you record it. Give a real example including one where you were overruled.
What to bring as evidence
A sanitised test plan showing prioritisation and explicit exclusions
A repository with automation that demonstrates structure and stable waiting
A well-written defect report with a minimal reproduction and evidence
A before-and-after measure such as escaped defects or pipeline runtime
Two references, ideally including a developer who worked alongside you
A short note on a process change you introduced and how it was received
Common mistakes
Producing an exhaustive unordered list of test cases with no prioritisation or rationale
Writing test cases as click sequences that break the moment the interface changes
Treating flaky tests as noise and adding retries rather than diagnosing them
Describing testing activities without ever naming a defect you prevented
Automating through the interface when the same check would be faster at the API level
Framing quality as someone else's failure rather than a shared responsibility
Questions to ask them
- ?
Who decides a release goes out, and what happens when QA disagrees?
- ?
How long does the pipeline take, and does the team trust its results?
- ?
Do developers write their own tests, and how is that boundary drawn?
- ?
What was the last defect to reach production, and what changed afterwards?
- ?
How early is QA involved — at the requirement stage or after the build?
- ?
How much of the current suite would you delete if you could?
Frequently Asked Questions
Do I need to be able to code to get a QA role now?
For most roles, yes, at least well enough to write and maintain automated tests and to read application code when investigating. Purely manual roles still exist in regulated and hardware-adjacent contexts but are a shrinking share. If your coding is light, focus on writing stable automation for a small real scenario rather than on language theory.
How much does the specific automation tool matter?
Less than the structure of what you write. Teams accept transferable experience readily, because the difficult parts — stable waiting, test data, isolation, reviewable structure — are common across tools. Say which tool you know, show you understand the underlying problems, and be explicit that you have switched tools before if you have.
What is the difference between QA Engineer and SDET in practice?
The boundary varies by company more than by title. SDET roles generally mean more time writing test infrastructure and framework code, while QA Engineer roles usually mix design, exploration and automation. Ask during the recruiter call what proportion of the week is spent writing code, because the answer determines how you should prepare.
How do I show impact when my job is to prevent problems?
Use before-and-after evidence: escaped defect trends, pipeline duration, how long a regression cycle used to take, or a class of bug that stopped appearing after a change you made. Where you cannot share numbers, describe the change and the consequence concretely.
Can I practise the exercise stage before doing the real one?
Rehearsing helps most for QA, because the practical stage rewards prioritisation and clear reasoning that are hard to produce cold. Cohesyve lets you import the role you are applying for, run a simulation of the exercise, and receive a scored report showing where your reasoning was thin, with a learning pathway attached. The free tier gives you three scored assessments and needs no card.
Practice
What a QA Engineer assessment tests, and how it's scored →
Career guide
What a QA Engineer actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a QA Engineer role? See how your applicants perform before you spend interview time.