I’ve also done a decent amount of interviewing, and have a similar (but slightly different) experience to the GP.
We considered someone’s career history a problem when they had several jobs of ~a year or less. Or someone interviewing for a senior position with 4-5 years of experience across 5 companies, for example. If those were the case, we were much more likely to reject them.
If someone (hypothetical) had 10 years experience, with a few that lasted 1-2 years, one that was only a few months, and maybe one that was 4-5ish years, then that was no problem at all. We wanted to be sure they had seen the consequences of their prior decisions, if they were coming into a high-mid or senior role.
When we did hiring, we wouldn’t be comparing candidates 1-to-1 like “Well A had this, but B was good at this, which one should we pick?” …instead, we would just say “ok we’re in hiring mode, keep hiring everyone who is good until we have enough for xyz goal”. So it wouldn’t be that CandidateA is better than CandidateB, but rather if they both met the standards, then they’d get hired.
Some of the qualifiers that mattered more than tenure for us were:
* are they capable of explaining technical problems and communicating
* do they understand algorithms at enough of a level that they won’t cause major performance issues
* are they polite and friendly, how do they respond to feedback
* can they build an architecture which handles expanding requirements
* how eager are they to learn and work on our tech stack + business domain
I haven’t interviewed juniors really, so I can’t speak much to that. But when we’ve hired someone less experienced, it would be the same requirements as above just with a lot more leeway on tech, and more emphasis on “eagerness to learn” + “receptive to feedback”
We considered someone’s career history a problem when they had several jobs of ~a year or less. Or someone interviewing for a senior position with 4-5 years of experience across 5 companies, for example. If those were the case, we were much more likely to reject them.
If someone (hypothetical) had 10 years experience, with a few that lasted 1-2 years, one that was only a few months, and maybe one that was 4-5ish years, then that was no problem at all. We wanted to be sure they had seen the consequences of their prior decisions, if they were coming into a high-mid or senior role.
When we did hiring, we wouldn’t be comparing candidates 1-to-1 like “Well A had this, but B was good at this, which one should we pick?” …instead, we would just say “ok we’re in hiring mode, keep hiring everyone who is good until we have enough for xyz goal”. So it wouldn’t be that CandidateA is better than CandidateB, but rather if they both met the standards, then they’d get hired.
Some of the qualifiers that mattered more than tenure for us were:
* are they capable of explaining technical problems and communicating
* do they understand algorithms at enough of a level that they won’t cause major performance issues
* are they polite and friendly, how do they respond to feedback
* can they build an architecture which handles expanding requirements
* how eager are they to learn and work on our tech stack + business domain
I haven’t interviewed juniors really, so I can’t speak much to that. But when we’ve hired someone less experienced, it would be the same requirements as above just with a lot more leeway on tech, and more emphasis on “eagerness to learn” + “receptive to feedback”