6 ms·

> While this might allow you to refine your search criteria (and probably have strong funnel metrics), it misses the point that most frameworks are easy to lear

> While this might allow you to refine your search criteria (and probably have strong funnel metrics), it misses the point that most frameworks are easy to learn and ramp up on. Great engineers all have the capability to learn new languages and frameworks easily. There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting. Sure, any engineer can pick up any language and framework provided enough time. However, an expert in said language or framework is familiar with the nuance. 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. > You really need to flip this on its head. As a startup, you need to be comfortable taking risks on hires but also parting ways if it isn’t working out after 2–3 months. This will feel hard, but in the medium-to-long run will feel a lot more sustainable. Some of the best companies I have ever worked with/for have operated this way and it leads a culture that doesn’t compromise on high-performance. This advice works when you have infinite capital from VCs in a market flush with free money. You probably spend 30-50k to hire an engineer after paying for everything and all the labor involved. You're saying to just throw this money away? Slow to hire, slow to fire is the only sustainable way to run a company. If you want to "flip the funnel on it's head" hire contractors because the message I am getting here is "increase developer churn". Moreover what even defines "high performance"? I swear, these vulture capitalists are getting far too big for their own britches.

watwut 4y ago
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.
kaesar14 4y ago
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.
- vosper 4y ago
  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.
  - fallingknife 4y ago
    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.
    - Beltalowda 4y ago
      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.
BugsJustFindMe 4y ago
> 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.
fabian2k 4y ago
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.
deleted 4y ago
[deleted]
dimal 4y ago
> 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.
ctvo 4y ago
> 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.
adamsb6 4y ago
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?
- heromal 4y ago
  Would you mind expanding upon this "80/20" idea, please?
limelight 4y ago
> 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.

watwut 4y ago

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.

kaesar14 4y ago

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.

vosper 4y ago
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.
- fallingknife 4y ago
  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.
  - Beltalowda 4y ago
    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.

BugsJustFindMe 4y ago

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

fabian2k 4y ago

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.

deleted 4y ago

[deleted]

dimal 4y ago

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

ctvo 4y ago

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

adamsb6 4y ago

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?

heromal 4y ago
Would you mind expanding upon this "80/20" idea, please?

limelight 4y ago

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