It’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.
