T-SQL Tuesday is something I don’t participate in nearly enough. When I saw Kevin Feasel’s invitation for this months topic, I knew I had to answer!

One of my favorite things to do is technical interviews (about stuff that I know). So much so that at one time, I had considered trying to start an agency that would screen applicants for their technical skills using SQL Server. If I could do this all day long, I would. (Others mentioned there might be liability and such, so I dropped it. I don’t have interview questions ready for lawyers.)

I just love the whole process though. Tech skills aren’t soft skills. If you know how to write queries, backup databases, and also know a good deal about the internals, I can tell. What I am pretty terrible at telling is if you will be good at applying those skills. I knew people who could sense a slacker, a jerk, or a general faker just talking to them. (A skill that is hard to evaluate until their opinion is overridden!)

But SQL Server (and a bit more of all databases) technical skills are my thing. The hard part is pinpointing the text of the one specific question that was my favorite.

Warning: the story you are about to hear is true. The questions have been changed to protect the innocent.

My True Favorite Question Varies

I have often been called a mean interviewer, and not to put too fine a point on it… I am. The reason is that my favorite interview question is a follow up question to something you got wrong.

It goes like this. “What kinds of indexes does SQL Server support?”

Then, the interviewee thinks a bit, and says, “Two kinds, clustered and nonclustered.”

Now while this is not technically perfectly correct, it is also right in the sense that these are two kinds of indexes. When I wrote the question, I realized that I would probably say the same thing. If the candidate also starts discussing rowstore and columnstore and B-Tree and Hash (in memory), I might move to a different topic feeling like they know their stuff. But since they gave the standard, right off the top of your head answer, I dig in. “How many of each type of index can you have on a table?”

Now, to be clear, I can’t answer that question to any specific detail myself right off the top of my head, much less in a discussion with multiple people judging my every word. I didn’t how many nonclustered indexes a table supports until I looked it up. I guessed 255, but I was wrong as I dutifully looked it up and it is 999. But here comes my favorite part.

When an interviewee replies with no hesitation and a confident, fearless look on their face, and answer something like “255 clustered indexes and 2 billion non clustered” (or something equally ridiculously wrong), this is where I learn a LOT about the person.

This is it. My favorite question

My favorite question is the first follow up to a very wrong answer.

How I follow up seems mean. It kind of is. But this is where I learn if they are lying or simply got something wrong. I don’t let on that they are wrong. I just ask a question like the following. Much of the choice will depend on the level of the person we are interviewing:

• “Tell me how the clustered index is used”
• “Tell me the structure of a nonclustered index”

Or something similar. If they produce an answer that feels like they just got confused. “The clustered index is often used as the primary key index”, then I will realize they may have made a mistake, and we will discuss it a bit and see if it rings any bells. (You know, when their face stops scrunching up and their eyes looking up and to the left in deep thought.)

Sometimes people will dig in and say, again with confidence, something like “clustered indexes make operations faster than nonclustered indexes, but nonclustered indexes are located on another disk.” At this point, I probably move on to the next topic.

But that isn’t the end

I don’t turn off the interview right then, certainly not the first couple of times, because it is entirely possible that they were taught incorrectly. Most of the time what happens is they realize they were wrong and say “I was wrong wasn’t I? I don’t know this well enough, it isn’t something I do, but I thought I did,” or even better “oh yeah, you can only have 1 clustered index… the data is sorted by it, isn’t it?”

And there you have it

That moment is one I am fishing for. This is where you see who they are. And it happens to all of us. There are things we don’t exactly know well enough to spout it out under pressure. It happens to us all. As the interviewer (especially doing remote interviews), I can check out answers and see if they are right. When you are sitting there in a high-pressure spot, you can’t.

Keep in mind that the interviewer may have a set of questions that get progressively harder, including some that it would take a perfect memory to answer. The goal is to get to that point and see how they handle something that the interviewee doesn’t know.

And this is what a lot of people complain about in interviews. “This is not real life, in real life I have computers. Once I figure it out, I can do great things.” Of course it isn’t real life. Of course you have Google, Bing, ChatGPT, Copilot, etc., etc. But if you have been doing a task before…you should typically remember something of it. That is the purpose of the interview, to confirm that you know what you said you know on your resume. (I will leave that for a future blog post!)

To guess or not to guess

I was once not considered for a job many years ago, because during the technical interview, I didn’t say “I don’t know.” I tried to reason out the problem they gave me and did my best to use the knowledge I had and show them I had an idea of what the problem was and how to solve it. I remember responding something like “I am not completely sure, but I think you would…”

The person who I knew that was in the interview said that was the feedback, he guessed too much. I on the other hand, love guessing people when they tell me they are guessing. I won’t drill in on those kinds of wrong answers, I will just see what they are thinking, and it becomes a discussion. They said they weren’t sure, so this is fine. I can see what all they get right and wrong in their answer. This tells me that they know something about the question, and that they are willing to say “I am not sure.”

As an aside: It is really important to determine when a person will say “I need help.” I do anytime I need to. And I am not afraid to ask people junior to myself for help. It is a good chance I don’t know everything they know, even when I know a lot more than they do about an overall subject. Because you know, I may have been doing this since before they were born.

I also 100% respect “I don’t know”. As in “I don’t know how many indexes you can have on a table. I don’t really do that,” is a fine answer for a lot of positions that don’t actually create tables or tune queries. When played right, another good answer to a question like “how many nonclustered indexes can a table have is essentially “Who cares? More than you need.” But it takes talent to be snarky in an interview and endear yourself to everyone in the room.

Sometimes you are just fishing to see what someone knows.

The most important thing to remember

The thing to remember with any interview is this. You are being evaluated, and your interviewer is going to seem kind of mean. I know I do (because I have been told by a lot of coworkers at my previous companies, they had that feeling during the interview!)

But despite my love for the interview game, I actually do want you to get all the questions right and get hired. There is nothing more awesome than finding that new coworker who just nails it. I just generally have to hope the rest of the team did their job and made sure they are generally nice people and good workers, because I am terrible at that!