Cypress Interview Questions: 7 Topics Every SDET Must Conquer Before the Panel (2026)

Your SDET interview is tomorrow and Cypress is on the job spec. Learn the 7 critical Cypress topics interviewers actually probe — command chaining, intercept & stubbing, component testing, CI/CD with Cypress Dashboard, Cypress vs Playwright vs Selenium, and the architectural thinking that turns a test writer into a test engineer. Mitchell Agoma's 20-year guide from HMRC, MoD, Nationwide, and Accenture.

Published 4 August 2026 • By Mitchell Agoma

It is 11:38pm. You are staring at the job description for a Senior SDET role at a fintech company in London. The salary range is £85,000–£105,000. The tech stack lists six frameworks, but one of them keeps drawing your eye back: “Proficiency with Cypress for end-to-end test automation.” You have used Cypress. You have written cy.get() commands, you have run npx cypress open, you have debugged tests in the Cypress runner. The problem: you do not have a structured, architectural answer to the questions that are coming. “How does Cypress handle network requests differently from Selenium, and what are the implications for test design?” “Walk me through how you would stub an API response with cy.intercept() and why that matters for test reliability.” “Design a Cypress test suite for a React app with 50 screens — what patterns would you use, what would you stub, and how would you keep the suite under 10 minutes in CI?” Your cy.get('.login-button').click() instincts are not going to answer those.

Mitchell Agoma has watched this gap claim strong SDET candidates across 20 years of hiring at HMRC, the Ministry of Defence, Nationwide, Accenture, Asda, the Co-op, and BT. The candidate who writes elegant Playwright tests with auto-waiting and network interception is asked “we use Cypress here — how would you adapt your approach?” and gives a generic answer about end-to-end testing frameworks. The candidate who has been working with Cypress for three years cannot explain why Cypress runs inside the browser, what that means for cross-origin testing, and when Cypress is the wrong tool for the job. And the candidate who says “I use cy.intercept() to stub API calls” cannot articulate the difference between stubbing for speed, stubbing for reliability, and stubbing for test coverage — and the panel hears someone who copies patterns from blog posts without understanding why they work. The gap is not knowledge of Cypress commands — every candidate knows cy.get(), cy.click(), cy.should(). The gap is architectural thinking about Cypress: the command-queue execution model, the network-traffic-control layer, the component-testing-vs-E2E decision, the pattern for organising 500 tests across 50 screens, and the CI/CD strategy that makes Cypress tests fast enough to run on every PR.

Here is what keeps Mitchell’s SDET candidates awake — and what should keep you awake: in 2026, Cypress remains one of the three dominant browser automation frameworks, installed over 7 million times per month on npm. Companies like Shopify, Atlassian, GitLab, and the UK Government Digital Service run Cypress at scale. Every SDET job description at mid-to-senior level now lists Cypress alongside Playwright and Selenium — and the interview panel expects you to discuss Cypress with the same architectural depth you bring to Playwright. Can you explain why Cypress’s in-browser architecture is both its greatest strength and its most significant limitation? Can you design a Cypress test strategy that distinguishes between what you test in Cypress (critical user journeys), what you test at the API layer (business logic, edge cases), and what you test at the component level (individual UI behaviours)? Can you discuss the trade-offs between Cypress, Playwright, and Selenium — not as a fan of one tool, but as an engineer who selects the right tool for the job?

The SDET Interview Coach iOS app — with 800+ questions across 32 topics, Claude-graded mock interviews from Junior to Lead, and dedicated modules on Cypress E2E testing, component testing, cy.intercept() stubbing, and Cypress Dashboard CI/CD — gives you the structured practice to discuss Cypress with the architectural depth that senior panels demand, for £4.99 per month. And the AI Test Automation Playbook (£9.99) includes a complete chapter on building Cypress test suites that scale — covering custom commands, test data factories, network stubbing strategy, and CI/CD pipeline design. Do not walk into your interview knowing only how to call cy.get(). Walk in knowing how to design a Cypress test architecture that catches bugs before users do.

What Interviewers Are Actually Testing When They Ask About Cypress — It Is Never “Do You Know the Commands?”

When an interviewer asks “tell me about your experience with Cypress,” they are not checking whether you can write cy.get('.selector').click(). A candidate who says “I use Cypress for all my E2E tests — it is easy to set up and the test runner is great” has signalled they use Cypress at a surface level. What the interviewer is actually testing is whether you understand Cypress as an architectural choice — a framework with a specific execution model, a specific network layer, and specific trade-offs that make it the right tool for some problems and the wrong tool for others.

Signal 1: You Understand the Cypress Architecture — It Runs Inside the Browser

The strongest candidates can explain the single most important architectural fact about Cypress: it executes inside the browser, in the same event loop as the application under test. This is fundamentally different from Selenium (which drives the browser externally via WebDriver) and Playwright (which controls the browser via the Chrome DevTools Protocol). “Cypress runs in the same JavaScript context as your application. There is no network bridge between your test code and the DOM — your cy.get() commands have direct, synchronous access to the application’s DOM, event system, and timers. This architecture gives Cypress three unique capabilities. First: real-time DOM inspection — the test runner shows you exactly what the DOM looked like at each command, with before-and-after snapshots, because Cypress was literally inside the DOM when the command executed. Second: native control over JavaScript timers — cy.clock() and cy.tick() let you control setTimeout/setInterval directly, which is impossible from outside the browser. Third: network traffic control — because Cypress is in the same JavaScript context, cy.intercept() can intercept, stub, and modify every HTTP request and WebSocket message the application makes, at the network layer, before they leave the browser. But this architecture comes with trade-offs. Cypress cannot drive multiple browser tabs simultaneously. Cross-origin navigation requires cy.origin(). You cannot test WebAssembly-heavy apps or apps that use iframes from different origins without significant workarounds. Cypress also uses a command-queue model: cy.get() does not execute immediately — it queues the command and Cypress executes the queue asynchronously. Understanding this async-queue model is essential to understanding why Cypress commands are not Promises, why you cannot use async/await with Cypress commands, and why test retry-ability works the way it does.” At HMRC, Mitchell’s team chose Cypress for the agent-facing tax-portal application precisely because the in-browser architecture gave them the real-time debugging visibility they needed to diagnose a complex async form-wizard flow. The before-and-after DOM snapshots cut debugging time by 60% compared to the Selenium suite they were migrating from.

Signal 2: You Can Design a Network-Stubbing Strategy with cy.intercept()

This is the question that separates test-script authors from test architects in Cypress interviews. “cy.intercept() is not just an API mocking tool — it is a network-traffic-control layer. I use it across three dimensions: Dimension 1 — Stubbing for reliability: if my test logs in, creates an order, and checks out, I do not want the test to fail because the payment-gateway sandbox is down. I stub POST /api/payments to return a predictable response — the test now tests my application logic, not the payment gateway’s availability. Dimension 2 — Stubbing for speed: if my search page calls a product-catalogue API that takes 800ms to respond, my test waits 800ms on every search interaction. Stubbing GET /api/products?q=* to return cached responses makes the test 10x faster while still validating that the page renders search results correctly. Dimension 3 — Stubbing for test coverage: I use cy.intercept() to simulate error states that are impossible to trigger in a test environment — 500 errors, 429 rate limits, 503 Service Unavailable with Retry-After headers, and slow responses that trigger loading spinners. I verify that the application displays the correct error message, retry button, or fallback UI for each network failure state. The key Cypress-specific detail: cy.intercept() can modify requests and responses dynamically. If I want to test that the application retries a failed payment with an idempotency key, I stub POST /api/payments to fail on the first call (500), succeed on the second (200), and assert that the second request includes the correct idempotency key header. This level of network control is unique to Cypress because it runs in the same JavaScript context as the application — the intercept happens at the XMLHttpRequest and fetch level, before the request leaves the browser.” At Nationwide, Mitchell’s team used cy.intercept() to build a comprehensive network-failure test suite for the mortgage-application portal. They stubbed 17 different error scenarios — network timeouts, 500 errors, 429 rate limits, 503 maintenance pages — and caught four production bugs where the application silently swallowed errors instead of showing user-facing notifications.

Signal 3: You Can Discuss Cypress Component Testing vs E2E Testing

Cypress launched Component Testing in v10, and interviewers in 2026 now probe whether candidates understand when to use it — because the decision affects test suite architecture, runtime, and maintenance. “Component testing with Cypress runs individual React, Vue, or Angular components in isolation — without a full application, without a backend, without routing. It mounts the component in a browser environment (real DOM, real CSS, real JavaScript), so you get the same rendering engine as production — unlike jsdom-based tools like Jest or Vitest. E2E testing with Cypress runs the full application — with routing, with a backend (or stubs), with all the interactions between components, services, and network calls. Here is my decision framework: I use component tests for individual component behaviour — ‘does the DatePicker emit the correct ISO date when the user selects March 15?’ ‘Does the ErrorBanner render the correct icon, message, and retry button for each error type?’ These tests are fast (100-500ms), deterministic, and test the component in isolation. I use E2E tests for complete user journeys — ‘can the user log in, search for a product, add it to the basket, apply a discount code, and check out?’ These tests are slower (5-15 seconds) and test the integration of components, services, and network calls. The key insight: component tests catch UI-logic bugs faster and cheaper. If you can test the error-banner rendering in a 200ms component test, do not wait for a 10-second E2E test to catch it. At the Co-op, Mitchell’s team moved 40% of their E2E assertions into component tests — the E2E suite went from 22 minutes to 9 minutes, and bug-detection speed improved because component tests ran on every commit while E2E tests ran on PR merges.” The component-testing question is a seniority signal: a mid-level candidate uses Cypress for E2E because that is what the team set up. A senior candidate evaluates the testing pyramid and pushes tests down to the fastest, most reliable layer — and Cypress Component Testing is that layer for UI behaviour.

Signal 4: You Can Structure a Cypress Suite That Scales to 500+ Tests

Writing 10 Cypress tests is easy. Writing 500 Cypress tests that run reliably, stay fast, and remain maintainable across a team of 15 engineers — that is what interviewers are testing when they ask about Cypress architecture. “My Cypress architecture follows four principles for scale. Principle 1 — Custom commands as a domain language: instead of writing cy.get('[data-testid="login-email"]').type('user@test.com') in 50 test files, I create a custom command cy.login({ email: 'user@test.com', password: 'Test123!' }) that encapsulates the login flow. If the login page changes, I update one command, not 50 tests. Principle 2 — Page Object Model for Cypress: I organise selectors and page actions into page objects — but in Cypress, I focus on actions rather than elements. My page object exposes loginPage.fillCredentials() and loginPage.submit() — not loginPage.emailInput and loginPage.passwordInput. This keeps tests readable (‘what does the test do?’) and keeps selectors encapsulated. Principle 3 — Test isolation through data management: I use cy.task() to seed and reset the database before each test via Node.js scripts. cy.task('db:seed', { scenario: 'user-with-3-orders' }) runs a Node.js function that inserts test data directly into the database — no UI-driven data setup, which is slow and fragile. cy.task('db:reset') cleans up after each test. Principle 4 — Intelligent test organisation: I organise tests by user journey, not by page. Instead of /tests/login.cy.js, /tests/checkout.cy.js, I use /tests/journeys/guest-checkout.cy.js and /tests/journeys/registered-user-order.cy.js. This makes it obvious which tests cover which business workflows — and when a journey changes, you know exactly which test to update.” At BT, Mitchell’s team adopted this architecture for a customer-support portal with 400+ Cypress tests. The custom-command DSL reduced test-authoring time by 40%, and the journey-based organisation made it obvious which tests needed updating when the checkout flow was redesigned — instead of discovering broken tests one by one in CI.

Signal 5: You Understand Cypress Flaky-Test Diagnosis — Not Just Retries

Every Cypress suite encounters flaky tests. The difference between a junior and a senior candidate is how they diagnose and fix them. “Cypress flaky tests fall into five categories — and I diagnose each differently. Category 1 — Timing issues: the test asserts on an element before the application has rendered it. Cypress’s built-in retry-ability handles most timing issues (cy.get() retries for 4 seconds by default), but if the application fetches data that takes 8 seconds to load, the default timeout expires. The fix: increase the timeout for that specific command (cy.get('[data-testid=slow-widget]', { timeout: 10000 })) — or stub the API response so the data arrives immediately. Category 2 — Test-state leakage: Test A creates a user, but Test B also expects a clean database. If Test A fails mid-execution and does not clean up, Test B starts with leftover data and fails. The fix: never rely on test execution order. Every test seeds its own data via cy.task('db:seed') and resets via cy.task('db:reset') in an afterEach. Test B should pass even if Test A never ran. Category 3 — Animation and transition races: the application has a slide-in animation that takes 300ms, and the test clicks a button that is animating into view. Cypress clicks the element at its target position, but the element is still moving — the click misses. The fix: cy.get('.animated-element').should('not.have.class', 'animating') before interacting — wait for the animation to complete. Category 4 — Network flakiness: the test depends on a real API that occasionally returns a 503. The fix: stub the API — tests should test your application logic, not your backend’s uptime. Category 5 — Iframe and shadow DOM issues: Cypress struggles with cross-origin iframes and shadow DOM boundaries. The fix: use cy.origin() for cross-origin iframes (Cypress 12+) and .shadow() to pierce shadow DOM. The principle: never fix a flaky test by adding cy.wait(2000). Every cy.wait() is an admission that you do not understand why the test is flaky — and it makes the suite slower every time you add one.”

The one-sentence answer that anchors every strong Cypress interview response: “Cypress is not just an E2E testing tool — it is an in-browser automation platform with a unique architecture (same event loop as the application), a network-traffic-control layer (cy.intercept()), and a command-queue execution model that makes it the right choice for single-origin web applications where real-time debugging visibility and network control outweigh the need for multi-tab, multi-origin, and WebDriver-protocol testing; the skill interviewers are testing is not whether you can write cy.get(), but whether you understand when Cypress is the right tool, how to architect a Cypress suite that scales, and how to use its unique capabilities — intercept, component testing, real-time DOM snapshots — to catch bugs that other frameworks miss.”

The 7 Critical Cypress Topics — With Interview Questions and Model Answers

Here are the topics that Mitchell has both tested candidates on and been tested on across 20 years of SDET interviews — each with the question format and the answer structure that demonstrates genuine Cypress-testing maturity.

Topic 1: Cypress Command Chaining and Async Execution — The Queue Model

Interview question: “Explain how Cypress commands execute. Why can’t you use async/await with Cypress commands? What is the difference between a Cypress command and a Cypress promise?”

What the interviewer is testing: They are checking whether you understand the command-queue model that underpins everything Cypress does — or whether you have just accepted that “Cypress works differently” without understanding why.

Model answer: “Cypress commands are not executed immediately when you call them — they are enqueued. When you write cy.get('.button').click(), Cypress does two things: first it enqueues a ‘get .button’ command, then it enqueues a ‘click’ command. The commands are executed asynchronously by the Cypress runner — one at a time, in order, with automatic retry-ability. This queue model is why you cannot use async/await with Cypress commands — they are not Promises. A Promise executes immediately when created; a Cypress command is enqueued and executed later. The queue model is also why Cypress commands are retry-able. When cy.get('.button') executes, if the element does not exist yet, Cypress retries the command for up to 4 seconds (the default timeout) — checking the DOM repeatedly until the element appears. A Promise that failed would reject immediately. The practical implications: (1) you cannot mix async/await with Cypress commands — cy.get() is not await-able; (2) you cannot use standard JavaScript control flow with Cypress commands — if (cy.get('.button').should('exist')) { ... } will not work because should is enqueued, not executed; (3) Cypress provides .then() for accessing values from commands — cy.get('.price').invoke('text').then((text) => { const price = parseFloat(text); }). Understanding the queue model is essential to understanding every Cypress behaviour that surprises developers coming from Selenium or Playwright.”

Topic 2: cy.intercept() — Network Stubbing, Spying, and Mocking

Interview question: “Walk me through how you use cy.intercept() in your tests. When do you stub vs spy? How do you handle dynamic responses?”

What the interviewer is testing: They want to see whether you treat cy.intercept() as a simple mock tool — or as the network-control layer that makes Cypress tests fast, reliable, and comprehensive.

Model answer: “cy.intercept() has three modes — and I use all three. Mode 1 — Spy: observe network traffic without modifying it. cy.intercept('POST', '/api/orders').as('createOrder') and later cy.wait('@createOrder').its('response.statusCode').should('eq', 201). This validates that the application made the expected API call with the expected payload — without changing the response. Mode 2 — Stub: replace the API response with a controlled one. cy.intercept('GET', '/api/products*', { fixture: 'products.json' }). The test now runs against known, predictable data — it does not depend on the backend being available or the database containing specific records. Mode 3 — Dynamic stub: modify the response based on the request. cy.intercept('POST', '/api/payments', (req) => { if (req.body.amount > 1000) { req.reply({ statusCode: 402, body: { error: 'Insufficient funds' } }); } else { req.reply({ statusCode: 200, body: { id: 'pay_123' } }); } }). This lets me test different code paths based on request parameters — without touching the real backend. The key Cypress-specific detail: cy.intercept() intercepts at the network layer — it catches XMLHttpRequest, fetch, and even WebSocket connections. It can also modify the response dynamically after intercepting it: req.continue((res) => { res.body.discountApplied = true; res.send(); }). This level of control is why I prefer Cypress for applications where the frontend behaviour depends heavily on API response shapes — I can test every response variation without building a mock server.”

Topic 3: Cypress vs Playwright vs Selenium — The Decision Framework

Interview question: “When would you choose Cypress over Playwright — and when would Playwright be the better choice?”

What the interviewer is testing: They are checking whether you are a framework partisan or an engineer who selects tools based on project requirements. The strongest candidates can discuss strengths and weaknesses of all three without denigrating any of them.

Model answer: “I choose Cypress when three conditions are met: (1) the application is a single-origin web app — no multi-tab workflows, no cross-origin navigation beyond a few well-defined flows; (2) debugging visibility is critical — the team needs real-time DOM snapshots, time-travel debugging, and the ability to inspect application state at every step; (3) the test suite needs comprehensive network stubbing — cy.intercept() at the JavaScript level gives more control than Playwright’s route interception or Selenium’s proxy-based interception. I choose Playwright when: (1) the application needs cross-browser testing (Chrome, Firefox, Safari, Edge) — Cypress officially supports Chrome-family browsers and Firefox; Playwright supports Chromium, Firefox, and WebKit; (2) multi-tab or multi-origin workflows are common — Playwright’s browserContext and page model handles multiple tabs natively; (3) mobile-device emulation is required — Playwright’s device descriptors (iPhone 14, Pixel 7) include viewport, user agent, touch events, and geolocation; (4) API testing should live in the same framework as UI testing — Playwright’s request fixture enables API tests with the same test runner, fixtures, and reporting. I choose Selenium when: (1) the team already has a mature Selenium suite with 5,000+ tests — migration cost exceeds migration benefit; (2) the application requires testing on browsers that Playwright and Cypress do not support — Internet Explorer, legacy Safari versions; (3) the organisation uses Selenium Grid for distributed execution and the infrastructure investment cannot be duplicated. The principle: framework selection is an engineering decision, not a preference. The tool that the team will maintain, that integrates with their CI/CD pipeline, and that catches the bugs relevant to their application is the right tool — regardless of what is trending on Twitter.”

Topic 4: Cypress CI/CD — Parallelisation, Cypress Dashboard, and Pipeline Design

Interview question: “Your Cypress suite takes 18 minutes in CI. The team wants it under 8 minutes on every PR. How do you achieve that?”

What the interviewer is testing: They are testing whether you have taken a Cypress suite from local development to CI/CD at scale — or whether you have only run npx cypress run on your laptop.

Model answer: “I attack the 18-minute runtime on five fronts. Front 1 — Cypress parallelisation: Cypress Dashboard (the SaaS service) supports parallel test execution across multiple CI machines. I configure cypress run --record --parallel and the Dashboard distributes spec files across available machines. If I have 4 CI workers, an 18-minute suite becomes approximately 5 minutes — each worker runs a quarter of the specs. Front 2 — Test selection: not every PR needs every test. I use Cypress’s --spec flag to run only the specs affected by the changed code. A CI step uses git diff to find changed files, maps them to Cypress spec files, and passes the narrowed list to cypress run --spec. A frontend-only change to the login page runs the login specs — not the checkout, search, and settings specs. Front 3 — Build-and-test separation: many Cypress CI pipelines rebuild the application (npm install, npm build) before every test run — even when the application code has not changed. I separate the build step (run once) from the test step (run N times in parallel). The build artifact is cached and reused across parallel workers. Front 4 — Test data strategy in CI: Cypress tests that call real APIs scale poorly in CI because the APIs become a bottleneck under parallel load. I use cy.intercept() with fixture data for CI tests — the tests run entirely against stubbed responses and complete in seconds instead of minutes. I run a nightly integration-test suite against real APIs to catch contract drift. Front 5 — Flaky-test quarantine: flaky tests that fail intermittently waste CI time (re-running the same test, debugging false positives). I track flaky tests in Cypress Dashboard (it flags specs with high flakiness rates), move them to a quarantine suite, and fix them as a dedicated engineering task — not as a side effect of debugging CI failures. The principle: the CI pipeline should answer ‘does this PR break anything?’ in under 8 minutes. A pipeline that takes 18 minutes gets skipped by developers — and skipped pipelines catch zero bugs.”

Topic 5: Cypress Custom Commands — Building a Test DSL

Interview question: “How do you use Cypress custom commands? What commands have you created, and what rules do you follow when designing them?”

What the interviewer is testing: They are checking whether you use custom commands strategically — as a domain-specific language for your application under test — or whether you wrap every cy.get() in a command and create unmaintainable abstractions.

Model answer: “I use Cypress custom commands to create a domain-specific language (DSL) for the application under test. The goal is that a test reads like a description of what the user did — not a sequence of selectors and clicks. I follow five rules when designing custom commands. Rule 1 — Commands represent reusable user workflows, not individual interactions. cy.login(email, password) is a good command because ‘log in’ is a workflow every test needs. cy.clickSubmitButton() is a bad command because it adds no abstraction value over cy.get('[data-testid=submit]').click(). Rule 2 — Commands encapsulate implementation details. cy.login() hides the three-step login flow (type email, type password, click submit) and the selectors for each field. Rule 3 — Commands are chainable. Every custom command I write ends with return or yields a subject so the next command can chain: cy.login().then(() => cy.get('.welcome-message')). Rule 4 — Commands have a single responsibility. cy.createOrderWithItems() is good; cy.createOrderLoginAndNavigate() is bad because it bundles three unrelated operations. Rule 5 — Commands are type-safe. In TypeScript projects, I declare custom-command types in cypress/support/index.d.ts so IDEs provide autocomplete: declare namespace Cypress { interface Chainable { login(email: string, password: string): Chainable<void>; } }. The commands I have built most often: cy.login() (authenticate and set session), cy.seed(fixtureName) (set up test data via cy.task()), cy.navigateTo(section) (navigate to a named section of the app), and domain-specific commands like cy.addItemToBasket(productId) or cy.applyDiscount(code). The principle: custom commands are an investment in readability and maintainability. A good command saves 5 lines of selector-riddled code every time it is called — and when the login page changes, one command update fixes 50 tests.”

Topic 6: Cypress Fixtures and Test Data Management

Interview question: “How do you manage test data in your Cypress tests? When do you use fixtures vs seeding the database vs stubbing API responses?”

What the interviewer is testing: Test data management is the silent killer of Cypress test suites — and interviewers want to know whether you have a strategy or whether you are hardcoding test data directly in spec files.

Model answer: “I use a three-tier test-data strategy. Tier 1 — Cypress fixtures for static reference data. Fixtures (cy.fixture('users.json')) store data that does not change between test runs: user profiles, product catalogues, country lists, configuration values. Fixtures are version-controlled with the test code, so data changes are reviewed alongside test changes. Tier 2 — cy.task() for dynamic database seeding. cy.task('db:seed', { scenario: 'user-with-overdue-invoice' }) runs a Node.js function in the Cypress setupNodeEvents configuration — outside the browser, with access to databases, file systems, and APIs. This is how I create test data that requires referential integrity — a user with 3 orders, each containing 2 items, with one order in ‘shipped’ state. Creating that data through the UI would take 30+ commands; cy.task() does it in one database transaction. Tier 3 — cy.intercept() stubs for API response variations. When I need to test the frontend’s response to 17 different API error states (500, 429, 503, timeout, empty response, malformed JSON), I stub the API with cy.intercept() — each error scenario is a different stub configuration. The decision framework: fixtures for static data that tests read but do not modify; cy.task() for dynamic data that tests need to create with complex relationships; cy.intercept() stubs for API behaviour variations that would be impractical to trigger through real API calls. Never hardcode test data in spec files — when the data changes, you update 200 tests instead of one fixture file.”

Topic 7: Cypress Best Practices — Selectors, Waits, and Test Organisation

Interview question: “What are your top Cypress best practices — and which anti-patterns do you see most often?”

What the interviewer is testing: They want to hear that you have opinions formed by experience — not a list of 10 bullet points from the Cypress documentation. The best-practices question reveals whether you have maintained a Cypress suite or just written tests in one.

Model answer: “My top Cypress best practices — and the anti-patterns they replace — are: (1) Use data-testid attributes for selectors, not CSS classes or element IDs that change for styling or accessibility reasons. cy.get('[data-testid="login-email"]') survives CSS refactors; cy.get('.btn.btn-primary.btn-lg') breaks when a designer changes the button style. (2) Never use cy.wait() with a fixed time. cy.wait(3000) is a time bomb — it slows the suite and does not guarantee the condition you are waiting for. Use cy.intercept() aliases and cy.wait('@apiCall') to wait for specific network requests — or use Cypress’s built-in retry-ability with .should() assertions. (3) Avoid testing external sites. If your test navigates to a third-party payment page, you are testing Stripe’s UI — not your application. Stub the redirect with cy.origin() or mock the payment flow entirely. (4) Keep tests independent. Never write a test that depends on a previous test’s state. If Test B relies on Test A creating a user, Test B breaks when Test A is skipped, reordered, or fails. Every test seeds its own data. (5) Use cy.session() to cache and restore authentication state — logging in once per spec file instead of once per test cuts login overhead from 30% of test time to 0%. The anti-patterns I see most often: cy.wait() everywhere (signals the developer does not understand Cypress’s retry-ability), CSS-class selectors (signals the developer has never had to update a test suite after a CSS refactor), and tests that create data through the UI instead of through cy.task() (signals the developer has never scaled a suite beyond 20 tests).”

Common Mistakes SDET Candidates Make in Cypress Interviews

Mitchell has watched hundreds of candidates make the same Cypress interview mistakes across 20 years at HMRC, the Ministry of Defence, Nationwide, and Accenture. Here are the five most common — and how to avoid them the night before your interview.

Mistake 1: Treating Cypress Like Selenium with a Prettier API

Candidates who come from Selenium often write Cypress tests the same way they wrote Selenium tests — explicit waits, manual timeout management, and cy.wait() calls everywhere. This signals to the interviewer that they have not internalised Cypress’s execution model. The fix: Lead every Cypress answer with the architecture: “Cypress runs in the browser, uses a command queue with automatic retry-ability, and handles waiting differently from Selenium’s WebDriver model.” Be explicit about how Cypress’s retry-ability and command queue change test design — no explicit waits, no Thread.sleep(), and assertions that automatically retry until the condition is met. The SDET Interview Coach app includes Cypress-specific mock interviews that flag when your answers sound like Selenium patterns applied to Cypress — and guide you toward Cypress-native thinking.

Mistake 2: Not Understanding the Network Layer

Candidates who say “I use cy.intercept() to mock API calls” but cannot explain when to stub vs spy vs modify demonstrate surface-level Cypress knowledge. The fix: Prepare the three-mode answer: spy (observe without modifying — cy.wait('@alias')), stub (replace with fixture data — { fixture: 'data.json' }), and modify (dynamic response based on request — (req) => { req.reply(...) }). Be ready to discuss when each mode is appropriate: spy for validating that the frontend calls the right API with the right payload; stub for isolating the frontend from backend instability; modify for testing different code paths based on API response variations.

Mistake 3: Ignoring Cypress Limitations

Candidates who describe Cypress as the perfect tool for everything lose credibility immediately. Cypress has well-documented limitations — no multi-tab support, limited cross-origin handling, no native mobile-device emulation, and Firefox support that lags behind Chrome. The fix: Acknowledge Cypress’s limitations openly: “Cypress is the best tool for single-origin web applications where debugging visibility and network stubbing are critical. It is not the right tool for multi-tab workflows, cross-browser testing on Safari, or mobile-native app testing.” This honesty demonstrates engineering judgment — the interviewer trusts your positive statements about Cypress because you are willing to be critical. Then bridge to when you would use other tools: “For a project that requires testing on Safari and Firefox alongside Chrome, I would evaluate Playwright — it supports all three browser engines natively.”

Mistake 4: Having No Answer to “How Would You Migrate from Selenium to Cypress?”

This is the system-design curveball that appears in senior SDET interviews: “We have 2,000 Selenium tests. We are considering Cypress. How would you approach the migration?” Candidates who say “rewrite everything in Cypress” have demonstrated they do not understand the cost of a big-bang migration. The fix: Describe a strangler-fig migration: “Step 1: new features get Cypress tests. The Selenium suite continues to run for existing functionality. Step 2: identify the top 20% of Selenium tests that provide 80% of bug-detection value — migrate those first, using Cypress’s cy.intercept() and custom commands to reduce test complexity during the migration. Step 3: run both suites in parallel for 3 months — Cypress for new and migrated tests, Selenium for legacy tests. Step 4: decommission Selenium tests one by one as Cypress coverage reaches parity. Step 5: archive the Selenium suite but keep it accessible for reference during the warranty period. This approach minimises risk because the application is always covered — the Selenium suite catches regressions until Cypress coverage is sufficient.”

Mistake 5: Confusing Cypress Component Testing with Unit Testing

Candidates who say “Cypress Component Testing replaces Jest unit tests” have misunderstood both tools. The fix: “Cypress Component Testing tests components in a real browser — with real DOM, real CSS, real event handling. Jest (with jsdom) tests components in a simulated DOM. They are complementary: Jest for pure logic tests (does this function return the correct value?), render-output tests (does the component render with the correct props?), and fast-feedback unit tests (thousands of tests in milliseconds). Cypress Component Testing for interactive behaviour tests (does the DatePicker open when clicked, navigate correctly with keyboard arrows, and emit the correct date?), visual verification (does the component render correctly across different viewports?), and integration tests where multiple components interact (does the SearchBar filter the ResultsList correctly?). The principle: use Jest for speed and logic; use Cypress Component Testing for real-browser fidelity and interactivity. You need both — not one replacing the other.”

The Cypress Tools and Ecosystem Landscape in 2026 — What Interviewers Expect You to Know

The Cypress ecosystem has expanded significantly, and interviewers expect candidates to have informed opinions about the tools that surround Cypress — not just Cypress itself. Here is the landscape as of 2026, with the trade-offs that matter in interviews.

Cypress Dashboard — The Paid CI/CD Service

Cypress Dashboard provides parallel test execution, test analytics (flakiness tracking, execution time trends), and test-result history across CI runs. Interview talking point: “Cypress Dashboard is worth the cost for teams with 200+ tests that need parallel CI execution and flakiness analytics. For smaller teams, the open-source cypress run with --parallel and a custom test-reporting solution (Mochawesome, Allure) provides similar functionality at no cost — but requires more maintenance. The decision is not technical; it is operational: do you want to maintain your own reporting infrastructure or pay Cypress to maintain it?”

cypress-cucumber-preprocessor — BDD with Cypress

The Cucumber preprocessor enables Gherkin-based test authoring in Cypress — ‘Given the user is on the login page, When they enter valid credentials, Then they see the dashboard.’ Interview talking point: “BDD with Cypress is valuable when non-technical stakeholders (product owners, business analysts) need to read and contribute to test scenarios. The trade-off is an additional abstraction layer — Gherkin steps map to Cypress commands, and when a step fails, you debug through two layers instead of one. I recommend BDD only when the collaboration benefit exceeds the abstraction cost — typically in regulated industries (finance, healthcare) where test scenarios serve as living documentation for compliance audits.”

Cypress Component Testing — The v10+ Game-Changer

Cypress Component Testing mounts individual React, Vue, Angular, or Svelte components in a real browser and tests their interactive behaviour. Interview talking point: “Cypress Component Testing is the fastest-growing part of the Cypress ecosystem in 2026 because it closes the gap between ‘is this component correct?’ (tested in Jest with jsdom) and ‘does the full application work?’ (tested in Cypress E2E). Component tests catch UI bugs that jsdom misses — CSS layout issues, event-handling edge cases, animation behaviour — while running 10x faster than E2E tests. The key architectural decision: where to draw the line between component tests and E2E tests. I draw it at the network boundary: component tests stub all network calls; E2E tests run with some real network calls (or carefully managed stubs).”

cypress-axe — Accessibility Testing in Cypress

The cypress-axe plugin integrates the axe-core accessibility engine into Cypress tests, enabling automated accessibility audits as part of the E2E pipeline. Interview talking point: “cy.injectAxe() and cy.checkA11y() add accessibility validation to every test with minimal overhead. The key insight: accessibility testing should not be a separate activity — it should run alongside functional tests. A test that validates ‘user can complete the checkout flow’ should also validate ‘the checkout flow is accessible to screen-reader users.’ cypress-axe makes this integration seamless, and in 2026, companies subject to the European Accessibility Act (effective June 2025) increasingly require automated a11y checks in CI — making this a strong interview differentiator.”

Percy / Chromatic — Visual Regression Testing with Cypress

Percy (BrowserStack) and Chromatic integrate with Cypress to capture DOM snapshots and detect visual regressions — pixel-level changes that functional tests miss. Interview talking point: “Visual regression testing catches the most expensive class of bugs — the ones users see but functional tests do not detect: a CSS change that shifts a button 5px to the left, a font that renders differently after a dependency update, a responsive layout that breaks at tablet width. cy.percySnapshot() captures the page and compares it against the approved baseline — any visual difference is flagged for review. The key operational challenge: visual snapshots are sensitive to environment differences (OS font rendering, GPU anti-aliasing). Percy solves this by rendering snapshots in a consistent, containerised environment — not on the CI runner’s OS.”

Your Cypress Interview Preparation Checklist — Starting Tonight

You do not need to have built a Cypress suite for 500 tests to answer Cypress questions with authority. You need to understand the architecture, the execution model, and the trade-offs — and practice articulating them out loud. Here is the preparation plan:

  1. Memorise the Cypress command-queue model: Be able to explain why Cypress commands are not Promises, why async/await does not work with Cypress, and what retry-ability means in practice. This is the question that exposes candidates who have used Cypress for a year without understanding how it works.
  2. Prepare the three-mode cy.intercept() answer: Spy (observe), Stub (replace), Modify (dynamic response). For each mode, have a concrete code example and a real-world scenario where you would use it. The network-layer question is asked in 70% of Cypress interviews.
  3. Have a Cypress vs Playwright vs Selenium decision framework: Be able to discuss when each is the right tool — not as a fan, but as an engineer. Interviewers at companies that use Cypress specifically test for this because they want to know you chose Cypress deliberately, not by default.
  4. Prepare a CI/CD answer: How would you reduce an 18-minute Cypress suite to under 8 minutes in CI? Parallelisation, test selection, build-artefact caching, cy.intercept() stubbing, and flaky-test quarantine. This question separates candidates who have run Cypress locally from candidates who have run it at scale.
  5. Build a custom-command example: Describe one custom command you would create — the workflow it encapsulates, why it adds value, and what rules you follow when designing commands. Even if you have not built custom commands, describing a well-designed one demonstrates architectural thinking.
  6. Download the SDET Interview Coach app and complete the 2-minute onboarding assessment. Select Cypress as your framework and your target seniority level. The app surfaces Cypress interview questions calibrated to your experience — Junior candidates get command-chain and selector questions, while Senior and Lead candidates face Cypress architecture discussions, CI/CD pipeline design, and framework-migration scenarios.
  7. Run a Cypress mock interview tonight. Answer the questions out loud — explain the command-queue model, describe your three-mode cy.intercept() strategy, and walk through your Cypress-vs-Playwright decision framework. The AI feedback will show you exactly where your Cypress knowledge gaps are before the real interview exposes them.
  8. Check your selectors: If you have existing Cypress tests, review them for anti-patterns — CSS-class selectors, cy.wait() calls, hardcoded test data, and interdependent tests. Fixing these before the interview means you can discuss your Cypress experience without the interviewer spotting red flags in your code samples.

The Cypress question is not testing whether you can write cy.get() — it is testing whether you understand Cypress as an architectural choice: a framework with a specific execution model (in-browser, command-queue), a specific network layer (cy.intercept()), and specific trade-offs (single-origin, no multi-tab, Chrome-focused). The candidates who walk into interviews in 2026 with an architectural understanding of Cypress — the command-queue model, the three-mode intercept strategy, the component-vs-E2E decision, and the CI/CD scaling approach — are the ones who get offers over candidates who say “I use Cypress, it is easy to set up.” Cypress is an engineering decision. Walk in ready to defend it as one.

For more on framework-specific interview preparation, see our guides on Playwright Interview Questions and Selenium Grid and Distributed Testing. For the complete SDET interview preparation roadmap, see our SDET Interview Preparation Plan 2026. And for daily structured practice with AI-graded feedback, download the SDET Interview Coach on iOS and Android — £4.99/month with 800+ questions across 32 topics, including comprehensive Cypress coverage from command chaining to CI/CD pipeline design. The AI Test Automation Playbook (£9.99) includes a complete chapter on Cypress test automation at scale — the exact patterns Mitchell used at Asda, the Co-op, and BT to build Cypress suites that ran under 8 minutes in CI/CD.

Understand the queue. Control the network. Design for scale. Walk in ready.

Ready to Transform Your Testing?

The AI Test Automation Playbook gives you everything you need: Playwright setup, Claude AI integration, MCP deep dive, 10+ ready-to-use prompts, CI/CD pipeline setup, and a 30-day implementation roadmap.

✅ Playwright + TypeScript✅ Claude AI Prompts✅ MCP Deep Dive✅ CI/CD with GitHub Actions✅ 30-Day Roadmap✅ Page Object Patterns
Get the AI Test Automation Playbook — $49.99

By Mitchell Agoma, Senior SDET & AI Testing Specialist with 8+ years of experience