QA mock interview 2026: 40 Junior and Middle tester questions
This is a technical interview rehearsal, not a glossary to memorise. Set a timer, answer aloud and only then open the review. Every question includes what a strong answer demonstrates and the mistake that weakens it.
How to use this mock interview
A real interview tests whether you can assemble an answer without a long pause. Allow 90 seconds for a theory question and up to five minutes for a scenario. Speak aloud: an answer in your head nearly always sounds more structured than the one you actually say.
Do not memorise the sample wording. Compare the structure: did you identify the goal, risk, concrete check, expected result and evidence? That reasoning pattern is what separates a working answer from a definition.
- Clarify context and constraints
- Name the main risk
- Offer concrete checks
- State the expected result
Mark a question after answering independently and checking the review.
- 0 No answer, or unrelated terms with no connection to the problem. 0 · gap
- 1 A correct definition, but no example, expected result or priority. 1 · theory
- 2 A structured answer with concrete checks and expected results, but limited risk and evidence. 2 · Junior+
- 3 The answer uses context, risk, trade-offs and observability and explains the choice. 3 · Middle
Junior QA: fundamentals tested through examples
Junior candidates are not expected to be encyclopaedias. They need stable foundations: test design, clear defect reports, HTTP, client-server basics and the ability to see a negative path.
1 What is testing, and can it prove that no bugs exist?
Strong answer review
Testing provides information about quality and reduces risk, but it cannot prove the absence of defects. Exhaustive testing is almost never possible, so checks are selected from requirements, risk, test techniques and product history. The QA outcome is not “there are no bugs”; it is a clear account of what was tested and what risk remains.
What it assesses: the purpose of testing, limited coverage and the connection to risk.
Red flag: “QA guarantees that the product works completely”, or a definition with no practical meaning.
2 How would you test a login form?
Strong answer review
I would first clarify login methods, email and password rules, lockout, recovery and roles. Then I would cover successful login, each field, empty and boundary values, case and whitespace, a wrong credential pair, brute-force protection, error messages, and session creation. After login I would check direct access to a protected page, logout, session expiry and switching users.
What it assesses: clarifying questions, grouped checks and movement from UI validation to session and security.
Red flag: an unprioritised list of fields that never checks what happens after login.
3 How do severity and priority differ? Give an example.
Strong answer review
Severity describes the effect on the system or user; priority describes when the business wants the defect fixed. Data loss in a rarely used internal report may have high severity without the highest priority. A company-name typo on the home page before a campaign has low severity and high priority. The exact scales and field ownership depend on the team process.
What it assesses: separation of technical impact from business order, with an example where values differ.
Red flag: “QA sets severity and a manager sets priority” presented as a universal rule without explaining either concept.
4 POST /orders returned 201. Is the test successful?
Strong answer review
Not yet. A 201 covers only part of the contract. Check the response body and headers, schema and order values, Location if applicable, persistence through a later GET, stock and total changes, and unwanted side effects. Repeat the request and determine whether it should create another order or be idempotent. A successful status with a wrong total is still a defect.
What it assesses: seeing status, contract, data and side effects as separate test layers.
Red flag: “201 means Created, so it works”, or checking only the green status in Postman.
5 What is the difference between authentication and authorisation?
Strong answer review
Authentication establishes who the user is through credentials, a token or a session. Authorisation decides what that user may do. Tests should include no token, an invalid or expired token, a valid token, another role and another user’s object id. In HTTP semantics, missing valid credentials normally produces 401, while a known user without permission gets 403, although private resources may deliberately be hidden behind 404.
What it assesses: identity versus permissions, roles and object ownership.
Red flag: checking that a UI button is hidden without sending the forbidden request directly.
6 How do a test case, a checklist and an exploratory session differ?
Strong answer review
A test case records preconditions, data, steps and an expected result. It is useful for a critical repeatable path, handover and audit. A checklist is shorter and lets the tester choose exact steps, which works well for a familiar area and fast regression. An exploratory session has a charter, risks and a timebox; learning, test design and execution happen together, producing notes, findings and questions. Choose the format by risk, product maturity and the cost of reproducibility rather than habit.
What it assesses: the purpose of each artefact and the ability to select an appropriate level of detail.
Red flag: calling exploratory testing random clicking or requiring a detailed test case for every check.
7 Which HTTP methods are safe and which are idempotent?
Strong answer review
A safe method is intended for read-only use: GET, HEAD, OPTIONS and TRACE should not change state at the client request. An idempotent method should have the same intended server effect after identical repetitions as after one call; safe methods plus PUT and DELETE are idempotent. HTTP gives no such general guarantee to POST or PATCH. A repeated DELETE may return a different status and a GET may still create a log entry: idempotency concerns the requested effect, not byte-for-byte identical responses or every internal side effect.
What it assesses: safe versus idempotent semantics, retry behaviour and why identical responses are not required.
Red flag: claiming every POST must duplicate data or every DELETE must return the same status.
8 How do you distinguish 400, 401, 403, 404, 409 and 422?
Strong answer review
400 covers a general client error such as malformed request syntax. 401 means valid authentication credentials are missing and includes a WWW-Authenticate challenge. 403 means the server understood the request but refuses it. 404 means the resource was not found or is deliberately hidden. 409 is a conflict with current resource state, such as an obsolete version or an email already in use. 422 means the content type and syntax are understood but the instructions fail semantic validation. The API contract selects the exact code; QA tests the contract for consistency rather than enforcing a favourite code.
What it assesses: status semantics, contract awareness and concrete examples that separate neighbouring codes.
Red flag: treating all 4xx responses as interchangeable or expecting 401 for an authenticated user who lacks permission.
9 How would you test a session and logout beyond clicking the button?
Strong answer review
First identify where the session identifier is stored and how it is sent. Check session rotation after login, Secure, HttpOnly and SameSite cookie attributes, no token in the URL, access before and after logout, replay of the old request, a second device, idle timeout and absolute timeout. Logout must invalidate the server session or refresh token according to the chosen model, not merely redirect the UI. Clearing localStorage alone does not prove that access was revoked.
What it assesses: the session lifecycle, direct request replay and multiple clients rather than only UI state.
Red flag: checking only that the user name disappeared or demanding the same token in both cookie and localStorage.
10 How would you find duplicate emails with SQL, and what comes next?
Strong answer review
A starting query is SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) FROM users GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1. Normalisation must follow the business rule; case and whitespace cannot be declared insignificant by the tester. Fetch the concrete rows next and compare tenant, status, deleted_at and creation time. Then test the write-side uniqueness constraint and two concurrent registrations. Finding existing duplicates does not prove that new ones are prevented.
What it assesses: GROUP BY with HAVING, deliberate normalisation and moving from data analysis to the source of duplicates.
Red flag: using DISTINCT, which hides duplicates, or deleting records before confirming the business rule.
Middle QA: priorities, uncertainty and product impact
Middle is not a larger vocabulary. Interviewers expect decisions under incomplete requirements, limited time and conflicting risks, plus clear communication of those decisions.
11 An API returned 202 Accepted. How do you test the asynchronous result?
Strong answer review
202 says the request was accepted, not completed. Check for a job identifier or status URL, valid transitions from queued to processing and completed or failed, an agreed timeout, repeated polling and the final business effect. Cover worker failure, duplicate message delivery, two identical commands and an unavailable dependency. The initial response must not promise success too early, and a final failure must be visible to the user and traceable by correlation id.
What it assesses: acceptance versus completion, eventual consistency, observability and duplicate delivery.
Red flag: ending the test at 202 or using a fixed sleep instead of polling an observable state with a timeout.
12 The backend changes an API field. How do you test backward compatibility?
Strong answer review
Identify every consumer and the promised contract: requiredness, type, format, nullability, enum and meaning. Run an old client against the new backend and, when rollout permits it, a new client against the old backend. Adding an optional field is often compatible; removing or renaming a field, changing its type or introducing a required enum value may break consumers. Test unknown-field handling, defaults, serialisation, versioning and contract tests. A migration plan needs an overlap period, usage telemetry for the old field and a removal date.
What it assesses: consumer-driven thinking, both compatibility directions and a gradual rollout plan.
Red flag: assuming every additive change is safe for strict parsers or testing only the current web client.
13 An automated test fails intermittently without a product change. What do you do?
Strong answer review
Keep the trace, screenshot, network data and logs from the exact run, then compare a passing and failing execution. Classify the likely source: waits and race conditions, shared data, order dependence, network, an external system, clock behaviour or a genuinely intermittent product defect. A rerun measures frequency but is not a fix. A quarantined test needs an owner, deadline and visible signal. Fix the condition with observable waits, isolated data or a stable contract instead of an unconditional sleep.
What it assesses: evidence-led diagnosis, flaky test versus flaky product and accountable quarantine.
Red flag: retrying until green or deleting the test before understanding the failure.
14 How do you test a feature behind a feature flag?
Strong answer review
Build a matrix for flag off and on, new and existing accounts, roles or cohorts, web and API, caches and multiple instances. Off must preserve the old behaviour; on must cover the new path and data migration. Check runtime switching, percentage rollout, cohort leakage, metrics and rollback. Once rollout is complete, remove the flag, dead branch and obsolete tests; otherwise the number of states grows without limit.
What it assesses: both states, segmentation, consistency, observability and the complete flag lifecycle.
Red flag: checking only the on state in one browser or forgetting existing data and rollback.
15 What should QA verify after a production deployment?
Strong answer review
Before release, agree on a small production smoke using read-only actions or safe synthetic data, dashboards, thresholds and rollback conditions. After deployment, verify health and version, a critical user path, 4xx and 5xx rates, latency, queues, a business metric and correlated logs. Compare against a baseline and separate release impact from normal noise. Record the time, version, checks, observations and the decision to continue rollout or roll back.
What it assesses: production safety, technical and business signals, and predefined stop conditions.
Red flag: experimenting on a real customer record or declaring success because the home page opens.
16 Release is tomorrow, but full regression takes two days. What do you do?
Strong answer review
I would collect the changes and affected areas, identify critical business flows and select tests by probability and impact. Smoke, changed functionality, money, access, data loss, integrations and defect-prone areas come first. I would state what remains uncovered and what residual risk the team accepts. If that risk is unacceptable, I would propose reducing release scope or moving the release.
What it assesses: risk-based selection, coverage transparency and useful options for the team.
Red flag: “I will stay late and test everything” without feasibility, or cutting cases at random.
17 A bug reproduces roughly once in ten attempts. How do you investigate it?
Strong answer review
I would record environment, account, data, time and exact sequence, then collect logs, Network data and a correlation id. I would vary one factor at a time: browser, network, repeated action, data volume and concurrency. I would compare successful and failed requests and measure frequency across a series. Even without stable steps, a high-impact issue deserves a report with evidence and a clearly labelled hypothesis.
What it assesses: experimental discipline, evidence collection and no invented causality.
Red flag: closing it as “cannot reproduce” after two tries, or presenting a guessed cause as fact.
18 The requirement says: “search must be fast and convenient.” How do you test it?
Strong answer review
I would turn the adjectives into measurable criteria: data volume, acceptable response time, searchable fields, partial matches, case, keyboard layout, typos, sorting and empty results. Before clarification I can explore current behaviour and risk, but I cannot call a subjective expectation a confirmed defect. The output is a list of product questions and draft tests with explicit assumptions.
What it assesses: requirement testability and the distinction between a question and a confirmed defect.
Red flag: deciding alone that “fast” means two seconds and reporting every deviation as a bug.
19 A CRM manager can see another manager’s client. How do you test and report it?
Strong answer review
I would use two accounts with the same role and an object owned by A. With B’s token I would request that id through the UI and directly through the API, then test read and update actions. The report includes both accounts, roles, object id, request and response, with personal data redacted. This may be Broken Object Level Authorization, so I would escalate it through the team’s security process.
What it assesses: horizontal authorisation, reproducibility and careful handling of sensitive data.
Red flag: reporting only the visible button, or attaching unredacted customer data to a broadly visible tracker.
20 A double-click creates two payments. What do you test besides the button?
Strong answer review
I would test rapid clicks, repeating the same HTTP request, retry after timeout, the same and a new idempotency key, concurrent requests and a retry from another device. At each step I would compare the API response, operation count and final balance. Disabling the button helps UX, but the backend must provide the guarantee because requests can be repeated without the UI.
What it assesses: idempotency, races and the difference between UI protection and a server guarantee.
Red flag: stopping at a disabled button and never replaying the request directly.
QA theory: 20 concepts that are easy to confuse
This is not a quiz on memorizing ISTQB wording. An interviewer may ask for a simple definition and then for a product example. Explain the distinction in your own words and show what decision it changes at work.
Topics follow the official CTFL 4.0.1 syllabus: objectives and principles, process, levels and types, static testing, test design, risk and completion. The questions and examples here are original, not official exam questions.
21How do QA, QC and testing differ?
Strong answer review
QA focuses on preventing problems in the way a product is built: requirements, acceptance criteria, reviews and team practices. QC evaluates the resulting product; testing is one way to do that. Job titles do not draw a strict boundary: a QA engineer may review a requirement and execute tests. For payments, clarifying rounding before implementation reduces the chance of a defect; checking the API total reveals a defect in the implemented product.
What it assesses: process versus product, and shared responsibility for quality.
Red flag: treating QA as a synonym for manual testing or promising a defect-free product.
22What activities make up a testing process?
Strong answer review
A context-dependent process includes planning, monitoring and control, analysis of the test basis, test design, preparation of data and environment, execution, evaluation against completion criteria and closure. These activities need not form a rigid sequence: exploration combines learning, design and execution. In a CRM, clarify who may convert a lead, model states and roles, prepare two accounts, run checks and communicate residual risk. A checklist and report may be more useful than a hundred detailed cases.
What it assesses: the difference between what to test and how to test, plus data and closure.
Red flag: reducing the process to writing cases, executing them and filing bugs.
23What is the difference between verification and validation?
Strong answer review
Verification asks whether the product meets specified requirements; validation asks whether the result meets the user’s real need. Both matter. An LMS rule might issue a certificate after a quiz score of 80%. A test verifies the rule, while user research may reveal that mandatory lessons must also be completed. Do not equate verification exclusively with static work or validation exclusively with running software: methods depend on context.
What it assesses: two different questions and formally correct but unsuitable behavior.
Red flag: reciting a slogan without an example or its limitations.
24Name the testing principles and explain the pesticide paradox.
Strong answer review
The classic seven: tests show defects, not their absence; exhaustive testing is impossible; early testing saves effort; defects cluster; unchanged tests become less effective; testing depends on context; and absence of detected defects is useless if the product misses user needs. The pesticide paradox describes how an unchanged suite stops finding new problems. Revisit regression tests using code changes, new risks and production evidence while retaining old checks that still matter.
What it assesses: a practical reason to update a suite, not just a memorized list.
Red flag: deleting all old tests or saying a green suite proves there are no bugs.
25How does a test level differ from a test type?
Strong answer review
A level describes the object and boundary: component, component integration, system, system integration or acceptance. A type describes the objective or quality characteristic: functional behavior, performance, security, usability and more. The same type can occur at different levels. Authorization can be checked in a unit policy test, API integration and browser flow. For a bank transfer, unit checks a fee, API checks transactionality, system tests balance and history, and acceptance checks the business rule.
What it assesses: where/what versus why, and security beyond end-to-end tests.
Red flag: listing smoke, regression and unit tests as equivalent points on one scale.
26What can static testing find before code runs?
Strong answer review
Static checks examine work products without executing the software under test: requirements, designs, tests and source code through review or analyzers. They can reveal contradictions, missing roles, unreachable branches and ambiguous criteria. In a CRM task, “a manager can see clients” does not specify own clients or all clients; a review question is cheaper than fixing a data leak after release. Dynamic tests still verify actual behavior; static work cannot replace them.
What it assesses: a defect in a requirement and QA involvement before execution.
Red flag: equating static testing only with linters or claiming it proves the app works.
27How do equivalence partitions differ from boundary values?
Strong answer review
Partitions group inputs expected to receive the same processing; one representative per group reduces the set. Boundary analysis selects transitions between ordered groups, where inclusion mistakes are common. For an integer range 1–99, groups include below, within and above the range, plus separate null, string and omitted values. Two-value boundaries are 0/1 and 99/100; a three-value approach adds 2 and 98. If zero means a special tariff, it is its own business partition.
What it assesses: a justified value set and numeric edges versus input types.
Red flag: listing 0, 1 and 2 without the rule and expected outcomes.
28When should you use decision tables and state-transition testing?
Strong answer review
A decision table fits an outcome determined by combinations: a discount is allowed only for an active customer on an eligible plan without overdue debt. Each row specifies conditions and an expected action; mark impossible combinations. State-transition testing fits behavior dependent on prior state and event: lead new → qualified → converted. Repeated conversion may be forbidden even with identical request fields. Check allowed, forbidden and repeated transitions and their side effects.
What it assesses: choosing a technique based on the shape of the rule.
Red flag: checking each condition separately while missing combinations or history.
29What is test coverage, and why is 100% line coverage not quality?
Strong answer review
Coverage is the fraction of elements checked in a chosen model: requirements, code branches, states, roles or risks. A percentage without its denominator says little. Full line coverage means lines ran; it does not prove useful assertions, all branches, negative cases or the user’s desired outcome. A useful report says 12 of 14 critical requirements and 4 of 5 roles were checked, naming the two uncovered areas and why. That makes residual risk discussable.
What it assesses: an explicit coverage model and honest gaps.
Red flag: treating a coverage percentage as product quality.
30How do you decide testing can stop?
Strong answer review
Agree completion criteria in advance: critical paths exercised, no unresolved blockers, known results and untested areas, assessed risk and a release-owner decision. A deadline affects scope but is not a quality criterion by itself. A double-charge defect is not made safe by 95% passing tests; a cosmetic issue might ship with documented residual risk. QA supplies evidence and a recommendation, not a unilateral “release approved” stamp.
What it assesses: exit criteria, open risks and decision ownership.
Red flag: “when no bugs remain” or “when all cases are run” without risk assessment.
31What is a test oracle, and where do expected results come from?
Strong answer review
An oracle is a source used to judge actual behavior: a requirement, agreed business invariant, API contract, independent calculation, previous version or another trusted system. It need not be a single document. For a bank fee, first establish rate, rounding order, currency and charge timing. Calculate an example independently of the API, then compare response, balance and statement. Copying the API output into an assertion only freezes an existing bug. If sources conflict, raise a question with the rule owner, record the assumption and risk, and do not invent an expected result. For undocumented UX, comparative research can inform a proposal, but a tester preference is not an approved requirement.
What it assesses: an independent oracle, conflicting sources and the limits of assumptions.
Red flag: using current implementation as the sole truth or calling a personal preference a defect.
32How do probability, impact and confidence shape testing risk?
Strong answer review
A risk is a potential problem with likelihood and consequences, not an already confirmed defect. Prioritize using recent code changes, dependency complexity, past incidents, users and data affected, and whether the effect can be reversed. Rare loss of money may outrank frequent cosmetic trouble. A 1–3 likelihood × impact score helps compare scenarios, but the arithmetic does not replace discussion. Record confidence separately: a new integration with no incident history may be dangerous precisely because it is poorly understood. A test plan should state not just the score but its reasoning, proposed check, residual risk and decision owner. Revise the ranking when new evidence arrives.
What it assesses: risk versus defect, likelihood and impact factors, and uncertainty.
Red flag: treating a subjective score as exact probability or checking only historically buggy areas.
33What is the defect lifecycle, and why retest a fix?
Strong answer review
Status names vary, but a defect is found, confirmed, assigned, fixed, awaiting verification, verified and closed or reopened. Duplicate, cannot reproduce, deferred and won’t fix need reasons. Retest checks the claimed fix on the correct build and data; regression checks nearby behavior for unintended effects. If a second click no longer creates two payments but retry after timeout still does, the issue is not fully fixed. Record build, steps and tested variants. Fixed in a tracker is a claim, not proof. If expected behavior changed, confirm the new rule with the product owner before closing the old finding.
What it assesses: status versus evidence, retest versus regression and reopening.
Red flag: closing after merge or checking only the original happy path.
34How do a human error, a defect and a failure differ?
Strong answer review
An error is a person’s mistaken action or decision: a developer might read “own clients” as “everyone in the department.” A defect is a flaw in a requirement, code, data or configuration introduced as a result. A failure is incorrect behavior observed during execution: manager B opens manager A’s client card. The whole chain is not always visible: a defect may remain dormant without the right role and data; a failure can involve environment or an external dependency. Report the observed failure and evidence without guessing the developer’s mental mistake. Later root-cause analysis may suggest better requirement reviews and access tests, but that is a team conclusion, not something proved by a screenshot.
What it assesses: cause, flaw and observed effect without invented causality.
Red flag: treating every failure as proof of a specific developer mistake.
35What questions do smoke, sanity and regression answer?
Strong answer review
Smoke is a short set of critical checks showing whether a build is viable for further testing. Sanity is a narrow check of a specific change and nearby behavior after a fix or small release; usage varies by team, so establish the local definition. Regression looks for unintended effects of changes on previously working behavior. After a discount fix, smoke might check sign-in, catalog and checkout; sanity checks the discount and its boundaries; regression covers promotion combinations, refund, old client and final total. These sets can overlap: do not run one test three times just to satisfy labels. Explain purpose, scope and what remains untested.
What it assesses: purpose, local terminology and an example without pointless duplication.
Red flag: claiming a green smoke run replaces change-impact analysis.
36How would you test “fast and reliable” as a non-functional requirement?
Strong answer review
Translate adjectives into observable criteria: p95 and p99 latency, acceptable error rate, data volume, concurrent users, measurement window, availability and recovery. A mean response time hides the slow tail. For CRM search, agree on database size, query mix and target p95 under a defined load; measure warm and cold cache separately. For reliability, test timeout, retry, idempotency and recovery of a queue after a dependency fails. A small QA environment is not production, so document its limits instead of making false SLO claims. Define the workload, metrics and pass/fail threshold before running the experiment.
What it assesses: measurable criteria, tail latency, workload and environment limits.
Red flag: treating one fast request or an average as proof of performance.
37How do you prepare test data without tests interfering with each other?
Strong answer review
Each scenario should know its initial state and own its data. For CRM, create synthetic accounts and clients with unique prefixes, set roles and owners through a setup API or fixture, and then clean them up or reset them using an agreed method. Do not rely on a fixed id that changes after another run. Parallel tests should not share one client or single-use promo code: one test may consume another’s limit. Check cleanup too, because a crashed test can leave contamination. If reset is unavailable, document run order and limitations. Mask tokens and personal data in logs; real clients are unnecessary for practice. Separately test shared state when concurrency is the actual purpose of the scenario.
What it assesses: controlled initial state, unique data, parallel runs and safe cleanup.
Red flag: hard-coding a shared id and calling a test reproducible because it passed locally.
38What does shift-left mean, and what are its limits?
Strong answer review
Shift-left means getting quality feedback earlier: requirement review, example-based acceptance criteria, static analysis, unit/component checks and contract tests before expensive end-to-end work. It does not mean testers must work before code exists or later checks disappear. In CRM, ask who sees a client after owner reassignment during planning, test policy and API, then walk the actual user path. Early checks are cheaper to diagnose but cannot reveal all production configuration, integration or human-use failures. Add post-release observability for access errors and failed workflows. Choose signals by risk and cost rather than where they sit in a fashionable pipeline.
What it assesses: concrete early actions and why system and production feedback remain necessary.
Red flag: declaring E2E unnecessary or moving all quality responsibility onto QA.
39When should a check live at unit, API/contract or E2E level?
Strong answer review
Use the least expensive level that reliably observes the risk. A unit check covers many fee-calculation boundaries quickly. API integration sees transaction writes, permissions, errors and idempotency. A contract check protects agreement between consumer and provider, including supported old clients. E2E shows that a user can complete a core journey and see the result. Do not repeat every value at every level: a few journey smoke checks connect components while combinations remain lower down. The test pyramid is not a law; payment integrations need sandbox checks and mocks alone do not prove the live provider contract. Every test needs an oracle, owner and sensible maintenance cost.
What it assesses: risk-to-level fit, no blind duplication and the limits of mocks.
Red flag: automating everything in a browser or treating unit coverage as integration proof.
40What should you say when requirements are incomplete or you do not know an answer?
Strong answer review
Separate facts from assumptions. If a CRM task says overdue items must stand out but omits timezone, transition moment and sorting, ask precise questions, propose a temporary assumption and checks for both reasonable interpretations. If you do not recall an exact HTTP status or tool command, explain the expected principle, identify the specification to consult and avoid inventing a rule. Interviewers assess your reasoning: risks noticed, experiment chosen, expected outcome and evidence. Update tests after the rule is clarified. “We need to agree on this before defining an oracle” can be a strong answer when the contract truly is missing; a confident guess is not.
What it assesses: handling uncertainty, testable assumptions and a concrete next step.
Red flag: inventing a universal rule or going silent rather than breaking down the problem.
How to review your mock-interview answers
Score the quality of the decision, not recognition of a term. For every question, ask whether you named context, a source of the expected result, concrete data and action, side effects and evidence for a deviation. “I will test the API” names no method, role, expected status or resulting state. “Use two managers, create A’s client, request its id with B’s token and check both denial and unchanged data” can become a real test. Do not award full marks for a risk named without a way to verify it.
For theory, use “distinction → example → limit”. Severity concerns harm, priority concerns repair order; another manager’s CRM card is serious even if rarely seen, but the team sets the deadline. If you can recite a definition yet cannot show its effect on a product decision, revisit it. If the example is strong but the exact phrase takes a moment, that is not failure: the workplace often values the decision more. Write down confused pairs and invent a counterexample for each.
Separate knowledge gaps from process mistakes. Not knowing what contract testing checks calls for reading the source and trying a small example. Knowing access control but forgetting to ask who owns the object calls for a habit of naming actors and states before choosing a request. Producing many tests without priority calls for a time limit and an explanation of the risk behind each first step. After one rehearsal choose only three weak topics. Try them again the next day without hints and check whether your answers now contain expected results and evidence.
Do not prepare only by memorizing model answers. Change the domain: replace bank transfer with lead conversion, or CRM with an LMS certificate. Then change the constraint: no database access, only one hour left, or a defect that appears under load. A strong answer preserves reasoning but changes checks and priority. That is understanding rather than recital. In a real interview you may honestly say a rule needs clarification; continue with a testable assumption, alternatives and a plan to obtain evidence. Try explaining one defect to three audiences: a developer needs steps, data and logs; a product owner needs user impact and workaround; a release owner needs likelihood, reach and residual risk. Keep facts consistent and vary only detail. If you cannot state briefly what failed and how you know, your investigation may have a gap. Verify claims against sources, not the confidence of your delivery.
Ten-minute API exercise
Requirement: a manager may read only their own clients. Without changing server data, design the smallest request set that verifies this rule. Then open the review.
GET /api/clients/{id}\nAuthorization: Bearer {token}\n\nmanager_a owns client 481\nmanager_b owns client 927
A good answer covers the boundaries of the access model, not one foreign id:
- A requests 481: expect 200 and A’s client data.
- B requests 927: expect 200 and B’s client data.
- A requests 927 and B requests 481: expect 403 or 404 according to the contract.
- No token and an invalid token: expect 401.
- Unknown id: verify the agreed 404 and that responses do not leak a difference between foreign and absent objects.
Show the answer rubric
The minimum is two positive and two crossed requests. A strong candidate adds missing authentication, an unknown id, mutation through PATCH/DELETE and checks for excessive response fields. An excellent candidate first asks whether a foreign object should return 403 or be hidden as 404 instead of inventing the contract.
Seven-day preparation plan
Common preparation questions
How long is a technical QA interview?
Often 45–90 minutes, but formats vary: theory, experience, scenarios, API or SQL, and sometimes a separate take-home task. It is reasonable to ask the recruiter for the structure in advance.
Does a Junior tester need SQL and Postman in 2026?
For many manual QA roles, a confident foundation is enough: read JSON, send requests with parameters and auth, inspect responses, and write SELECT with WHERE and a simple JOIN. Applying these skills matters more than naming commands.
Is it acceptable to say “I don’t know”?
Yes. State the boundary and explain how you would resolve it: clarify the contract, read documentation, reproduce a request or inspect a log. A confident invention is more dangerous than an honest gap.
How do I know I am ready?
You are ready when you can explain a decision without notes, name the expected result and ask useful questions about an unfamiliar scenario. You do not need perfect answers to every possible question.
Preparation is complete not when you have read a hundred answers, but when you can reason through a new task aloud: clarify it, choose the risk, propose a check and name the evidence.