[HN Gopher] Anti-Patterns in Startup Engineering Hiring
___________________________________________________________________
Anti-Patterns in Startup Engineering Hiring
Author : catapultis
Score : 58 points
Date : 2022-10-25 18:01 UTC (4 hours ago)
(HTM) web link (blog.southparkcommons.com)
(TXT) w3m dump (blog.southparkcommons.com)
| Test0129 wrote:
| > 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.
| ctvo wrote:
| > 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.
| BugsJustFindMe wrote:
| > _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.
| limelight wrote:
| > 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.
| adamsb6 wrote:
| 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?
| [deleted]
| watwut wrote:
| 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.
| fabian2k wrote:
| 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.
| kaesar14 wrote:
| If you have at least one or two engineers familiar with the
| language it is not hard to teach the rest of the team good
| practices.
| vosper wrote:
| 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.
| tick_tock_tick wrote:
| 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.
| fallingknife wrote:
| Most of the benefit of hiring smart people in a startup is
| not that they do brilliant things, but that they don't do
| stupid things. So not really necessary that they be domain
| experts in most cases.
| Beltalowda wrote:
| 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.
| fallingknife wrote:
| 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.
| Beltalowda wrote:
| 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.
| djbusby wrote:
| Anyone could paint-by-numbers a Monet. But only Monet could
| create a new one.
|
| You don't need painters, you need artists.
| xcambar wrote:
| 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.
| drewcoo wrote:
| 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...
| kaesar14 wrote:
| 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.
| julik wrote:
| 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.
| dimal wrote:
| > 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.
| jampa wrote:
| I agree with most of the things, but as someone whose
| responsibility is hiring people, the hiring for a particular
| toolchain or framework holds to some degree, for example, some
| places want to tick every single box.
|
| On the other hand, it is good to search for the affinity between
| the languages. Python to Ruby can ramp up faster than Python to
| C#/Java for example. So someone can have a harder time and in the
| end, won't enjoy the overall framework and leave.
|
| Another example: If you search for someone to take a Next.js
| project, a React engineer would work well, a Vue engineer might
| need more time but could also work, but a hardware engineer would
| struggle and might need too much time to produce.
|
| > Fire fast
|
| 2-3 months is way too short for letting someone go, and it is the
| problem for some startups nowadays.
|
| Most companies onboarding documentation sucks or does not exist,
| so you can hire a great engineer and think they are not.
|
| There are great unicorn engineers that can manage themselves in
| the project but most people need some help, feedback, and
| guidance.
|
| Also, most managers are afraid of giving feedback, I did some
| consultancies with startups that had managers complaining a lot
| about a certain engineer, already at the point to fire them. When
| I asked "do they know that you are unhappy with them?" they
| always say that they "implied" once or twice. When I give them
| feedback the improvement is noticeable just in weeks.
|
| Firing fast is sometimes just a cop-out to not give people proper
| feedback and properly managing them.
| catapultis wrote:
| 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?
| ShinySquirl wrote:
| Having been a generalist at several startups throughout my career
| , can totally agree the highest leverage folks are usually just
| the smartest, not the most specialized.
| planetsprite wrote:
| 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.
| smcin wrote:
| > _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'.
| polskibus wrote:
| In startup context, when still experimenting with product-
| market fit and trying to win early customers, you need
| generalists to be able to quickly change direction when
| necessary. Specialists have too much inertia in such cases.
| ivan_gammel wrote:
| When searching for product-market fit the last thing you
| need is changing your tech stack on the fly. Generalist can
| help you to bootstrap your initial stack if she has a good
| knowledge of all components, but specialists allow you to
| focus on what really matters, building foundation of your
| ops while you experiment.
| ghiculescu wrote:
| 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.
| ivan_gammel wrote:
| 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.
| mkl95 wrote:
| > 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.
| throwaway0060FF wrote:
| 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.
| jkingsbery wrote:
| 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?
| noodle wrote:
| > Hiring for a particular tool-chain or framework
|
| Dunno about this one. This is very much so FAANG type of
| thinking, not really (newer) startup type of thinking.
| Sacrificing a few man-months to training is something that is
| hard to do when that's a significant percent of your remaining
| runway.
| paulgb wrote:
| 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.
| Communitivity wrote:
| I agree with the anti-patterns described. Based on my experience
| they are also anti-patterns for hiring at non-startups.
___________________________________________________________________
(page generated 2022-10-25 23:00 UTC)