Hacker News Reader

Comment by gfiorav | Hacker News Reader

I'm always going to cringe at Twitter's "star" engineers who spend an average of 7 months in each company. HTH do you even understand the product and contribute in that time frame? One of two things needs to be at play:

1. You were brought in to do very specific work (i.e.: migrate something to k8s).

2. You were brought in as a token due to your social media following.

Seriously, how else?

View on HN

Haha, it typically takes 6 months to get up to speed at a company as everyone has their own set of unique tools and infrastructure. Also at that cadence you are not vesting any stock(1 year cliff?) so that seems very strange. Having worked with high-vis engineers in the past, alot of them seem to be vanity hires, they really don't impact much change and probably stoke the egos of the upper managers/execs much like (prof. slughorn from harry potter), collecting "geniuses".

If it takes 6 month to come to speed for an experienced engineer, I would say you are working with dinosaurs, in a jurassic age company.

In jurassic age companies you can get up to speed quicker, there is less to wrap your head around and the onsite staff tend to use a simpler approach (manual methods etc).

If you think you are "up to speed" on a large company a week or so you are usually so incompetent you don't know what you don't know.

You can be contributing code in a week or less, but if you're getting fully up to speed on any moderately large system in under 3 months, you probably should take breaks for meals and sleep more. Or you're not getting fully up to speed and are just ignorant. It could be less for a trivial or entirely greenfield system, but then you're worrying about other things like requirements/constraints/etc.

Unless you stick to a very niche domain that you know well, there will be a massive amount of new information to learn. It takes many months to absorb it all.

It depends on the domain. If it's something complicated it might take a while to figure out the business logic of the system, especially if it's something large like an enterprise system. Also, I think a better way of putting it is that it might take that long for them to have a net positive effect on the org. As in they are contributing with minimal help from the rest of the team.

Depends what you define as up to speed

if an engineer can't make impact until 6 months later is this engineer even worth hiring? Large organizations typically take longer time to ramp up, but regardless of size I expect to make impact at least to my team within the first month of hiring.

Sure it is easily possible to make impact in the first month of hiring, but this will most likely be the wrong kind of impact.

I know one like this and the truth is that he doesn’t bother.

He dramatically improves the processes and code which isn’t domain specific and just leaves the rest a mess.

Improve auth? Yes. Improve finance module? Yes. Build better APIs and SQL queries? Yes.

Fix the problems in the actuarial system for funerals? Nope. That’s when you leave and do it all over again.

They contribute to all the parts not specific to the product but common between many products.

I agree, this seems an extremely self-serving creed for "Twitter devs"

Other companies offer added benefits to retain their valuable talent.

The push among "social media stars" to declare long tenures as a negative is problematic, to say the least.

>1. You were brought in to do very specific work (i.e.: migrate something to k8s).

That's how most work gets broken down though. Just find an entry point and start reading code. Read docs, comments, find dependencies, figure out what needs to change in light of your change.

You shouldn't need deep product and tribal knowledge to make simple changes.

In most places you don't need deep product and tribal knowledge to make small changes. You need deep product an tribal knowledge to know what small change to make. Almost anyone new at a company will have someone else telling them what the first thing they need to do is, and that person is telling you to do something that wasn't important enough for them to do themselves.

For what it's worth, the best interns/juniors I've had started out making simple changes like this. I'd break down the work and parcel it out for them every day until they had accomplished something big. Then I'd start parceling it out less and less until they just knew what they were doing.

Is this really true? Do you have any sources for this? I'm interested in learning more.

Reply on news.ycombinator.com