Thursday, May 31, 2007

Interviewing for DBAs

We are currently looking for contract DBAs and also a permanent full-time Senior DBA and I spent a good part of last week and this week reviewing resumes and conducting interviews.

Thankfully, there are a lot of interview questions out on the Internet. One of my senior DBA's favourite was "What was the most dangerous thing that you have done as a DBA?" and we get a wide ranging and variety of answers to that one. The good thing with this one is that there is no right or wrong answer but rather it provides us with an insight to the candidate's perspective of what is considered to be dangerous actions or actions that requires special attention and care.

We threw a few technical questions in the mix to allow us to gauge the level of technical expertise and knowledge of the candidates as we have found that 10 years spent creating database does not equate a senior level of knowledge and expertise as a DBA. Other questions are designed to identify the candidate's natural behaviour under stress or their thought processes in identifying and resolving issues.

One thing for sure is that it is practically impossible to judge simply from the resume but we still use the resume as our filtering mechanism on who should be interviewed and who shouldn't. I normally scan the resume for the type of work and organization that the candidate has worked for in the past where they picked up their DBA experience. For example, if someone put down that they spent 3 months at a small organization and was heavily involved in implementing RAC, 10gAS, DataGuard, replication, tuning, OEM, OID, RMAN, etc., then I got to question how much experience was picked up for each individual technology within the 3-month period. The other thing that I watched out for is whether someone spent the whole period doing DBA work or whether it was a combination of DBA, System Administration and/or Development work.

I can tell you that it is still a hit and miss exercise as one of my contract "hires" turned out to be a dud and I am still searching for the perfect process to hire the right person.

4 comments:

Joel Garry said...

There is no perfect process. Anything you do is likely to filter out someone who is good. The best you are likely to do is find someone with recent experience in your exact environment and application with your exact social fit who happens to have some non-negative circumstance that enables him to be available.

Good luck with that.

You should perhaps settle for something less perfect and more amenable to training to your environs.

Personally, I can only reliably elucidate the last thing I've worked on. If that isn't what you need, does that make me a bad DBA?

Which one are you? :-)

Peter K said...

Thanks Joel,
Unfortunately with this current round and the "hire" was for contract DBAs, they have to have the right skill from the start. If we were hiring for an employee, then one of the things that we will be looking for on top of fit, skills, knowledge and experience would be the potential of the candidate.

The market for DBA has picked up within the Vancouver area and it's a matter of being first to offer before other employers find out. A little like the housing market here.

Hahah...that was a good one...Gotta admit that there are non-technical challenges here (aren't there always).

Anonymous said...

Hi Peter,

How are you? It is very nice to meet you here! I am one of the candidates who were fortunately interviewed by you and Scott on May 28. I recognize your interview questions are good enough to measure a candidate. I remember one of the questions you asked is what you will do after all the control files are lost but all the datafiles still exist. My answer is related to rebuild the control file using SPFILE. During the interview, I knew there is a way to rebuild the control file, but I could not give you how to do it because I myself was nervous at that time. After the interview, I think about this question and find there at least two ways to rebuild the control file: one way is to run "ALTER DATABASE BACKUP CONTROLFILE TO TRACE" from another Oracle server to create text file, then modify it to fit in the broken Oracle server. And if the "ALTER DATABASE BACKUP CONTROLFILE TO TRACE" was used to run at the corrupted Oracle Server, it is more simple, just one PL/SQL command: CREATE CONTROLFILE REUSE DATABASE 'your_ORACLE_SID' NORESETLOGS ARCHIVELOG

It is hard for you to find a right person for this position. An experienced DBA may not complete the job. You need a person who must be a good DBA, as well as a good developer. For example, to transfer Oracle naming implementation to OID, a guy must know LDAP, he/she must write a program to import/export data.

Peter, I thank you very much for your time to interview with me. During the last two weeks, I tried to contact you but your email was undeliverable. I hope you could give me some feedback so that I know why I am not the right person for this position.

Sincerely,
Jim

Peter K said...

Peter, I thank you very much for your time to interview with me. During the last two weeks, I tried to contact you but your email was undeliverable. I hope you could give me some feedback so that I know why I am not the right person for this position.

Jim, thanks for your time and I would suggest that you talk to your Account Manager, Alison on the feedback. I've spoken and provide feedback to her. This is not the right forum for me to be providing feedback on a specific matter.