Explain your framework

"Walk me through your framework" is asked in nearly every automation interview. A framework here means the code and tools around your tests: how tests are organized, how browsers start, where data and settings live, and how results reach people. The interviewer wants to see that you understand how the pieces fit and what you personally did. A fixed structure keeps you clear under pressure. Describe only what you really used, because each detail you mention can become the next question.

Know the layers first

Most pytest frameworks have the same layers, whatever the company. Each layer calls the one below it, and fixtures in conftest.py connect them:

If you can draw your own version of this picture with real file and fixture names, you can explain it.

How to answer in an interview: the two-minute structure

1. Type and stack, in one sentence.
2. Layers and folders.
3. One test from collection to report.
4. Data and configuration.
5. Reports and CI.
6. Your part, with one problem you solved.

A filled example

The text below shows the shape of a good answer. It is an example, not a story to copy; swap in your real tools, names and numbers. Some words in it are explained on other pages: pytest-xdist runs tests in parallel and a Grid session is a browser on another machine (Parallel and CI runs), and a report hook is a function pytest calls after each test (Reports, screenshots and logs). The requests library lets Python call APIs, Allure makes reports, and GitHub Actions is a CI server that runs your tests automatically.

"It is a pytest framework: Python 3.12, Selenium 4, pytest with pytest-xdist and allure-pytest, the requests library for API set-up, and GitHub Actions for CI.

The repository has tests, grouped by feature; pages, one class per screen plus components like the header and the data table; api, a small client for set-up and clean-up; and utils with wait helpers and data loaders. Fixtures live in conftest.py: the browser, configuration, the API client and logged-in pages. Config files per environment and test data files sit beside them.

A test runs like this: pytest collects it and applies the marker filter; the driver fixture builds Chrome, Firefox or a Grid session from command-line options; a fixture creates the test's data through the API; the test calls page methods and asserts; a report hook marks failures, and the driver fixture attaches a screenshot to Allure before quitting the browser.

--env picks the config file, data comes from JSON through parametrize, and passwords come from GitHub secrets as environment variables. Pull requests (proposed code changes that teammates review) run -m smoke, a short set of the most important tests; the nightly job runs everything with -n 4, publishes the Allure report and posts a summary.

My part: I replaced shared test accounts with per-test users created through the API. That removed most of our random failures and let us turn on parallel runs."

How to prepare your own version

Trace one real test through every layer, naming real files and fixtures, and know which fixtures depend on which. Know your numbers: test count, run time, schedule and failure rate. Have one improvement you made and one thing you would change. Practice to about two minutes, then pause and let the interviewer choose.

Follow-ups to expect

• "How do you run tests in parallel?" pytest-xdist with -n, a function-scoped driver fixture, unique data, and the fact that session fixtures run once per worker.
• "Why pytest?" Fixtures, plain assert, parametrize, markers and plugins.
• "How does the browser get created and closed?" A factory function builds options and returns a local or remote driver; the fixture yields it and quits it afterwards, even when the test fails.
• "How do you take screenshots on failure?" The pytest_runtest_makereport hook plus the driver fixture's teardown.
• "How do you handle flaky tests?" Spot them in CI history, reproduce with repeats, fix the cause; reruns only as a tracked safety net.
• "Where do you use OOP?" (object-oriented programming) Page classes that inherit from a base page, components, and data classes (classes that mostly hold fields) for test data.

The other questions in this round

The same round often asks a few related questions. Short, structured answers work best:

• "Design a framework from scratch": ask first (app type, team language, CI tool, browsers), agree the test mix with the team, then build the layers above and start with a few valuable tests running in CI.
• "What do you automate?": checks that run often, guard high-risk flows and are stable. Exploratory and usability testing stay manual.
• "How do you split UI, API and unit tests?": the test pyramid. Test each rule at the lowest level that can catch it, and keep UI tests for the main journeys.
• "Is automation paying off?": time saved minus maintenance, time from commit to result, regressions caught, and the share of failures that are real bugs.
• "A challenge you faced" or "a tool you built": situation, cause, action and result, with a number if you have one.

Common mistakes

• Listing libraries without explaining how they connect.
• Describing a tutorial framework instead of your own.
• Skipping CI and reporting.
• Taking credit for a whole framework you joined late. "It existed when I joined; I added..." is fine, and interviewers trust a precise answer about a small part more than a vague answer about everything.

Recap

Know your layers and fixtures, then answer in six parts: stack, layers, one test end to end, data and config, reports and CI, and your own part. Use real names and numbers, stop at about two minutes, and be ready for follow-ups on parallel runs, the driver fixture and flaky tests.