Ask HN: How do I convince management to hire better?
28 comments
" I.e. they take time to learn or practice their skills outside of work projects" translated means "I don't want to invest in people's time or training, I want them to do on their own time."
Seems like you're suffering from same problem as the rest of organization, unwillingness to invest in your employees, just with a slight variation.
Seems like you're suffering from same problem as the rest of organization, unwillingness to invest in your employees, just with a slight variation.
Personally I am a big believer in mentoring and growing people at their place of work, can't speak for others. The candidates I don't want however are those who display no interest in their profession outside of their direct work related tasks. Even if you work on some legacy technology, you can at least read about new trends and best practices.
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."
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 give the employees training. You can pay them to have their behinds in seats somewhere while they ignore someone (whom you have also paid) who is trying to teach them something.
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.
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.
Caring and wanting to learn are not the same as wanting to spend one's free time learning.
Sure. But if the person is willing to learn, the manager can help them learn, even if it's on company time.
I averaged a 60hr workweek last month. Oftentimes I couldn't give a crap about working on side projects outside of work because I have both a life, and am approaching burn out. Making side projects a hard requirement is going to cut off your nose to spite your face.
I've worked in organizations where management had a technical background (previously worked as programmers or some related technical role earlier in their career) or a non-technical background (degree in business or "MIS", tell people they're technical but all they did is write some basic like 20 years ago in one class or wrote HTML in some class one time).
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.
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.
Interestingly, I have never really used algo questions in my hiring. I also have never worked in companies where any fundamental innovation in computer science takes place but rather we need strong application developers who understand particular business domains and can make the end use cases work for business clients.
I have used coding assignments with junior hires where comparing several candidates based on school work is sometimes challenging.
I have used coding assignments with junior hires where comparing several candidates based on school work is sometimes challenging.
Deadlines. Software. Lol.
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.
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.
Hiring to meet a deadline.
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?
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?
I am not, nor have I been a team lead, but will pitch in with a couple ideas.
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.
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.
Thanks for the feedback.
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.
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.
Then that's maybe a long-term way you can fix it. Your team needs to visibly out-perform other teams. Then you can go over the heads of the other team managers to impose better hiring practices.
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.
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.
tight deadlines reeks of death march and burnout. How is the company culture? Why would anyone want to commit to tight deadlines? Those with passion and dedication are easy to lure into neat projects but the more experienced ones smell your death march and go somewhere else.
> 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.
This isn't Obsessive Compulsive Disorder it's being thorough or knowledgable. No need to further the misuse of this term here.
This isn't Obsessive Compulsive Disorder it's being thorough or knowledgable. No need to further the misuse of this term here.
My personal bias matches your first point - I prefer candidates that are curious (to understand how things work), versatile (dabbled with more than one language), hungry (to build things) and accomplished (have built things they are proud of). I do not care about OCD. I don't think the next engineer should be better than the last engineer.
That 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.
That 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.
But the “O” in OCD comes from Obession. Well, Obsessive, technically.
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?
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?
How big is your organization (you, the other hiring managers, and the people under all of you)?
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.
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.
Your guidelines sound good, but why would excellent engineers want to work a company where most of management wouldn’t appreciate them?
Probably the best thing you can do is start collecting data around the quality of the hires, and who interviewed them/hired them/etc. You should see that some people are better at hiring than others (yes, this is a skill). Start by collecting the data you already such as annual reviews and fired employees. You should start doing is having every hiring manager bucket rank their hires after 3 months, 6 months, 1 year. Is their recent hire a star, above average, average, below average or poor? Would you hire this person again?
Keep in mind, that this will also reflect how well you onboard engineers. If someone has a really good onboarding process then that may transform the average engineer to an above average engineer. Likewise a poor onboarding experience can make an above-average engineer into a poor engineer.
> How can this be turned around?
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...
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...
By consistently hiring the best people in your company, it can be easier to show upper level management that what you do is good and your methods should be shared and applied to your colleagues.
Work hard, use metricsm show them why your candidates are better fit than your colleague and maybe they will understand what should be done in order to hire better people.
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.
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.
[deleted]
Hire better people than your colleagues and explain them how you achieve that.
On the IRC channel I'm on (see my profile) some people will be available soon. Take the time to talk with them.
On the IRC channel I'm on (see my profile) some people will be available soon. Take the time to talk with them.
Good question, would be great to hear some wisdom from team leads that have managed to build great products.
What type of work do you do?
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?