When you’re hiring a Junior DBA, ask yourself a few questions:

“What job did they have before this?”

Someone who’s currently employed as a Junior DBA isn’t looking for another Junior DBA job: they’re looking for a Senior DBA job. Because of that, you have to rethink how you write the job description and minimum required qualifications.

To explain DBA career paths, let’s start with a slide from The Senior DBA Class‘s first session:

The left side talks about what’s involved in building and hosting a database application.

Developers usually start from the top and work down: they work with databases in terms of what they need to do to get data in & out of the SQL Server. They’re familiar with the T-SQL language, for example, but not intimately familiar with hardware, virtualization, storage, and Windows clustering.

Systems administrators start from the bottom and work up: they come from an infrastructure perspective, and they’re used to installing and troubleshooting SQL Server. However, they may not even be able to write a single T-SQL query.

You might want someone who knows that whole left side stack, but that person isn’t a Junior DBA. That person is a Senior DBA – and even then, they won’t have a deep level of knowledge across the entire stack.

“What part of that stack is most important to us?”

If you can’t have everything in a Junior DBA, then you’ll want to prioritize which roles in that stack they need to already have experience in when they start on day 1. If table & query design is more important to you, then look for developers first. If installation & troubleshooting is more important, then look for systems administrators.

Then, write a career development plan for the target hire. Where are you going to send them for training after 6-12 months in order to flesh out their knowledge in other areas where you need them to grow? This becomes part of your sales pitch – and it’s exactly the kind of pitch that will set your company apart from other offerings.

Then, write it into your job description. For example:

• We want a systems administrator who’s been spending part of their time with SQL Servers for the last 1-2 years
• You should have installed several production SQL Servers, and done troubleshooting on them when they went down
• You don’t need to know how to design tables, indexes, or queries
• After 6-12 months with us, we’ll send you to a query design class so you can become comfortable with T-SQL, and segue into full time database administration

“Do we have someone who fits this already?”

You might recognize that this person is already on your team. You might already have a developer or systems administrator who really seems to love databases, and they want to take their career to the next level. Promoting them into a database administrator position lets you keep their valuable company knowledge around, and give them some more career runway.

When given the choice, I’d usually rather promote someone internally because the DBA position can be politically challenging. This person’s job is to serve and protect the data, which means telling a lot of people “no.” Their job is a little easier if they’ve already built up some political capital internally in the company. If a new person comes in and starts telling everybody “no no no, we have to shut that off,” then they make enemies fast.