T-SQL Tuesday #54–Interviews and Hiring

TSQL2sDay150x150It’s the May T-SQL Tuesday, and this time it’s a great one. This month the host is Boris Hristov (@BorisHristov) and his topic is one that’s near and dear to me. He’s asking about interviews and hiring, and I have a lot to say on this topic. I could talk about both sides of the table here, and I’ll have to choose one for today, but I’ll give a few more stories over at The Modern Resume.

This is the monthly blog party in the SQL Server community. The second Tuesday of the month is when you need to publish a post, on GMT time, and then link to the invitation. I’d encourage you to participate.

I Don’t Know

I’ve interviewed lots of times in my career. I’m not sure why, because I’ve often gotten great performance reviews, and I think I’ve been well liked at my jobs. Perhaps it’s my own restlessness, but it seems that I’ve often found myself in some situations where I needed to move on for some reason. Quite a few of the times it wasn’t my fauly, but However I’m picky, and so I’ve usually interviewed with lots of companies before deciding to take a job.

A few years back I was unhappy with my current employer (they’d been acquired) and set up 5 or 6 interviews across a couple months. I often get responses from resumes I submit, and usually secure an interview after a phone screen. A lot of my writing at The Modern Resume is based on my success in getting interviews and job offers.

The interview I got was at Raytheon Polar Services, the company that manages the infrastructure for the South Pole research station at McMurdo. A developer friend I’d worked with at a previous job had spent a couple years there, including a summer at the South Pole and he helped me get the interview.


I walked into a room like the one above. My friend and his boss shook hands with me and we sat down. About 9 or 10 others filed in and took seats around the table. They introduced people and said they would go around the table, allowing the various developers to ask questions.

The first person to my left looked at me and asked me, “what is ACID?”

I started to answer. “It’s Atomic, Consistent, …”

I couldn’t remember. I was sitting there, this great opportunity being offered to me, a friend’s recommendation, and I was stuck on the first question of the afternoon. With a room full of developers watching me.

“I don’t know what the rest of the acronym stands for, “ I said (if you don’t, look it up), and then I proceeded to explain that the idea of ACID in databases has to do with transactions and ensuring data integrity and consistency. I also explained that I could google the exact terms, and would after the interview.

I didn’t know, and I admitted it. I try to be honest in interviews, hoping that I can get the company to be honest with me. It’s a joint interview, and I interview the company as much as they interview me.

However I also know that I don’t know everything. I’ve had multiple questions over the years where I didn’t know the answer, and I just admit I don’t know, explain how I might solve the issue. Someone asked me about a complex networking issue one time and I didn’t know the answer. I admitted it, but also told them I had a friend that was a CCIE and he’d be who I’d ask about networking issues I didn’t understand.

When you don’t know, admit it. However don’t stop there. Explain what you’d do. Show how you can learn, or solve the problem. Would you ask other developers on the team? You can do this, but not too often. Would you research? How long do you work on it before you ask for help? Do you admit when you’re out of your depth?

Often I’ve found that showing you can admit faults, can learn, and have plans to drive yourself forward help. Of course, you can’t be woefully under qualified. If I interviewed as an MDX developer, I could talk for days on how I’d learn and the people I could ask for help, but outside of an entry level position, I wouldn’t be qualified to work in that area. Hopefully, however, I’d have made that clear in a phone interview.

Admitting you don’t know is OK. Just don’t stop there.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , . Bookmark the permalink.

5 Responses to T-SQL Tuesday #54–Interviews and Hiring

  1. Great addition to T-SQL Tuesday. Its funny that you picked this angle as this is how I got my current job. When in an interview and I don’t know the answer, I’ll share what I do know on the subject, and then indicate that I don’t know the exact answer, and then I write it down.

    It comes across odd to many interviewers that I’m taking notes during the interview, but those that notice really appreciate the fact that I want a list of the things I don’t know.

    Between me and another guy, my boss voted for the other guy because he had more experience, but the two other interviewers voted for me as I seemed more eager to learn, just by taking notes.

  2. way0utwest says:

    Interesting and congrats on a good interview and taking notes. That’s a good thing to do. I’ve typically said that I’ll check later, and I’ve sometimes even sent the answer back to the interviewer later.

  3. sqlbek says:

    Great post Steve! Kind of goes along with mine, as I advocate that strong candidates should exhibit and embrace resourcefulness, to fill the inevitable knowledge gaps that we all have.

  4. Robert Pearl says:

    Nice blog post! I’ve had my share of “I don’t know” moments. Better option than making a fool of yourself pretending to know the answer. Often in these situations I try to describe what I DO know about the topic, and how I would go about and find the answer. Contrary, I have a special pet peeve about jeopardy type quizzes that tells you nothing about how the potential DBA would go and solve the problem. I mean obscure internals questions about an obscure column in a system view is more like a game of stump the chump, than finding out about your overall experience and skills. On the flip side, I actually challenged the interviewer on a Std vs. EE question – he was wrong (and when I started, he actually laughed about it and said I should have interviewed him.

  5. Pingback: T-SQL Tuesday #54 An Interview Invitation (The Summary) - Boris Hristov

Comments are closed.