1.11Interview Depth Check

Question 1

Prompt: "Walk me through the architectural differences between Selenium WebDriver and Playwright. Why does it matter?"

What a strong answer should cover:

• WebDriver's HTTP request-response model vs Playwright's persistent WebSocket connection
• The per-command overhead in Selenium (DNS, TCP, serialization for each action)
• The race condition gap between "check state" and "act on state" in Selenium
• Playwright's atomic operations (find + wait + act in one command)
• How this architectural difference leads to Playwright's auto-waiting
• The implications for debugging (opaque HTTP errors vs rich traces)

Example answer:

• "Selenium sends a separate HTTP request for every action --- finding an element is one request, clicking it is another, checking if it is visible is a third. Each request has connection overhead. More importantly, between those requests, the page can change. That gap is where flaky tests are born."
• "Playwright connects via WebSocket and keeps the connection open for the entire test. When you call page.click(), it sends a single command that atomically finds the element, waits for it to be actionable, and clicks it. There is no gap for a race condition."
• "For debugging, Selenium gives you an HTTP error response with a message like 'element not interactable.' Playwright gives you a trace file where you can see the DOM state, network requests, and console logs at the exact moment of failure."

Question 2

Prompt: "What is test flakiness, and how would you systematically reduce it in a browser test suite?"

What a strong answer should cover:

• Definition: tests that produce inconsistent results without code changes
• The three main root causes: race conditions, shared state, external dependencies
• Why flakiness destroys trust in the test suite
• Measurement: how to calculate flake rate
• Architectural solutions: auto-waiting, browser contexts, network mocking
• Process solutions: flake tracking, quarantine, root cause analysis

Example answer:

• "A flaky test is one that sometimes passes and sometimes fails with no changes to the application or test code. I start by measuring --- run the suite 10 times, identify every test with inconsistent results, and calculate the flake rate."
• "Most flakiness falls into three categories. Race conditions: the test checks for something before the app is ready. Shared state: tests depend on each other's side effects. External dependencies: the test hits a real API that is slow or unreliable."
• "For each category, there is an architectural solution. Auto-waiting for race conditions. Browser contexts or isolated environments for shared state. Network interception and mocking for external dependencies. Retries are a symptom treatment, not a cure."

Question 3

Prompt: "Your organization uses Selenium for 2,000 browser tests. Leadership asks if you should migrate to Playwright. What is your recommendation framework?"

What a strong answer should cover:

• Assessment of current pain points (flake rate, execution time, maintenance cost)
• Cost of migration (rewriting tests, retraining team, dual infrastructure)
• Incremental migration strategy (run both tools in parallel, migrate by feature area)
• Risk analysis (what breaks during migration, rollback plan)
• Decision criteria that could lead to "stay with Selenium" (stable suite, team expertise, no pain points)

Example answer:

• "I would not recommend migrating based on tool popularity alone. I would start by measuring the current pain: what is the flake rate, what is the execution time, how much time does the team spend debugging infrastructure vs writing tests?"
• "If the suite is stable and the team is productive, migration has a cost with limited benefit. If the flake rate is above 5%, execution time is a bottleneck, or the team spends more time fighting Selenium than writing tests, migration becomes compelling."
• "For 2,000 tests, I would recommend an incremental approach: write all new tests in Playwright while maintaining the Selenium suite. Migrate existing tests feature by feature, starting with the flakiest ones. Run both suites in CI until the Selenium suite is empty. This avoids a big-bang rewrite and lets the team learn Playwright gradually."