Hacker News Reader

Comment by gozur88 | Hacker News Reader

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

View on HN

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

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.

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

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.

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.

Depends on developer I one took over a super nich system written in a new language (Pl1g) and using bleeding edge tech (Map reduce in the 80s) took me < than a month to get productive.

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.

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.

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.

There are very few companies that have a completely unique tech stack that couldn't have been encountered anywhere else.

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

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.

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.

Reply on news.ycombinator.com