Others Talk, We Listen.

SQL Technical Interviewers: Seek Opinions Not Facts

by Bob Lambert on Feb 19, 2014

Asking fact questions in technical interviews is like eating a donut, feels great at the time but not so satisfying later.

Let’s say the interview consists of facts like this “softball question”: “What is the default port number for SQL Server?” The linked list of questions is a really good high level study guide for a SQL Server student. If a SQL Server developer candidate answers all correctly, then the interviewer can be confident that the candidate knows a lot about SQL Server. 

However, few development jobs require only technical fact knowledge. Typically, developers must apply creativity when working with unclear or poorly expressed requirements under tight schedules. They must be versatile so that they can take on unforeseen roles in case of resignations or transfers of team members. If you make an investment in an individual by hiring her or him, you’ll look for a return in the form of professional development as the individual grows their skills.

So how do you test creativity, versatility, and ability to learn, while still gauging raw technical talent? My method is to ask opinion rather than fact questions. 

Anyone with more than a year’s experience, with a tool or technique, should have opinions about what works and what doesn’t. People who are truly interested in their career field like to share their opinions, the experiences that created them, and the underpinning technical facts behind them. If you ask for opinions on design options, then you can not only find out if the candidate knows what he or she is talking about but also follow up with questions. Did specific project experiences form that opinion? What has happened when that design guideline wasn’t followed, and what did they do about it? And so on. 

Using the list linked above, here are the questions I’d substitute for some of theirs:

1. “What is your approach to monitoring database performance?” instead of “What are DMVs?” and “What are DBCC commands?”

2. “When is it not a good idea to use a global temp table?” instead of “Define a temp table” and “What’s the difference between a local temp table and a global temp table?”

3. “How do transactions impact performance and integrity of an application?” instead of “How do you use transactions?”

4. “What are the costs and benefits of clustered and non-clustered indexes?” instead of asking the difference between the two.

5. “When do you use truncate as opposed to delete?” instead of asking for descriptions of the two.

6. “What is your approach to troubleshooting a slow query?” instead of “What is a Query Execution Plan?”

Rather than just seeking quick fact answers, these questions require understanding of the technical concepts and how to apply them in real world situations. The candidate’s answer will clearly show level of interested in the topic, hinting at ability to learn, and the interviewer can follow up to explore creativity, flexibility, and non-technical capabilities like attitude and teamwork.