What's Really Happening with TestNG Right Now
TestNG is infrastructure, not a headline skill, and job ads reflect that — it appears as a supporting bullet inside Java automation roles rather than as a requirement of its own. What has changed is that JUnit 5 closed most of the historical feature gap, so teams no longer choose TestNG for parameterisation and grouping alone. Where TestNG still wins, and where interviews still probe it, is suite orchestration for large legacy estates: XML-driven suite composition, dependency ordering, and configurable parallelism across hundreds of classes.
What we'd actually recommend
Learn the parallel execution model properly, because that is where TestNG questions get real. Understand what `parallel="methods"` versus `parallel="classes"` actually does to your shared state, why a single static WebDriver breaks immediately under either, and how ThreadLocal fixes it. If you can explain a `testng.xml` that runs smoke on every commit and the full regression nightly, with groups and thread counts chosen deliberately, you have covered roughly everything an interviewer will ask — and you have described a genuinely useful setup rather than trivia.
The pitfall: memorising annotation order instead of understanding scope
The classic question is the execution order of `@BeforeSuite`, `@BeforeTest`, `@BeforeClass`, and `@BeforeMethod`, and most candidates can recite it. Then the follow-up arrives: your suite runs in parallel, where does the driver get created and why? Recitation does not help there. The related misconception is that `dependsOnMethods` is a good way to sequence tests — it makes tests interdependent, so one failure cascades and skipped results hide real signal. Experienced reviewers treat heavy use of it as a design smell rather than a feature.