TSQL Tuesday, the brain-child of Adam Machanic ( blog | twitter ), has come around once more and this time it is being hosted by Kendra Little ( blog | twitter ). The topic? Interviewing Patterns & Anti-Patterns.
Truth be told…
… I have not had that many interviews. A combination of not being that long in the working community since college and staying at the same company for quite a while means that it’s just not something at which I’ve had a lot of practice.
I suppose that I should do one or two, if not to look for a new place to work, then to practice them, see how I measure up, and test my skill.
Mainly though to answer some questions that I have.
Questions about interviewing for DBAs.
I hope you don’t find them too boring or basic.
How do you interview a DBA?
This question is one that I couldn’t really wrap my head around. How do you interview a DBA? If the purpose of an interview is to evaluate a candidate for a position then how do you measure them?
Technical wise, what do you do? Most of the interviews that I’ve been to have involved some aspect of testing, but the thing is there are different types of DBAs, all to do with what they focus on.
Do you judge a DBA, who is focused on Virtualisation, on the intrinsics of SQL Internals?
Or a DBA, focused on Azure, on their knowledge of SQL Server 2005 and when certain T-SQL functions came in?
A company who is looking for a database design expert is going to focus on that and may not care about a DBA’s expertise in HA/DR options.
How do you ensure that you are adequately testing the competency of a DBA?
How do you interview a company?
Interviews go two ways though, and companies can be more wrong that right (it happens).
The question here is when you run into a company with the wrong beliefs, what do you do?
If the company interviews you and says that you’re wrong in saying that TRUNCATE TABLE can be rolled back, what do you do?
If they say that index rebuilds doesn’t update index statistics on the columns in the index, again what do you do?
What do you do if they won’t listen, if they won’t look at any examples, if they won’t see reason when given proof to the contrary?
How do you deal with a company that is incorrect in their basic assumptions and unwilling to learn?
They say that the DBA role is changing…
…and that we, as DBAs, have to learn to change with it otherwise we’ll get left behind.
A concern for me is that maybe the way that we interview DBAs isn’t right, and that it needs to change or it, too, will get left behind.
Unfortunately, like most things, I don’t have the answer yet…
I’m learning though…
I don’t think this is too boring or basic at all. Rather, you raise excellent questions — and thinking about them will help people on both sides of the interviewing table. Thanks for writing!