Software, technology, sysadmin war stories, and more. Feed
Wednesday, April 3, 2013

How to ask questions of your interviewer without seeming evil

I've noticed a common theme in discussions of my "put down the crack pipes" post. Specifically, when it comes to participating in an interview, some candidates like to ask what the caller does just to break the ice. The problem is that if they don't choose the right wording, they might come across as particularly evil when no such evil is intended. Using a blunt question like "are you an engineer?" is a great way to earn yourself a one-way trip to "no hire".

I have a suggestion to anyone who finds themselves in this sort of situation and yet wants an answer to their question. All you have to do is broaden the scope a little.

Which team are you on?

That's a great question. If you asked me that over the years, you would have gotten something like "it doesn't have a public name, but it's the big account system you log into", or "it also doesn't have a public name, but it's the scary-big database which stores all of your prefs". After that, there was the "kernel qualification automation team", and then finally "yet another project without a public name which acts as a nanny for all of the machines in production".

If it's a really small company, you might hear something like "well, we're all on the same team", and that in itself is potentially useful information. Likewise, if the interviewer can't answer because they don't know or aren't allowed to give even a sanitized description of their job, that might tell you about the environment at that company.

Let's say you still don't trust that your interviewer is technical. I don't know why you'd feel the need to suss that out during a phone call which is all about you, but let's say you go there anyway. You can still get an answer without coming off as some kind of sexist ramrod.

What's a typical day like for you on that team?

Assuming they answer it honestly, then you might be able to learn quite a few things about what they do, their credentials, and whether you want to be a part of it. Imagine a description of a day which went like this:

Well, today, I guess I got to the office around 10... late enough to where the carpool lanes are open to everyone and the traffic has died down, but still early enough to actually get a parking spot by my building. I pushed out the new version of our storage software to a couple of locations and checked on how it was doing at the places where I pushed it yesterday. Then I updated the push schedule for next week with the details.

I guess after that it was time for lunch, then I scooted off to make this call to you. After this, I'm going to key in my reactions to our applicant tracking system. I'll probably wind up working on my project to add better logging to our production toolbox after that. I may or may not grab dinner at the office, and then I'll probably go home by 7:30 or 8 or so.

Here are a few things you can learn from this ...

One, your interviewer drives to work alone and this implies she does not take the company shuttle for some reason. Two, traffic in the region can be a pain (that's not really news, though). Three, parking anywhere close to the office can be a problem. Four, she does pushes to production. Five, she does QA checks on those pushes. Six, there's a "push schedule", and she creates or maintains it, or perhaps just has write access to it.

... and that's just the first paragraph.

If that doesn't strike you as the life of a typical engineer, then I don't think anything will.