OracleBlog

"We're interviewing an Oracle guy tomorrow, can you give me a few questions to ask him?"

Not an uncommon request. The problem is, there are literally thousands of potential Oracle questions, but it all depends on what are you trying to achieve. So I pushed back:

"What kind of Oracle-related skills would the candidate need that you want to ask for?"
"You tell us. We just want to know if he knows Oracle. Whatever an Oracle guy would need to know."

Pretty soon thereafter I figured out that it was a pointless conversation to continue, although I did love the way he summarized dozens of very different positions into that one term: "Oracle Guy."

Nevertheless, it got me thinking. What makes for a good technical question? I have conducted, or been invited to, several interviews, so it got me to thinking about which questions were most effective at getting to the heart of the matter: "Will this candidate succeed technically in this role?"

Elements of a Good Technical Interview Question.

1. Must require knowledge of the area, including domain and philosophy, to solve.

I don't think it's enough that a candidate demonstrates proficiency with the technology. I like to see if they understand the overall philosophy of the product (Oracle, in this case): What needs was it meant to provide, what kind of problems was it designed to solve, how does it accomplish those tasks.

2. Must require overall technical skill/experience/understanding to solve.

I mean to say that a good question shows if the candidate understands (for example) relational databases themselves, not just a particular relational database. Carrying this example, does your C++ developer understand algorithms and software design?

3. Does not require knowledge of precise syntax

In my mind, anyone can look something up in a manual. You don't need to walk into an empty boardroom and know exactly how something is called. I don't think knowledge of syntax is a reliable indicator of the suitability of a candidate.

For example, you could have a good candidate "blank out" on the syntactic details, and you could also have a bad candidate who swallowed a reference manual the night before the interview.

Now, I would be worried if the candidate didn't know BASIC syntax. But I don't want to waste precious time asking basic questions, and if he is truly is that inexperienced, I should be able to figure it out in other ways.

4. Can be answered quickly.

Time is precious in an interview, and you shouldn't need long, convoluted questions to determine whether or not a candidate "gets it." A good question demonstrates quickly if the candidate is on the right path, or wouldn't get it regardless of how much time he had.

5. Is not a "gotcha"

I've met some interviewers that seem to use the opportunity not to evaluate the candidate, but to prove how clever they are (either to the candidate or the manager). They do this by asking really obscure tricks, sometimes referred to as "gotchas."

The problem with asking questions in the obscure corners is that even very experienced candidates may not have worked in that area and, if they have, may not have stumbled across that particular gem.

Just remember, the purpose of the interview isn't to make YOU look clever, and asking silly questions might make a great candidate think "what kind of clown show am I getting myself into?"

6. Has many possible solutions and approaches

The most effective questions I have ever asked, or been asked, were the ones that triggered lively technical discussions between the interviewer and the candidate. Why? You get to catch a glimpse not only of the candidates thinking process, but also how he communicates. I also like the added benefit of not punishing (in fact, rewarding) those that approach problems differently than the interviewer.

7. Requires asking for more information (or make assumptions).

Personally, I believe one of the keys to success in IT is to define a problem before approaching it. That's why I lean towards these types of questions. Did the candidate come back, or just try to solve it? If he came back, what kind of questions did he ask? In the face of an incompletely-defined problem, did he get stuck, or did he make some assumptions and continue? If so, what assumptions did he make?

8. Is relevant to the business/job being considered

Would you hire a cleaning service with award-winning carpet cleaning if you had hardwood floors? Would you hire a running back who excels in bad weather if you played in a dome? Would you hire an accomplished science-fiction writer to author your biography? No? Then why probe for technical skills that don't directly apply to the position you're attempting to fill?

Closing Thoughts

Incidentally, in the end I referred the manager in question to a couple of links which have hundreds of Oracle-interview questions. You can pick your favourites but, more likely, you can read them until you come up with good ideas that suit your needs.

http://www.orafaq.com/forum/t/9760/2/
http://www.databasejournal.com/features/oracle/article.php/3085171

As an aside, that last article was written by one of my preferred columnists, James Koopmann. He hasn't written much recently, but check out his archives, he's got some great articles there. For instance, check out his series on Oracle Session Tracing.