What's Really Happening with Appium Right Now
Mobile automation stayed a niche, and that niche got more valuable rather than less. The supply of engineers who can actually stabilise an Appium suite on real devices has not grown, while every consumer product now ships an app. The real change in the last two years is infrastructure: teams have largely stopped maintaining local device labs and moved to cloud device farms, so interviews now include questions about device allocation, parallel session limits, and cost per run — commercial questions that pure scripting practice never prepares you for.
What we'd actually recommend
Do not try to mirror your web suite on mobile. The highest-value mobile automation is a small, ruthlessly maintained set of critical journeys — install, login, core transaction, payment, offline behaviour, upgrade path — run on the two or three device/OS combinations your analytics say actually matter. Pair that with strong accessibility identifiers agreed with developers. Getting `accessibilityIdentifier` and `content-desc` added to the app is the single highest-leverage thing a mobile QA can negotiate, and it is a great thing to describe in an interview because it shows you influence the codebase, not just test it.
The pitfall: believing one script runs identically on iOS and Android
Candidates often present cross-platform reuse as if Appium erases the platform difference. It does not. XCUITest and UiAutomator2 expose different element trees, different gesture behaviour, different permission dialogs, and very different startup timing. In practice you share the test logic and page objects and keep platform-specific locator layers. Anyone who has shipped a real suite knows this; the answer "write once, run anywhere" tells an experienced interviewer you have only run the sample project.