As you can probably understand from the title, this is not going to be a regular post (and a bit long as well), as usually my posts are technical. I have been thinking about writing this post for a while now, and lately, for some unknown reason, have had the urge to finally start. It will be about my opinion and my experience with DBA interviews.
I have been a DBA since 1998, which is about 17 years now, when I’m writing this. I have to admit that during these years I wasn’t interviewed many times, probably about 4-5 times (technical interviews I mean). I have, however, interviewed quite a few DBAs, most of them in my current position as a VP Professional Services at Brillix (a 20-employee database consulting company).
So this post is going to be about my opinion, my way, do and don’t and other stuff from my experience. A disclaimer I need to mention – I’m not an HR person and don’t have formal education in this field, but any way I will be covering only the professional side of the interview.
What are You Looking For?
I think the first think you need to do is decide what you are looking for in your DBA. A “good DBA” is not a good answer. An “experienced DBA” is not good as well. We are constantly looking for good people, which are hard to find. But how are we looking for them, and what are “good people”?
Another thing to remember is the professional level of the person we are looking for. A 10-year experienced DBA is totally different than a junior DBA with 1 year of experience. And this will affect both the questions I’ll ask and the answers I’ll expect to get. Also, a junior DBA will be exposed to a totally different stress level than an experienced one during the interview.
What to Expect from a Candidate?
When I’m interviewing, first I expect that what they write in their CV is accurate (or at least close to reality). If she is an applicative DBA, writing SQL statements and performing SQL tuning for 10 years, I expect that she would understand execution plans, indexes, related features, etc. and would know how to write SQLs quite well.
But we need to remember that the CV doesn’t always reflect the real knowledge of a person. It often doesn’t mention the level of knowledge and sometimes people write things they only heard about, and didn’t work constantly with, so we can’t rely on it. I really don’t, and I’ll explain soon what I do about this issue.
Interview Flow
When I interview a candidate, and I mostly did this in the past in order to recruit consultants, I need her to be a “consultant type”. This type can explain things well, speak clearly, have good human relations, etc. So the first part of the interview is just getting to know the person and understanding who she is.
When coming to the technical section, I divide it into two. In the first part I ask the candidate to give me an example of something big they did like a big project, a major SQL tuning process or something similar. When they explain the process or project, it allows me to assess their abilities to explain and communicate as well as their technical knowledge.
The second part is me asking technical questions. I don’t ask many questions, just a few. By that time I hope I have some idea about the person in front of me, so I don’t need many questions. I also ask questions that might take some time to answer, so asking many of them can be a problem.
The technical part is relevant mainly to experienced DBAs. As I said above, I don’t expect junior DBAs to answer my technical questions during an interview. I might ask them really basic questions, but I’ll look for basic understanding and general ideas to see their potential.
Technical Questions I Will Never Ask
I’ll start with things I never ask, and this is about the details. Good questions for OCP tests, like on specific behavior, initialization parameters, etc. are not good for an interview. Let’s say I’m asking “What is the value of OPTIMIZER_MODE parameter?” the correct answer will be Tom Kyte’s favorite: “it depends”. Because until 9i (including) it was “choose”, and from 10g it’s “all_rows”. If I ask about the meaning of the “_gby_hash_aggregation_enabled” parameter, you might know that the answer is that it disables the hash group by feature in 10g and above, and there was a well-known wrong results bug that got fixed in 10.2.0.3 and some other bugs as well.
Now assume that the candidate knows the answer, what does it mean? And if he doesn’t, what does that mean? In my opinion both answers will be “it means nothing”.
When I ask about a parameter and the candidate knows the answer it means that he had an issue with it or read the manual carefully. It doesn’t tell me how experienced he is or whether he can troubleshoot problems or not. If he knows the meaning of “_gby_hash_aggregation_enabled” for example, he might have hit a bug and learned about it, but someone might have told him about it. It doesn’t tell me that he managed to troubleshoot it by himself.
The same goes for specific behavior, or a question like what “SMON” does. I know good, experienced DBAs that don’t necessarily remember all the details and junior DBAs that just finished the basic DBA course and still remember them. Knowing or not knowing the answer doesn’t tell me whether they are experienced or not, understand the database or not, and basically doesn’t give me any information about their experience.
Technical Questions I Do Ask
As opposed to the small details I don’t ask about, I do ask about the big picture. First, it depends on the expertise of the person. If she is an applicative DBA, I expect her to be able to write SQL and PL/SQL well, and know how to perform SQL tuning. If she’s more on the infrastructure side, she should be familiar with some infrastructure topics (for example: backup and recovery, HA solutions such as RAC / Data Guard, instance tuning).
Since an interview can be stressful, and people are not usually at their best in front of investigating eyes and paper instead of a computer screen and Google, I have a few questions in each field. I also understand that people exaggerate in their CV, so I give the person in front of me several topics, and ask how well she knows them. I also make it clear that it is perfectly legitimate to say “I don’t know it” or “I used it a bit but that’s it”, but if she says “I know this topic very well”, I expect that she will indeed know it well.
Once I have a topic or two she knows well, I ask her a general question in that area. The idea of a general question is to see the way she thinks, and general knowledge of the topic. I don’t care about the small details as I said above, but the general knowledge and understanding are very important to me.
I thought about writing here some specific examples, but that means I won’t be able to use them anymore, so I’ll just explain the idea, without giving the details. Sorry about that 🙂
Example 1
An applicative DBA should know how to write SQL, even on paper. I have a nice SQL question I usually ask, a query that can be written in at least 5 totally different ways. If the candidate gives me a solution quickly, I ask for another way to write the same thing. Two ways are enough for me. If an experienced DBA struggles with the first way to write it, it might be a problem. They sometimes have bugs or don’t think it through, but I can see who is thinking right and who isn’t.
Example 2
Still in the applicative area, I sometime ask the candidate for a basic design of a database. I give her a simple requirement and ask for a basic design. Here too, I don’t care about the details such as lookup tables, but I do care about the main tables, usually no more than 4-5.
After explaining the requirements, candidates usually give me one design option which they think is best. Then I ask for different design options, I sometimes give them a design or two myself. The last part is asking them to compare between the options in terms of performance, versatility, and maintenance.
Example 3
For tuning, I can ask them to analyze AWR report. Again, I don’t care about the details, but I’m looking to see how they start and what they understand about the database performance. As this is a huge report, I don’t care if there is stuff they don’t know or understand, as long as they know how to understand the main things and troubleshoot. During their analysis, I can also ask some questions to make sure they understand I/O, statistics, wait events, etc.
Example 4
For more hard core infrastructure issues, I can take any topic as long as I ask general questions. I can ask, for example, how to design a RAC or Data Guard environment, or how to recover from a specific and a bit complicated crash or any other question.
I’ll say it again, I like to ask general questions, mainly design or general troubleshoot. I don’t care even guiding them towards my expected answer. This interaction should be a process, where the candidate thinks about the way he is going to address the question. During this process (which sometimes can take even 10-15 minutes per question, that’s why I don’t ask many of them) I can assess the person, his knowledge and way of thinking and to see if he fits my needs or not.
My Experience with Candidates
After explaining my method, here are some examples of interviews I’ve had:
Example 1
A few years ago I interviewed an applicative DBA. He had many years of experience (more than me), so it was strange for me to even ask technical questions. But I had to, and I did. As I wrote above, with 20 or so years as a DBA, he should write SQL queries without even thinking, right? I gave him the question from example 1 above. He got stuck after writing the word “select”. I’m usually very supportive and even help during the interview, because of the uncomfortable situation the candidate is in. But in this case, he didn’t even get to something I can help with. Till this day I’m not sure what happened there because it was a very extreme case, but this was one of the times that showed me that number of years of experience is not everything.
Example 2
In a different case I interviewed DBAs for a customer of mine. For this position, I wanted someone who can perform database design, so my question was a simple application they need to design the database for (like example 2 above). It wasn’t too complicated, and I had several options in mind and wanted to see what the candidates decide and how they compare between them. One of the candidates came up with a strange design. She decided to put some of the basic columns in one table along with XML that contains all other information. Although it’s a somewhat valid solution, I didn’t expect that as a first choice from someone that is interviewing for Oracle DBA position, which is a relational database.
Another 2 examples, now with me as the candidate:
Example 3
Quite a few years ago I had an interview with a very technical guy. The questions he asked me are totally different than what I wrote here and I specifically remember 2 questions. The first was about the CKPT process, and we had a little argument there. He asked when it wakes up and I answered. Then he said that I forgot to mention that it wakes up every 3 seconds and I said he’s wrong (I was quite bold in this interview). This was something that I checked later (and found to be right, even though I never mentioned it to him). The second question was if I knew regular expressions. I said I knew a little bit, so he started writing a huge one on the board. I stopped him in the middle and said that I wouldn’t know what it does, so he can stop writing (I told you, bold). Just FYI, I worked there as a consultant twice a week for about 2 years, and I have a lot of respect for him. But you can understand why I don’t get into the small details, right?
Example 4
Another interview I had was even before, when I was very unexperienced. Interviewers sometimes ask about open issues they have in their job, and this is what happened to me. I was unexperienced, as I said, and I didn’t do well at all in this interview (and didn’t get the job as well, and rightly so). I guess this is one of the reasons I don’t do that as well. I never ask candidates about open issues I have, for several reasons. First, if it is so complicated that I have to sit down and think about it for a while (and even consult with other people), it will be even harder for a nervous candidate. I don’t ask easy questions (depends on the candidate’s experience of course), but I choose the level carefully. Second, a brilliant candidate (or a very very experienced one) can give me an idea for a solution, but most won’t, and this will lead to false negative situations. If I’m waiting for the one who gives me the answer, I might wait for a long long time, and I might even fail a person that is perfect for me.
And lastly, general examples that I’m sure some of us encountered:
Example 5
A common thing that didn’t happen to me personally, but to many colleagues and friends, is asking riddles in an interview. Interviewers that I met claimed that if candidates know how to solve riddles, they have a developed way of thinking and can solve problems better. I’m sorry, but I think it’s simply stupid. The fact that I can or can’t solve a logic or mathematic riddle doesn’t say anything about my database design skills or database troubleshooting abilities. I might be good or bad at it regardless. So I’m really against it.
Example 6
The last example will be fairly short, and it’s about tests. Interviewers and HR sometimes like tests. As you probably understood already, I don’t. However, if you build the test that contains questions on not the little details but the larger picture, it might assist in filtering the low-end candidates. That way we can invest the effort reviewing the better candidates and choose our next employee from them.
That’s it for today, long, but I’m quite happy with it. Hope you find it interesting.
Liron
Thanks for that Liron, it’s interesting to see how you try to judge the candidate’s ability and not necessarily their knowledge. I particularly found interesting your thoughts on knowing details.
Over the years, I’ve learnt to be a little dismissive of one of the staples that is asked for in job adverts – being OCP. To be OCP you need to know a load of details. When OCP was new, I thought it would be a good thing as it would force people to learn at least some of the documentation to be able to know the details. It turned out not to be a good thing, especially for more junior DBAs. I would interview for a junior or vanilla DBA and those with OCP tended to both expect to be given some unchallenged credit for being OCP but also could rarely convert the knowledge-of-parameter-names type information into any understanding of managing databases! People without OCP tended to do better at the solving-issues questions. In fact, the last couple of people I knew who did OCP stopped learning the manuals/training courses and just downloaded lots of OCP questions and practiced them. As such they had learnt to be good at the OCP tests but not anything else.
Hi Liron, You are right, checking for small details doesnot help in assessing the knowledge of the person.
One tip that i can give to candidates who attend interview is that they should end their “Tell me about yourself” with the project that they are confident about, so that the interviewer starts asking the questions from that project and then once the candidate gains enough confidence and interview trusts him/her, the interview will go smoothly and then based on first impression, the candidate will get selected.
When i attended interview with Oracle Corporation, they asked me complicated scenario based questions, They ask scenario based questions just to check our depth in understanding the architecture. Once we are good with architecture, then they assume that we would do well in all other departments as well. Some ask questions in complicated recovery, say for example redo recovery for all status – current,active and inactive.
So by asking few complicated scenario based questions, interviewer comes to know our knowledge in architecture and also about recovery. They dont ask complicated RAC or dataguard questions because they know that once you are good with architecture you will perform well in other high availability technologies as well.
Kadhir,
I agree with what you wrote, scenario-based questions are very good (and I like to ask those as well). These questions will definitely show the knowledge and experience of the person. There is one thing, however, that I’m not sure I agree, and that’s what you wrote right at the end. It is really OK to ask high availability questions (about Data guard or RAC), as long as the candidate says he knows these fields very well. Sometimes people know some topics (such as RAC) very well, but not others (such as recovery). It depends on their role and experience. If someone knows RAC architecture but not recovery, I’m fine with that as well as the other way around.
Liron