> And that is the core problem for job hopping applicants: Inevitably, you’re going to go up against other candidates with resumes suggestive of longer tenures and, in turn, bigger accomplishments at companies.

Can you consider job hopping as an advantage of the candidate, the same way you seem to consider it as a disadvantage?

I've seen this bias for various people many times, and I also have examples among my fellow engineers, way more competent than average level in tech companies, who can't find a new position, not without many months of search and being dismissed for imagined shortcomings from the fragile interviewing process. Job hopping bias is one of traits lately which skews the field against them even more.

You keep mentioning “very competent engineers” which somehow experience repeated short tenures. Might I suggest that competency is not just about technical skills, and that soft skills are also part of the expected “brilliant engineer” package?

> Might I suggest that competency is not just about technical skills, and that soft skills are also part of the expected “brilliant engineer” package?

Basically, no. Soft skills are sufficiently different, so that mismatch their should be considered differently. Just like hiring is a hard problem, retaining hard-skillers is something industry has no good solution at the moment.

If they don't have enough soft-skills the hard skills aren't worth retaining in a typical corporation.

> way more competent than average level in tech companies

How does one evaluate the competency an engineer who has never had to consider and be responsible for the implications of their decisions two or three years down the road?

I think one perspective for companies looking to hire FTEs is that at some point, those "job hopper" advantages are best captured by hiring consultants and other non-full-time people for fixed term gigs. (It's another question to ask the job hopper, too, why don't they go into consulting or fixed contract work?) Sometimes that will involve them writing code, other times advising/overseeing/helping some internal team, but at some point they've done what was needed and it's see you later. Your actual full time employees though, you want them to stick around.

The last big company I worked at made it pretty easy to "team hop", which I'm sure cut attrition to the company overall by quite a bit. There was even a cool "sniper team" that would move around to assist different teams every few months. And of course there were the summer interns, most teams tried to make them net-positives and productive during their few months -- that is, even with some overhead of spinning up to the environment, having some team members mentoring them, and having to make sure their work is well understood enough by others to survive them taking off, you're still happier they were there than not. But IIRC no one was directly hired onto the sniper team, they were internal transfers. Maybe some were job hoppers in the past. But most teams interviewing new outside candidates for FT roles want the same sort of expected stability as everyone else, so of course too frequent job hopping isn't going to be seen positively.

I had a fun experience interviewing someone for a management role, he had previously left the company (after a year or so as a dev and about the same as a freshly transitioned manager) for another, but after maybe a year and a half or so at the other was thinking of coming back to the old one. I can't remember my phrasing but I basically asked him what sort of guarantees (I know I didn't use this word but it captures the desire) he could make that he wouldn't just leave again after a year or so, when this particular position really needed someone invested for at least 3 years. His answer was something like a pretty floaty "we never know what life will throw at us", which sure, there are no real guarantees here, but still, you could at least try and make me believe, like demonstrating a passion for the underlying product space or something, or heck even a simple mercenary view of trying to get a lot more RSUs that don't vest after that many years would be acceptable to me (if not others). Anyway, I recommended against him, for that and other reasons.

> There was even a cool "sniper team" that would move around to assist different teams every few months.

Were they actually good? I could see this being an absolute fly-by wharbargle.

I never heard complaints, and my own experience was with the stuff they were wrapping up for my team just as I was hired. It was solid and we extended it further about a year later on our own without issue. (Organized code, including some plsql, tests, and some useful docs were left behind.) I could see the concept going south somewhere else though especially if they're more thrust upon teams that don't want them by upper management.

I think both too much tenure and too little are both "warning signs". Nine times out of ten I'm going to prefer the two year per role candidate to the 20 years at the same enterprise dev shop candidates (who I've universally had the worst experiences with). But if they can't manage at least a year per engagement? That's a bit too active for me generally. I have more confidence in my ability to build an environment that'll encourage people to stay than I have in my ability to rehabilitate a developer with twenty years of ingrained bad habits because they've only seen how one (likely dysfunctional) environment operates.