Hiring is hard. It really is. You are looking to add a new human to your team who will hopefully work with you for many months to come but you have about an hour, at best, to develop some strong opinions about how they will perform in the future. We spend way more time than that on vetting vendors, don’t we? I recently worked with my manager to double the headcount of my team which was both daunting and very illuminating. By sharing how it went and things I have learned along, I hope I can provide some takeaways that can help you when you hire people in the future.

But I am not a manager!

Before we even get into the hiring cycle, you may ask: But I am not a manager! Why am I even getting involved in this? My time is better spent writing code! Well… the idea that an engineer’s job is solely to churn out code is a myth, and it’s an unhealthy one. Unless you don’t plan on ever talking to those new teammates, you should be jumping on the chance to help with hiring the people you are about to work with. We spend more time during the week interacting with team members than family members sometimes. Shared core values and complementary problem solving styles can take a team from marginally functional to highly functional and performing strongly. I am lucky to be in an organization that recognizes the importance of senior ICs input when expanding its teams and I was eager to help every step of this process.

Expectations

Before we even published the openings on my team, we needed to get on the same page as to what we expect. This is important because this was the first time either my company or I have hired level 1 DBAs. It is, in some ways, easier to know what the job opening will look like and list its competencies when the need is for a role that presumes previous experience. Level 1, in this case, was closer to associate and needed to focus a lot more on potential while still setting some as yet unknown level of general technical expertise that got us candidates who at least had some idea what a database is. That turned out harder than I thought. My manager and I started pairing on a Google doc as the basis of the job description and we focused on a few things. For junior level positions, we avoided listing a bunch of technologies as ‘requirements’. Literally the only things in there were “you have some history using MySQL/a database” and “You have written code before”. The idea here is that this is a role that will already involve a lot of learning. To come into it with a lot of expectation of previous experience will not only be lazy on my part as the future mentor of these employees but would out of the gate exclude any URM candidates who may have genuine interest in becoming DBAs but lack the disposable time/income to self learn these things. We made sure to explicitly mark ‘nice to have skills’ as ‘bonus skills’. Men apply for a job when they meet only 60% of the qualifications, but women apply only if they meet 100% of them and I was aware of that. The DBA field, much like the rest of tech, has its own issues around women advancing and lasting in the industry as much as men. I wanted at this entry level position not to compound the problem by inadvertently chasing away potential candidates through making a list of skills that is implicitly sometimes ‘must have’ and sometimes ‘bonus’ Finally, it was important in the job description, upon which our public post was based, to describe more of what the person in this job will do. I was deliberate early on to emphasize the need for someone who will collaborate and work with engineers closely and talk to people. There is a stereotype around DBAs that I did not want to ignore or gloss over and I felt it was important to be upfront early on in the process that this DBA team will not be operating in that manner. We also made sure to pass the job description through a couple of tools that analyze the language for gender bias. One of those is open source and can be used for free. This was important to make sure we weren’t inadvertently projecting gender stereotypes in how we described the people we were looking for to fill these roles.

Screening

We had planned an interview team for these positions. But my hiring manager was the one tasked with screening incoming resumes and doing initial phone screens. This did not have to mean he had to be the sole authority on who comes through the door. In fact, in our conversations about how the screening was going were already shaping and fine tuning what we wanted the roles to be and therefore what kinds of questions to ask in later phases of the interview process. A lot of things that many people talk about as signals for screening and filtering candidates proved not as useful as we went through resumes of candidates:

• Github profiles. That was never even a question. And if you follow me on Twitter you may have caught me rant about this after someone privileged declared it ‘the new resume’. Let me reiterate here: Whether for a senior role or a more beginner role, personal projects and GitHub activity are a strong indicator of candidate’s free time which is really not an indicator of how well they will collaborate with the larger ops org, delivery engineers or what style of problem solving in our existing infrastructure they will use.
• Degree or the university they graduated from. Sure, a Bachelor’s degree is a nice to have. But I know too many very good engineers with no college degree to presume it is an indicator of someone’s ability to learn.
• Tech stack previous experience. This one is a useful signal, to a degree, for senior roles. But when it came to level I hiring where I already expect the hires to need training, it would have been disingenuous to then filter on whether they already knew what I am expected to teach. What matters here is showing hunger to learn.

Interviews

The interview team selection also took some thought. I do not believe in DB ops being a silo that is only focused on managing databases. Sure, we still have a good amount of that work at hand as business responsibilities of Data Operations, but I was hiring people who would also learn a lot about this job for the long run and I knew I wanted to stress the collaborative nature of how this team is supposed to operate from day one. On that note, the on site interview team needed to be more than just me and the hiring manager. We enlisted the team’s project manager to get a sense of candidates’ value alignment and ability to balance unplanned work from outside the team with planned projects. We worked with our People Ops team to prepare relevant score cards in our hiring tool so that when we sit down and have a debrief about a candidate, it is a more productive conversation and we can all come together with a recommendation for the VP of Ops who had the final say before sending an offer.

Filtering out ‘brilliant jerks’

I know some companies like to do panel interviews. I get the rationale behind it. The most expensive resource is your people’s time and many see it as a way to be efficient. But I am also not a fan of panel interviews. In my experience, and from talking to a number of other women in tech who have been in hiring positions, panels are not very effective at detecting interpersonal issues with candidates that can cause problems down the line. Let me explain how that plays out. Sexism, racism and bias in tech are not a secret. If you are reading this and still believe that hiring in tech is a meritocracy based solely on skills and never about impressions, implicit and explicit biases then you should go read some research here and here then come back to the rest of this post. Now that we have set this baseline, it is a natural deduction that when you are tasked by helping your team grow, it is important to make value alignment an important part of the process. A 1:1 setting for interviews is far more effective in showing how candidates will behave around team members who are from under represented groups (URM) in tech. Sure, there will always be the more egregious examples of candidates so full of their ego that they talk down to a woman on the team in front of everyone else but that will only happen if you are lucky. What you should strive to detect for is the more sinister attitude of potential team members who could hurt the team morale using a thousand tiny cuts to their URM team members. The cost of a toxic member coming on your team is far greater to your team and the organization than the cost of some more interviews to find candidates whose values align with yours. This is not to say that the on site interview process was solely focused on interpersonal skills, we also needed to gauge for problem solving skills from the technical standpoint. Database engineering is still a job that has on call requirements and it is still very possible to get asked to debug issues in production before anyone is even sure if it is a database bottleneck or something else entirely so we needed to screen the candidates for their ability to inspect systems and to show how they approach debugging on live systems which can often feel like a murder mystery. Some teams like to prepare test code or a service they write specifically for these exercises but in my case it was as simple as a verbal hypothetical and a number of follow-ups as the candidate tells me what they would look at and what they expect to find. For me, what I watch out for here is persistence, curiosity and demeanor under pressure far more than whether they guess what the problem actually is in this hypothetical. When an outage situation escalates to my team it tends to mean it is already an all hands on deck situation, so it is very important to see that the people on my team will be calm under such pressure.

Debriefs

After each onsite interview, the entire interview team along with the people ops recruiter responsible for this hire huddle together to discuss our score cards. This is where discrepancies in the candidate behavior we may have encountered are brought up and discussed. This candidate was respectful and charming with the hiring manager but kept interrupting and talking down to the project manager? Nope. The next candidate showed frustration at scenarios where we discussed feature planning with product and delivery engineers? Also no. That senior DBA candidate made an off hand comment about how he never wants developers to touch his database? Also no. Usually in these debriefs we look for strong yes answers on candidates or we discuss the interviews we did with that person some more. We talk more about reasons we may not hire a person because it is important to surface these concerns early. Many times I have seen teammates come into these debriefs as a weak yes on a candidate only to become a solid no after they go over notes from the other people on the interviewing team and that is why we do these debriefs.

Things I learned

My road to where I am now in my career was full of serendipitous encounters, a chain of things that if they hadn’t happened, I wouldn’t be where I am today; If I hadn’t found a job as the DBA’s intern in college, if my first job in tech wasn’t with such a small team that they’d let me, 6 months out of college, debug issues with the billing code and the database. This process of hiring new level 1 DBAs, knowing that I was about to have a lasting impact on two other people’s careers was a humbling thing and it made me take note of a lot of the advantages I had in my journey. It brought back memories to spending days in MySQL documentation learning about all sorts of configuration and commands, then later spending days in Chef documentation trying to understand how the hell attributes work. During the initial screenings and after a couple of initial on site interviews, my manager and I had some honest conversations about what preexisting knowledge we were truly testing for and whether that was fair. Yes! That was already discussed when writing the job description, but it was important to keep revisiting that because it is easy to want the knowledge to be already there. As he, myself and my fellow senior DBA on the team talked about it more, we determined that we were looking far more for potential than expertise and that quickly made a large chunk of prepared interview questions carry a lot less weight in how we scored candidates. I started using the ‘technical phone screen’ as a way to motivate the candidates’ curiosity and hunger. The two engineers we hired showed hunger for reading material in the initial screening with me and when they came to the on site with prepared questions based on things they already read and learned, I knew that they had the curiosity to learn about this stuff to make it past the initial steep turning curve of the database toolset.

A team to last

My team has grown from a team of one (me) to now four people strong. This has been great not just for sheer team velocity and being able to service a large engineering organization but has also given me a ton of room to grow in my career. I have benefitted a lot from showing my fellow senior DBA how I have been doing things for a while, he has taught me a lot and now we have 2 level 1 DBAs who are giving us the opportunity to mentor them and they are excited to do all the tasks we were ready to grow out of. The biggest lesson to me in this past 18 months of growing the team has been than the most important thing is hiring people who have empathy, humility to learn, and curiosity. A good friend and my former manager recently sent me a link this post and this line stood out to us in the email discussion.

The most productive teams I’ve been on are the ones who are pulling each other over these walls in the battle against real-world problems.

Managing infrastructure, data stores or otherwise, is a team sport. And that is why the process for joining the team has to optimize for team collaboration and psychological safety.