At some point in a job interview the candidate should get the chance to ask the interviewer(s) questions. Here are 3 that I think at times could have made me squirm, if I were the interviewer. Any more suggestions for illuminating questions?
Re:My list
nicholas on 2006-11-22T21:35:45
Which reminds me that one non-squirmy question I've asked is What version(s) of perl do you use? Now I might be a bit narcissistic for asking that one, but it does tend to reveal how much the person interviewing you really knows about the system, and about Perl. It reminds me of clkao's classic conference question, which he asked after every talk (until other people started joining in and beating him to it):
What version control system do you use?Re:My list
DAxelrod on 2006-11-22T21:52:25
What version(s) of perl do you use? Now I might be a bit narcissistic for asking that one
Not at all. It gives you useful information, and reveals that you take your pumpking responsibilities seriously.
Additionally, if the employer is interested in you specifically because of your deep knowledge of perl internals, it lets you start a conversation with them about why they use the version they do, and the benefits and problems with that version related to the kind of programs they write.
Then again, I'm relatively new to the workforce, so I probably shouldn't be giving interview advice.
:) Re:My list
lachoy on 2006-11-22T21:55:32
Good questions, but I have one modification. I think you should try to phrase these in a more concretely open-ended fashion (if that makes sense) because you can wind up stumbling onto really juicy and useful stuff.
For instance, instead of "How are conflicts resolved?" I'd ask "Tell me about a conflict in your team." And if they don't get to how it was resolved (which is what you really want to know), you can then follow up with, "How did it get resolved?" or "How did [team member X] handle being on the losing end?" If they start floundering with an example of a conflict, give them a softball, such as the all-purpose and universal: "Have you ever had marketing deadlines conflict with technical capabilities?" After they hit this out of the park they might be more chatty.
Re:My list
autarch on 2006-11-23T01:48:39
Do you realize that these are questions I ask of an _employer_? I kind of assume they're not nervous interviewing me and already willing to be chatty. I do think that making it a bit more open-ended might be a good way to get better information out of them, though.Re:My list
lachoy on 2006-11-23T01:54:16
Yeah, I understood. But even though it's an employer, it's still a human. And because we're in a technical industry, it might be one of those peers who isn't that great at communicating with their fellow humans. And even folks who are decent communicators might be have a script they're told to stick to -- asking the right kind of questions can get them off it.
Re:My list
mr_bean on 2006-11-26T01:53:03
Yes, if it is apparent what your intention is when asking the question, they can just tell you what you want to hear.
If they aren't too sure what the meaning of your question is, they can't lie, or are less likely to lie. Or put an acceptable spin on their reply.
On IRC, konobi added
Are you simply looking for a competent programmer, or are you looking for someone who can bring valuable insight and experience to architectural or procedural issues?
Re:This actually works the other way around...
drhyde on 2006-11-23T13:13:51
When I'm being interviewed - and indeed when I'm interviewing someone - I like it to be more a conversation than a question/answer session. The last several times I've been interviewed, all of my questions have been answered in the conversation. I'll have already, for example, made it clear to the interviewer that I have other interviews lined up, or other positions offered to me, and they'll have already had their opportunity to convince me to work for them.
I like to ask about the manager's management style: who they admire as managers of development teams, what they read to learn more about and keep up with the field.
It's surprising how many people just flat-out admit they just make it up as they go along, or say they don't have time for reading about how to do their job (as though that's somehow a long-term win!).
For example I'd be happy with a manager who's read what Joel on Software and Paul Graham have written on the subject. I could also be happy with a manager who disagreed with those two, or was a big fan of somebody else's writings (which I would then ask for a reference to, for looking up after the interview).
I have a good idea which giants' shoulders I was standing on to become a decent Perl programmer, and what I do to progress further. I'd be really surprised if somebody could be an excellent manager without learning from those who have gone before.
