Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by autarch (914) on 2006.11.22 16:24 (#51850) Homepage Journal
    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 role as?
    * Why should I work here? Sell me on this job.
    • 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.