What's Really Happening with Selenium Right Now
Selenium job ads have not disappeared — they have quietly changed shape. Two years ago a listing said "Selenium WebDriver + TestNG"; today the same listing says "Selenium or Playwright, Docker, GitHub Actions, and ownership of flaky test triage." Selenium is no longer the product being hired for, it is the assumed baseline underneath a delivery pipeline. Interviewers rarely ask you to write a locator any more; they ask why your suite took 42 minutes and what you did about it. Meanwhile the enormous installed base of Selenium code in banking, insurance, telecom, and ERP means maintenance demand is still enormous and will be for years — which is why Selenium pay bands are stable rather than falling, even as the excitement moves elsewhere.
What we'd actually recommend
If you already know Selenium, do not throw it away to chase Playwright. The far better move is to make your existing Selenium suite look modern: run it in parallel with Selenium Grid or a container, wire it into CI on every pull request, publish an Allure or HTML report someone actually reads, and put an explicit flake-rate number in your resume bullet. A candidate who says "I inherited 900 Selenium tests at 22% flake and got it to 4% by removing implicit waits and fixing test data isolation" beats a candidate who has rewritten fifty tests in a shinier framework. Framework fluency is cheap now; suite reliability is not.
The pitfall: treating Selenium knowledge as locator knowledge
The most common misconception is that Selenium expertise means knowing lots of XPath. In real interviews, XPath comes up for about ninety seconds. What sinks candidates is the next question: how do you handle a test that passes locally and fails in CI? People answer "add a Thread.sleep" or "increase the implicit wait" and the interview is effectively over. Mixing implicit and explicit waits, sharing a WebDriver instance across threads, and depending on records another test created are the three specific things senior interviewers listen for — and all three are architecture problems, not locator problems.