30 Interview Questions for a Database Administrator and Developer

This blog post summarizes the type of technical questions I would ask candidates for a Microsoft SQL Server data platform administrator and database developer role.

Hopefully this helps both candidates and managers prepare for interviews. I have no qualms in providing the brief answers because your interview, like mine, should be: 

• behavioral: based on scenarios, not multiple choice answers.
• open ended: ask for an explanation, not a single word answer.
• conversational: testing how the candidate would explain this to a client or colleague.
• applicable: only ask questions relevant to your environment and in the job description.

When I was the manager of a SQL Server managed service provider and a principal consultant at a consulting company, I interviewed and hired database administrators to be consultants, remote DBAs, and database developers for our app dev internal projects.

I've divided the 30 questions into four categories.

PASS Professional Development Virtual User Group: Certification Exams Inside Out

Thanks for the 90+ who joined today's PASS Professional Development Virtual Group webinar on Certification Exams Inside Out: How to Think Like a Certification Exam! This was a lot of fun. Thanks everyone for joining us! And great questions!

If you have any further questions on cert exams that we didn't get to during the webinar, reach out on Twitter or LinkedIn. And if you've become unemployed because of covid-19 and my wife Christine Assaf or I can help, let's talk. We're all in to help. Hit us up on LinkedIn.

Here's a link to the slide deck: https://github.com/williamadba/Public-Presentations/tree/master/PASS%20Professional%20Development%20VUG

Sorry about all the technical foibles that our Paresh and I encountered! We weren't able to record it for some reason. Here's a recording of a past presentation of this talk if you want to share with folks who didn't see it live: https://www.pass.org/marathon/2019/careerdev/Sessions/Details.aspx?sid=98558

Stay safe, stay home, wash your hands. Here's some further Q&A:

Q: Does it still make sense to get one of the "old" certifications (MCSA, MCSE) as long as they're offered by Microsoft? 

A: Sure. Exams are always changing generationally and expiring. If being a SQL DBA is still a big part of your career, those older exams do not expire until January 31, 2021 and they will continue to show on your public transcript until January 2023, and the certifications still count towards partner competency attainment through January 2022, I believe. I wouldn't dedicate a lot of time and treasure in achieving them, but if you think you're close, go right ahead. Eventually you will be able to and you'll want to get the newer certifications, as always. Learning new skills in your trade has always been part of the game.

Q: How does the new Azure Database Administrator Associate certification compare to the previous MCSA and MCSE certifications?

A: This is probably a question better answered by others. Aside from further emphasis on newer and especially Azure-hosted technology, I couldn't speak to question format or selection other than what is publicly available anyway. In general, the exams have for a decade been trending towards broader sets of experience (again, an emphasis on delivering solutions as opposed to mastering features).

Q: Tell me more about beta exams.

A: Not free any more, but check the Microsoft Learning community blog for opportunities like this, where you can take a beta exam for 80% off if you're early to it. And while beta exams aren't scored immediately, if you pass the beta exam, you do get credit for passing the exam.

Q: Can you spread crunchy peanut butter with a fork?

A: Yes. That's just science.

@william_a_dba Fantastic session on demystifying certifications. Excellent description on how questions are constructed and methods of deconstruction. #PASSprofdev #certification

— timothy carpenter (@DasCarp) April 3, 2020

Great learning session from @william_a_dba on Cert Exams Inside Out

— Richard Lewis (@gogorichie) April 3, 2020

A very interesting webinar session "Certification Exams Inside Out" by William Assaf @william_a_dba, who went through the process of designing Microsoft certification exams. One part impressed me a lot is that SQL server knowledge is still practically important in Azure databases pic.twitter.com/JZkkGDByen

— John fan Zhang, CFA (@JohnfanZhang) April 4, 2020

Thanks for this fantastic and funny webinar on certifications @william_a_dba! pic.twitter.com/pmXAmxkdwe

— k-m.p (@sql_kmp) April 3, 2020

Why I Don't Use the Architect Title

I get nervous when I see the title "architect" in IT job roles.

I've had this title before as an employer's standard, but lobbied against it. I instead prefer separating job titles from project roles.

Why?

"Architect" as an IT role descriptor carries an appropriate level of technical expertise and broad experience - but typically, for too long. I don't like "Architect" because it sticks.

The verb "architect" implies a leadership and guidance in big system design decisions.
The noun "architect" can be a bludgeon in a software planning meeting.

Putting egos aside when making platform and architecture decisions can be next to impossible if someone decides to wield the "architect" hammer.

Can you think of a situation when large amounts of dated technical experience did not make for quality technical guidance in the future? I bet you can. I bet you know exactly the type I'm talking about.

Platforms, language versions, feature sets and even product suites change regularly, so a clingy title like "architect" may be appropriate for only one or two projects or generations of a given technology. A few major releases, framework versions or platform changes later, and the "architect" title may be as stale and waning as the technical skillset behind it. Without continuing education, "architect" becomes synonymous with "boat anchor".

When the next project comes, the "architect" resource from the original project may be (not as a rule) more gentrified than skilled. And while the "architect" doesn't need to be the most technically savvy member of a project team, the assumption that "architect" was an applicable title a few years ago - and so shall ever be - is a dangerous trap.

• The "architect" for your SQL 2005 project needs to get up to speed on the latest changes (ex: data types, high availability, and columnstore indexes) before serving in a similar role for your new SQL Server 2014 project.
• The "architect" for your .NET v2.0 project that's now in maintenance would perhaps better serve as a developer for your new .NET 4.5 project. 
• The "architect" for your first-iteration Entity Framework 4 project might not be ready to carry the lead that new EF6 application.
• The "architect" for your SQL Server 2008 R2 SSAS multidimensional business intelligence platform may not be aware of architecture features involved in your new SharePoint-based business intelligence project leveraging SSAS Tabular and PowerBI.

Instead of your top-tier developers assuming the title of "architect", try using the names with transient intent, like Project Lead, Team Lead, Technical Lead, Designer, Analyst or Developer.

In summary, please make sure that you and your coworkers aren't treating "architect" like academia treats tenure. It's not a lifetime appointment, and the ego boost that comes with "architect" needs to give way to honesty, humility and continuing education.

The Nine SQL Server Careers

Microsoft SQL Server is a mature and broad technology platform that supports a diverse set of careers - this blog post is an attempt to provide technical detail to my personal theory on careers in the Microsoft SQL Server world.

A mid-tier SQL Server professional who may carry the title "Database Administrator" could find career traction with high-level skill in only three or four of these categories. It would be a rare accomplishment to find someone with honest expertise in all nine of these buckets, and most mid-tier SQL Server professionals have significant experience with no more than six of these roles.

It is also important for any IT professional to be aware of his/her limitations. We should all "know what we don't know," so this blog post is an effort to quantify these items. It is also very likely that the modern "DBA" possesses skill sets in .NET and other surrounding technologies which I do not aim to include here.

"What You Need To Know About Being a DBA and What You Need To Know That You Don’t Know Yet"

Last night was a big success for the first annual Baton Rouge User Groups Networking Night, an all-user-groups invited event that saw members of the Baton Rouge SQL Server, .NET, Java, IT Pro, SharePoint, Women in IT user groups, plus members of user groups in Hammond, Lafayette and New Orleans (all about one hour away) join for a night of short-format speeches on career and professional development. We also were joined by a bunch of new folks from the public who'd never been to a user group meeting before - they picked a great first meeting to attend!

To the ~60 folks in attendance last night, the other seven speakers who made it a great event, our two Platinum SQL Saturday Baton Rouge sponsors, my all Sparkhound colleagues who joined me to speak, my wife who was volun-told into speaking from an HR perspective, and my friends in the user group community, thanks for being a part of that great event last night!

I was one of the eight community speakers and enjoyed presenting a thrown-together talk with a simple and concise title: "What You Need To Know About Being a DBA and What You Need To Know That You Don’t Know Yet". It was a ton of fun to present and share in the laughter!

It's a short slide deck and I pushed my 10-minute window a little bit, but thankfully our timer and stage-hook-master Jeremy Beckham from BCBS allowed some lenience.

If you are curious to see the "big list" of things you need to know to be a DBA, here's a link to download my PowerPoint slidedeck.