This 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:
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.
