11 ms·

Startup engineering hiring anti-patterns (2021)

112 points by catapultis 4y ago

bcarroll22 4y ago
> Hiring for a particular tool-chain or framework Anecdata, but it wasn't helpful for my company to remove this boundary. I bought into the idea based on some other articles and threads posted here recently, but when we actually widened searches and removed the requirements from the postings, it didn't really move the needle. I'm sure there's a group out there who isn't married to one stack, or is interested in learning a new one, but it was tough for me to feel like it was worth the added complexity of effectively screening and interviewing to accommodate it. Is the suggested approach to focus sourcing on certain stacks but be open to interviewing promising applicants who don't use them? I suppose I could see that if your technical interviews can accommodate it without much rework.
dimgl 4y ago
I actually don't agree with the first two points, at all. In fact, I've seen it NOT work firsthand for several startups I've worked for. > Don't hire for a particular tool-chain or framework This is horrible advice. When you hire devs who don't know the toolchain or frameworks, they make obvious and glaring mistakes, especially if they're being asked to move quickly. It takes someone who is experienced with that toolchain or framework to get them up to speed, especially in the very beginning. If you want to avoid issues hiring people who are well-versed in your toolchains or frameworks, pick the most popular, attractive and/or mature ones. > Don't hire specialists You should absolutely hire specialists (or people who have even a little bit of experience in your vertical) for parts of your product that really matter. Usually hiring those 80/20 software engineers or contractors to build the first version of your core product is a terrible idea, because once you have paying customers it's hard to fix the issues that a specialist would not have made. This kind of thing leads to bad UX for customers, incidents in production, heavy on-call rotations, ridiculous technical debt that never seems to get solved, etc. Bigger companies can afford to hire a generalist and then pair them with a product manager. You can also probably get away with this if you're a highly specialized founder that can get the generalist up to speed with your requirements. But specialists are almost always a better fit for core product pieces. To be clear, a specialist does not _only_ need to have done that throughout their career, but they should at least be very knowledgable in that area. > Comfort in the False Negative Zone More shockingly bad advice. Your first hires _are your most important hires_. They will either make or break your company. Again, I've seen this at a couple of startups I've worked at. These hires will create all of your initial code and infra that will sustain past seed and into product market fit.
tobilocker 4y ago
I would like to add: - Let senior engineers or architects do coding challenges - Ask stupid questions like "What's the runtime of bubble sort?"
lucasfcosta 4y ago
I agree with most aspects, especially with regards to specialists versus generalists. There is, however, one point with which I strongly disagree: > Comfort in the False Negative Zone In most jurisdictions, it's extremely expensive to fire someone. In Brazil, for example, you may have several months of severance pay and it's likely that you will have to significant face legal trouble, thus increasing overall costs with a lawyer (plus your time). I think this advice must be evaluated depending on your jurisdiction, not taken as an absolute.
suction 4y ago
Test0129 4y ago
> 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.
- 4y ago
ShinySquirl 4y ago
Having been a generalist at several startups throughout my career , can totally agree the highest leverage folks are usually just the smartest, not the most specialized.
- planetsprite 4y ago
  What do you mean by smart? A well organized moderately smart person is more productive to a company than a disorganized genius. Someone who can hyper focus on their competent domains is more effective than a super smart generalist who spreads themselves too thin.
  - polskibus 4y ago
    In startup context, when still experimenting with product-market fit and trying to win early customers, you need generalists to be able to quickly change direction when necessary. Specialists have too much inertia in such cases.
    - ivan_gammel 4y ago
      When searching for product-market fit the last thing you need is changing your tech stack on the fly. Generalist can help you to bootstrap your initial stack if she has a good knowledge of all components, but specialists allow you to focus on what really matters, building foundation of your ops while you experiment.
      - ghiculescu 4y ago
        A good generalist will not change your tech stack on the fly. Of course that’s a bad idea. I think what GP meant is more like they will be willing to change what they are working on day to day in response to what you learn from the market, and will be fine with throwing lots of things away if they don’t work. If you focus on foundational work too much that comes with the trade off that you can’t spend as much time building features. It’s common to see engineers fall into this trap.
mkl95 4y ago
> Hiring for a particular tool-chain or framework Startups do this bait and switch thing where they hire people who have no experience with their stack and domain, tell them it's OK if it takes them a while to learn it, and then expect them to magically learn it in a few months with no proper onboarding or training. In most of these cases disappointment is unavoidable both for the employer and their new hire.
jampa 4y ago
I agree with most of the things, but as someone whose responsibility is hiring people, the hiring for a particular toolchain or framework holds to some degree, for example, some places want to tick every single box. On the other hand, it is good to search for the affinity between the languages. Python to Ruby can ramp up faster than Python to C#/Java for example. So someone can have a harder time and in the end, won't enjoy the overall framework and leave. Another example: If you search for someone to take a Next.js project, a React engineer would work well, a Vue engineer might need more time but could also work, but a hardware engineer would struggle and might need too much time to produce. > Fire fast 2-3 months is way too short for letting someone go, and it is the problem for some startups nowadays. Most companies onboarding documentation sucks or does not exist, so you can hire a great engineer and think they are not. There are great unicorn engineers that can manage themselves in the project but most people need some help, feedback, and guidance. Also, most managers are afraid of giving feedback, I did some consultancies with startups that had managers complaining a lot about a certain engineer, already at the point to fire them. When I asked "do they know that you are unhappy with them?" they always say that they "implied" once or twice. When I give them feedback the improvement is noticeable just in weeks. Firing fast is sometimes just a cop-out to not give people proper feedback and properly managing them.
- catapultis 4y ago
  Interesting point on most managers not trying feedback first. In a scenario where feedback is clear and early, would that shorten your timeline for firing?
  - trowawee 4y ago
    Still doesn't really address the reality that onboarding is dreadful at most startups, I think. Docs tend to be bad/outdated/nonexistent and even "grab an onboarding buddy and talk through it with them" can fail easily, especially if the business is growing quickly. I do think there should be a cliff (maybe six months for seniors/9-12 months mids/juniors) where as the manager, you take a really hard look at how the person has adapted to the job/what they're contributing, while also taking into account their and the company's situations.
Communitivity 4y ago
I agree with the anti-patterns described. Based on my experience they are also anti-patterns for hiring at non-startups.
throwaway0060FF 4y ago
The author was the CTO for a company that’s stock has been flat or down since IPO. He made decisions and wrote a blog post here about the strategy he thinks is best, but the justification here seems to be confirmation bias and self confidence. The team that built out Dropbox’s (incredibly hard and complex) custom replacement for Amazon S3 hadn’t built distributed systems for 20 years. They were strong generalists who had a passion for learning and figured it out. This is a misrepresentation. A PHD who co-authored papers on distributed systems led the team. https://www.usenix.org/legacy/event/usenix09/tech/full_papers/cowling/cowling_html/ https://www.usenix.org/legacy/event/usenix09/tech/full_paper... Top experts experienced in running large scale infrastructure from Facebook and Google supported the team.
- meitros 4y ago
  That was definitely the weirdest point of that post. Even if you agree with "hire generalists over specialists", hiring generalists to build a custom S3 sounds like a terrible idea.
  - BigJono 4y ago
    Hot take from someone with a decent amount of experience in this area, but half way across the world: Everything in this article is a terrible idea that only works when you're drowning in investor money. If you try and apply articles like this outside of SV, you're going to be miserable. The only point in this article I can't completely refute with my own experience is the one about funnel discipline, and really that one just boils down to "write stuff down" (still good advice, but hardly needs to be said). Bad code spreads like cancer. 2-3 months is more than enough time to do serious damage. "Comfort in the false negative zone" is EXACTLY what you should be doing as a startup, your first bad hire will ruin you. Even the framing at the start of the article (first 10-20 engineers) is wrong. The point of a startup is to create an environment where your devs can literally 20-100x the average dev at a big corp (10x is honestly too conservative with the rubbish I see in my day job). Each hire in that environment gets exponentially more difficult if you're doing it right. I think realistically the startup phase probably tops out at 5-10 devs, but it depends heavily on how many 'large modules' you can split your business up into. If you're operating more like 5 startups working together then maybe you can get into the 10s and 20s. If you're hiring 10-20 devs to work on a single product, you're in no man's land. That's the point where you want to start converting to a business that relies on 1xers. To do that you need to scale up, and you can't do that unless you're already successful or you have boatloads of investor capital. What these bozos call a "startup" in Silicon Valley is actually just medium/big business dev that doesn't make any money yet. You're welcome to try that approach if you have the investment to make it work, but as someone that's consulted for a bunch of companies doing exactly that and seen all of them spiraling rapidly down the drain, I'd advise against it. This exact approach is why "99% of startups fail", it's just rolling a dice to try and skip the whole "building a sustainable business" phase and go straight to "billion dollar enterprise". That's totally fine if you understand exactly what's happening and what the trade off is. Not so fine if you don't understand and you're just following along with articles like this make it seem like generic good advice for all startups.
noodle 4y ago
> Hiring for a particular tool-chain or framework Dunno about this one. This is very much so FAANG type of thinking, not really (newer) startup type of thinking. Sacrificing a few man-months to training is something that is hard to do when that's a significant percent of your remaining runway.
- paulgb 4y ago
  I agree, but it's also a matter of degree and availability of the skill you're looking for in the market. I wouldn't hire a developer who has only touched Java to do React when there's lots of React developers out there, but as a Rust shop I'm happy to talk to a Go developer who seems open to learning Rust on the job.
  - noodle 4y ago
    Sure, I've done that before many times, as well. It isn't my preference, generally speaking, for earlier-stage startups.
jkingsbery 4y ago
A few thoughts: 1. There's been a big difference between mostly hiring generalists, and only hiring generalists. When you only hire generalists, all those generalists are trying to figure out the tech from scratch, which can be messy. If you have a specialist in a tech stack and then otherwise hire mostly generalists, you pair people who can learn quickly with someone who is capable of teaching them - this is a great mix. 2. Your hiring should reflect your goals. Sometimes startups really do just need to get a prototype out as soon as possible. But, sometimes, startups need help figuring out what kind of thing they should build in the first place. Those are two different skill sets, and not all engineers are great at helping shape product decisions. 3. While you need to consider the good and bad in all people, and recognize there is no perfect candidate, hiring someone who isn't a good fit for the role is often worse than not hiring someone at a startup. If you have 12 months of runway and you're burning 2-3 months being distracted by a Smart Jerk, then you might be jeopardizing your whole company. 4. So-called soft skills should be taken into consideration. It's not just someone's coding skills. Are they good at giving feedback? Are they effective at working with others? Do they demonstrate the ability to project plan?
- lumost 4y ago
  >3. While you need to consider the good and bad in all people, and recognize there is no perfect candidate, hiring someone who isn't a good fit for the role is often worse than not hiring someone at a startup. If you have 12 months of runway and you're burning 2-3 months being distracted by a Smart Jerk, then you might be jeopardizing your whole company. This really clarifies the hiring decision as an investment decision in the early stage. However I must ask, why not offer a good chunk of the company to engineers to ensure you have the best chance? If SmartJerk can sink the company, then is SmartNicePerson worth 5%?
  - jkingsbery 4y ago
    Lack of execution in your tech roadmap can sink your startup. However, effective execution by your engineering team does not guarantee success. The thing that leads to success is product-market fit and growing revenue. Tech can be a barrier preventing revenue, but the thing that determines revenue is product (does your thing solve a problem?) and marketing (can you make other people aware of your thing?). But there aren't a lot of product-minded engineers out there: most engineers get excited about scaling databases rather than marketing funnels. So the tradeoffs aren't symmetrical: a bad engineer hire hurts than a good engineer hire helps. In any case, 5% is a lot for any salaried employee. It's been a few years since I've been at a startup, but employee share pools used to be 15% or 20% - you wouldn't give a third or a quarter of your pool to one person.
tyronehed 4y ago
matai_kolila 4y ago
Learned the first and second lesson here the hard way; two times, we were burned by folks representing a "full stack" skillset with a preference for frontend, but what we got were React devs who've done small amounts of work in the backend. That said, if they had been smart/willing enough to pick it up quickly we'd have probably been fine, but both ended up falling into oddly similar mental health spirals and washed out after 3-4 months each. We never ended up filling the role, and are using the funds to hunker down through this VC downturn or until we can find P/M fit. Honestly seems fine, the volume of work isn't really justified in a 3rd engineering hire right now, we need to improve sales.
keeptrying 4y ago
The language agnostic approach works unless you're hiring for languages with a steep learning curve. Eg: Ruby Engineers. Hire a Ruby egnineer if you want an Ruby engineer. I've found engineers being able to quickly pickup Python, Java and C.
- ecshafer 4y ago
  Is ruby considered hard? I think I picked it up in a couple weeks and was productive. C is harder to pick up and be productive just due to the existence of footguns. Scala I thought was harder as well.
  - keeptrying 4y ago
    It used to be considered hard. Happy to know that you think otherwise.
- sanderjd 4y ago
  ... ruby doesn't have a particularly steep learning curve.
AnotherGoodName 4y ago
A straightforward rule for startups is to hire for the green flags rather than against the red flags. You have a job that needs to be done. You can't pay FAANG wages. If you find a candidate capable of doing the job ask yourself how much those red flags really matter. And just to be clear I'm not talking about 'horrible person' red flags but rather the 'other employers skip this person' red flags. You're a startup. You can accommodate the burnout eng who wants to work 2 days a week for 2/5ths the pay. The only thing you need to worry about are the green flags. Are they capable of doing the job?
- beachy 4y ago
  > You have a job that needs to be done. You can't pay FAANG wages. There was an article some time ago (can't find it now) that posited that one of the only points you can beat FAANG on is speed of hire. Having worked on recruitment software for many years, I believe this is true - most people just aren't that focused on having a fast hiring process, so that can be your edge. If you manage to get the offer to the candidate many days - or weeks - before FAANG, you may be able to lock up the deal before there is any real competition. I'd like to say it's easy but I'm not familiar with any companies that really live and breath this. But challenge yourself - why can't we fit more interviews into the day? Tell the candidate that there will be a panel decision within 30 minutes of each interview - if they pass, the next interview will follow right on, otherwise you'll wish them on their way. Why do an in person interview if you can do it virtually or over the phone? Why do two interviews when you could do one with both interviewers present? Why wait on references when you could make the offer dependant on getting them later? etc. etc. A lot of people talk the talk about speed of hire but how many really measure it and track themselves against it?
  - daniel-grigg 4y ago
    Nice idea though what happens is you manage to quickly recruit the person and then a month later the other job that they’ve been slowly recruited on, eventuates and they walk off, leaving you worse off than if you never hired them. Personally I just try to find people that have already experienced years of pain of big companies and rejoice in the freedom most startups offers.

112 points by catapultis 4y ago

> Hiring for a particular tool-chain or framework Anecdata, but it wasn't helpful for my company to remove this boundary. I bought into the idea based on some other articles and threads posted here recently, but when we actually widened searches and removed the requirements from the postings, it didn't really move the needle. I'm sure there's a group out there who isn't married to one stack, or is interested in learning a new one, but it was tough for me to feel like it was worth the added complexity of effectively screening and interviewing to accommodate it. Is the suggested approach to focus sourcing on certain stacks but be open to interviewing promising applicants who don't use them? I suppose I could see that if your technical interviews can accommodate it without much rework.

dimgl 4y ago

I actually don't agree with the first two points, at all. In fact, I've seen it NOT work firsthand for several startups I've worked for. > Don't hire for a particular tool-chain or framework This is horrible advice. When you hire devs who don't know the toolchain or frameworks, they make obvious and glaring mistakes, especially if they're being asked to move quickly. It takes someone who is experienced with that toolchain or framework to get them up to speed, especially in the very beginning. If you want to avoid issues hiring people who are well-versed in your toolchains or frameworks, pick the most popular, attractive and/or mature ones. > Don't hire specialists You should absolutely hire specialists (or people who have even a little bit of experience in your vertical) for parts of your product that really matter. Usually hiring those 80/20 software engineers or contractors to build the first version of your core product is a terrible idea, because once you have paying customers it's hard to fix the issues that a specialist would not have made. This kind of thing leads to bad UX for customers, incidents in production, heavy on-call rotations, ridiculous technical debt that never seems to get solved, etc. Bigger companies can afford to hire a generalist and then pair them with a product manager. You can also probably get away with this if you're a highly specialized founder that can get the generalist up to speed with your requirements. But specialists are almost always a better fit for core product pieces. To be clear, a specialist does not _only_ need to have done that throughout their career, but they should at least be very knowledgable in that area. > Comfort in the False Negative Zone More shockingly bad advice. Your first hires _are your most important hires_. They will either make or break your company. Again, I've seen this at a couple of startups I've worked at. These hires will create all of your initial code and infra that will sustain past seed and into product market fit.

tobilocker 4y ago

I would like to add: - Let senior engineers or architects do coding challenges - Ask stupid questions like "What's the runtime of bubble sort?"

lucasfcosta 4y ago

I agree with most aspects, especially with regards to specialists versus generalists. There is, however, one point with which I strongly disagree: > Comfort in the False Negative Zone In most jurisdictions, it's extremely expensive to fire someone. In Brazil, for example, you may have several months of severance pay and it's likely that you will have to significant face legal trouble, thus increasing overall costs with a lawyer (plus your time). I think this advice must be evaluated depending on your jurisdiction, not taken as an absolute.

suction 4y ago

Test0129 4y ago

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

ShinySquirl 4y ago

Having been a generalist at several startups throughout my career , can totally agree the highest leverage folks are usually just the smartest, not the most specialized.

planetsprite 4y ago
What do you mean by smart? A well organized moderately smart person is more productive to a company than a disorganized genius. Someone who can hyper focus on their competent domains is more effective than a super smart generalist who spreads themselves too thin.
- polskibus 4y ago
  In startup context, when still experimenting with product-market fit and trying to win early customers, you need generalists to be able to quickly change direction when necessary. Specialists have too much inertia in such cases.
  - ivan_gammel 4y ago
    When searching for product-market fit the last thing you need is changing your tech stack on the fly. Generalist can help you to bootstrap your initial stack if she has a good knowledge of all components, but specialists allow you to focus on what really matters, building foundation of your ops while you experiment.
    - ghiculescu 4y ago
      A good generalist will not change your tech stack on the fly. Of course that’s a bad idea. I think what GP meant is more like they will be willing to change what they are working on day to day in response to what you learn from the market, and will be fine with throwing lots of things away if they don’t work. If you focus on foundational work too much that comes with the trade off that you can’t spend as much time building features. It’s common to see engineers fall into this trap.

mkl95 4y ago

> Hiring for a particular tool-chain or framework Startups do this bait and switch thing where they hire people who have no experience with their stack and domain, tell them it's OK if it takes them a while to learn it, and then expect them to magically learn it in a few months with no proper onboarding or training. In most of these cases disappointment is unavoidable both for the employer and their new hire.

jampa 4y ago

I agree with most of the things, but as someone whose responsibility is hiring people, the hiring for a particular toolchain or framework holds to some degree, for example, some places want to tick every single box. On the other hand, it is good to search for the affinity between the languages. Python to Ruby can ramp up faster than Python to C#/Java for example. So someone can have a harder time and in the end, won't enjoy the overall framework and leave. Another example: If you search for someone to take a Next.js project, a React engineer would work well, a Vue engineer might need more time but could also work, but a hardware engineer would struggle and might need too much time to produce. > Fire fast 2-3 months is way too short for letting someone go, and it is the problem for some startups nowadays. Most companies onboarding documentation sucks or does not exist, so you can hire a great engineer and think they are not. There are great unicorn engineers that can manage themselves in the project but most people need some help, feedback, and guidance. Also, most managers are afraid of giving feedback, I did some consultancies with startups that had managers complaining a lot about a certain engineer, already at the point to fire them. When I asked "do they know that you are unhappy with them?" they always say that they "implied" once or twice. When I give them feedback the improvement is noticeable just in weeks. Firing fast is sometimes just a cop-out to not give people proper feedback and properly managing them.

catapultis 4y ago
Interesting point on most managers not trying feedback first. In a scenario where feedback is clear and early, would that shorten your timeline for firing?
- trowawee 4y ago
  Still doesn't really address the reality that onboarding is dreadful at most startups, I think. Docs tend to be bad/outdated/nonexistent and even "grab an onboarding buddy and talk through it with them" can fail easily, especially if the business is growing quickly. I do think there should be a cliff (maybe six months for seniors/9-12 months mids/juniors) where as the manager, you take a really hard look at how the person has adapted to the job/what they're contributing, while also taking into account their and the company's situations.

Communitivity 4y ago

I agree with the anti-patterns described. Based on my experience they are also anti-patterns for hiring at non-startups.

throwaway0060FF 4y ago

The author was the CTO for a company that’s stock has been flat or down since IPO. He made decisions and wrote a blog post here about the strategy he thinks is best, but the justification here seems to be confirmation bias and self confidence. The team that built out Dropbox’s (incredibly hard and complex) custom replacement for Amazon S3 hadn’t built distributed systems for 20 years. They were strong generalists who had a passion for learning and figured it out. This is a misrepresentation. A PHD who co-authored papers on distributed systems led the team. https://www.usenix.org/legacy/event/usenix09/tech/full_papers/cowling/cowling_html/ https://www.usenix.org/legacy/event/usenix09/tech/full_paper... Top experts experienced in running large scale infrastructure from Facebook and Google supported the team.

meitros 4y ago
That was definitely the weirdest point of that post. Even if you agree with "hire generalists over specialists", hiring generalists to build a custom S3 sounds like a terrible idea.
- BigJono 4y ago
  Hot take from someone with a decent amount of experience in this area, but half way across the world: Everything in this article is a terrible idea that only works when you're drowning in investor money. If you try and apply articles like this outside of SV, you're going to be miserable. The only point in this article I can't completely refute with my own experience is the one about funnel discipline, and really that one just boils down to "write stuff down" (still good advice, but hardly needs to be said). Bad code spreads like cancer. 2-3 months is more than enough time to do serious damage. "Comfort in the false negative zone" is EXACTLY what you should be doing as a startup, your first bad hire will ruin you. Even the framing at the start of the article (first 10-20 engineers) is wrong. The point of a startup is to create an environment where your devs can literally 20-100x the average dev at a big corp (10x is honestly too conservative with the rubbish I see in my day job). Each hire in that environment gets exponentially more difficult if you're doing it right. I think realistically the startup phase probably tops out at 5-10 devs, but it depends heavily on how many 'large modules' you can split your business up into. If you're operating more like 5 startups working together then maybe you can get into the 10s and 20s. If you're hiring 10-20 devs to work on a single product, you're in no man's land. That's the point where you want to start converting to a business that relies on 1xers. To do that you need to scale up, and you can't do that unless you're already successful or you have boatloads of investor capital. What these bozos call a "startup" in Silicon Valley is actually just medium/big business dev that doesn't make any money yet. You're welcome to try that approach if you have the investment to make it work, but as someone that's consulted for a bunch of companies doing exactly that and seen all of them spiraling rapidly down the drain, I'd advise against it. This exact approach is why "99% of startups fail", it's just rolling a dice to try and skip the whole "building a sustainable business" phase and go straight to "billion dollar enterprise". That's totally fine if you understand exactly what's happening and what the trade off is. Not so fine if you don't understand and you're just following along with articles like this make it seem like generic good advice for all startups.

noodle 4y ago

> Hiring for a particular tool-chain or framework Dunno about this one. This is very much so FAANG type of thinking, not really (newer) startup type of thinking. Sacrificing a few man-months to training is something that is hard to do when that's a significant percent of your remaining runway.

paulgb 4y ago
I agree, but it's also a matter of degree and availability of the skill you're looking for in the market. I wouldn't hire a developer who has only touched Java to do React when there's lots of React developers out there, but as a Rust shop I'm happy to talk to a Go developer who seems open to learning Rust on the job.
- noodle 4y ago
  Sure, I've done that before many times, as well. It isn't my preference, generally speaking, for earlier-stage startups.

jkingsbery 4y ago

A few thoughts: 1. There's been a big difference between mostly hiring generalists, and only hiring generalists. When you only hire generalists, all those generalists are trying to figure out the tech from scratch, which can be messy. If you have a specialist in a tech stack and then otherwise hire mostly generalists, you pair people who can learn quickly with someone who is capable of teaching them - this is a great mix. 2. Your hiring should reflect your goals. Sometimes startups really do just need to get a prototype out as soon as possible. But, sometimes, startups need help figuring out what kind of thing they should build in the first place. Those are two different skill sets, and not all engineers are great at helping shape product decisions. 3. While you need to consider the good and bad in all people, and recognize there is no perfect candidate, hiring someone who isn't a good fit for the role is often worse than not hiring someone at a startup. If you have 12 months of runway and you're burning 2-3 months being distracted by a Smart Jerk, then you might be jeopardizing your whole company. 4. So-called soft skills should be taken into consideration. It's not just someone's coding skills. Are they good at giving feedback? Are they effective at working with others? Do they demonstrate the ability to project plan?

lumost 4y ago
>3. While you need to consider the good and bad in all people, and recognize there is no perfect candidate, hiring someone who isn't a good fit for the role is often worse than not hiring someone at a startup. If you have 12 months of runway and you're burning 2-3 months being distracted by a Smart Jerk, then you might be jeopardizing your whole company. This really clarifies the hiring decision as an investment decision in the early stage. However I must ask, why not offer a good chunk of the company to engineers to ensure you have the best chance? If SmartJerk can sink the company, then is SmartNicePerson worth 5%?
- jkingsbery 4y ago
  Lack of execution in your tech roadmap can sink your startup. However, effective execution by your engineering team does not guarantee success. The thing that leads to success is product-market fit and growing revenue. Tech can be a barrier preventing revenue, but the thing that determines revenue is product (does your thing solve a problem?) and marketing (can you make other people aware of your thing?). But there aren't a lot of product-minded engineers out there: most engineers get excited about scaling databases rather than marketing funnels. So the tradeoffs aren't symmetrical: a bad engineer hire hurts than a good engineer hire helps. In any case, 5% is a lot for any salaried employee. It's been a few years since I've been at a startup, but employee share pools used to be 15% or 20% - you wouldn't give a third or a quarter of your pool to one person.

tyronehed 4y ago

matai_kolila 4y ago

Learned the first and second lesson here the hard way; two times, we were burned by folks representing a "full stack" skillset with a preference for frontend, but what we got were React devs who've done small amounts of work in the backend. That said, if they had been smart/willing enough to pick it up quickly we'd have probably been fine, but both ended up falling into oddly similar mental health spirals and washed out after 3-4 months each. We never ended up filling the role, and are using the funds to hunker down through this VC downturn or until we can find P/M fit. Honestly seems fine, the volume of work isn't really justified in a 3rd engineering hire right now, we need to improve sales.

keeptrying 4y ago

The language agnostic approach works unless you're hiring for languages with a steep learning curve. Eg: Ruby Engineers. Hire a Ruby egnineer if you want an Ruby engineer. I've found engineers being able to quickly pickup Python, Java and C.

ecshafer 4y ago
Is ruby considered hard? I think I picked it up in a couple weeks and was productive. C is harder to pick up and be productive just due to the existence of footguns. Scala I thought was harder as well.
- keeptrying 4y ago
  It used to be considered hard. Happy to know that you think otherwise.
sanderjd 4y ago
... ruby doesn't have a particularly steep learning curve.

AnotherGoodName 4y ago

A straightforward rule for startups is to hire for the green flags rather than against the red flags. You have a job that needs to be done. You can't pay FAANG wages. If you find a candidate capable of doing the job ask yourself how much those red flags really matter. And just to be clear I'm not talking about 'horrible person' red flags but rather the 'other employers skip this person' red flags. You're a startup. You can accommodate the burnout eng who wants to work 2 days a week for 2/5ths the pay. The only thing you need to worry about are the green flags. Are they capable of doing the job?

beachy 4y ago
> You have a job that needs to be done. You can't pay FAANG wages. There was an article some time ago (can't find it now) that posited that one of the only points you can beat FAANG on is speed of hire. Having worked on recruitment software for many years, I believe this is true - most people just aren't that focused on having a fast hiring process, so that can be your edge. If you manage to get the offer to the candidate many days - or weeks - before FAANG, you may be able to lock up the deal before there is any real competition. I'd like to say it's easy but I'm not familiar with any companies that really live and breath this. But challenge yourself - why can't we fit more interviews into the day? Tell the candidate that there will be a panel decision within 30 minutes of each interview - if they pass, the next interview will follow right on, otherwise you'll wish them on their way. Why do an in person interview if you can do it virtually or over the phone? Why do two interviews when you could do one with both interviewers present? Why wait on references when you could make the offer dependant on getting them later? etc. etc. A lot of people talk the talk about speed of hire but how many really measure it and track themselves against it?
- daniel-grigg 4y ago
  Nice idea though what happens is you manage to quickly recruit the person and then a month later the other job that they’ve been slowly recruited on, eventuates and they walk off, leaving you worse off than if you never hired them. Personally I just try to find people that have already experienced years of pain of big companies and rejoice in the freedom most startups offers.