Separate the layers. Page or component objects encapsulate selectors and low level interactions; a flow layer composes them into business actions like log in or complete checkout; tests contain only intent and assertions. Keep selectors in one place, prefer dedicated test identifiers over brittle CSS paths, and keep assertions out of page objects so failures point at the right layer.
Why interviewers ask this
UI suites collapse under their own weight when selectors and logic are scattered, so interviewers want to see that you treat test code as production code. The specifics they listen for are a single home for selectors, a flow layer above page objects, and keeping assertions in the tests. Mentioning dedicated test attributes instead of brittle CSS or XPath is a strong practical signal.
How to structure your answer
- Name the layers and what each one owns.
- Put every selector in one place per page or component.
- Argue for dedicated test identifiers over brittle selectors.
- Keep assertions in tests, not in page objects.
- Mention doing shared setup through the API rather than the UI.
Example answer
I treat test code as production code, so the same rules apply: no duplication, clear layers, meaningful names. At the bottom I have page or component objects that own selectors and the mechanics of interacting with that piece of the UI. Above that sits a flow layer for business level actions, so log in as a user with this role, or add an item and complete checkout, because those sequences get reused constantly and you do not want them copy pasted across forty tests. The tests themselves then read like the requirement, mostly method calls and assertions. I keep assertions out of page objects, because when a page object asserts, a failure tells you a page is unhappy rather than which behavior broke. On selectors, I push hard for dedicated test attributes agreed with the developers, because chasing CSS paths that change every time someone restyles a component is the main reason these suites get abandoned. And I do setup through the API wherever possible: if a test is about checkout, creating the account and cart over HTTP is faster and far less flaky than driving twelve screens to get there.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you stop page objects from turning into thousand line god objects?
- What would you do if developers refuse to add test identifiers?
- How do you share login state across tests without repeating the login flow?
Related qa engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions