AI SDET Interview Prep: Python & Playwright Q&A

Forget the fairy tales you hear about SDET interviews—they're not just about clicking buttons in Selenium anymore. Especially if you're aiming for a strong AI company, they expect you to code, to debug, and to think like an engineer, not just a QE tester. This isn't your grandpa's QA. I've sat through enough of these loops to know what's real: they want someone who can build intelligent testing frameworks, often in Python, and who understands modern web automation. So, if you're prepping for an AI SDET interview, let's talk about Python and Playwright, because that's where the rubber meets the road.

Python Fundamentals: Beyond LeetCode Easy

You must know Python cold. I'm not talking about just coding up a FizzBuzz solution and calling it a day. They're looking for practical application of data structures and algorithms, specifically how they'd aid in testing scenarios. Think about how you'd use a dict to store test data permutations, or a set to quickly check for duplicate elements in a large dataset of API responses.

Expect questions that combine language features with problem-solving. A common one I've seen: "You have a log file with millions of entries. Each entry is a JSON string representing an event. How would you count the occurrences of a specific event_type without loading the entire file into memory?" This isn't a trick question; it's about iterator protocols, generators (yield keyword!), and efficient file parsing. You'll need to know context managers (with open(...)) for robust file handling. Don't just regurgitate definitions; show them how you'd use these concepts to solve a real-world problem.

Another area they probe deeply is object-oriented programming (OOP). You'll likely get asked to design a basic system, like a "Test Report Generator" or a "Page Object Model for an E-commerce Site." This isn't about memorizing design patterns, it's about demonstrating encapsulation, inheritance, and polymorphism in a practical context. How would you represent different types of test cases? How would you structure your test suite to be maintainable and extensible? Show them you understand __init__, self, class methods, and instance methods. They're trying to see if you can build something that won't collapse under its own weight after a few thousand lines of code.

Playwright Mastery: Not Just "Click and Type"

Playwright is the tool of choice for many AI companies because it's fast, reliable, and supports multiple browsers. If your experience is solely with Selenium WebDriver, you need to dedicate serious time to Playwright. It's not just a syntax swap; the asynchronous nature and powerful auto-waiting capabilities fundamentally change how you write tests.

They'll expect you to write actual Playwright code during the interview, often live-coding. Be ready for scenarios like: "Automate logging into this dummy website, fill out a form with specific data, click a submit button, and verify the success message." Simple, right? But then they'll add twists: "What if the button takes 5 seconds to appear? How do you handle dynamic IDs? How do you ensure the page has fully loaded before interacting with an element?" This is where Playwright's locators, explicit waits, and expect assertions come into play.

You should be comfortable with:

• Locators: page.locator('text=Login'), page.getByLabel('Username'), page.locator('#submit-button'). Understand the hierarchy and best practices. XPaths are a last resort, not a first choice.
• Actions: fill(), click(), press(), select_option(), check().
• Assertions: expect(locator).to_be_visible(), expect(page).to_have_url(), expect(locator).to_have_text(). These are your bread and butter for verifying application state.
• Contexts and Browsers: How do you set up a new browser context? How do you handle multiple tabs or windows? How do you run tests in headless mode versus headed mode?
• Network Requests: This is huge for AI SDET roles. How do you intercept API calls with page.route()? How do you mock network responses to test specific error conditions or data payloads? This skill separates the basic automators from the true SDETs.

Practice writing full end-to-end tests from scratch. Don't just watch tutorials; actually build something. Clone a public repo with a web app and try to write a comprehensive test suite for it.

Beyond UI: API Testing and Data Validation

Many AI applications are heavy on APIs. Your interviewers will absolutely expect you to test these directly, not just through the UI. This means using Python libraries like requests for making HTTP calls. Know your HTTP methods (GET, POST, PUT, DELETE), status codes (200, 400, 500), and how to send JSON payloads.

A typical scenario: "You have an API endpoint that creates a new user. How would you test it? How do you verify the data persisted correctly? What if the API returns an error? How do you handle authentication?" This involves making a POST request, parsing the JSON response, perhaps making a subsequent GET request to verify creation, and asserting on specific fields. They might throw in authentication challenges like OAuth or API keys. Understand how to include headers in your requests.

Data validation is critical here. After calling an API, how do you ensure the response matches the schema you expect? You might talk about using Pydantic for schema validation, or writing custom validation functions. Consider edge cases: what happens with malformed input? What about excessively long strings or negative numbers where positive are expected? This demonstrates a thorough testing mindset.

Test Frameworks and Structure: Pytest is Your Friend

Knowing how to write a single script is one thing; building a scalable, maintainable test suite is another. Pytest is the de-facto standard in the Python testing world, and you must be proficient with it.

They'll ask about test organization, fixtures, and parameterization. Can you explain why pytest.fixture is better than setting up resources in each test function manually? How do you use conftest.py to share fixtures across your test suite? How would you run the same test with 100 different input values using pytest.mark.parametrize?

Consider this: "You're building a test suite for an e-commerce site. How would you set up a test user for each test that needs one, and tear down their data afterwards, ensuring clean test isolation?" This is a classic fixture problem. You'd create a user_fixture that yields a user object, then cleans up the user data in its finally block or after the yield.

They also want to see how you structure your test directories. Keeping tests separate from source code, organizing by feature, and using clear naming conventions (test_something.py). This isn't just aesthetics; it impacts discoverability and maintainability for future engineers.

SDET Mindset: Debugging, Performance, and Observability

This is where you differentiate yourself from a pure developer. An SDET doesn't just write tests; they think about the quality of the system.

Debugging: Expect to walk through debugging scenarios. "A test is failing inconsistently. How would you approach debugging it?" Your answer should involve:

1. Reproducibility: Can you make it fail consistently?
2. Logs: What information are your application logs giving you?
3. Playwright Tracing/Screenshots/Videos: How do you use Playwright's built-in tools to see what happened during the UI interaction?
4. Stepping through code: Using an IDE debugger (pdb in Python) to inspect variables.
5. Network inspection: Looking at browser dev tools or proxy logs to see API calls.

Performance Testing: While often a separate role, an AI SDET should have a basic understanding. "How would you measure the response time of a critical API endpoint within your existing test framework?" You'd use time.perf_counter() or similar Python timing functions around your requests calls and log the results. They're not looking for expert-level JMeter knowledge, but rather an awareness of performance as a quality attribute.

Observability in Tests: How do your tests report what's happening? Beyond simple pass/fail, how do you provide actionable insights? Think about logging detailed information, attaching artifacts (screenshots, HAR files), and integrating with reporting tools. What if a test fails; what information do you provide to the developer to help them fix it quickly? This is where your test reports become valuable engineering tools, not just checkboxes.

This often depends on the specific team's maturity and the product's complexity. A smaller startup might expect you to wear more hats, including deeper performance analysis, while a larger organization might have dedicated performance engineers. Tailor your focus based on the job description and company research.

Practice, Practice, Practice

You won't get good by just reading. Seriously, allocate time. Set a goal: "I'll spend 2 hours every day writing Python code and Playwright tests for the next three weeks."

1. Mock Interviews: Find someone (a friend, a mentor, or even an AI tool) to run mock interviews with you. Get used to explaining your thought process out loud. This is invaluable.
2. Coding Challenges: Focus on problems that involve parsing data, manipulating strings, working with dictionaries/lists efficiently, and designing simple classes. Don't just solve them; optimize them and explain your choices.
3. Build a Project: Pick a small web app (maybe a to-do list, or a demo e-commerce site) and build a comprehensive test suite for it using Playwright and Pytest. Include UI tests, API tests, and some data validation.
4. Review Code: Look at open-source Python testing frameworks and Playwright tests. See how experienced engineers structure their code.

Remember, the goal isn't just to pass the interview, it's to demonstrate that you can be a valuable, autonomous engineer who improves the quality of their AI products. Show them you can think, debug, and build.

Ready to Ace Your Next Interview?

Practice with AI-powered mock interviews tailored to your target role and company. Start Practicing for Free | Explore Interview Prep