RE: How do you conduct technical interviews ?
Date: Wed, 13 Aug 2008 16:06:27 -0400
I have interviewed 3 or 4 dozen dba's and developers over the years and at first I did pure tech interviews and got stuck with individuals that could quote "the book" verbatim but when they had to combine 2 pieces of information to solve a simple problem could not accomplish it. So over the years my questions shifted toward asking more general questions that identified a person's thought process and their willingness to not only think outside the box but go there as well, with technical questions thrown in as follow-up questions.
My first hiring mistake many years ago was an individual with a very impressive resume with lots of experience from high end consulting company. I realized it, 2 days after I hired him when he was vehemently arguing with a junior dba that DDL needs to committed, and the junior dba obviously knowing better. The next project that was assigned to him (from my boss at the time), was to work with one of the mid level developers to identify records that changed between two different systems. At his direction, a pl/sql procedure was written that compared each record in each system, row by row and field by field. It took 2 weeks to write the code which processed 400 (400 not 400k) records an hour. This process had to be run daily for 4 million records. Later when I took over the task I wrote a 2 queries each with a minus which processed the data over 10,000 times faster about 4 million per hour.
This experience is what lead me to ask questions, about how a person thinks. If they can think through a problem, then learning specific functionality should be easy while the reverse in my experience in not true. I find it easier to teach an individual about bulk processing for example than teaching them problem solving.
Some of my favorite questions and answers
Q1. What do you do when you come across a problem that you do not know how to solve? Most common answers are Documentation and Metalink. Second most common answer is "I have never come across a problem I didn't know the answer to". I prefer to hear a broader answer that contains at least some of the following: Google, Asktom, Oracle-l, my coworkers/manager, friends, user group, books, white papers from user groups/ conferences.
Q2. What project have you worked on that you are most proud of from a technical point of view and why? This question is very open ended which I then like to drill into and ask technical questions about their implementation. This provides an insight to what makes a person happy, and if/how they solved problems in the past. I feel that an interviewee should be very proficient in any topic that he/she brings up in response to this question.
Q3. What are your favorite changes/enhancements Oracle 10g (latest or next to latest major release) and why? This question gives me a feel for how up to date an individual is and what features they have used and find important. One answer I got from an individual that worked on "10g extensively" was that there weren't any major enhancements in Oracle 10g vs 9i, and it was just a marketing thing by Oracle.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Dba DBA
Sent: Wednesday, August 13, 2008 1:29 PM To: oracle-l_at_freelists.org
Subject: Re: How do you conduct technical interviews ?
as far as compensation... I have worked with people who make well over $100/hour who still don't have this type of personality. I have worked with hourly contractors pulling down this type of money who will sit and surf internet because its not a problem for their narrow domain and then expect to be paid for surfing the internet and waiting for a problem to be solved. I have worked with people who have 30 years experience who do this. I have worked with people who refuse to do anything unless its totally perfect.
I have hired people who nail every answer in a technical interview, but then when you get passed the textbook to actually doing stuff and having a decent personality are useless. I think I have gotten alot better of screening out people who give good textbook answers to lots of gadget questions and people who can actually implement.
I think its hard to find the right personality. This type of personality is more important on a smaller team, but is useful on larger teams. I also know that in some environments you can get in trouble for being pro-active because its outside your domain. I have had a manager who would not allow us to check out code and had to do it for us. She would expect us to surf the internet for weeks waiting for her to individually assign stuff to us. I prefer the opposite.
Lets face it. DBAs and to some extent administrators in generally have alot of people in the profession who are just plain difficult to work with. It seems like alot of them are autistic. You tell them one thing. They hear what they want to here. You say something and they over react. Send an email to 15 people and CC 3 different VPs to show you up. Or play the passive aggressive game. Where you talk to them and they just blow you off and don't respond or say they will do something and won't do it. These are people that know all the gadget answers, but are just jerks.
You know the type. They worked with some java developers on a previous project who were idiots. Therefore all developers are now idiots and they are all treated this way. The kind that complain about everything. Some times you just don't have the schedule for something to be perfect, but we have deadlines and if we want to keep getting paid we have to make do.
I have worked with people who have great attitudes. Its just really hard to screen them out in an interview. One thing we started doing is asking them to describe their organization, project, and what they do at the high level. What value do the users get out of the applications they work on? What value do they add to management? Most of them can't get passed Oracle speak. Some are very articulate and can explain more about what they do and how their organization works. I find articulate people like this are often better. They can more easily explain things to non-technical senior management and to non-oracle techies.Received on Wed Aug 13 2008 - 15:06:27 CDT