Comment by zaphar | Hacker News Reader

Comment by zaphar | Hacker News Reader

The answer to this question depends very much on how quickly you need to get value out of an engineer after their start date. At a minimum regardless of stack familiarity they are going to have to get to know the existing codebase and environment. Not knowing the frameworks you already use will increase the ramp up time for an engineer. If they are a long term hire then the start cost will be amortized across the duration of their time with you so in the long term the cost for a good engineer is probably negligible.

However if you have tight time to market constraints then hiring someone with experience in the stack you already have might be more important to optimize for than long term amortized costs. However if you are having trouble finding a candidate then you may waste more time finding someone than it would take a good engineer to ramp up on the framework and stack.

Thanks - I think in this case it makes sense to find a good engineer and as you put it "optimise for a long term amortised cost"

It's also worth thinking about the timeline inclusive of hiring delay. More detailed requirements makes hiring slower.

I know 2 startups both hiring their first set of non-founder engineers.

One startup took 4 months to hire 2 senior engineers who weren't in their stack and then gave both of them about a month to come up to speed on the tech. Literally running tutorials.

So 5 months in, they have two onboarded senior engineers.

The other startup is 6 months in and hasn't made either hire. They see deep experience in their tech stack as required and don't want to wait longer for onboarding.

But in retrospect, they would have gotten to an onboarded team faster if they had hired like the first company.

yes very interesting take indeed, sometimes it is worth knowing also if your stack is too complicated that you truly need someone already trained, I have had that situation where I entered a job where I already knew the stack but the code was organized in a way with so many opinions that took me longer to understand and follow them in order to make meaningful contributions

the staff developer had very narrow experience doing software and made almost everything he wanted in a "library" way or in a "micro service" way until he got bored and started doing mono repos

because of this the CEO or founder, had a very bad impression on hiring and of course it was unrealistically to hire someone who had experience in the stack and in dealing with the ego of a lone wolf programmer which I believe can be as high as a Hollywood artist some times

Reply on news.ycombinator.com