Category: Editorial

I saw this on one of the syndicated SQL Server Central blogs: Job Description of a DBA. This is mostly a list of things, but it covers a lot of the general types of things that many of us expect a DBA to do. However, my question is whether you think this is a good description for a job opening. Would you ask someone to fill this list of things?

Maybe a better question is whether you could use this to evaluate candidates, and how would you go about asking questions or gauging a fit based on this. Perhaps you should ask yourself how you evaluate others and if there is a good way to rate them against a list of daily tasks.

To be fair, I know most job descriptions often include many “desires” along with “needs.” That can be maddening to many job seekers, as they don’t feel qualified. What I’ve found when building descriptions is that a wider variety of people provide input for what they would like in an employee than just the hiring manager. The hiring manager might weigh these items differently and accept someone who doesn’t know replication well, even though replication is used if the candidate is skilled at query tuning. I would say expert, but how do you judge that? Most of us would probably settle for someone who can improve queries even just a little bit.

When I interview people, I want to know a few things. One is can I get along with them, as well as the rest of the team. This isn’t to discount technical skills, but we need to be a team. If we can’t get along, and maybe more importantly, disagree civilly, it’s hard to work together. We do need to bond, though that doesn’t need to be over a drink or sporting event. However, we might need to share a meal, so I hope we can enjoy a conversation for an hour.

The other thing is that I need to see some effort and desire to succeed. I don’t need someone to be an expert, but I do need them to show an interest in helping our customers, whoever they are. Part of that is trying; part of that is getting to the end result. I see far too many people that don’t try to solve problems or care that there is someone waiting on a solution. I also see too many people unwilling to try and improve the environment, whether that’s a codebase or server configuration.  They might be good at their jobs, but I like to associate with people who want to make the world better. People who think forward, who ask questions, who under-promise and over-deliver.

I think the job description I linked above is a good one, fairly comprehensive in scope, but lacking in lots of details. The devil is often in the details, especially in how hard someone might work to complete these tasks, and if they would work to do so to meet their commitments, but also do so in a quality manner. And, of course, under pressure. Most of us know that things break, and when the thing is a database, a good DBA is invaluable in restoring service under pressure.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

It can be hard to find candidates for positions these days. I know there are a lot of people looking for jobs, but are they the ones you want? Are they a good fit for your team? Those are hard questions to answer when culling through resumes, conducting phone screens, and sitting in interview rooms asking questions from a template. What can be even harder is to compare different candidates when multiple people may interview the candidates. Even if you do all the work yourself, you’re busy. Can you make good comparisons of different individuals that you’ve spoken to across a few weeks, in between all the real work you’re trying to get done?

I know I’ve struggled to do this, no matter how many notes I take or how long the discussions are with other team members. I have had a very mixed bag of success in hiring.

What if you had more qualified, more talented candidates applying who were interested in the work your organization does? What if you gave candidates a chance to impress you with actual work that’s related to what you do? It’s an interesting idea, and I saw this in action from an organization recently. Verizon has built a repo that has a bunch of docker files to show how they build, test, and deploy database changes.

They make this available to anyone, but certainly to candidates who are looking for work. A candidate can experiment with this, play around, and make some decisions about if this is the type of environment in which they want to work. This repo is limited to database changes, with testing, linting, and more, but I could certainly see some sample challenging query problems added in here, perhaps just as tests (similar to exercism.org) with the opportunity for candidates to solve them. I would even take these from internal teachings/learnings that current employees use. Surely, you’re leveling up and teaching your staff how to write better code.

I don’t know if this is hugely scalable as candidates might not have time to work through 10 repos from 10 companies, but I do think that asking those who pass a phone screen to look through here makes some sense. Walking them through some of this in an interview and having them ask questions or explain something could help you better understand how someone works. They might even suggest improvements. This should give you a better idea of whether a candidate is someone who fits in your environment, can do (some of) the work, and works in a way that meshes with your team.

I know some companies have tried some of this in the past, often with a standard test or code quiz, but having a repo gives more time for someone to delve in and learn a bit in advance. It also gives you the chance to showcase some tech that your org uses, which might get a higher caliber of candidates applying because they want to work the way you do. Maybe you’ll even get some experts who want to leave their current job to work with your org.

There is no perfect way to find and hire successful candidates, but I think this is an approach that has some merit and could potentially help create interest from candidates that might not otherwise apply.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.