Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of nicholas (3034)

Wednesday November 22, 2006
02:40 PM

interviewing the interviewer

[ #31695 ]

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?

  • Is this a new position?
  • Is this job fun?
  • No job is perfect. What do you find is the most annoying part of this job?
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've been looking for a new job recently. Here's some of the questions I ask:

    * What do you like best about working here? What do you like least? What would you change if you could?
    * How are conflicts resolved? Specifically, technical conflicts, interpersonal conflicts, etc.
    * How are business and technical goals balanced?
    * Do you think you're given reasonable goals? How are missed deadlines handled?
    * Do do automated testing? Do you have QA? Code reviews? Docs?
    * How would I fit in here? What do you see my rol
    • 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?

      • 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. :)

    • 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 l

      • 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.
        • 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.

          • 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 [perl.org] 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?
  • I always ask the interviewee at the end of the interview "do you have any questions for us" and give them five minutes for this. You are actually judged on the quantity and quality of the questions you ask at that point. It will quite often reveal what you are interested in, career, collegues, projects, technical stuff etc. If you have no questions, it doesn't reflect very well and probably means you don't actually want the job.
    • 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 [joelonsoftware.com] and Paul Graham [paulgraham.com] have written on the subject. I could also be happy wit