Voice of the DBA

Tag: career

  • Navigating the Database Landscape

    The title of our keynote session at the Redgate Summit in Atlanta is Navigating the Database Landscape, and I’ll be delivering part of the talk, along with Grant Fritchey and Kathi Kellenberger today, Mar 13. This is based on the State of Database Landscape Survey results, as well as our experience working with customers and implementing DevOps solutions over the last decade. The talk was mostly written by others, but as I rehearsed the session, I found myself wondering about how I’d approach my job if we returned to being a DBA or developer.

    When working in technology today, there are many challenges outside of actually learning about any of the particular products, languages, platforms, etc. We have the politics of working with others, ongoing work, emergency requests outside of channels, random questions asked by others, code reviews, and probably a few other things I’m forgetting, all outside of learning any new skills. While I consider myself a lifelong learner, I know that finding time (and energy) to acquire the basics of any new technology is challenging.

    At the same time, while working in any size estate, it seems that someone always wants to add a new tool, platform, language, service, or database to the environment. It’s great we have choices, but it seems like sometimes every technologist wants to just use something new rather than work within the areas we have experience. Early in my career, it was rare to find more than 1 or 2 database platforms in a company. Now we have lots, often seemingly just added because one person watched a talk or video and thinks it would solve all our problems in this particular instance.

    Working in an enterprise of any size likely means there are multiple database platforms in use. While you might only be in charge of 1 or 2 today, who knows when someone will call you as the “database expert” and expect you to configure Redis or troubleshoot ElasticSearch. I’ve had friends in this position, and I’ve had people come ask me to figure out MySQL, DB2, BTrieve, Lucerne, and more in my career. It’s a challenge, and it’s also stressful because I want to do a good job, even if I don’t know what I’m doing. Fortunately Internet search, contacts among friends, and more have helped me usually solve an issue.

    The modern database landscape is likely to be more complex than ever, and with the advent of cloud services, we find there are lots of options that anyone in an organization might choose to use in production, and then ask you to support them. Our jobs are increasingly complex, both from the depth of things we need to know about a database to the breadth of different products and services that might enter our realm of responsibility. Navigating all this is a challenge, but if you rise to the occasion, there can be a lot of rewards.

    Steve Jones

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

  • Is This a Good DBA Job Description?

    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.

  • Creating Candidate Interest

    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.

  • Am I Good At My Job?

    I was talking with a friend recently about some of their co-workers. In this case, they were complaining that another person couldn’t do some tasks that my friend considered relatively easy things. Deal with an unusual restore situation, write some PowerShell to reconfigure servers, build somewhat complex (to them) queries, etc. Things that my friend thinks most database people should be able to do after a year of experience.

    However, my friend questioned whether they were evaluating co-workers appropriately. How can one tell? I might be able to tell if a coworker is better or worse at a task, but what’s my frame of reference and my experience. I might think them not capable at things I do well. At the same time, I can be wowed by someone with more experience with a technology I don’t know well, such as Azure Data Factory, but not really be able to judge if they’re average or an expert.

    I suspect most people think they’re good at their jobs, or at least competent. They think they are earning their salary, and they likely are. However, that doesn’t mean they are better than the average SQL developer (or DBA or C# dev, etc.). That’s a different standard, and while most people in surveys think they are better than average, that’s not how averages work. Half of us are below the average.

    It can be hard to determine where you might relate to others in a skill level. I think this is one reason why we struggle to interview and hire well. It’s just hard to determine what a senior person should do, and in a short Q&A period, we can’t often determine if a candidate can do all the things we might ask them to do later. I think many people get good at a small number of things their organization asks them to do, but often aren’t well rounded outside of those boundaries.

    The people I’ve known in any business who excel are those who are always learning and improving themselves. Whether they’re technologists, doctors, or chefs, they are looking to get better at their existing skills and regularly add new ones. That’s a good outlook for life in general, and I would hope many of you adopt that attitude.

    Steve Jones

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