You’ve been in the job hunt for weeks – maybe the market’s shrinking or you’re ready to leave your current job and start something new. You finally get a callback; a prestigious company wants to interview you for a highly coveted Database Administrator or Developer position! Are you ready for it?

Interviewing is a complicated process; in fact it’s almost like a psychiatric session. Interviewers ask pointed questions that seem simple, but in reality they’re gathering a wealth of information about you and building a profile of not only your technical skills, but also your personality, drive and overall demeanor to determine whether or not you’re a good fit. Preparing beforehand, knowing how to answer questions during the interview, and following up appropriately afterwards can mean the difference of whether or not you get the job.

Preliminary Preparation

Know the answers to the most common interview questions

Yes, these are pretty straightforward, but if you don’t have a rough idea of what to say, you’ll inevitably fumble through them during the interview. It’s impossible to prepare for every question, but chances are you’ll get asked a couple of the following, and it’ll be worth your time to have the answers ready.

What are your strengths?

Focus on what you’re really good at, like responding under pressure or paying attention to detail. Throw in some qualities that specifically pertain to databasing, what really makes you a great DBA. I always stress that I’m careful, which I think is really important to being a successful (and employed) DBA, but you can also say something like researching problems effectively or providing great customer service. The variation of this question is what would a coworker say about you – don’t get tripped up, it’s essentially the same question. Don’t try to figure out what people actually think of you (sometimes it’s different than how you view yourself!) but answer it in much the same way, adding in some character attributes like reliable and trustworthy, which you may not have mentioned already.

What are your weaknesses?

Weaknesses should be carefully chosen and worded; if you’re horrible about managing your time, don’t say that outright. A better response would be, “In the past, I’ve gotten so wrapped up in writing a stored procedure that I’ve lost track of time.” It’s technically a weakness, but it shows your unwavering dedication to development.

Tell me about your current job.

What they’re looking for here is a basic run-down of your job responsibilities, as well as what you do specifically. For example, “I’m the sole DBA and developer in a production environment, working with multiple terabyte databases. I’ve migrated production databases from SQL Server 2005 and 2008, provided custom reports with Report Server, programmed custom data extractions with SSIS, and did performance tuning and maintenance on over 100 databases.” Be specific – they’re trying to learn what you actually work with, as the database world is quite vast and no one does everything. You can mention specific third party products here too, like Idera or Red Gate’s offerings. It may be a product they use and could be beneficial.

Note: If you’re brand spanking new and have never had the illustrious title of DBA before, try to play up any experience in your current job that has to do with databasing. For instance, if you’re a system administrator, talk about the projects you worked on with the DBAs or any custom programming you’ve done. If you’re fresh out of school and vying for a junior DBA position, talk about your experiences on a major class project or even what you’ve done in your personal lab environment. Just don’t act too overconfident – meaning if the interviewer says something you don’t understand, don’t just nod, he may call you on it!

Tell me about a difficult problem you had to solve successfully.

I love this one – It’s your time to shine. Come up with a really good one, like the time you had to rebuild the master and saved the day (provided you didn’t mess it up in the first place), or that amazing extraction you designed with ActiveX controls under the hood. Again, having talked through it beforehand will make answering it in the interview easy.

Tell me about a recent failure / difficulty working with another person.

This one is more tricky; what they’re trying to discern is how you handled it (problem-solving skills), and what you learned from it. So you must effectively present a turd and transform it into a bouquet of flowers. How? Well, start with the issue, explain what went wrong and how you handled it, then finish on a positive note. For example, “I was in charge of deploying a service pack. I tested it successfully in our older development environment with no problems, however, in production, it caused a particular piece of code to take twice as long to execute. I optimized the code to fix it, but I learned the importance of ensuring that the development environment is closely up-to-date with production before I test new functionality. I now have a detailed checklist that I follow and have never had a problem since.” So this illustrates that you’re a better person for it. When other people are involved, be sure not to point fingers. Again, explain the situation and what you learned from it. For example: “Though I had some difficulties in communicating with a project manager, I learned it’s best to write out expectations and review to ensure we’re on the same page. Once I developed that system of written confirmation, the rest of the project went smoothly.”

Where do you see yourself in five years?

This one is also tricky, at least for database-type jobs. In the database world, there’s usually not much room for advancement within a company. If there’s a lead position, you can answer it with that. The key is to not sound overzealous or flighty. Most companies I’ve worked for have a single or small group of DBAs, so that very much limits how you can answer. What those smaller companies are looking for is that you’ll stick around. It takes awhile to get up-to-speed in a DBA position, especially if development is involved. You have to learn the servers and how they’re set up, the databases, tables, relationships, stored procedures, SSIS packages, jobs, etc. It takes at least a good six months to get comfortable, if not a year with larger implementations. The company wants to know you’re not going to get bored and job-hop, particularly if your resume has a lot of one to two year job history entries. I was in that category at the beginning of my career – truly it’s sometimes the only way to get a pay raise. When you start out as an OS Admin or a tech, most companies won’t raise your salary to a DBA level, even after your responsibilities change. So you get your first real database job somewhere else, but with less experience comes less pay. Once you’ve been around awhile, the company will probably not adjust your pay to reflect your experience. Sad but true reality. A good answer to this question, then, will assure them that you want to stay with the company and continue to be the fine, upstanding database admin you are.

Why do you want to leave your current position?

The best, safest answer to this question is something like, “To pursue other opportunities.” Of course you should elaborate – you don’t want to seem mysterious because then they’ll think you’re hiding something. No matter what the size of the company, as a DBA you often end up doing the same thing over and over, so this answer is perfectly acceptable. Don’t talk down the company or any of the people there, even if that’s really the reason you’re leaving. Also you’ll want to leave out lack of pay or poor raises. I know that seems common-sense, but if you’re an honest person, it can be difficult. Talk about some of the new opportunities this job has to offer – for example, if it’s a larger company, setting up and maintaining High Availability (HA) / Disaster Recovery (DR) solutions.

Interview Time

When it comes to technical jobs, there is usually a set of technical questions that are asked to gauge the candidate’s technical prowess. Yes, it is nerve-wracking. Often you will be asked how to do something, and you have to visualize the interface in your head and go over the steps, naming the pieces of the UI or specific commands to demonstrate technical competence.

A common question would be to name some native tools and utilities you use to troubleshoot performance issues. You might even be asked to write specific SQL syntax or diagram an entire solution to a complex database scenario on a whiteboard. Once I was asked to write a CTE as the solution, another time I had to select the appropriate backup types for a given database failure situation.

The other kind of question is more of a high-level overview, where you need to explain enough of the concepts to show you are skilled in that area. They’re trying to confirm that your actual skills match your professed skills. Hopefully you didn’t embellish your resume too much, and you can answer the question! If not, be sure to be honest with them, and tell them you don’t know. If you fail a basic question, like writing a syntactically valid simple SELECT statement, don’t expect a callback from the interview. However, if it’s something you’re not familiar with or don’t do every day (recall how you answered in the ‘tell me about your current job’ question), then it’s understandable if you’re not sure or can only provide a partial answer. The most important thing to remember is to be honest. Nothing is more of a turn off in an interview than people who act like they know everything under the sun, then attempt to tap dance their way through a topic.

What to do

Answer technical questions as briefly and accurately as possible

Think about exactly what it is they’re asking for. People tend to go off on tangents when they’re nervous. For example, the question may be about backup strategies, and you end up on your dissertation topic of how transaction log files work. Though the tangent may be related, it’s not answering the question, and that’s not good in an interview. You need to show that you can stay focused, especially for a DBA position.

Try to avoid filler words like uh, um and other verbal pauses. The key is to take a little time before you answer to organize your thoughts and have a clear outline of what you’ll say before you speak.

Try to avoid talking with your hands. This one is my Achilles’ heel – I’m from New Jersey and everyone talks with their hands there. To compound the issue, I used to instruct, so I regularly gesture to an imaginary whiteboard. A few gestures here and there will keep it interesting; just don’t go crazy with it.

Ask questions

This one can easily be overlooked or forgotten when you’re in the middle of the interview, nervous, and trying desperately to impress the interviewer. But it’s important to ask questions. It’s an indication that the lights are on and somebody’s home. It’s also your opportunity to turn the tables, so to speak, and make your own psychological discoveries.

• Responsibilities – is the job more production or development? This may have been covered initially by the interviewer, but if you have any additional questions, be sure to ask so you know exactly what you’re getting into if hired.

Author’s note

Sometimes when you ask questions like these, you can get a glimpse into how often you’ll be spending your Saturdays and weeknights at work. Of course it’s in the nature of the job to have unscheduled overtime on salaried pay; someone has to combat rogue code and random hardware outages. The issue is your tolerance level of DBA abuse versus their situation and needs. Keep in mind you won’t get the whole truth, especially if you’re interviewing with the person you’re going to replace. This is when it’s important to pay close attention to body language, tone of voice and overall demeanor. Does the person seem happy or stressed out or depressed? It may be a good indicator of how you’d feel working there.

If the interviewer is a peer or even the direct boss, ask what he/she likes most and least about the job. These kinds of questions are important for two reasons: the first is to get an idea of what it’s like to work there, and the second is to get a feel for his/her personality. You may find that the work environment isn’t what you want, or that you wouldn’t like working with that person. Granted, it is hard to tell if the person really is a creep from a ten minute conversation, but sometimes you get lucky. This is really important in smaller shops, where you end up spending more time with your coworkers than your family. Why is the position open? Again, this’ll give you a feel for the place. Did they fire the last person, are they expanding? If given an intentionally vague answer, you might want to keep looking. Expectations – how is performance evaluated? What is the management style like? Training opportunities, especially for learning new versions of the database software. Questions geared toward the company or business in relation to the job, such as, “In supporting insurance-related databases, would you say the databases tend to be more OLTP or OLAP?” Towards the end of the interview, be sure to express your gratitude and interest in the position, as well as summarize any strong characteristics/experience that pertain to the job.

Remember to breathe. It’s important you don’t pass out.

What Not to Do

Be dismissive when corrected, if you answer a technical question incorrectly. Also don’t fight with the interviewer, or try to make excuses. Be respectful and polite at all times.

Dominate the interview with grandiose stories of how awesome of a DBA you are. This one can be hard for DBAs, as many of us are somewhat egomaniacal, if not completely suffering from a God-complex. An interview at its core is a conversation, so there should be some give and take. If you find the interviewer is keen on telling stories, engage but don’t compete and turn it into a contest.

Act superior. Even if the job is for less pay or less responsibility, it’s never okay to be superior. If you honestly feel that way, apply for a different job, because anyone good at reading people will see it.

Discount the importance of character-based questions and focus all on the technical questions. Particularly in a group with multiple DBAs or even in a smaller shop, personality is arguably more important than skill set. You could be the most knowledgeable DBA in the universe, but if your personality is a poor fit, you’re not going to get the job. It’s also important to think about customer service questions and answer those properly. Most DBA positions involve interfacing with end-users of some kind, and the ability to explain difficult concepts and have a good sense of customer support is critical. I remember being asked in my interview a deceptively simple question like, “Is the customer always right?” The answer I gave wasn’t cut and dry; sometimes it’s okay to push back when the customer is proposing a bad solution for their needs.

Post Interview

It’s important to do a follow-up thank you correspondence, either by email or snail mail. In it you want to address the interviewers by name and thank them again for their time. Take the time to edit it, reading it aloud to ensure accuracy. Spell check doesn’t always pick up all the mistakes, and it reflects very poorly on you if you can’t compose a couple of simple sentences correctly.

There you have it, all of my knowledge on how to survive the DBA job interview. Please keep in mind, these are my opinions and experience, your mileage may vary. Good luck and happy interviewing!