Startup engineering hiring anti-patterns (2021)
blog.southparkcommons.com
blog.southparkcommons.com
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.
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.
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.
Also, your examples are still fairly isolated - ultimately it was almost like using an outdated dictionary where words map to different things. Once you had the right "translation", the issue was fixed. That's not typical for employer feedback scenarios. Often the manager just wants the employee to be more diligent, attentive, have better Pareto 80/20 judgment, etc. You can't teach that to someone who doesn't get it.
“Hey it looks like we’re miscommunicating, what do you hear when I say X?” is a great way to start. Much much better than thinking quietly to yourself something like “Gosh that engineer is so dumb why don’t they ever do what I ask???” and never telling the employee that there’s a problem.
Ultimately people can’t fix a problem they don’t know exists. And despite their best efforts, they can’t read your mind.
If the manager asks you repeatedly about project X, and you repeatedly say "I haven't looked at that yet" or some other thing that accepts responsibility but clings to the original phrasing as an excuse to get yourself off the hook, the manager is correct about thinking "why don't they do what I ask". This indicates a judgment problem.
That sounds a lot like feedback to me. Your earlier comment said you don’t believe in that
Perhaps we have different definitions of “feedback”
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.
I get it, there are other cultures, some say "why don't you look into X" while others say "do X" - but if it takes years to calibrate while projects are not done and deadlines get missed, there is a much bigger problem.
[citation needed]
I'm very curious what your experiences are that lead you to this conclusion. It just seems wrong to me. If someone is spending too much time coordinating and not enough time coding or vice versa, you should tell them that explicitly so that they can switch their priorities. If someone is spending too much time writing well factored code and not enough time shipping or vice versa, you should tell them that so that they can change their approach. If someone needs to up their level expertise on your toolset in order to be productive, you should tell them that and point them to the right literature so that they can learn.
In none of these situations is it better to ... what are you even suggesting doing? like winking at them or something? awkward shifting in your seat? the silent treatment? using obtuse jargon?
Just tell people how you think they're doing and how you think they could improve! It may be awkward but you'll get over it...
Not giving feedback is just lazy, and borderline cowardize because it is an easy way to avoid conflicts.
Ideally, the employee’s “right thing” and the manager’s “right thing” are already well-aligned and “feedback” is more like “finetuning”.
If there is a large gap between the “right thing”s - aka what is considered good judgment, this situation is incorrigible with verbal feedback.
None of this is to imply malice (behave like a-holes), just that there are so few hours in a day, and trying to get an employee to pick up on everything through individualized verbal feedback is very taxing.
People are not interchangeable, with regard to any skill. This is even more so for communication which is a meta-skill over many skills.
The upside to greater communication effectiveness is higher performance with regard to skills downstream from communication (almost all of them, almost all the time).
Dismissing the job of adapting communication styles or substance to one side of any relationship just leaves upside potential on the table, or locks in unnecessary downside. This seems antithetical to what management is about - maximizing the value returned by those being managed.
Virtually every time when an employee doesn't work out, it's because they used bad judgment. Feedback is useless for that.
So for example, you will ask them to write documentation and they might technically write documentation, but maybe they write it unclear and don't even recognize it as such. Now, do you want to teach someone the concept of "clarity" like an English teacher? No! If they can't understand what level of clarity is needed based on other code in the company or other cues, it is a manifestation of a judgment problem.
Of course working together won't be instantly smooth like a Swiss watch movement, and you can make adjustments, but there cannot be a big judgement gap. The employee has to be able to recognize what you mean by "clear" without a full blown multi-year English lesson. If they consistently think their work as a "first draft", to be double-checked always by you and given specific feedback over, that is a judgment problem. Massive time-waste.
Yep, if you're that person's manager, what you do is you tell them, unambiguously, that the documentation they wrote was not clear, and you tell them why, and you direct them to examples of clear documentation and other resources that can help improve their ability to write documentation. That's the job! If you don't want to do the job of a good manager, that's fine, but you're doing a disservice to the people who work for you. And, weirdly, you seem to be patting yourself on the back for it. But make no mistake: being unwilling to mentor and teach is actually just bad management.
There are lots of books you can read to improve your management skills!
OP said that subtle clues are inferior, and even useless, compare to direct communication.
In your response, you said indirect, subtle communication is better, but your reason is that it is pointless.
You claim people can never improve, or, that helping them is pointless.
In this scenario, you are not arguing that subtly is better, you are arguing that nothing is better.
Yet by your metric, there is no logic in pointing this out...
You don't need to answer that. It is a rhetorical question. But consider what you wrote relative to good parenting, regardless of ages.
Nobody stops learning. On any measure, hopefully as long as we live, we are all still children relative to where we will be in a decade or two.
Mentoring, books, feedback, encouragement are valuable to give and receive throughout our lives because there is always another level of skill and wisdom to be achieved.
Obviously you can. People are not born with good judgment. Every single person with good judgment was mentored and taught it by different people throughout their lives.
Perhaps you mean that you can't mentor or teach adults good judgment? This is slightly more plausible but also wrong. People are capable of learning new tricks their entire life.
But especially if we're talking about the people I think we're talking about - entry level ish employees, probably in their 20s - no, this is silly, these are exactly the people you can mentor and teach good judgement. They are hungry for someone capable of doing so!
> Management has virtually nothing to do with mentorship and teaching.
I'm telling you, you need to read a book on management. You don't seem to know anything about it, but are nonetheless opining on it very confidently.
> Books will teach you nothing useful
Hahahaha no wonder you're so ill informed. You're wrong, books are great. If you go through life trying to reinvent the world from within the bubble of your own mind alone, you are doomed to fail.
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.
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.
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.
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?
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%?
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.
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.
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.
Almost everything you do is "wasted" effort at this stage (until it suddenly isn't, and arguable if failed experimentation is "wasted" in the first place), you need to be okay with that when in this role, and everyone needs to know how to do everything if you want to even have a prayer of a chance at a normal life.
You must learn new tech quickly, and pivot to different decisions if it makes more sense to do something another way. You also must be okay with terrible code written hastily, as long as it's good enough to not have any fatal bugs in it, and the only way I know how to do that is to have another person to validate/refute your work.
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'.
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?
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?
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.
So both tactics are even better? Fast offer making to candidates you judge are less likely to leave once hired?
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.
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.
> 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.
Hire for your stack is absolutely a good idea, unless you have no other option.
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.
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.
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.
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.
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.
You don't need painters, you need artists.
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.
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).
Hiring only Monets doesn't scale. Could the dude have even worked with himself?
https://www.mysanantonio.com/entertainment/arts-culture/book...
Plus people require and deserve investment. It's okay to take in people who need development and turn them into solid engineers.
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.
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.
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.
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.
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 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.
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.
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.
> 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.
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.
Hire a Ruby egnineer if you want an Ruby engineer.
I've found engineers being able to quickly pickup Python, Java and C.