Startup engineering hiring anti-patterns (2021)

https://blog.southparkcommons.com/startup-engineering-hiring-anti-patterns/

by catapultis • 4 years ago

112 101 4 years ago

blog.southparkcommons.com

Test0129• 4 years 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• 4 years 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.

kaesar142• 4 years 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.

vosper3• 4 years 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.

djbusby2• 4 years ago

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

You don't need painters, you need artists.

julik• 4 years ago

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.

BugsJustFindMe• 4 years 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• 4 years 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.

dimal• 4 years 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• 4 years 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• 4 years 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• 4 years ago

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

limelight• 4 years 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.

ShinySquirl• 4 years 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• 4 years 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• 4 years 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.

smcin• 4 years ago

What do you mean by smart? A well organized moderately smart person is more productive to a company than a disorganized genius.

Maybe Yes, maybe No, depends entirely on the job function they're in, the assumed style and heaviness of management and how much communication (if any), let alone oversight, they are obligated to have with their peers and subordinates. I have seen people who rarely emerged from their room/cubicle yet consistently produced brilliant code; versus people who looked and sounded amazing in meetings yet didn't deliver. There is definitely such a thing as too much communication, btw, which Elon Musk points out regularly. Have you ever been inside a company that talked and meeting'ed and memo'ed itself to death? I have. Sometimes you need a crew that simply quickly agree a sensible plan, shut up and build the dang thing lightning-fast before the cash runs out and the lights get turned off.

There are organization styles that thrive on lone wolves and ICs and know how to manage them hands-off, and ones that thrive on big-company style corporate 'team players'. There's a place for everyone.

'smart' IME is far less a measure of IQ/EQ and more 'robustly adaptive to whatever arbitrary management structure you try to force on them'.

mkl95• 4 years 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.

jampa3• 4 years 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• 4 years 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• 4 years 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.

jampa3• 4 years ago

Yes, after feedback is given I expect them to fix the behavior or to show progress in 2-4 weeks, if not then deliver the notice, or in some companies formalize a Performance Improvement Process.

The way I give feedback is by investigating first what is going on inside their lives, sometimes things happen and they just need some time to recover.

If there are no problems in their personal lifes then I give clear examples of where they are falling short, how that impacts the team, and what needs to be changed, and then give them incentives, like how fixing this behavior can improve their career.

Generally, feedback given to early hires is due to lack of communication, most new hires that we onboarded had tendencies of disappearing, skipping meetings, and not replying for many hours.

Turns out they had a freelancing background, where doing those things is common since they talk with clients once a week.

So I walk through them to set up their tools, set up notifications, configure a proper calendar, and general teamwork advice, not to just rush through delivering tasks and then they start to ramp up.

club_tropical13• 4 years ago

I think feedback is overrated. If somebody can't read the myriad of indirect and nonverbal communication to understand whether they are pulling their weight and meeting expectations, there is little words can fix. Feedback only works if the addressed issue is isolated and not symptomatic of a broader poor judgment problem.

Swizec3• 4 years ago

Cultures vary and only words can bridge the gap.

It took me years to figure out that “It’s not my favorite” is Californian for “I hate this”. At least months to realize that “We should do X” means “You should do X” and that “Would you mind checking Y” is a direct request with expectations attached.

Invictus0• 4 years ago

What if your colleague is autistic and struggles to understand indirect and nonverbal communication?

jampa3• 4 years ago

Sometimes people don't understand there is a problem unless is very clear. Culture also plays into the issue, I work with international teams, and the English needs to be very direct.

Like another comment says people from California are more subtle. OTOH my experience working with people from Eastern Europe is that in their culture there are not many nuances in conversation, they don't give it, so they don't expect it as well.

sanderjd8• 4 years ago

This honestly sounds like cowardice to me. Maybe you're right that explicit feedback is overrated; I don't know. But what is the drawback to providing it? Is there one, besides a fear of awkwardness? Even if the upside isn't strong, there is no real downside, so it's worth doing.

motoxpro• 4 years ago

I guess this gives me some insight that some people over the course of my life will want me to read non-verbal cues instead of using words to communicate.

baxtr2• 4 years ago

So you suggest great devs not only do great coding but are also mind readers?

P5fRxh5kUvp2th• 4 years ago

What's worse about the managers point is that's literally their job. If they're not comfortable doing that they don't need to be a manager.

Communitivity• 4 years ago

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

throwaway0060FF• 4 years 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_paper...

Top experts experienced in running large scale infrastructure from Facebook and Google supported the team.

hedora• 4 years ago

I’ve seen other startups with poor post-IPO performance make the same mistake:

Hire a bunch of domain experts, then let someone who has no clue why those people were hired (or why the team succeeded in the past) run the show.

meitros• 4 years 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• 4 years 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.

noodle2• 4 years 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• 4 years 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.

noodle2• 4 years ago

Sure, I've done that before many times, as well. It isn't my preference, generally speaking, for earlier-stage startups.

jkingsbery2• 4 years 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?

lumost2• 4 years 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%?

jkingsbery2• 4 years 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.

matai_kolila2• 4 years 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.

keeptrying2• 4 years 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• 4 years 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.

keeptrying2• 4 years ago

It used to be considered hard. Happy to know that you think otherwise.

sanderjd8• 4 years ago

... ruby doesn't have a particularly steep learning curve.

AnotherGoodName• 4 years 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• 4 years 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• 4 years 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.

bcarroll22• 4 years 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• 4 years 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• 4 years 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• 4 years 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.

Startup engineering hiring anti-patterns (2021)

Related Stories