Hiring Good People

One of my engineers asked to me to do a brown bag on "hiring good people". I responded by saying just hire smart people and let them do their thing. Predictably, that wasn't a great response and probably doesn't do the question justice. I'm not the best engineer or manager but I do pride myself on building great teams so I agreed to do the talk. I want to share here what I shared with them.

TEAMS

I want to start by saying I don't hire individuals in a vacuum. I try and think like a General Manager putting together a sports team (yes this will be a sports analogy). What matters most to me is how a team is going to function together. You wouldn't just get throw a team together without any thought to roles. For example, a team where no one can shoot would be terrible (cc: Rob Pelinka).

And I'm not simply talking about skillset. That's important but it's obvious and if you're reading this you probably already know how many backend, frontend, mobile, etc engineers you need (chances are you need more than the headcount you have, am I right!).

I'm talking about the roles people play on the team. Who is going to be the stickler for following good practices, who is going to bring excitement to try new tech, who is going to be the curmudgeon to slow down just enough to make sure there is a good reason to do that shiny thing...

The roles people play matter a lot. Imagine a team where there is no one who enjoys mentoring. You could make this part of the career ladder (and you should!) but it's not the same when you don't have someone who is passionate about it to at least show everyone else how it can be done. Imagine a team where everyone wants to be social but no one wants to take part in organizing something. Again, you could mandate it or do it yourself as the leader of the team (and I recommend you take this on some of the time) but it's more fun when it's organic. The best events I've been a part of at work were organized by someone who cared.

(Important Note: There is a whole other post I could write (and many have) about how women tend to take on tasks that don't lead to promotions like organizing social events. Google it and be aware of it!)

So the questions you really need to ask yourself when interviewing someone is how does this person fit into my team. What will they add to make it a better, happier, more productive group of humans?

But How

The questions I ask in interviews aren't particularly sophisticated. The trick is to let the candidate talk and then listen. If you ask about a time they mentored someone, do they go through a laundry list I could read off an informational sheet or do they share details that show engagement, joy and most important pride.

The best mentors will tell you where their mentee is now, what they are up to and how proud they are. The engineers that care about best practices will tell you about their pet peeves, their favorite tools, the changes they've made and why (the why is so so important). The bad answers are usually some form of "We catch stuff in code review. Code review is super important. We do code review. I named my dog Code Ruffview." Lots of buzz, no substance.

When I'm not sure, I take a step back and ask myself if I've learned anything from them and if not did they challenge or strengthen an opinion I already have. I don't even care if they told me tech I think is garbage is actually the best thing since sliced bread. I have even hired folks who told me mongodb is a good database (it's not and if you chose to use it, you should feel terrible about yourself).

There's one kind of candidate here to look out for. The one that throws buzzwords until they get you rolling and then agree with what you're saying. That's your fault, not theirs. They may not even realize that's what they are doing. They told you they use FAVORITE LIBRARY and you were like "omg yes lol I love FAVORITE LIBRARY" and now you think they are like you when they didn't say anything particularly interesting. Did you ask them why they like FAVORITE LIBRARY, how they used it, when not to use it, what were the challenges involved, how did it disrupt their existing practices, what would they have done differently next time and on and on and on until you really feel like they understand why they are talking about it.

Two last rules

First, I have a very strict "no jerks" rule. I think I have something like a 85%-90% hit rate on my filter. I have been wrong a few times in both directions. There's at least one person I didn't want to hire, was overruled on and later ended up loving working with them. There's at least one person where I was overruled on and turned out right. They were managed out and it was not fun. So you never really know. But here's the thing, as much as I loved working with that first person, had I not been overruled, I wouldn't have taken the chance. Jerks kill your team. Full stop. It's the hardest thing to recover from.

Humans, fortunately or unfortunately, can tolerate a lot at work but the thing they can't take is someone on their own team being a jerk. When that happens, they don't have the safety of their team. So I personally think it's always better to be on the safe side. If someone is giving off jerk vibes? Don't hire them. I would however give them some feedback on it to be kind. Maybe don't say "you sound like a jerk" but something like "when you spent 10 minutes ranting about how everyone on your former team didn't get your genius, you didn't come off great".

Second (and pay close to attention here!), GET OVER YOURSELF. You're a hiring manager. You're already in your role. There's no one you need approval from. An interview is not where you show someone how smart you are. For the entire 30-60 minutes, you have all the power. Act like it. It's very rare a candidate isn't nervous and feeling off the entire time. Don't abuse it.

Here are some gotchas

• You ask a question that only has one particular answer
• You ding people who don't agree with you
• You like people who do agree with you
• You like people who changed their mind mid interview because you convinced them (first, why are you using interview time to convince them you're right and two GET OVER YOURSELF)
• You spend more time talking then they do
• You take more than 30 seconds to ask your question (and that's a max time dude, not a goal)

There are so so many hiring managers I've worked with where I either had to train this out of them or I wanted to (but didn't) slap them upside the head and tell them to get over themselves.

You'll notice again that I never talked about technical skills. There are a million places where you can read up on every leet code, take-home, interview tool, etc that's out there. My opinion on this changes all the time based on situation, company, role and a million other circumstances. What I will say is that I'd rather take an engineer with B technical skills who is an A+ teammate than someone who has A+ technical skills but is a < A+ teammate.

Onboarding

So you did it! You hired a great engineer. You're super stoked. You did your job and now you can go back to meetings and status updates (I mean, we are being real, right?).

HA! WRONG! Your status updates will have to wait a little longer. You missed the most important part. Onboarding an engineer too often gets overlooked.

I'm not even talking about getting a dev environment set up (though my rule here is you should be able to get set up and commit to production on day 1). I'm talking about the norms and expectations of being on the team. You think they'll just figure it out? Maybe.. but it'll take longer.

I'd recommend putting together a few living documents. I like to start with a North Star. The North Star describes your ideal future for your team, product, goals and anything else you deem important. The idea is that if folks on your team are trying to make a decision, it should reflect moving towards your North Star. It creates a system where you don't have to be in every meeting or review every decision to trust that it's mapping to the way you want the team to perform. The team should obviously be involved in editing the North Star and it should be revised as your team's missions and culture evolves. It's nice to look back at it from time to time and see how much closer you are to it.

The next document is your roadmap with the goals clearly laid out. It should be easy enough to digest for a new person and help them orient themselves within the team's day to day. If the North Star is the compass, the roadmap is your map to get there. A team that doesn't have a roadmap tied closely to clear goals is one of the worst team smells.

You should have a doc of docs. A place where you can put all other important things to read. Again, update this from time to time. It goes stale fast. Let anyone contribute. It should have enough content to understand the business domain, major tech used, important decision docs, company norms and procedures, glossary of terminology and acronyms, how-tos (e.g. how to deploy code, rollback changes, handle an incident) and a list of the fun stuff (slack channels, fun groups, etc).

Lastly, a 30/60/90. I tell everyone who joins to put a 90 day invite on their calendar. I tell them to not panic about being overwhelmed until they hit that day. Let them know it's ok to ask the same questions over and over. They should feel safe being lost in meetings. Don't worry about being less productive. Your job for 90 days is to learn. The 30/60/90 is a good way to break down that plan. If done well you usually aren't even following it by the end. It's just there to make sure you have a plan for getting someone from zero to full teammate.

So there it is

I told you. I didn't really have much insight. It's all fairly obvious and has been written about a million times before. I think the trick is to do it. Hiring is hard. The worst managers are just trying to find someone. The best managers are scared of hiring the wrong person. If you have infrastructure around you like a recruiting team with quotas, other hiring managers competing for talent or engineers who don't really want to be interviewing, you'll be in a struggle against their own opinions, biases and incentives. I've worked with some recruiters who are the best of the best. I've also worked with recruiters who want to check a box so they make their quarterly goal.

This is your team. It's up to you to hold the line. Remember that for every person you hire, you have to believe you're going to be hiring 10 more of them. They will interview other people. They will refer their friends. They may not be able to get over themselves. They are people too. So you want to make sure that you never bend the standards or give in. Sure this can't always be helped. I've been overruled at times. There have been circumstances outside of my control. But you do the best you can. I've hired some amazing teams and it's been a joy to work with them. Not just because they make me look good (though that helps) but because it makes coming to work (even virtually) a pleasure. And in the end, I believe that most people care more about who they are working with over what they are working on.