Ask HN: How do I convince management to hire better?
Most of my peers are mainly concerns with deadlines and to meet deadlines they need bodies. Once they get said bodies, they complain about how little people on their teams seem to care, how they don't read the requirements, how they don't bother asking questions when they don't understand etc
I don't claim to have cracked the hiring challenge but I do have some guiding principles which seems to work:
* The candidate must demonstrate passion, curiosity and personal commitment to their craft. I.e. they take time to learn or practice their skills outside of work projects. They test their code not because the process says to do so but because they themselves have strong motivation to deliver a dependable product.
* They are OCD. Not only do they need to know the how, but they need to understand why...and they won't stop until they have figured out the why. This helps in many situations from understanding standards, debugging odd bugs, selecting a good stack.
* The next engineer must be better than the last hired engineer. Don't hire unless the candidate is solid even if your team is struggling.
Other managers check boxes next to frameworks, acronyms and spend more time telling the candidate about the company than asking questions.
How can this be turned around?
28 comments
[ 3.3 ms ] story [ 35.7 ms ] threadThat said, I would hire one person that meets your bias, get them to do great things, and use that example to influence your peers. Once they start seeing results, they are more likely to use your bias. I would also opportunistically discuss the performance of people they have been hiring and trigger trigger thoughts.
However, I've found that hiring alone does not fix the core problem in engineering - which in my perspective boils down to building a culture of obsession. I've never seen a team full of rockstars. But I've been able to improve outcomes by constantly obsessing about some aspect of the product or code with engineers and getting them excited about it and take ownership and make things better. Get someone excited about UX, someone excited about code quality, someone about security, someone about unit tests, and constantly talk to them about it, and reward them for making it better. And over time you might see better results.
I’m confused as to how you can say you don’t care about OCD at the beginning of your post, and yet by the end you are harping on the key requirement for obession.
Can you clarify this?
It sounds to me like the other managers don't believe that the metrics you are using will result in higher productivity faster. This could be because they just don't understand or haven't fully internalized the benefits of passion etc., but I suspect it's more likely that they're feeling the pressure to higher someone, anyone. Assuming you have enough autonomy on your team to make a hire based only on the merits you list above, have you been able to demonstrate to your higher-ups that your method is more effective? If the higher-ups understand what's better about your approach and that other teams aren't following it, they may be able to start changing the culture or putting pressure to change interviews.
I'd also recommend re-examining the "must be better than the last hired engineer" point. Different engineers excel in different areas and I suspect you'll run into problems like "well they're much better at algorithms than the last hire but they didn't ask the requirements questions I'd like", etc. To me it seems like a weak link that your peers may focus on to the detriment of your other goals.
Again, not a team lead, just suppositions and suggestions based on the engineer side. Mostly just sounds like a company culture issue, gotta make the superiors understand why haste makes waste.
Luckily I do have some autonomy and can onboard who I feel is a strong candidate. It's more when I participate in hiring for other teams and object to certain candidates that I just want to slap my palm to my forehead. It only affects my team when we depend on deliverables from other teams.
"must be better than the last hired engineer" - This is definitely more aspirational than a hard rule and in fact financially unfeasible in the long term. However, it's a useful measuring stick when you comparing candidates. I typically use existing team members as reference points and try to imagine where the candidate before me will fit in the range of talent we already have.
Note that this is primarily a political problem, not a technical one. Truly fixing it may not happen when the other team managers are still in their positions.
The technical management makes better hiring decisions, in my experience.
Among the technical management, at two of the FAANGs I've worked at, hiring decisions are made based on algorithmic/coding interviews, which can be decent for evaluating fresh grads but not so great with more experienced hires.
I agree with your principles you bulleted. However, I've also worked at organizations where those were part of our hiring requirements, yet, management was hyper focused on just filling heads because "deadlines".
This is a pattern I've gotten used to at this point. I don't have a solution for it other than to push back, at least when you're directly being pressured to hire some candidate just to meet a deadline.
I have used coding assignments with junior hires where comparing several candidates based on school work is sometimes challenging.
Sorry, every time I marvel at how much we’ve progressed since the 90s, I hear these 2 words used together and I’m reminded that we actually haven’t.
Hmm.
Sounds to me like they never heard of the book “The Mythical Man Month” by Brooks.
Maybe you want to tell them about it?
On the IRC channel I'm on (see my profile) some people will be available soon. Take the time to talk with them.
You should also know that some people are stubborn and some have such a big ego that changing anything in your company can feel a bit "David vs Goliath"y - in that case, it is way harder to change anything.
Seems like you're suffering from same problem as the rest of organization, unwillingness to invest in your employees, just with a slight variation.
It's sometime shocking to me when I get candidates who seem to have lived under a rock for the last 5 years and aren't aware of what's out there. I'll definitely keep the interview going with a person who says "No, I have not directly worked with React but I've been reading about it and this is how I understand it's different from XYZ framework I currently use." vs "React, Angular, GraphQL, SCSS, sorry no, I don't know anything about them. We only use Apache Struts."
You can't make them care. You can't make them want to learn.
You might be able to show them that they ought to care, but you can't guarantee that they will listen.
Once you are a large organization, you have the law of large numbers. All of your employees can't be above average. (Your personal team may be small enough that you can, but the larger organization is harder.)
For that matter, the problem may be that the other managers are average, not just the people under them.
This isn't Obsessive Compulsive Disorder it's being thorough or knowledgable. No need to further the misuse of this term here.
Laslo Bock's take on this might be helpful -- For us, there's not a sense that any individual has to be the complete package. We find you build a better team when you think about the balance and portfolio of skills within that team, rather than say, "I need one person who's got it all." There's actually not that many people who have it all on the planet.
> https://insights.som.yale.edu/insights/whats-the-google-appr...