I released an article a few years ago on a similar topic: Who Do You Hire?. In this article I looked at who you should actually hire to fill that next open position. At the time I was in a place to hire people, so I tended to look at the situation from that perspective. Now I'm on the other side of the table, in a position where someone would hire me and so I've got a few thoughts about who I'd want working next to me.
Fit Like a Glove
It's fall and in the US that means, among other things, it's football season. I tend to prefer the NFL games for many reasons, but one of them the synchronicity of certain players on the team. The plays are scripted well in the NFL and often a receiver and quarterback are so closely synched that each knows where the other will be at a particular time and the ball moves between them as if they are reading each others' minds.
That level of teamwork usually comes from years of training together in difficult environments, usually military ones, but it can exist in a corporate environment. Ideally you want to know what and how other co-workers will react and work in stressful and non-stressful situations. Knowing the capabilities and to what extent you can count on others builds a strong team where each person feels a bond with the others and does his or her best to not let the others down.
I've written about this many times, but the personality and fit of another employee needs to be of primary considering with any hiring decision. You can teach someone technology, but you can't teach them to be a friend or even an acquaintance. I think the number one thing that you should look for in a new employee is if he or she gets along with everyone else.
If you are not the person doing the hiring, and you want to have a successful team, you need to inject yourself into the hiring process. Offer to help interview people or even better, ask if you can get the team together for short group interview or even an informal coffee break with the prospective employee. As must as this seems like it could be busy work, it's an investment worth making. The last thing you want is an employee that you hate talking to.
Pulling the Load
While I believe that most technical people can be taught new technologies and technical skills aren't as important as interpersonal ones, that are a little simplistic. Technical skills are important since you are hiring for a technical position. If you aren't, perhaps you're reading the wrong article 🙂
When an advertisement is placed for a position, usually it lists all types of qualifications that the company would like. It's often like a "dream employee" job, looking for the Nobel Prize winning computer scientist that can also make gourmet coffees for the department. It's rare that someone actually meets all the criteria listed, but that hasn't stopped companies from asking for the world in job ads. Maybe this is the corporate equivalent of "enhancing your resume."
However buried in all the details are usually some core skills that you expect the person to know. Or at least pick up quickly and become a productive employee. If an employee can't pull their weight, then everyone else grows resentful and the best personality in the world doesn't protect them from being seen as a slacker.
The trick is for you to flex your technical criteria enough to find good team members, but not so much that the person is in over their head. This is especially important with DBAs in a different way than it is for developers.
When I was in high school I took an advanced programming class in Pascal and we did some basic work with pointers. Quite a few of the 12 people in my class struggled, and I didn't think much of it. Later in college I saw similar problems with many CS students and when I got to the corporate world and had exposure to enough developers, I realized something.
Some people don't get pointers.
And by "don't" I mean they won't ever get them. They just don't understand the concept and there's no way you can explain this rather abstract concept to them. Well maybe there is, but over days and days I've come to the belief that they're just beyond some people.
For some developers, C++ guys, people working on lower level projects, this is critical. You cannot hire a developer for an embedded system OS that does not understand pointers. And you cannot hire someone as a DBA that does not understand set based logic.
Working with SQL and sets of data is hard. It's a concept that escapes some developers and while they might be able to learn it, you don't want to have them dragging your team down. The primary DBA needs to understand sets, multi-row operations, and joins.
If you find a great employee that doesn't understand sets, hire them. Just not as the DBA. Let them be a developer, project manager, whatever, and then find someone else to be the DBA. Maybe you can grow them into a DBA, but they should understand the basics and be comfortable with the technology, in this case SQL Server. They might struggle in some areas, but that's ok as long as they're comfortable and these aren't critical areas.
Along the lines of being a successful DBA, you should have a list of questions. If you don't know enough about SQL Server, then turn to one of the resources at the end, grab one of our Two Minute SQL Server Stumpers books, or hire a consultant to build you a test. But have a list of questions.
Along with this list, be sure you know which ones are important and which ones aren't. By this I mean which apply to your environment. You might have a question like:
In what order do you upgrade replicated servers?
Now if you are thinking of implementing replication for some new project, this might not be a critical question. Your environment will be growing and the DBA can do so with it. If you have 200 databases being replicated across 12 servers and 3 countries, this might be fairly critical.
So, be sure you don't automatically discount someone because they can't answer some question that may or may not be important to your environment. I forgot one of the principles of ACID in an interview a coupe of years ago. After a decade with SQL Server, I forgot one of the primary principles of a relational database. Did it matter? Well I admitted I'd forgotten and got offered the job, but either way, I'm not building SQL Server, so it's not really a part of my job to be able to understand ACID. Now if I couldn't find duplicate data in a table....
You want to ask a variety of questions to explore the boundaries of someone's knowledge, but be sure that you are really focused on those questions that apply to your environment. And be sure that you know which questions these are.
I'm delving a little into interviewing and you might not be the person that conducts the interview, but you want to have some input. If you're going to be working with this person, ask to be involved and if you can't get into the interview, try to review the questions, contribute your own, and be sure that the core skills necessary are being checked.
And be sure you know the absolute minimum the candidate needs in those areas. And by minimum I mean minimum. In most cases this means the person can perform backup and restores, write queries, and manage security. Things beyond that will vary with the position, but know those core skills because if someone doesn't have them, they won't pull their weight.
Lastly, give people a break in the interview. Most people are nervous and they don't get a copy of BOL to reference. Syntax, specific memorized values, like how many tables could be in a database, etc., don't help you to test technical skills. Ask conceptual questions and allow for minor mistakes if it appears the person grasps the concept. Weigh this against their personality when voting to hire someone.
Growth
Most people in this business want to learn. They want to be challenged and work with different technologies and projects. Others are more set in their ways and want a stable, comfortable place where they can come to work everyday and just do their job.
Make sure you hire the right person for the right position. A job that is methodical and tedious over time fits people that would fail in a creative, build-new-things-and-fight-fires position. Be sure your boss takes this into account when making a decision. A bad fit is a bad fit and doesn't help either side succeed. Hiring people takes time and resources and you don't want to repeat it unnecessarily.
Conclusion
Suppose you have a four blocks that meet at a four-way intersection. At the end of each block you have a different person: Santa Claus, the Easter Bunny, the Great Pumpkin, and the "Best person for the job". In the intersection is a bag of money. If you blow a whistle and all start running at the same time, which one gets to the bag of money first?
The answer is none of them because none of them exist.
I hear "the best person for the job" and I want to laugh because the people and the jobs are always morphing, so even if you find the best person today, maybe they're not the best person tomorrow.
And even in the limited domain of candidates that you have applying for the job, how do you measure them against each other? Who's the better DBA or a small company, Brian, Andy, or I? Brian probably has the most experience, Andy's very business savvy and me, well I'm fun. We all have over a decade of SQL Server experience. Who's the best?
It's something that varies by who you ask and how that person feels that day. Every decision will be based on a "feeling". So here's the best advice for you to use, or to pass on to the person that makes the decision.
Eliminate those that can't pull their weight with the minimum technical skills needed.
Eliminate those that don't meet your personality criteria (meaning all, or most people like the candidate)
Go with your first instinct on whoever's left.
Resources
Interviewing questions:
- Who Do You Hire? - A variety of questions
- Survive A SQL Server DBA Technical Interview
- SQL Interview Questions with Answers
Interview Resources