How do you structure mentoring for engineers new to test automation in a Java/Selenium codebase?

Onboarding to a Java/Selenium codebase has three failure modes, and a good mentoring plan addresses each.

Failure mode 1 — Language. The new engineer is comfortable with another language but rusty in Java. Tests pass but the code is "Python written in Java." Fix: a one-week refresher on Java idioms — generics, streams, Optional, exceptions, build tools (Maven). Don't skip Maven; it's the source of half the new-engineer frustrations.

Failure mode 2 — Framework. They write Java fluently but reach for Selenium anti-patterns: Thread.sleep, locators duplicated across tests, assertions in page objects. Fix: pair-program the first 5-10 PRs. Code review with comments that explain the why (not "use explicit wait" but "explicit waits avoid 30% of our flake — see this incident").

Failure mode 3 — Codebase. They know Java and Selenium but get lost in your repo's conventions: which package owns shared waits, where listeners are wired, how config is overridden. Fix: a written architecture doc with diagrams, plus a "first PR" guide pointing at 3-4 small, well-scoped issues to start with.

A 30/60/90 plan I'd write:

30 days — foundations:

• Read the architecture doc.
• Run the suite locally; fix one flaky test under supervision.
• Submit a small PR adding a test for an existing feature.
• Pair-debug a CI failure.

60 days — independent contribution:

• Own a small feature area's test coverage.
• Refactor one page object to current conventions.
• Lead a review on someone else's test PR.
• Present in the QA team meeting on what they've learned.

90 days — full member:

• Independently scope and ship test coverage for a new feature.
• Mentor the next new joiner on something they've learned.
• Have an opinion on at least one process change.

Cross-cutting practices:

• Pairing on real PRs, not toy exercises. Toy exercises don't expose the codebase's conventions, which is where most onboarding pain lives.
• Reading group — once a week, walk through one part of the codebase or one classic Selenium pattern. Builds shared vocabulary.
• Failure post-mortems — when a test escapes to prod, the team meets and the new engineer participates. They learn what "good" looks like by seeing what "bad" looked like.
• Document gaps — anything the new joiner asks twice gets written down. This is how the architecture doc actually grows.

The interview signal: thinking in terms of failure modes and matching the mentoring layer to the cause, plus explicit milestones that make progress measurable.