This month, Kendra Little is hosting a soft skills topic for T-SQL Tuesday: interviewing patterns and anti-patterns. I'm probably going to go a little off-script here.
My own experience as an interviewer
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:
What in the fresh hell is 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 each with 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.