Interview questions / UI Automation
Cypress has its own execution model: commands are queued, not awaited. Interviewers probe that model, plus network stubbing and test isolation.
5 questions · 1 beginner· 3 intermediate· 1 advanced
beginner 0–2 yrs
Selenium drives the browser from outside via the WebDriver protocol. Cypress runs test code inside the browser next to the app, with a Node.js process for tasks and network proxying. That gives automatic retries, network control and time-travel debugging, at the cost of multi-tab and cross-origin limits.
Full answer with examplesintermediate 2–5 yrs
Cypress commands are not promises. Calling cy.get() enqueues a command and returns a chainable immediately; Cypress runs the queue later with retries. Use .then() to work with yielded values, aliases to share them, and cy.wrap() for real promises, instead of await.
Full answer with examplesintermediate 2–5 yrs
Register cy.intercept before the action that triggers the request, alias it, then cy.wait('@alias') to synchronise and assert on the request and response. Pass a response or fixture to stub it, or use a handler with req.reply / req.continue to modify traffic. Keep some tests unstubbed end to end.
Full answer with examplesintermediate 2–5 yrs
With testIsolation on (the default), Cypress clears cookies, localStorage, sessionStorage and the page before each test, so tests can't depend on each other. cy.session() caches and restores a logged-in session per id, with a validate callback, so you log in once (ideally via API) without sharing state.
Full answer with examplesadvanced 5+ yrs
Reproduce and classify the failure, then fix the cause: understand which commands retry (queries and assertions) and which don't (actions, .then), avoid detached-DOM errors by re-querying after re-renders, synchronise on network aliases not cy.wait(ms), isolate data, and use test retries only as a signal, not a cure.
Full answer with examplesCypress runs inside the browser alongside your application, while Selenium and Playwright drive the browser from outside through a protocol. That architectural choice explains most Cypress behaviour, and interviewers use it to separate people who have read the API from people who understand it. Expect to be asked how Cypress differs from Selenium, what the trade-offs are (fast feedback and automatic retries, but historically limited multi-tab and cross-origin support), and when you would choose it.
Cypress commands are not promises. cy.get('[data-cy=total]') does not find anything when it is called; it adds a command to a queue that Cypress runs later, retrying queries and assertions until they pass or time out. That is why const el = await cy.get(...) does not work and why async/await is not supported for Cypress commands. Values are passed along the chain instead:
cy.get('[data-cy=total]').should('have.text', '$42.00') retries the query and the assertion together..then((el) => …) gives you the yielded value, but code inside .then does not retry..as('total')) share values between commands; cy.wrap() brings a real promise into the queue.cy.intercept to wait on, spy on and stub network requests: register it before the action, alias it, then cy.wait('@alias') instead of a fixed cy.wait(2000).cy.session caches a login so you do not repeat it through the UI.When asked how to wait for data to load, a weak answer is cy.wait(3000). A strong one registers cy.intercept('GET', '/api/orders').as('orders') before visiting the page, waits with cy.wait('@orders'), asserts on the response status, and then lets a retrying assertion such as cy.get('[data-cy=order-row]').should('have.length', 3) confirm the UI. The answer shows that you know which Cypress commands retry and that synchronisation should be tied to an event, not a duration.
Interviewers also like to hear why data-cy or data-testid attributes are recommended for selectors in Cypress projects: they are stable through styling changes and make the test intent clear, although user-facing text and roles are still worth asserting on.
SDETRole does not have a Cypress lab yet. Read the Cypress basics lesson, work through the questions above, and practise the transferable skills (choosing user-facing locators, writing retrying assertions, synchronising on network calls) in the Playwright practice lab, whose challenges check that your selectors and assertions really work. The automation tool comparison lesson helps with the "why Cypress?" question.