4 ms·

>About 15 years ago I came to the conclusion that "over qualified" was never a legitimate disqualifying disposition of a candidate. Which is about the same tim

>About 15 years ago I came to the conclusion that "over qualified" was never a legitimate disqualifying disposition of a candidate. Which is about the same time I decided the opposite, having been burned a couple times. You're neglecting the amount of time and effort other people in the group put in to make a new employee productive. Where I work it takes an absolute minimum of about three months to understand how all the moving pieces of the business data flow fit together, and maybe another three before the new person is truly independent. And during that time other people in the group are spending time on the new guy instead of doing work themselves. If I hire someone and then he quits in six months, all that effort is wasted.

marktangotango 9y ago
This "time on the new guy" ought to only happen once, document the on boarding process. Personally I've never seen a 15 or 20 year guy (yes it's always men at this tenure) take more than a couple of weeks to get productive, 6 months to mastery. That's been my experience at least.
- gxs 9y ago
  Your experience is probably atypical. Documentation is one of those concepts that can be the answer to any problem, but seldom is. I've yet to work at an organization where everything is documented, the documentation is up to date, and the documentation is of high quality. There are always gaps somewhere in the documentation and in the end it does take time to ramp people up. Now, if you work on project based work and it's always on something different, that's a different story.
  - le-mark 9y ago
    Well yeah, the gp specifically said document the on boarding process. A high level architecture overview is all the system documentation required. Personally I ignore all that crap anyway, the truth is in the code and deployments. I don't know how many times I've had to tell the senior, long time employees how their system works.
- pgwhalen 9y ago
  I’d love to work on a tech stack that can be mastered in six months, with just as much understanding as someone who has been around it for five years.
  - pilsetnieks 9y ago
    There are very few companies that have a completely unique tech stack that couldn't have been encountered anywhere else.
    - smcdow 9y ago
      Depends on how similar the domains are. Stacks are vastly different in companies working in disparate domains -- I've worked as a software engineer in C4ISR, gaming, EDA, oil & gas, HFT, remote sensing, consumer electronics, and more. The stacks couldn't be more different & foreign from each other. Like living in different universes. Six months to learn all the moving parts is about right. (I can't imagine a career in only one domain; how boring would that be? Hopefully will be getting a new job in HPC soon.)
  - TeMPOraL 9y ago
    An experienced developer won't need that amount of understanding to do 99% of the tasks at work, and for the remaining 1% there is documentation (right?). And if that's all your homebrewn stack, something is very wrong there.
  - turk184 9y ago
    There is no such thing, not at any of the higher paying roles. I'm 6 months in to a new job right now and although I had some early wins for them, I'm definitely still learning my way through the systems, the people, and the overall organization. There are no shortcuts. 6-12 months is typical. That doesn't mean you should let an ineffective person hang around that long, though. This place fired another developer who started on the same day as I did because he wasn't engaged and showing competent progress.
maxsilver 9y ago
> If I hire someone and then he quits in six months, all that effort is wasted. That a crazy huge amount of ramp up time, so much so that it sounds like there might be a major problem with your project or employer. There would have to be a super uncommon, really good reason to justify a six month ramp up time for a skilled experienced developer. I mean, it would have to be something like "I literally work at NASA on the International Space Station" levels of complexity to justify that length of time.
- ams6110 9y ago
  He said it took that time to "to understand how all the moving pieces of the business data flow fit together" which doesn't seem to me to be that long at all. Not every employer is an "Uber for X" where you can understand the product concept in a day or two. I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years.
  - humanrebar 9y ago
    > I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years. I've had that problem, too, but I considered it a failure of architecture and design, not an inherent property of the space we were operating in. Often this is a sign of a lack of separation of concerns at the system level.
- FireBeyond 9y ago
  Yeah, I don't think so. It's not "have something of an understanding of what we're doing here", it's "feel comfortable, and _competent_, in the interactions across the code base, why some approaches might not work or have failed in the past, etc. I'd totally agree with three to six months before that comfort sets in.
- overgard 9y ago
  Six months really isn't uncommon at all. Almost every company has a weird legacy codebase you have to figure out. Unfortunately it doesn't generalize very well -- figuring out why some weird COM interface has 14 inheritance dependencies or what weird JSON file is driving behavior is part of the job. It's just, uh, the part that kind of sucks.

marktangotango 9y ago

This "time on the new guy" ought to only happen once, document the on boarding process. Personally I've never seen a 15 or 20 year guy (yes it's always men at this tenure) take more than a couple of weeks to get productive, 6 months to mastery. That's been my experience at least.

gxs 9y ago
Your experience is probably atypical. Documentation is one of those concepts that can be the answer to any problem, but seldom is. I've yet to work at an organization where everything is documented, the documentation is up to date, and the documentation is of high quality. There are always gaps somewhere in the documentation and in the end it does take time to ramp people up. Now, if you work on project based work and it's always on something different, that's a different story.
- le-mark 9y ago
  Well yeah, the gp specifically said document the on boarding process. A high level architecture overview is all the system documentation required. Personally I ignore all that crap anyway, the truth is in the code and deployments. I don't know how many times I've had to tell the senior, long time employees how their system works.
pgwhalen 9y ago
I’d love to work on a tech stack that can be mastered in six months, with just as much understanding as someone who has been around it for five years.
- pilsetnieks 9y ago
  There are very few companies that have a completely unique tech stack that couldn't have been encountered anywhere else.
  - smcdow 9y ago
    Depends on how similar the domains are. Stacks are vastly different in companies working in disparate domains -- I've worked as a software engineer in C4ISR, gaming, EDA, oil & gas, HFT, remote sensing, consumer electronics, and more. The stacks couldn't be more different & foreign from each other. Like living in different universes. Six months to learn all the moving parts is about right. (I can't imagine a career in only one domain; how boring would that be? Hopefully will be getting a new job in HPC soon.)
- TeMPOraL 9y ago
  An experienced developer won't need that amount of understanding to do 99% of the tasks at work, and for the remaining 1% there is documentation (right?). And if that's all your homebrewn stack, something is very wrong there.
- turk184 9y ago
  There is no such thing, not at any of the higher paying roles. I'm 6 months in to a new job right now and although I had some early wins for them, I'm definitely still learning my way through the systems, the people, and the overall organization. There are no shortcuts. 6-12 months is typical. That doesn't mean you should let an ineffective person hang around that long, though. This place fired another developer who started on the same day as I did because he wasn't engaged and showing competent progress.

maxsilver 9y ago

> If I hire someone and then he quits in six months, all that effort is wasted. That a crazy huge amount of ramp up time, so much so that it sounds like there might be a major problem with your project or employer. There would have to be a super uncommon, really good reason to justify a six month ramp up time for a skilled experienced developer. I mean, it would have to be something like "I literally work at NASA on the International Space Station" levels of complexity to justify that length of time.

ams6110 9y ago
He said it took that time to "to understand how all the moving pieces of the business data flow fit together" which doesn't seem to me to be that long at all. Not every employer is an "Uber for X" where you can understand the product concept in a day or two. I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years.
- humanrebar 9y ago
  > I've had jobs where I didn't feel really comfortable with my understanding of the entire scope of the business until I'd been there a couple of years. I've had that problem, too, but I considered it a failure of architecture and design, not an inherent property of the space we were operating in. Often this is a sign of a lack of separation of concerns at the system level.
FireBeyond 9y ago
Yeah, I don't think so. It's not "have something of an understanding of what we're doing here", it's "feel comfortable, and _competent_, in the interactions across the code base, why some approaches might not work or have failed in the past, etc. I'd totally agree with three to six months before that comfort sets in.
overgard 9y ago
Six months really isn't uncommon at all. Almost every company has a weird legacy codebase you have to figure out. Unfortunately it doesn't generalize very well -- figuring out why some weird COM interface has 14 inheritance dependencies or what weird JSON file is driving behavior is part of the job. It's just, uh, the part that kind of sucks.