Candidates are wise to screen out hiring managers like that. They generally don't run teams worth working for, and if you're not smart enough to filter out managers like that, you might end up with too many short tenures.
Candidates are wise to screen out hiring managers like that. They generally don't run teams worth working for, and if you're not smart enough to filter out managers like that, you might end up with too many short tenures.
I wasn't trying to suggest the parent commenter was trying to work for me (nor would that even make logical sense, given that I'm replying to them...)
The comment was a general observation on the hiring process, short tenures, and how hiring managers operate. I meant it in the general context of the article we're all commenting on.
The bottom line is that hiring managers are looking for good employees. If someone outwardly identifies as a person who "hates being an employee" then it would seem the system is working if they're struggling to convince hiring managers otherwise.
I think this looks closest to the problem of misunderstanding. Hiring managers should look for people who solve their problems, not for good employees (in the sense of this discussion). Hating being an employee should be understood correctly.
Firstly it means the hiring manager has to redo this whole process again. So if nothing else a problem for him.
Secondly everything the person worked on will have to be moved to someone else - an expensive cost of time.
Thirdly there's typically a reason for them leaving, and they often pollute the workspace with that discontent on their way out.
As an employer it's not hard to find people with sufficient skills. Despite what programmers think it's not tech chops that are unique. Being a "good employee" for lots of definitions of "good" is exactly what I'm looking for.
One year is plenty of time to make many meaningful contributions, especially if the employee is already experienced. You might not get the super deep knowledge to drive roadmaps and cross team projects. But it's definitely not going to be a net negative unless the employee is just bad (so not likely to make it to a year).
Don't compare the right person staying only one year to the right person staying 3 years. Compre them to no hire, or to the wrong person being hired. Getting amazing people who want to stay with you forever is really rare.
Hiring managers need to look for good employees as well as people who solve their problems, and whoever joins the team is going to need months of training to be productive.
Someone who jumps ship after a year is...not entirely useless, but was certainly a waste.
Perhaps it's different in other domains.
These two things are one and the same.
The idea of a mercenary developer who shows up, solves problems in exchange for money, and then disappears in a relatively short period of time is exactly what contractors are for. Not all problems are amenable to the contractor model, though. It also takes extra work to prepare problems to be solved in this piecewise fashion, so you can’t just apply the contractor model to random problems and expect good results. There’s a reason people loathe consulting companies.
Full time employees really do need to ramp up, integrate with the team, learn how the company works, build relationships within the company, and otherwise become an integrated employee.