Tag: career

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.

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.

In the Phoenix Project (worth a read), there is a character called Brent, who is to go-to person for everything in IT. I don’t know if this character was modeled after Brent Ozar, but I always picture him when I re-read the book, and I suspect he was that person in previous positions. I’ve been that person as well, and it’s both exciting, fulfilling, and very stressful. At Redgate, that person has been Robert C, who is my go-to person for many questions.

In the DBA world, I think of Jeff Moden. He’s been a prolific and incredible author over the years on many things SQL-related and is a huge proponent of others learning to write better code and better utilize the database platform more efficiently. I suspect in his company, he is the go-to person for most database-related questions and problems. I also suspect he solves most of them very well and has the influence (or power) to effect change.

However, are you Jeff in your organization? Do you have a Jeff? In many of the customers I work with, there is no Jeff. Sometimes there are very smart people, but they cannot effect change. Or they don’t know how to go about making change happen. In other companies, there isn’t anyone who is an expert on the database or related technologies. Too often, I think people aren’t often aware of what expert really is and they just do the best they can without knowing if it’s a great job or a poor one. That’s my opinion, but it’s based on decades of experience (and success) working with lots of others on database code.

The good news is that most of you can learn to be Jeff. You can work to improve your skills, both technical and interpersonal (soft), to raise the quality bar at your organization. Maybe you can get more work done and get a huge sense of satisfaction from your job (and a raise). Maybe you just want to get things done more efficiently and get away from work more often.

There are many ways to do improve the quality at work, but essentially the idea behind platform engineering is to produce tools that make developers and operations groups more efficient. The goal is to get more work done, easier, reducing the cognitive load on everyone involved with software. Not because they can’t do the work, but because we want them focused on their specialty. Whether that’s writing C# code for an application, writing zero downtime database changes, or making beautiful reports. The hassles of actually capturing and moving code should be something provided by a platform. A person can do some of this by sharing their knowledge, not just in conversations, but providing templates, models, standards, and other code elements that might help their co-workers become more productive.

DevOps is about producing code quicker, reliably delivering that to the customer, and raising the quality bar (don’t forget this) and platform engineering is the next evolution here, where the tools, process, and flow are set to make the implementation of DevOps easier for most developers and DBAs. Even if your organization doesn’t want to produce a platform, the idea of building and deploying tools (samples, models, snippets, etc.) to make someone else’s job (or yours) easier and smoother is something we all can do. We can all aspire to be Jeff and get there with a little investment in our skill across time.

Steve Jones

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