[PragmaticPulp]

> Companies should immediately tell if they would reject job-hoppers

Job-hopping isn't some arbitrary threshold that gets crossed. It's more of a pattern that gets identified while evaluating a person's resume.

When I say "job hopper" I don't mean someone who has 10 years of experience across 3 or 4 different jobs. The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company. If someone can't last a full year as an FTE at any company, it's hard to argue that there isn't a problem.

It's not a big deal for someone who is 1-2 years into their career. But when someone is 10 years into their career and they're not staying anywhere long enough to really make an impact, why would any hiring manager reasonably expect that to be different after hiring them again for job number 11 or whatever it ends up being? The most likely outcome is that the pattern continues.

[j-bos]

I agree with you, with one caveat. Why is one year not enough time to make an impact? Isn't a key in agile development the iterated development? Wouldn't a year have plenty of iterations where a developer could build out tooling, ci/cd processes, ship many multiple long lasting features?

[ominous_prime]

You can absolutely make an impact multiple times within a year, but the odds of those "impacts" being a net positive without ever having maintained the results is not good.

If I'm hiring for a senior or better role, I want you to be able to make meaningful, sustainable changes in large and complex systems. It can take the better part of a year to even fully understand many complex systems, so it's unlikely you ever experienced the full long term affects of your changes.

[flutas]

> You can absolutely make an impact multiple times within a year, but the odds of those "impacts" being a net positive without ever having maintained the results is not good.

Fully agree. I've seen a few FTEs come in, try to make a giant splash with changes, then leave right when their changes have any sort of major issue.

I'm still dealing with bad code from someone that came in and tried to do that.

[driscoll42]

This is one of the key "promises" of agile development, which to me shows why agile promises more than it can deliver often times.

[__derek__]

> The "job hopper" resumes I see are some times as extreme as 12 jobs in 10 years, or occasionally people who have never reached the 1 year mark at any company.

Oh, man, I briefly worked adjacent to someone like that who went on to have principal and director level roles at pretty well-known start-ups, despite never sticking to any role for a year (according to their own LinkedIn!). Apparently they're now CTO of a small start-up, which seems like a recipe for disaster.

[izelnakri]

Never reaching a year at 10 jobs is something to ask I think however:

> why would any hiring manager reasonably expect that to be different after hiring them again for job 11

Thats is I think still the wrong approach, signals the wrong mentality in an IT company(a company thats greatest asset is its employees). Investing in employees can never be a saving center in a good IT business, considering all businesses are becoming IT businesses perhaps in every business in this context. If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them. If I was the manager of the hiring manager, I’d probably fire this hiring manager for keeping the organization dumber, and seeks his own interest/status-quo seeking behavior & protectionism with this behavior/approach/mentality. I do believe in moving mountains in 3-6 months, especially in badly managed projects or super fast growing companies.

[andmarios]

If you haven't stayed at any single position for at least a year, then odds are you haven't developed some skills crucial for your job.

Sure, you can move a mountain in 3-6 months, I've seen such people. Most of them will move the mountain to a wrong place, and won't stay to help bring it back at the desired one. They will just go, leaving chaos back, totally unaware of the mess they created. Or they will move the mountain to the correct place, but will do it in such a way, that no-one is able to maintain, improve, or fix the mountain.

Leaving before a year or two, means you never owned your mistakes. You never tweaked your engineering intuition for teamwork, reliability, or maintainability.

Hey, you might be brilliant, but that's not what engineering is about.

[peteradio]

You are basically saying big work doesn't ever get done in 3-6 months of someone joining a team, or its so remarkably rare that you would rather completely write off the rare case (who sits at the opposite spectrum of what you wish to weed out) than risk hiring a basket case.

Mountains don't ever get moved, the problem gets planned properly or it doesn't. Testing takes forever but development along a single trajectory is always fast.

[WastingMyTime89]

There is no rare case at the opposite end of the spectrum.

Significant contributions aren’t a settled thing after six months. There always are loose ends to tie, things to reflect upon or unforeseen evolution forcing you to come back.

The issue with people leaving after six months is not that they might not have made a significant contribution in these six months. It’s that they never had to live through the consequences of what they did. It’s not a deal breaker but it’s career limiting because I very much want to hire people who know how to deal with things not going to plan and able to own their work. That’s why experienced people are paid more after all.

I’m equally suspicious of people with ten years of experience who can’t explain to me when something they were working on went wrong and what they did to fix it. It’s nearly impossible to work ten years on major projects and not having something blowing up on you at some point.

[peteradio]

> That’s why experienced people are paid more after all.

They are paid to stick around? I thought good people would produce work that was well thought out enough to not require endless amounts of "maintenance".

[WastingMyTime89]

They are paid better because they know what they are doing and they know what they are doing because they have been through it and experienced what should and should not be done.

How do you know how much maintenance your work actually needed if you never stuck out long enough to witness it?

[lhorie]

Personally, I'd refrain from throwing around "If I was the manager of the hiring manager" rhetorics when responding to PragmaticPulp; that's someone w/ a lot of hiring experience in big tech.

I'll throw my own two cents as someone who interviewed a couple hundred senior/staff level eng candidates. When a candidate comes around w/ 10+ years of experience, a career filled with one year stints will not pass the bar for L6 level because some of the evaluated requirements (e.g "consistent cross-functional impact") simply cannot be achieved in <12 month stints (and this shows in the interviews)

Something to consider is that tenured big tech interviewers can have hundreds of interviews w/ 10+ YOE candidates under their belts; they've seen high performers and low performers and inflated titles and smooth talkers and everything in between. So when they say someone doesn't pass a bar, it's not just a quick dismissal of a resume (the interviewing process at these companies typically doesn't even allow that); instead there's a lot of interviewing experience behind that statement.

[avmich]

> Personally, I'd refrain from throwing around "If I was the manager of the hiring manager" rhetorics when responding to PragmaticPulp; that's someone w/ a lot of hiring experience in big tech.

Having seen a bunch of companies and hiring managers, I don't believe PP's approach is the correct one if he wants to maximize results, not minimize efforts.

There are reasons why at some point stellar candidates stop considering Big Tech, companies like FAANG etc. and also why good engineers deteriorate if staying there for too long (doesn't apply to certain departments, like RnD). Policies are simplifications, and hiring good candidates is a hard problem in modern industry; removing flexibility only makes the task that much harder.

[lhorie]

I mean, I think "maximizing results" is a bit of a loaded term. The bar at FAANGs and adjacent companies is already very high to begin with; their systems are optimized to prevent bad hires and I'd argue they're quite successful at that. Also worth noting that when you hire at scale, optimizing for finding mythical 10x'ers doesn't scale, almost by definition.

The other thing is that you're assuming a hypothetical candidate w/ only short tenures is someone who is necessarily an ace, vs the original claim that this person is likely a dud. The point I'm making is that in a real concrete scenario w/ lots of numbers to look at, people w/ that sort of resume don't perform well when benchmarked against known high performers. Which then begs the question of whether it is even reasonable to assume that there's any overlap between the extreme job hopper archetype and the "ace" archetype statistically speaking, when comparing to the stats for the cohort of people with "normal" tenures.

I can point to a vast pool of people jumping from one 6 month contract to the next that tend to do abysmally bad in interviews, and I can tell you none of the staff+ or director-type people I know are extreme job hoppers, as anecdotes to support the argument that the overly short tenure strategy doesn't perform as well as average tenures. You'd need to provide a very strong argument for the idea that "short tenures = good heuristic for finding golden needle in a haystack" is a superior strategy for either job seekers or employers, because I just don't see it.

[Spooky23]

Huh? If someone never stays for more than a year at a job, unless they are consulting gigs, that’s a red flag. The person is either dumb, unable to complete tasks, a risk due to behavior/etc, or otherwise problematic.

Sometimes you see people who hop around while transitioning between roles. It’s fairly typical to see veterans hit 2-3 places after leaving the service. Likewise, if someone leaves a unique vertical (ie healthcare, government, some finance), some hopping around makes sense. But like all things outliers are usually outliers for a reason.

[avmich]

> Huh? If someone never stays for more than a year at a job, unless they are consulting gigs, that’s a red flag. The person is either dumb, unable to complete tasks, a risk due to behavior/etc, or otherwise problematic.

Really, that's the only conclusion here? Can't a person, who's much better engineer than an interview-goer - I mean, to modern interviews in the industry - have to get at some point a position which he isn't so sure about, get his concerns realized, and made to leave? It's tough market for good engineers, despite some media would tell otherwise; search for a position could take months, more than half a year sometimes, and engineers typically have to make some money, not only working software. So if a good engineer loses a good position, it's a situation against him to find another one - and job hopping bias only makes it worse for everybody, except maybe those bad companies who still hire him, but which can't sustain him.

[onion2k]

That's reasonable, and rational, but at the same time I don't want to disrupt my team by bringing in someone who might decide they don't like the job after six months and who isn't able to ask the questions they need answers to during the hiring process to find that out. Consequently I might miss out on some good engineers by rejecting people with a series of short jobs on their resume and I accept that's a downside for me. The upside is better though.

I don't care if the candidate is having a hard time finding their ideal job. I care about my team.

[speakfreely]

> Really, that's the only conclusion here?

Well, yes, because any other conclusion really misunderstands what problem the hiring process is solving. It is not optimizing for hiring the best engineer possible, it's aiming to minimize a range of possible headaches for the employer. There's a hundred ways that best engineer could have work or personality traits that are absolutely terrible for your organization.

[Spooky23]

How do you assess, or even self-assess engineer goodness if they’re never around? Most people take a few months to get productive at a given job and become less productive when they get ready to leave.

So the strawman engineer who has never been at a job for more than a year probably only had 4-6 months of productive work at these jobs, and never had any meaningful responsibilities or career growth.

In my experience, most folks stay around for 2-3 years at a job or >5.

[snapcaster]

Thanks for all your comments on this thread. Made me think more about this issue than I ever had before. Props for standing up to the hive mind. I think for me the crux is that searching/interviewing/etc. all that stuff to find a job _fucking sucks_ and anyone not managing to either pick the right jobs or stay at their current one is a big red flag. I have trouble imagining someone not hating the process of finding a job and so why can't they avoid having to go through it every year?

[csomar]

It's a funny industry full of people making tech to "meritocracize" society and enable everyone; but will dismiss you if you look one pixel different than some arbitrary rule they just thought about when eating sushi at an overpriced cr*phole.

[PragmaticPulp]

> If a candidate has the skills and took time to apply, if they are qualified you are responsible to hire them and keep them.

The problem with this mentality is that the hiring process isn’t a 1-on-1 process between candidate and employer. When a job opening is posted, you get multiple applications from different people.

It doesn’t make sense to suggest that hiring managers are obligated to hire the first candidate who applies. They collect a number of candidates and try to give the role to the person most qualified for the job.

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.

[avmich]

> 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.

[crubier]

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?

[avmich]

> 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.

[beckingz]

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

[shagie]

> 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?

[Jach]

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.

[peteradio]

> 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.

[Jach]

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.

[tstrimple]

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.

[Gh0stRAT]

There are costs to onboarding a new employee (not just in money, but also in time and attention from more-tenured teammates, finding good "starter" tickets for them to work on, longer standups, interviewing their replacement after they leave, etc)

For pretty much any team, there's some ramp-up time where a new employee won't be contributing much and may be taking more time/attention from your experienced employees and manager. (explaining how the system works, code reviews, helping debug why something's not working, etc etc) There's some break-even tenure below which it's a net loss for a team to have hired someone. It'll be different for each team and also different for each new-hire. Maybe it's only a couple days, or maybe it's 6+ months. Either way, managers should at least be aware of this when making hiring decisions. (exception: unless they're at a cushy enough gig where there's not much/any pressure to deliver)

[avmich]

> (exception: unless they're at a cushy enough gig where there's not much/any pressure to deliver)

Another exception: when the applicant is actually passing able/willing interviews.

Do you really think a good engineer would leave willy-nilly a good place to work? I've yet to see a good software engineer who loves interviewing for the process of it.

[atq2119]

> Do you really think a good engineer would leave willy-nilly a good place to work?

No. Which is precisely why, via contrapositive, a string of short stints is a relevant signal that the person might not be a good engineer.

[themitigating]

I agree about the cost of hiring and on boarding time but you should know by three months if it is going to work out.

There's also a cost to not having the proper head count