What's Really Happening with Java for Testers Right Now
Java's position in QA is more secure than internet discourse suggests. The large regulated enterprises that employ the most testers standardised on the JVM long ago, and their automation estates are Java estates. What has changed is the depth expected: interviews have shifted from "can you write a for loop" toward collections behaviour, streams, exception design, and enough object-oriented modelling to explain your framework's structure. The bar rose because the alternative — hiring a developer and teaching them testing — became a real option for employers.
What we'd actually recommend
Optimise for the code review, not the puzzle. Very few QA interviews ask you to invert a binary tree; nearly all of them look at how you would structure a framework. So get fluent in the things that show up in review: collections and when to use each, streams for filtering and mapping test data, generics well enough to write a reusable base class, and exception handling that fails a test loudly instead of swallowing it. Then read one mature open-source Java test framework end to end. That single exercise teaches more about expected structure than months of syntax practice.
The pitfall: catching exceptions to make tests pass
The pattern that ends interviews is a try/catch around a flaky step that logs the error and continues, so the test reports green. It usually comes from genuine pressure to keep a dashboard clean, but it destroys the entire value of the suite and it is instantly visible in a code sample. The related misconception is that testers need less rigorous Java than developers — in practice test code lives longer and is read more often than the feature code it verifies, so sloppy inheritance hierarchies and swallowed exceptions cost more here, not less.