QA Automation Interview Prep: Choose What to Study Before Learning Another Tool

When QA interviews go badly, it is tempting to add another framework to your study list. That may help if the next role requires it. It may also consume the time you needed to practice explaining test choices, debugging a failure, or writing a small piece of code without following a tutorial.

Recent public questions show candidates trying to make this decision: one tester described several unsuccessful interviews and uncertainty about learning AI testing, while another discussion asked which automation skills to prioritize. A separate SDET preparation question focused on uncertainty about coding and design depth. These accounts support a preparation problem; they do not establish a universal hiring standard or explain why any individual was rejected.

Choose the next study task from evidence

• Pick one actual role and its next interview stage.
• Confirm the assessment format, language requirements, available time, and permitted tools.
• Attempt one realistic task before opening a course.
• Classify the difficulty: knowledge, implementation, investigation, explanation, or role mismatch.
• Use the next study session to repair that specific gap, then repeat the task with a variation.

Keep this plan small enough to finish. A preparation list covering every automation tool, cloud platform, algorithm category, and AI framework cannot tell you what to practice tonight.

Clarify what this role actually asks you to do

QA Engineer, Automation Engineer, and SDET titles can describe different combinations of work. Read the responsibilities and the assessment brief together. Identify the output the employer wants: investigating product behavior, maintaining an existing suite, building test infrastructure, or writing production-like utilities. Avoid assigning a universal definition to a title.

A useful message to a recruiter is: “To prepare for the next stage, could you confirm whether it includes live coding, adding tests to an application, test design, or framework discussion? Is a particular language required, and may I use documentation? Should I bring an existing project?” This requests the format, not advance access to assessment questions. If no answer arrives, prepare the core activity stated in the invitation and keep your assumptions visible.

Many interviews combine these activities. The table helps you choose a starting point; it does not imply that a lead never codes or that an automation engineer never designs exploratory testing.

Run a 15-minute diagnostic before choosing a course

This complete, fictional exercise tests state, assertions, and investigation. It uses Python 3 and its standard library, with no packages, network, or database. Copy the first block into a new file named diagnostic.py. If Python is unfamiliar, trace the code or translate the exercise into your usual language; unfamiliar syntax alone does not diagnose your readiness for another stack.

Contract: a booking object starts empty. Reserving a new name succeeds only while capacity remains. Duplicate names and attempts beyond capacity return False without changing bookings. Capacity may be zero. For this exercise, capacities are already validated nonnegative integers and names are nonempty, case-sensitive strings. Persistence, input validation, and concurrent requests are outside scope.

1. Minutes 0–3: predict both tests' outcomes. Write the expected booking set before each test starts.
2. Minutes 3–7: run the whole file, then the capacity test alone. Identify the first failing assertion and explain the difference before changing code.
3. Minutes 7–11: repair the test setup without changing the booking contract. Add a duplicate-name case and a zero-capacity case. Check state as well as return values.
4. Minutes 11–15: rerun, explain why your repair works, and identify one important behavior this exercise does not test.

import unittest


class SeatBook:
    def __init__(self, capacity):
        self.capacity = capacity
        self.booked = set()

    def reserve(self, name):
        if name in self.booked or len(self.booked) >= self.capacity:
            return False
        self.booked.add(name)
        return True


class SeatTests(unittest.TestCase):
    book = SeatBook(2)  # Deliberately shared test setup.

    def test_01_normal(self):
        self.assertTrue(self.book.reserve("Ada"))
        self.assertEqual(self.book.booked, {"Ada"})

    def test_02_capacity(self):
        self.assertTrue(self.book.reserve("Ben"))
        self.assertTrue(self.book.reserve("Chen"))
        self.assertFalse(self.book.reserve("Dee"))
        self.assertEqual(self.book.booked, {"Ben", "Chen"})


if __name__ == "__main__":
    unittest.main()

Run these as separate commands in the folder containing the file:

python3 diagnostic.py -v
python3 diagnostic.py SeatTests.test_02_capacity -v

Before reading the answer below, record: your prediction; the observed result; the cause you suspect; and the smallest observation that would distinguish a test problem from a product problem. Running the command again without changing conditions is not a diagnostic by itself.

Answer key: the failure is in shared test setup

With the supplied file, the full run executes two tests and reports one failure: reserving Chen returns False. The first test left Ada in the class-level booking object. The second adds Ben, filling both seats. Run alone in a fresh process, the capacity test passes because the shared object starts empty. These are the expected results of the deliberately flawed fixture, not intermittent product behavior.

The product is following its contract. Increasing capacity or removing the assertion would hide the isolation problem. Replace the entire SeatTests class with this version, leaving SeatBook and the final unittest.main() block unchanged:

class SeatTests(unittest.TestCase):
    def setUp(self):
        self.book = SeatBook(2)

    def test_01_normal(self):
        self.assertTrue(self.book.reserve("Ada"))
        self.assertEqual(self.book.booked, {"Ada"})

    def test_02_capacity(self):
        self.assertTrue(self.book.reserve("Ben"))
        self.assertTrue(self.book.reserve("Chen"))
        self.assertFalse(self.book.reserve("Dee"))
        self.assertEqual(self.book.booked, {"Ben", "Chen"})

    def test_03_duplicate(self):
        self.assertTrue(self.book.reserve("Ada"))
        self.assertFalse(self.book.reserve("Ada"))
        self.assertEqual(self.book.booked, {"Ada"})
        self.assertTrue(self.book.reserve("Ben"))
        self.assertEqual(self.book.booked, {"Ada", "Ben"})

    def test_04_zero_capacity(self):
        book = SeatBook(0)
        self.assertFalse(book.reserve("Ada"))
        self.assertEqual(book.booked, set())

The corrected full run reports four tests and OK. The capacity test alone still reports one test and OK. Python's unittest documentation describes setUp() running before each test method. Here it supplies a fresh object for every test, so the earlier test cannot consume a later test's seats.

The added duplicate test checks refusal, unchanged state, and the remaining usable seat. The zero-capacity test checks refusal and an empty booking set. A passing return-value assertion alone would miss an implementation that rejected a name but still changed the stored state. These cases do not establish thread safety or durable storage; neither is implemented in this in-memory example.

Worked example: allocate eight hours before a practical interview

Fictional planning example: Maya has manual QA experience and has contributed Java/Selenium tests. Her invitation says she will add tests to a supplied web application, run them, and discuss decisions. The recruiter confirms that her familiar stack is acceptable. Maya has eight preparation hours and no evidence that AI evaluation or system design is part of this stage.

That totals eight hours. Use the diagnostic to identify which block needs the most attention, then practice in the actual interview stack. This is a proposed allocation, not a guaranteed formula. If the employer instead requires TypeScript and Playwright, Maya should first attempt the smallest required task in that stack. The result will show whether eight hours is enough for focused translation or whether she needs to discuss readiness and expectations. She should not claim production experience with a tool she has only studied.

Transfer the diagnostic to the actual interview task

Choose a project you are authorized to show. Explain the behavior, setup, action, and expected result before running it. Then distinguish a product failure from a test failure and state what a pass leaves untested. If you propose a repair you have not implemented, label it as a proposal.

For a Playwright interview, review one actual check against its official guidance on isolation, locators, and waiting assertions. Its retry documentation distinguishes a first-attempt pass from a test that only passes on retry. Preserve that distinction in your report. The small Python exercise trains investigation habits; you still need to demonstrate the tools and environment named in the brief.

Decide whether AI testing belongs in this preparation cycle

Separate two questions: does this role expect you to use an AI assistant while creating tests, and does it expect you to evaluate a product that contains AI? Those are different tasks. Ask which is relevant when the job description is ambiguous.

If the assessment focuses on an ordinary application workflow, repair the missing test-design, programming, or investigation skill first. If the role explicitly tests model behavior, add a bounded evaluation exercise with stated expected behavior and failure criteria. A new specialty deserves deliberate study; it should not become an automatic response to a rejection whose cause you do not know.

Turn the plan into three concrete practice sessions

• Attempt the CI-only failure investigation. Before reading the answer, list the observations that would distinguish your leading hypotheses.
• Attempt the framework design exercise. Check that your proposal fits the supplied team, runtime, and existing-stack constraints.
• Record your answer to explaining readiness for an automation role. Every claimed contribution should be something you actually did; learning plans should sound like plans.

These questions belong to the QA and Test Automation collection; full answers may require account access or a subscription. Use the exercise results to choose your next session. You are ready for a better rehearsal when you can complete a relevant task, explain the choices, and respond honestly when the requirements change.