SentryOne Team Blog (

Looking Back at Bad Interviews

T-SQL TuesdayThis month, Kendra Little (@Kendra_Little) is hosting a soft skills topic for T-SQL Tuesday (interviews : patterns and anti-patterns). I'm probably going to go a little off-script here.

Before joining SentryOne, I spent 13 years at a startup. Somewhere around the middle of my time there, I tried for two years – unsuccessfully – to hire a junior DBA. Let me tell you about the experiences I had, multiple times, as an interviewer.

I always started simple, and then routed like a choose-your-own-adventure book, depending on the answers.

  • Describe the different string data types.
  • Explain the differences between a clustered index and a non-clustered index.
  • Describe an indexed view.
  • Tell me about full, differential, and log backups.
  • Explain the different isolation levels.
  • Describe how reorganizing and rebuilding an index are different.
  • Tell me about the principle of least privilege.
  • Explain how to make module and schema changes backward compatible.
  • Walk through the best way to make a size-of-data change to a 100 GB table (back when 100 GB was big and very few online operations existed).

I had several of what I would call "fakers." People who passed the phone screen with flying colors, but then performed terribly in the interview. I had a few admit that they used Google while on the phone, and one who confessed that someone else took the phone screen for them. I suggested at least two people take SQL Server off their CV, at least for the time being, since they couldn't answer a single question successfully.

One recurring exercise was to draw, on a whiteboard, their rough idea about the Fatbrain schema (I probably said Amazon most times, but always had to clarify that I only care about the books). Wow, did I get some crazy answers here. One I remember quite vividly looked like this:

Interview Nightmare

I mean, I don't even know where to start with that one. Comma-separated lists of BookIDs in the Authors and Orders tables? It's clear someone memorized table and column names from glancing at the pubs schema, maybe, but didn't quite grasp how you'd lay this information out in a relational database. This could almost have been JSON, if JSON had been a thing back then.

Another experience I had frequently was the know-it-all, who took every question and pointed it back at you like some kind of alternate universe episode of Jeopardy. From "Well, how do you use differential backups here at this company?" to "Well, I've done that for 1 TB tables, but never anything as small as 100 GB. How did you do it?" and even "Well, any moron knows that differential backups are a kludge and are only useful in a few edge case scenarios."

Don't be these people. You're not there to one-up the interviewer, and you certainly shouldn't be applying for a job you're not at least partially qualified to perform.


My own experience as an interviewee

Not counting fast food, bank, and horse betting jobs before graduating from Nipissing University, I've only had a single true job interview. It was a multi-day interview at Microsoft, back in 2008, and I spent about an hour with at least eight different people.

I solved some interesting questions that I hadn't prepared for, like the "two glass balls" problem. I also frustrated an interviewing pair who tried to trip me up on a bunch of hierarchical queries. They must have only known the 2000 syntax, because all of my answers were very minor edits to a simple recursive CTE. (They also didn't believe me that a foreign key could point to the same table – they went to another room to verify, and then apologized.) I was kind of a know-it-all in that case, but truly, don't send a busboy to interview a chef.

In the end I got the offer, but it had to be in Redmond and, at the time anyway, they simply weren't offering enough for me to pick up and move. I thought long and hard and ultimately turned it down. Haven't once had any feelings of regret about that decision.

5 replies on “Looking Back at Bad Interviews”

5 Comments (Comments are now closed.)
  1. I had a candidate where I learned I hadn't read his resume close enough before sitting down to talk. It had stuff like vb script and other sort of unrelated technologies to the job at hand. To get a feel for people's thinking I ask about unrelated technologies sometimes. So, I asked "What sort of stuff have you done with vb script?" He would answer "Well, people at my organization have done a,b,c…". I was sort of getting confused. Well, he didn't know what he was supposed to and did not get moved to the next step. Later I looked at his resume more closely and it was just full of "People at my organization have done…..". Wow. I guess that was to get past any word search filtering. It never occurred to me someone would put skills on a resume that they in fact did not have, won't miss that one next time.

    I was working at a hospital at the time–should I have put on my resume "People at my organization perform open heart surgery." ;)

  2. I'm thinking a valid option for candidates who are stumped by a technical question is to say, "I don't know how to solve this directly. But I could solve it indirectly by writing a carefully crafted Stack Exchange question which anonymized anything confidential, and lured Aaron Bertrand into solving this problem for me in exchange for Internet Karma."

    Thanks for writing for TSQL Tuesday!