
Ask HN: How do I convince management to hire better? - canterburry
Ironically, I am part of said management but I feel like all other hiring managers ,around and above me, don&#x27;t even know what &quot;excellent&quot; engineering talent looks like.<p>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&#x27;t read the requirements, how they don&#x27;t bother asking questions when they don&#x27;t understand etc<p>I don&#x27;t claim to have cracked the hiring challenge but I do have some guiding principles which seems to work:<p>* 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.<p>* They are OCD. Not only do they need to know the how, but they need to understand why...and they won&#x27;t stop until they have figured out the why. This helps in many situations from understanding standards, debugging odd bugs, selecting a good stack.<p>* The next engineer must be better than the last hired engineer. Don&#x27;t hire unless the candidate is solid even if your team is struggling.<p>Other managers check boxes next to frameworks, acronyms and spend more time telling the candidate about the company than asking questions.<p>How can this be turned around?
======
itamarst
" 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.

~~~
AnimalMuppet
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.

~~~
itamarst
Caring and wanting to learn are not the same as wanting to spend one's free
time learning.

~~~
AnimalMuppet
Sure. But if the person is willing to learn, the manager can help them learn,
even if it's on company time.

------
ed_at_work
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.

------
tracer4201
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.

~~~
canterburry
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.

------
ThorinJacobs
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.

~~~
canterburry
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.

~~~
AnimalMuppet
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.

------
serpix
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.

------
imauld
> 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.

------
mvpu
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.

~~~
bradknowles
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?

------
AnimalMuppet
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.

------
dgwight
Your guidelines sound good, but why would excellent engineers want to work a
company where most of management wouldn’t appreciate them?

------
twunde
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.

------
JSeymourATL
> 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...](https://insights.som.yale.edu/insights/whats-the-google-approach-
> to-human-capital)

------
ninedays
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.

------
mabynogy
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.

------
africa-toto
Good question, would be great to hear some wisdom from team leads that have
managed to build great products.

------
whb07
What type of work do you do?

