Hacker News Reader

> Slow to hire, slow to fire is the only sustainable way to run a company.

I disagree. Expanding the range of positives to decrease false negatives does not mean that the goal is "increase developer churn". Many startups seem to be so petrified of hiring the wrong person that they miss out on a lot of people that would be good enough or even great. And being "slow to hire" is not a free option. The constant interviewing is a drain on current resources' time and energy. It's a constant distraction. And the longer you wait for the "perfect" person (who you never find) that's time that you're not getting shit done because you're understaffed. There's a balance, and too many companies are paralyzed with indecision, leading to a default "no hire" if someone isn't perfect. This is just arguing for a reasonable recalibration of standards.

> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.

I disagree.

I've hired (and like to think I'm part of this group) folks that can comfortably pick up any domain, not just a language or framework. That's to say, if I needed them to get depth on compiler back-ends because that was part of our value proposition, they could quickly get up to speed on the state of the art and be productive. Maybe they'd start by reading through LLVM documentation and code, understanding its optimizations, and then catch up on the latest papers? Who knows, but they'd have some confidence in weeks.

Would they be on par with world class experts? No. And I don't think the OP claimed this, but not being limited by languages and frameworks isn't that rare.

> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.

There might be a disconnect, but I think it's probably not in the direction you expect.

The vast majority of high-performing engineering teams (good startups, big tech companies) don't hire standard SWEs for specific language/framework expertise. The truth absolutely is that languages are interoperable enough that someone who is smart and understand the underlying principles can get up to speed in a new ecosystem quickly.

If you hire people that can't 80/20 their way to learning a new framework or language within a few weeks, what are you going to do with those folks when you need to adopt some new framework or language? Replace them? Halt development for a few months?

Would you mind expanding upon this "80/20" idea, please?

I think that you are overstating the difficulty of solving new nuanced problems and also of their frequency. New frameworks dont have that much of a depth in them yet ... and old one are super googlable. The hardest problems have zero to do with frameworks and a lot to do with local codebase. Because you cant google any part of those and generally code quality is lower then those of highly acclaimed frameworks/languages.

> More often than not if your problem is harder than slamming together off the shelf components to fleece the consumers of their money the nuance comes into play quickly.

Most of what is harder then "slamming together off the shelf components" is still not that difficult to solve. You cant do it if you are super new, but you can actually do it after few months in.

> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.

Agreed. Not to mention that the author leans very heavily on the notion of "great engineers" as if that describes even a small fraction of candidates. In hundreds of technical interviews across a decade of interviewing in multiple industries, I can count on one hand the number of actually great engineers I've encountered. 99% of everyone who calls themselves a senior software engineer is mediocre at best. I'd rather hire someone who can do the specific work I need them to do who isn't otherwise very good at engineering, because that means I can fill the role after two interviews instead of twenty.

If you have at least one or two engineers familiar with the language it is not hard to teach the rest of the team good practices.

I don't think good practices is enough. It's all the little bits of knowledge about what works and what's the right way to do things that you pick up over years of working in and around a framework. Could an excellent C++ dev become and excellent developer working in React with Redux and Typescript and NextJS and Material UI? Of course. And probably less effort than training someone who's never written code before. But that's way, way more than just learning some good practices. It could be _years_ of collective effort (or more likely, just slowly written not-so-good-code) to bring a team up to an advanced or expert level.

Hire for your stack is absolutely a good idea, unless you have no other option.

Most of the benefit of hiring smart people in a startup is not that they do brilliant things, but that they don't do stupid things. So not really necessary that they be domain experts in most cases.

The thing is that even good engineers but inexperienced with some language or environment are exactly the sort of people likely to do "stupid things". People will shoehorn patterns that work well in X into Y where it doesn't really work, they misunderstand things, or don't know something exists, or use things incorrectly leading to subtle bugs, etc. And then a year later you discover "oh, in hindsight now that I know more about this language that was silly, but now we're stuck with it",

If we're talking about startups, then you often don't really have time or staff to spend on training. You want to be able to say "we need X!" and be confident it gets implemented in a reasonable way that's not going to bite you down the line. If you do have the money and staff to train people, then by all means do so, but "super early stage" startups (quoting the article): you're setting the foundation of what the entire business will be built on for years to come and typically have a limited budget to do that. You need people who can get things done reasonably fast but also do it in a way that's not going to cause a lot of headaches in 2 years down the line, and this takes a certain level of experience.

My advice for startups is exactly the opposite: use tools and languages you're already familiar with, unless you have a very good reason not to. Maybe there's some other language that's a somewhat better fit, but being familiar and experienced counts for a lot. I've seen a number of startups really suffer from using $new_tech a few years down the line simply because they used it badly on account of being new to it.

I agree with most of what you're saying. I think at least the first 2 engineers in the team should be experienced in the stack. And nobody inexperienced should ever be making initial design and architecture decisions.

The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.

In a more established company that works well. In very early stage startups? It can, but it's more of a risk. Most early-stage startups are not well organised and the typical situation is that you can do whatever with fairly little oversight. The 3rd, 4th, or 5th engineer can still make a right mess of things.

This applies even more so if your country has fairly strict labour regulations by the way, where it's hard to fire people; bit of a different discussion, but not completely unrelated here.

That's why for me having a strongly technical / expert-level co-founder is really important. I'm lead engineer and the first non-founder coder at at tiny startup, and I just spent several months rebuiling the entire application after spending several more months of grappling with the mess made by the weakly-technical CTO. This is very much not what a super-early startup should be spending it's time on, but there was no way forward with what we had.

If you're a senior engineer joining a startup where the initial application has been built by a non-technical (or weakly-technical aka junior-dev level) person then beware! It may be much, much more of a mess than you are expecting. Go in with your eyes open. You might not have the luxury of fixing it properly, as I have just had. So it better be a promising startup.

I quit my last job due to a situation like this.

The person that built the entire application was very weak technically. I'm pretty sure the motivation for bringing me in was that I would "fix up" the entire mess. There was no documentation, no tests, and tons of code copy/pasted everywhere.

I spent a year trying to improve it, but for every thing I'd clean up, the original engineer would write twice as much new code without consulting me. I tried to get them to do architecture reviews and code reviews, but everything was always an emergency that needed to go live immediately.

If I ever thought about joining a startup that small again, I'd make sure I got to look at a representative chunk of their code base first. And if it looked like it needed a lot of work, I'd grill the existing engineers hard to make sure I can actually do what they want me to do.

Sorry you had that experience. I was also planning to quit if I didn’t get my way on having a rewrite (though I never told anyone at the company my plans). I was lucky that the CTO was not unaware of the weaknesses, and listened to me. And now they mostly stay out of the codebase. It could have gone the other way.

I've been at a startup where this was the case, but they didn't start over, and it was a disaster that, at least partially, was the cause of the failure of the company. Props to you for making the difficult, but correct, choice.

Going "up levels" or side to side is very easy compared to "going down" it's a pain to teach and get people to truly understand stuff like pointers if they've never touched them.

Anyone could paint-by-numbers a Monet. But only Monet could create a new one.

You don't need painters, you need artists.

This is unbelievably condescending.

I'll follow up on your false analogy to try to get you to your mistake: even Monet had to learn before he became Monet! Even Monet had to fight before he became Monet. He even got rejected and created an art salon because he and his peers were misunderstood by art intelligentsia.

So by rejecting engineers that you deem not worthy of being artists, you're just putting yourself in the position of the bourgeoisie that rejected Monet in the first place.

You're ignoring potential for talent. And really am I glad you're doing that because I then get to train and hire them.

You've missed my point and made incorrect claims about how I operate.

You could elaborate on your point?

It may be effective shorthand for your approach, but without more specifics it reads like fortune cookie wisdom to others (i.e. could be very wise, or very unwise, depending on specifics that you have not given).

Actually, you want a team of painters who work well together.

Hiring only Monets doesn't scale. Could the dude have even worked with himself?

https://www.mysanantonio.com/entertainment/arts-culture/book...

You don't need a team of people as skilled as Monet to make a working software product. Incredibly condescending. And good lucking ONLY hiring absolute masters for your engineering team as you scale beyond like, one or two hires. How many people in the world do you even think are that skilled?

Plus people require and deserve investment. It's okay to take in people who need development and turn them into solid engineers.

Truth, though I would argue very few areas in CS still need that caliber of dev - surely most (middling) shops would prefer the paint-by-numbers dev for most roles as it shows they're likely reliable and able to work within the team's existing framework than a maverick who may run circles around the rest (in both good and bad ways).

Ofc you need both, would be interested to see how a full 10x team would operate with no 'grunts' there to slog through all the tedious parts of the SWE process.

If the new hires do not reject the stack (or do the "this would have been so much better if it were written in Y") - in general, yes.

One of the bigger differences is speed, someone that has used a specific framework a lot will likely be much faster in creating new stuff in it than someone that never used it. A lot of typical tasks will fall into the "I've done that before" category, which does speed up things a lot.

For me the most time-consuming part when working with entirely new technology is figuring out how to do certain parts. And for some of them I will initially miss better approaches because I didn't know about them. The other part that is time-consuming are unexpected or complex behaviours that lead to bugs or unexpected behaviour. Every framework has a bunch of stuff that tends to surprise new developers, if you've already worked with it those parts will likely be familiar.