Startup engineering hiring anti-patterns (2021)(blog.southparkcommons.com)
blog.southparkcommons.com
Startup engineering hiring anti-patterns (2021)
https://blog.southparkcommons.com/startup-engineering-hiring-anti-patterns/
104 comments
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.
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?
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.
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.
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.
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.
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.
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.
When an employee doesn't work out, it is virtually never because, had you used different words, the issue would have been fixed.
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.
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.
> When an employee doesn't work out, it is virtually never because, had you used different words, the issue would have been fixed.
[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...
[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...
You can take things on/off someone's plate, but you cannot improve them into good judgment. If you are letting someone go, it is almost never the case that, had you given a different set of tasks, they would have been a good employee.
Again, I think this just isn't accurate. Many issues really are due to unclear expectations. Maybe because a lot of people have bad managers who are scared to just give clear feedback...
You expect something from me, tell me. I don't like to guess and I am no telepath, so withou you telling me there is no way for me to know. Left to my own devices, I do what I consider the "right" thing. And without contrary feedback, I will continue to consider this to be right thing. People usually do not do wrong things, or behave like a*holes, intentionally.
Not giving feedback is just lazy, and borderline cowardize because it is an easy way to avoid conflicts.
Not giving feedback is just lazy, and borderline cowardize because it is an easy way to avoid conflicts.
Not getting into pointless conflicts is not cowardice; it is prudence. I am not conflict avoidant, but I’m not going to hand hold someone - double checking their work and giving feedback takes a huge amount of effort. It can only really be done a few times, at the beginning of a person’s employment.
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.
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.
You seem to be ignoring the importance of centuries of concern and acquired wisdom on how important good communication is, by emperors, CEOs, managers, ... etc., for maximizing the value of any relationship.
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.
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.
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.
The drawback is that most of the time, words are highly reductive and inferior to indirect and nonverbal communication. They are only useful if the issue is extremely isolated or about adding/removing things off someone's plate.
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.
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.
> 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?
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!
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!
1) You cannot mentor and teach good judgment.
2) Management has virtually nothing to do with mentorship and teaching. It is more akin to having a garden. You have a particular type of soil and sunshine and rainfall (tasks, company culture, pre-existing teammates, etc) and you pick the right seeds that will flourish in this environment.
3) Books will teach you nothing useful, because they are almost always a) written by psychologists who couldn't manage a group of chickens let alone humans b) written by competent managers for the purpose of having a feel-good career capstone, not transmit actual advice. What they would tell you behind closed doors is virtually diametrically opposed to the platitudes in management books.
You and the other poster are discussing different things.
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...
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 cannot mentor and teach good judgment.
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.
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.
Do you have children?
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.
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.
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.
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.
And yet, your examples are when words did not bridge the gap. You think "You should do X" is more clear, but to the Californian in question, that framing would sound very harsh. If they gave you "feedback", the manager would think they expressed dissatisfaction, while you'd come out of the same meeting thinking things are great. Human language is not computer code and an employee that takes years to understand that while they are not meeting expectations is not worth it.
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.
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.
Yes and the quickest way to solve that problem was to have a conversation about it. Not by ignoring the issue and hoping things magically work out.
“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.
“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.
"never telling the employee that there’s a problem" is almost never the case. Your comment mentioned years of miscommunication. If they never expect an update or ever ask you about that thing you were supposed to do, I guess that's one thing, but it's highly unusual. Usually the manager will check in several times "so where's project X at?" and your response would easily clear up the confusion. 'I don't think that's on my plate, I thought you said X' would lead to a quick conversation where the problem is solved, and mappings are updated. This doesn't take more than 2-3 weeks of coworking to figure out, not years.
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.
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.
> would lead to a quick conversation where the problem is solved, and mappings are updated
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”
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”
I cannot see how, if the issue was a simple mapping update like this, it would have taken years to come up.
No this isn't right. "You should do X" is clear to everyone. You're right that it will sound more or less harsh to different people, but the meaning is not unclear as it is when using obtuse language.
Harshness is absolutely a metadata of language, at least as important as the dry content. If I say "pass me the salt", but do so with a loud and angry voice, far more is being communicated than the simple request to pass a salt. Phrasiology is part of communicating harshness. Failure to read language metadata is a judgment problem. With good employees, no matter the background, it almost never takes more than a few weeks to accurately interpret metadata. If they don't and they constantly fall back to "well, actually, a robot might not have understood it" and constantly expect disambiguation, this is an insurmountable issue.
You're overthinking it. You're being too clever by half, or maybe too clever by more like 9/10. A good manager really does just give clear feedback, and it's helpful. It doesn't solve all problems for all people, but it's the place to start, not all this mumbo jumbo about metadata or whatever.
What if your colleague is autistic and struggles to understand indirect and nonverbal communication?
It it’s a colleague, I’d limit my exposure. If I am manager, I wouldn’t hire such a person or fire asap. Inability to process indirect and nonverbal communication - aka 90% of human communication - is a major energy sap and drag to anyone interacting with this person. The thing that only responds to explicit verbal instruction is called a robot. When hiring, people expect to be hiring a human with good (albeit ineffable) judgment, not a robot with blank slate.
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.
*most people
So you suggest great devs not only do great coding but are also mind readers?
No. “Mind reader” implies someone is reaching into deep dark corners of your mind and figuring out things that are never externalized. There is enormous communication that is completely clear and unambiguous, but not verbal in the incredibly direct and explicit, almost like a legal contract-y way people pushing back seem to want. You are expected to pick up on those. An employee who constantly needs you collapse all these dimensions into the verbal sphere is almost never worth it.
Could you give an example maybe? I really struggle to understand what you mean
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.
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.
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.
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.
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.
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.
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.
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?
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?
>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%?
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%?
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.
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.
Fair, however I'd generally expect that you are more likely to find engineers who care about your product if you give more equity. In times past, great engineers moved to startups to satisfy their ambition. Now big-tech is giving out liquid compensation that is 2-3x more valuable than a startup compensation package at exit. All else being equal, a large well funded corporation is more likely to find product market fit than a small underfunded one.
> 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.
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.
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.
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.
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.
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.
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.
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.
If we are not talking about one person team, frequent context switching is counterproductive and same jobs are better done by two specialists (e.g. FE and BE) than two generalists. It’s also a common trap to build a lot of features without any evidence that users need them, 30-40% of effort wasted on something that does not have enough business value or on validating with code hypotheses that could be validated by one email with typeform.
Nooo, as literally a person doing this right now, splitting up the work is a terrible idea.
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.
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.
> 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'.
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'.
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?
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?
> 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?
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?
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.
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.
Good point.
So both tactics are even better? Fast offer making to candidates you judge are less likely to leave once hired?
So both tactics are even better? Fast offer making to candidates you judge are less likely to leave once hired?
> 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.
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.
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.
Sure, I've done that before many times, as well. It isn't my preference, generally speaking, for earlier-stage startups.
> 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.
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.
> 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.
I disagree. Expanding the range of positives to decrease false negatives does not mean that the goal is "increase developer churn". Many startups seem to be so petrified of hiring the wrong person that they miss out on a lot of people that would be good enough or even great. And being "slow to hire" is not a free option. The constant interviewing is a drain on current resources' time and energy. It's a constant distraction. And the longer you wait for the "perfect" person (who you never find) that's time that you're not getting shit done because you're understaffed. There's a balance, and too many companies are paralyzed with indecision, leading to a default "no hire" if someone isn't perfect. This is just arguing for a reasonable recalibration of standards.
> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.
I disagree.
I've hired (and like to think I'm part of this group) folks that can comfortably pick up any domain, not just a language or framework. That's to say, if I needed them to get depth on compiler back-ends because that was part of our value proposition, they could quickly get up to speed on the state of the art and be productive. Maybe they'd start by reading through LLVM documentation and code, understanding its optimizations, and then catch up on the latest papers? Who knows, but they'd have some confidence in weeks.
Would they be on par with world class experts? No. And I don't think the OP claimed this, but not being limited by languages and frameworks isn't that rare.
I disagree.
I've hired (and like to think I'm part of this group) folks that can comfortably pick up any domain, not just a language or framework. That's to say, if I needed them to get depth on compiler back-ends because that was part of our value proposition, they could quickly get up to speed on the state of the art and be productive. Maybe they'd start by reading through LLVM documentation and code, understanding its optimizations, and then catch up on the latest papers? Who knows, but they'd have some confidence in weeks.
Would they be on par with world class experts? No. And I don't think the OP claimed this, but not being limited by languages and frameworks isn't that rare.
> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.
There might be a disconnect, but I think it's probably not in the direction you expect.
The vast majority of high-performing engineering teams (good startups, big tech companies) don't hire standard SWEs for specific language/framework expertise. The truth absolutely is that languages are interoperable enough that someone who is smart and understand the underlying principles can get up to speed in a new ecosystem quickly.
There might be a disconnect, but I think it's probably not in the direction you expect.
The vast majority of high-performing engineering teams (good startups, big tech companies) don't hire standard SWEs for specific language/framework expertise. The truth absolutely is that languages are interoperable enough that someone who is smart and understand the underlying principles can get up to speed in a new ecosystem quickly.
If you hire people that can't 80/20 their way to learning a new framework or language within a few weeks, what are you going to do with those folks when you need to adopt some new framework or language? Replace them? Halt development for a few months?
Would you mind expanding upon this "80/20" idea, please?
I think that you are overstating the difficulty of solving new nuanced problems and also of their frequency. New frameworks dont have that much of a depth in them yet ... and old one are super googlable. The hardest problems have zero to do with frameworks and a lot to do with local codebase. Because you cant google any part of those and generally code quality is lower then those of highly acclaimed frameworks/languages.
> More often than not if your problem is harder than slamming together off the shelf components to fleece the consumers of their money the nuance comes into play quickly.
Most of what is harder then "slamming together off the shelf components" is still not that difficult to solve. You cant do it if you are super new, but you can actually do it after few months in.
> More often than not if your problem is harder than slamming together off the shelf components to fleece the consumers of their money the nuance comes into play quickly.
Most of what is harder then "slamming together off the shelf components" is still not that difficult to solve. You cant do it if you are super new, but you can actually do it after few months in.
> There is just such a disconnect with reality here I am having a hard time thinking the author has done any actual technical recruiting.
Agreed. Not to mention that the author leans very heavily on the notion of "great engineers" as if that describes even a small fraction of candidates. In hundreds of technical interviews across a decade of interviewing in multiple industries, I can count on one hand the number of actually great engineers I've encountered. 99% of everyone who calls themselves a senior software engineer is mediocre at best. I'd rather hire someone who can do the specific work I need them to do who isn't otherwise very good at engineering, because that means I can fill the role after two interviews instead of twenty.
Agreed. Not to mention that the author leans very heavily on the notion of "great engineers" as if that describes even a small fraction of candidates. In hundreds of technical interviews across a decade of interviewing in multiple industries, I can count on one hand the number of actually great engineers I've encountered. 99% of everyone who calls themselves a senior software engineer is mediocre at best. I'd rather hire someone who can do the specific work I need them to do who isn't otherwise very good at engineering, because that means I can fill the role after two interviews instead of twenty.
If you have at least one or two engineers familiar with the language it is not hard to teach the rest of the team good practices.
I don't think good practices is enough. It's all the little bits of knowledge about what works and what's the right way to do things that you pick up over years of working in and around a framework. Could an excellent C++ dev become and excellent developer working in React with Redux and Typescript and NextJS and Material UI? Of course. And probably less effort than training someone who's never written code before. But that's way, way more than just learning some good practices. It could be _years_ of collective effort (or more likely, just slowly written not-so-good-code) to bring a team up to an advanced or expert level.
Hire for your stack is absolutely a good idea, unless you have no other option.
Hire for your stack is absolutely a good idea, unless you have no other option.
Most of the benefit of hiring smart people in a startup is not that they do brilliant things, but that they don't do stupid things. So not really necessary that they be domain experts in most cases.
The thing is that even good engineers but inexperienced with some language or environment are exactly the sort of people likely to do "stupid things". People will shoehorn patterns that work well in X into Y where it doesn't really work, they misunderstand things, or don't know something exists, or use things incorrectly leading to subtle bugs, etc. And then a year later you discover "oh, in hindsight now that I know more about this language that was silly, but now we're stuck with it",
If we're talking about startups, then you often don't really have time or staff to spend on training. You want to be able to say "we need X!" and be confident it gets implemented in a reasonable way that's not going to bite you down the line. If you do have the money and staff to train people, then by all means do so, but "super early stage" startups (quoting the article): you're setting the foundation of what the entire business will be built on for years to come and typically have a limited budget to do that. You need people who can get things done reasonably fast but also do it in a way that's not going to cause a lot of headaches in 2 years down the line, and this takes a certain level of experience.
My advice for startups is exactly the opposite: use tools and languages you're already familiar with, unless you have a very good reason not to. Maybe there's some other language that's a somewhat better fit, but being familiar and experienced counts for a lot. I've seen a number of startups really suffer from using $new_tech a few years down the line simply because they used it badly on account of being new to it.
If we're talking about startups, then you often don't really have time or staff to spend on training. You want to be able to say "we need X!" and be confident it gets implemented in a reasonable way that's not going to bite you down the line. If you do have the money and staff to train people, then by all means do so, but "super early stage" startups (quoting the article): you're setting the foundation of what the entire business will be built on for years to come and typically have a limited budget to do that. You need people who can get things done reasonably fast but also do it in a way that's not going to cause a lot of headaches in 2 years down the line, and this takes a certain level of experience.
My advice for startups is exactly the opposite: use tools and languages you're already familiar with, unless you have a very good reason not to. Maybe there's some other language that's a somewhat better fit, but being familiar and experienced counts for a lot. I've seen a number of startups really suffer from using $new_tech a few years down the line simply because they used it badly on account of being new to it.
I agree with most of what you're saying. I think at least the first 2 engineers in the team should be experienced in the stack. And nobody inexperienced should ever be making initial design and architecture decisions.
The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.
The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.
In a more established company that works well. In very early stage startups? It can, but it's more of a risk. Most early-stage startups are not well organised and the typical situation is that you can do whatever with fairly little oversight. The 3rd, 4th, or 5th engineer can still make a right mess of things.
This applies even more so if your country has fairly strict labour regulations by the way, where it's hard to fire people; bit of a different discussion, but not completely unrelated here.
This applies even more so if your country has fairly strict labour regulations by the way, where it's hard to fire people; bit of a different discussion, but not completely unrelated here.
That's why for me having a strongly technical / expert-level co-founder is really important. I'm lead engineer and the first non-founder coder at at tiny startup, and I just spent several months rebuiling the entire application after spending several more months of grappling with the mess made by the weakly-technical CTO. This is very much not what a super-early startup should be spending it's time on, but there was no way forward with what we had.
If you're a senior engineer joining a startup where the initial application has been built by a non-technical (or weakly-technical aka junior-dev level) person then beware! It may be much, much more of a mess than you are expecting. Go in with your eyes open. You might not have the luxury of fixing it properly, as I have just had. So it better be a promising startup.
If you're a senior engineer joining a startup where the initial application has been built by a non-technical (or weakly-technical aka junior-dev level) person then beware! It may be much, much more of a mess than you are expecting. Go in with your eyes open. You might not have the luxury of fixing it properly, as I have just had. So it better be a promising startup.
I quit my last job due to a situation like this.
The person that built the entire application was very weak technically. I'm pretty sure the motivation for bringing me in was that I would "fix up" the entire mess. There was no documentation, no tests, and tons of code copy/pasted everywhere.
I spent a year trying to improve it, but for every thing I'd clean up, the original engineer would write twice as much new code without consulting me. I tried to get them to do architecture reviews and code reviews, but everything was always an emergency that needed to go live immediately.
If I ever thought about joining a startup that small again, I'd make sure I got to look at a representative chunk of their code base first. And if it looked like it needed a lot of work, I'd grill the existing engineers hard to make sure I can actually do what they want me to do.
The person that built the entire application was very weak technically. I'm pretty sure the motivation for bringing me in was that I would "fix up" the entire mess. There was no documentation, no tests, and tons of code copy/pasted everywhere.
I spent a year trying to improve it, but for every thing I'd clean up, the original engineer would write twice as much new code without consulting me. I tried to get them to do architecture reviews and code reviews, but everything was always an emergency that needed to go live immediately.
If I ever thought about joining a startup that small again, I'd make sure I got to look at a representative chunk of their code base first. And if it looked like it needed a lot of work, I'd grill the existing engineers hard to make sure I can actually do what they want me to do.
Sorry you had that experience. I was also planning to quit if I didn’t get my way on having a rewrite (though I never told anyone at the company my plans). I was lucky that the CTO was not unaware of the weaknesses, and listened to me. And now they mostly stay out of the codebase. It could have gone the other way.
I've been at a startup where this was the case, but they didn't start over, and it was a disaster that, at least partially, was the cause of the failure of the company. Props to you for making the difficult, but correct, choice.
Going "up levels" or side to side is very easy compared to "going down" it's a pain to teach and get people to truly understand stuff like pointers if they've never touched them.
Anyone could paint-by-numbers a Monet. But only Monet could create a new one.
You don't need painters, you need artists.
You don't need painters, you need artists.
This is unbelievably condescending.
I'll follow up on your false analogy to try to get you to your mistake: even Monet had to learn before he became Monet! Even Monet had to fight before he became Monet. He even got rejected and created an art salon because he and his peers were misunderstood by art intelligentsia.
So by rejecting engineers that you deem not worthy of being artists, you're just putting yourself in the position of the bourgeoisie that rejected Monet in the first place.
You're ignoring potential for talent. And really am I glad you're doing that because I then get to train and hire them.
I'll follow up on your false analogy to try to get you to your mistake: even Monet had to learn before he became Monet! Even Monet had to fight before he became Monet. He even got rejected and created an art salon because he and his peers were misunderstood by art intelligentsia.
So by rejecting engineers that you deem not worthy of being artists, you're just putting yourself in the position of the bourgeoisie that rejected Monet in the first place.
You're ignoring potential for talent. And really am I glad you're doing that because I then get to train and hire them.
You've missed my point and made incorrect claims about how I operate.
You could elaborate on your point?
It may be effective shorthand for your approach, but without more specifics it reads like fortune cookie wisdom to others (i.e. could be very wise, or very unwise, depending on specifics that you have not given).
It may be effective shorthand for your approach, but without more specifics it reads like fortune cookie wisdom to others (i.e. could be very wise, or very unwise, depending on specifics that you have not given).
Actually, you want a team of painters who work well together.
Hiring only Monets doesn't scale. Could the dude have even worked with himself?
https://www.mysanantonio.com/entertainment/arts-culture/book...
Hiring only Monets doesn't scale. Could the dude have even worked with himself?
https://www.mysanantonio.com/entertainment/arts-culture/book...
Truth, though I would argue very few areas in CS still need that caliber of dev - surely most (middling) shops would prefer the paint-by-numbers dev for most roles as it shows they're likely reliable and able to work within the team's existing framework than a maverick who may run circles around the rest (in both good and bad ways).
Ofc you need both, would be interested to see how a full 10x team would operate with no 'grunts' there to slog through all the tedious parts of the SWE process.
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.
You don't need a team of people as skilled as Monet to make a working software product. Incredibly condescending. And good lucking ONLY hiring absolute masters for your engineering team as you scale beyond like, one or two hires. How many people in the world do you even think are that skilled?
Plus people require and deserve investment. It's okay to take in people who need development and turn them into solid engineers.
Plus people require and deserve investment. It's okay to take in people who need development and turn them into solid engineers.
If the new hires do not reject the stack (or do the "this would have been so much better if it were written in Y") - in general, yes.
One of the bigger differences is speed, someone that has used a specific framework a lot will likely be much faster in creating new stuff in it than someone that never used it. A lot of typical tasks will fall into the "I've done that before" category, which does speed up things a lot.
For me the most time-consuming part when working with entirely new technology is figuring out how to do certain parts. And for some of them I will initially miss better approaches because I didn't know about them. The other part that is time-consuming are unexpected or complex behaviours that lead to bugs or unexpected behaviour. Every framework has a bunch of stuff that tends to surprise new developers, if you've already worked with it those parts will likely be familiar.
For me the most time-consuming part when working with entirely new technology is figuring out how to do certain parts. And for some of them I will initially miss better approaches because I didn't know about them. The other part that is time-consuming are unexpected or complex behaviours that lead to bugs or unexpected behaviour. Every framework has a bunch of stuff that tends to surprise new developers, if you've already worked with it those parts will likely be familiar.
[deleted]
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.
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.
> 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.
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.
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.
> 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.
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.
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.
I agree with the anti-patterns described. Based on my experience they are also anti-patterns for hiring at non-startups.
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.
Hire a Ruby egnineer if you want an Ruby engineer.
I've found engineers being able to quickly pickup Python, Java and C.
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.
It used to be considered hard. Happy to know that you think otherwise.
... ruby doesn't have a particularly steep learning curve.
I would like to add:
- Let senior engineers or architects do coding challenges
- Ask stupid questions like "What's the runtime of bubble sort?"
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.