Re: Interviewing experiences with novice interviewers

Mark, and others.

I have been following this thread with some interest because it is a subject which I have some experience on both sides. I feel that most people put too much into this subject.

In my experiences as the person being interviewed I look forward to an interview where the questions are technical but put into the context of a situation that is indicative of a production or development environment. I often ask the interviewer to put their question into that context. This gives me a good idea of the interviewer's understanding of the question itself and tells me if he/she looked it up or if they will understand the answer. I also understand the importance of "knowing what I don't know" and if I don't know I will indicate the resources I would use to find the answer and I will also often ask the interviewer to answer the question himself/herself.

As the interviewer, I will usually spend the first 5-10 minutes getting to know the person. Part of the criteria has to be whether the person will bond with the team or not. Then I will put my questions in specific context, I.E. "You receive a call from one of the application support team, he/she says that the system is slow, what do you do?". In my experience this is very common. I listen to their explanation of the process to isolate the issue and sometimes give them direction, for example, if they indicate the use of iostat, vmstat, top, ps, or some other method of isolating top sessions, tell them "OK you find a process taking all the CPU, what next". It is this experience that will tell you how deep the person really is.

I know a lot of DBA's that are very very smart technically but get frustrated and lost when it really counts and they have 7 people standing behind them when the production environment is having issues.

I would want someone with a good understanding of the architecture and the database, but I also want someone who is always ready to learn something new, knows what he/she doesn't know, willing to ask questions of the team, willing to take on a challenge, and honest when they may make a mistake.

As a perfect example, in my past life I managed a team of production support db admins, system admins, and network admins. When hired, each person was given direction on the to do's and not to do's. One day, a system admin came into the office to explain that he violated one of these rules and corrupted the shadow file on all of our database servers. These servers were all over the globe from Germany to Toronto to London and Denver. We gathered the team, I explained the situation to the VP and we spent the next several hours correcting the situation. The next day he came into the office and stated he was ready for whatever action I thought was warranted.

To make my point I explained to him that I would not take additional action because of two reasons. First, he came to me and the rest of the team when he made the mistake and didn't try to hide it. Second, I knew he would never make that mistake again. The rest of the team came together and we resolved the issue with little to no effect on the servers. This admin turned out to be one of the best on our team and always to supported anyone else on the team.

I may have gone way off topic but the point is that it is the person, their ability to learn, and their understanding of what they don't know that is sometimes most important to determine during the interview process.

Mike

--
http://www.freelists.org/webpage/oracle-l