Speaking personally, I always want to give a technically promising candidate a chance to defend his job hopping, but rarely do I hear convincing reasons for sub 2 year stints unless it is something out of their control, like a spouse needing to move for work, or their whole department getting laid off.

I'll just second this based on my experience with software engineers. Most places I've worked your looking at at least 6 months before someone is starting to get enough familiarity with everything involved in the internal ecosystem (both technical and non) to really be productive and probably a year before they're starting to reach the productivity of their peers. So if someone leaves at 2 years you've probably gotten one of something resembling their full productivity. Less than that and there's a good chance your better off hiring the slightly less impressive candidate who will stick around for a few. Less than 6 months to a year you may be better off hiring no one.

I've contributed significant changes in my first 3 months at most jobs. Lack of fit (eg with your manager) can become too much at 5 months.

In my last job I completed a project that had been backlogged for months within about two months of starting. It was still about 6 before I really felt like I had my feet under me, and definitely closer to the year mark before I really had a grasp of the full ecosystem and was operating at the level I'd expect to be. Admittedly this was a larger organization with around 10-15 engineering teams all managing services that had to interact. The numbers I mentioned weren't a hard-fast universal rule, more a rough guideline from the environments I've been both an IC and manager in.

I 100% agree lack of fit can absolutely be a reason to leave in < 6 months. One or two of these wouldn't be a concern, however I've seen resumes of people who have been in the industry 8 years, with the average stint being between 6-8 months and none over 2-years. I'll probably pass on this candidate, even if they otherwise look better than my next choice. Sure they might make "significant changes" in the 6 months they are here, but I'll almost certainly be better off in the long run with the person who sticks around long enough to have something resembling deep knowledge of our environment. If they have had a "lack of fit" with that many previous managers, I have no reason to believe I'll be the one they finally click with.

So have I, but notably the jobs where I have not, are identifiable by significant legacy code.

It's easy to make a quick impact on greenfield or yellow field projects with little or no pre existing dependencies.

Hiring managers need to consider if the question is relevant, given the work to be done.

Surely this is the baseline? If you hadn't contributed significant changes in the first three months and I was your line manager I probably would have failed your probation. I wouldn't expect you to be at maximum productivity by this point but I would be expecting you to make substantive contributions appropriate to your skill level and experience within this time.

I am baffled by this. It has to be so different between fields and companies.

At 2nd job it took 5 months until the first commit. At my 3rd like 4 months.

Getting up to speed and not being a net time sink for the coworkers, like 8 months on my 2nd job even though I did kinda the same thing in my first job. About 5 months at my third job.

This also make me have a hard time understanding how job hoppers are valued at all.

But reading your comment I realize some companies work completely differently.

5 months to the first commit!

At my last job I had a small bugfix (a one liner but still a bug) committed on my first day, PRed and merged by the end of my second day. That job was the definition of hit the ground running but still. Damn.

Ye, automotive ECU programming, 5 months. The 3rd one industrial plant controller software, 4 months. Both one-liners if I remember correctly.