SQL Exercise During Candidate Interview Process

A discussion of how BPS uses a SQL exercise for candidates and why it is helpful

At the Boston Public Schools, SQL is highly important. As I mentioned in my introductory post, the data at BPS is vital and a significant chunk of time for any application developer is spent at the database level writing, modifying, or reviewing queries.

Over the last year, we’ve spent a good deal of time looking for good candidates for a few open application developer positions. Some of the interviews went well, others not so well, and we’ve made several new hires in the last year. One of the key aspects to the interview process has been a SQL exercise we administer. Candidates work out the solutions at a computer connected to a real database using Query Analyzer and/or SQL Management Studio.

The SQL exercise itself isn’t terribly difficult. It has 5 questions, with the first few being somewhat easy and the last couple being moderately difficult but certainly not overly complex. Rather than asking 5 unrelated SQL questions, each question builds on the previous one in some way by adding a handful of extra requirements or a particular logic modification. While the questions aren’t too difficult, the exercise has become a cornerstone of the interview process. Why? For a number of reasons:

1. It establishes that a candidate has a baseline fundamental understanding of SQL. The queries require the use of grouping, correct filtering criteria in the where clause, selecting a certain number of rows, joining tables in the right way, etc. Simple stuff, yes, but it serves as a way to ensure a baseline level of competency in SQL.
2. It shows how candidates do under pressure. We give candidates 30 minutes, and the majority were unable to finish all 5 questions [most got through 4 questions]. While it is completely understandable if someone isn’t quite able to finish, if a candidate is simply unable to get even through the first 2-3 questions, it isn’t a good sign for how they’ll do on the job. However, if they get through all 5 with time left to spare and have developed clean, correct queries, that’s a very good sign.
3. It gives insight into their coding standards. For example, is the SQL clean, indented, broken over multiple lines, etc? Are good table alias names used? Does anything stick out that screams “unmaintainable”?
4. It gives us a way to evaluate how they react if they’re unsure about something. Many of the candidates ask at least one or two clarifying questions during the exercise. For the ones that don’t, it’s either because they completely understand the requirements [which is fine] or they decide not to seek help despite needing it. The latter would raise a red flag – what if they encountered a similar situation while actually working on a high-priority task? We’d certainly prefer they seek assistance and clarification when needed.
5. The SQL exercise is a great comparison mechanism between candidates since everyone gets the same set of questions. While we certainly consider other aspects of the interview when making a hire decision, the SQL exercise can help sway the decision and/or help break a tie between two equally qualified candidates.

I’d highly recommend anyone evaluating technical candidates to incorporate a hands-on technical exercise into the interview process. For BPS, we chose a SQL-oriented exercise, but other possibilities [depending on the focus of the position] include asking candidates to develop a mockup webpage design, code a certain business logic function, develop a simple web form with specific requirements, etc. The exercise should be a representative [though likely scaled down] version of what the candidate will do on the job and will therefore give insight into whether they’re ready to successfully do the job they’re interviewing for.