What Interviewers Actually Probe For
Cypress interview questions typically fall into three buckets: fundamentals (commands, assertions, the command queue), architectural understanding (why Cypress behaves differently from Selenium, what its constraints are and why they exist), and practical troubleshooting (how you'd debug a flaky test, handle iframes, or test file uploads). Strong candidates don't just recite command syntax; they explain the reasoning behind Cypress's design, such as why cy.get() returns a chainable rather than a promise, because that understanding is what lets an engineer diagnose novel failures rather than just pattern-matching to memorized fixes.
Cricket analogy: A good selector doesn't just ask a bowler to recite their average; they ask how the bowler would set a field for a specific batter, testing understanding over memorized stats, similar to interviewers probing Cypress reasoning over rote syntax.
Core Concept Questions
A very common opener is: 'Is cy.get() a Promise? Why does that matter?' The correct answer is no — Cypress commands are enqueued onto an internal command queue and executed sequentially with automatic retries, which is why you cannot use async/await or .then()-chained plain JavaScript logic the way you would with a real Promise, and why mixing cy commands with synchronous JavaScript variable assignments (e.g., trying to store cy.get()'s value directly into a variable) is a classic beginner mistake — you must use .then() callbacks or aliases (cy.get(...).as('foo'), cy.get('@foo')) to work with values across the queue. Another frequent question asks candidates to explain the difference between cy.get() and cy.find(), or between should() and then(): should() re-runs its callback automatically as part of retry-ability whenever the subject changes, while then() runs exactly once, which matters when writing custom assertion logic that needs retry behavior versus one-off side effects like logging.
Cricket analogy: A bowler's over is a fixed queue of six deliveries executed in strict sequence rather than an unpredictable jumble, similar to Cypress commands being enqueued and run sequentially rather than as freely reordered Promises.
// Common interview trap: this does NOT work as expected
let text;
cy.get('[data-cy=title]').then(($el) => {
text = $el.text(); // wrong scope reasoning if used outside .then()
});
cy.log(text); // undefined! runs before the queued command resolves
// Correct approach using .then() chaining or an alias
cy.get('[data-cy=title]').then(($el) => {
const text = $el.text();
expect(text).to.eq('Welcome back');
});
// Alias approach
cy.get('[data-cy=title]').invoke('text').as('titleText');
cy.get('@titleText').should('eq', 'Welcome back');Architecture and Design Questions
Interviewers often ask why Cypress historically couldn't test two different superdomains in a single test, or why it can't easily interact with browser-native dialogs like window.confirm. The answer traces back to Cypress running inside the browser itself: the test code executes in the same origin context as the application by default, so navigating to a different origin previously required an explicit workaround (now solved with cy.origin()), and native OS-level dialogs like window.alert or file pickers exist outside the DOM and JavaScript context Cypress can control, so Cypress stubs window.confirm/window.alert automatically and requires special handling (like cy.stub or selecting files via cy.get('input[type=file]').selectFile()) instead of literally clicking an OS dialog button. A well-prepared candidate connects the constraint to the architecture rather than memorizing it as an arbitrary limitation.
Cricket analogy: A player confined to one ground can't simultaneously influence a match happening at a different stadium, similar to Cypress test code being scoped to a single origin's JavaScript context by default before cy.origin() existed.
A strong follow-up answer on native dialogs: Cypress automatically auto-accepts window.confirm and stubs window.alert so tests don't hang waiting for a real dialog. To assert a confirm was shown with specific text, use cy.on('window:confirm', (text) => { ... }) or cy.stub(win, 'confirm').returns(true) via cy.window().
Practical Troubleshooting Questions
A realistic scenario question: 'A test passes locally but fails intermittently in CI — how do you debug it?' A strong answer walks through a systematic process: first check the Cypress Cloud (or CI artifact) screenshots/videos for the failing run to see the actual DOM state at failure time; check whether the failure correlates with CI being slower (suggesting a missing wait on a network request rather than a genuine bug); check for test order dependency by running the failing spec in isolation; and check for environment differences such as viewport size, timezone, or seeded data differing between local and CI. Another common question covers testing file uploads and iframes: file uploads use cy.get('input[type=file]').selectFile('cypress/fixtures/photo.jpg'), while cross-origin iframes require either the cypress-iframe plugin or restructuring the assertion to use cy.origin() when the iframe content is same-origin-accessible.
Cricket analogy: A team analyst reviewing why a bowler performed differently under lights checks pitch conditions, ball wear, and dew factor systematically rather than guessing, similar to systematically ruling out causes of CI flakiness.
Be wary of the tempting but wrong 'fix' for a flaky test: increasing the default command timeout or sprinkling in cy.wait() calls until it passes. Interviewers specifically probe for this anti-pattern; the better answer is to find and fix the underlying race condition (usually a missing cy.intercept alias or an assertion on the wrong element).
- Explain the Cypress command queue and why cy.get() is not a Promise — commands enqueue and retry, they don't resolve like async/await.
- Know the difference between should() (re-runs on retry) and then() (runs once) for building assertions vs side effects.
- Be able to explain Cypress's same-origin architecture and why cy.origin() exists for cross-domain flows.
- Understand that native browser dialogs (confirm/alert) are auto-stubbed by Cypress rather than clickable like DOM elements.
- Have a systematic debugging process ready for 'passes locally, fails in CI' questions: artifacts, timing, isolation, environment diffs.
- Know practical mechanics: file uploads via selectFile(), iframe handling via cypress-iframe or cy.origin().
- Avoid presenting cy.wait(<number>) or timeout inflation as a fix for flakiness — identify and explain interviewers watch for this.
Practice what you learned
1. Why does cy.get() not behave like a JavaScript Promise?
2. What is the key difference between .should() and .then() in Cypress?
3. Why did Cypress historically require special handling to navigate between two different origins in one test?
4. How does Cypress handle native browser dialogs like window.confirm?
5. What is considered an anti-pattern answer when asked how to fix a test that passes locally but fails intermittently in CI?
Was this page helpful?
You May Also Like
Cypress Best Practices
A practical guide to writing Cypress tests that are fast, resilient to UI changes, and free of the flakiness that erodes trust in a test suite.
Cypress vs Selenium vs Playwright
A technical comparison of the three major browser automation tools, covering architecture, language support, speed, and when each is the right choice.
Cypress Quick Reference
A condensed reference of the most-used Cypress commands, assertions, network mocking patterns, and configuration options for day-to-day test writing.