I've recently started a new job at a company that uses perl as its main programming language (yay! Being around people that share my professional interests is such a nice change of pace.) And, as part of this job, I find myself having to interview people.

So, I'm wondering if anyone has any good advice? What kinds of questions work well? Are those annoying logic questions worthwhile? Does anyone have any really good questions to separate the strong candidates from those just faking it, particularly relating to perl? (I'm also interested in weeding out mysql dba candidates, but that's probably less interesting to the perlmonks as a whole.) And really bad questions?

I've definitely seen the downside of hiring someone that wasn't up to the position (from both sides, actually), and a lot of people are very good at faking their way through interviews. And, perhaps just as importantly, some really good people are terrible at interviews, and I want to try and find those, too.

(Yes, you can infer that I work for a company hiring Perl programmers. We're in (or rather, moving in a few weeks to) Berkeley, CA. Feel free to send me email if you want more info.)

-- Kirby

Replies are listed 'Best First'.
Re: Perl Interviews
by myocom (Deacon) on Feb 13, 2001 at 06:10 UTC

    There are good discussions of this sort of thing to be found over here and here.

[reply]
Re: Perl Interviews
by arhuman (Vicar) on Feb 13, 2001 at 19:07 UTC

    I have to interview people too, but on the contrary of what you do :I'm not trying to find if people are good;
    Instead I'm rather trying to find if it will be useful/pleasant to work with those people.

    I mean a great programmer, being asocial can ruin an entire team work.
    A Newbie can become a great coder (at an interesting price...)
    An so on...

    So I've choosen some traits which are important to me, and that's what I'm trying to find during the interview :

    1) REAL desire to learn or better a passion for computer/coding.

    Does the guy code by pleasure (does he code at home?) what is the last thing he has learnt and why ?(show me if the guy is ecclectic ? Curious...)
    This desire to learn or coputer's passion is the best garanty that the guy will be constantly improving for me.

    2) Human qualities.

    Hey ! some people (me?) will have to work with him
    Can I trust him ? Does he accept his weaknesses (Those who have no weaknesses in interview tend to report their failure on others(and never learn from their mistakes) according to my experience...) ? Is he smiling ?(don't know for you, but I prefer to work with happy people...) How does it stands pressure ? Is he feared by heavy work load (My boss seems to have no limit on this !)


    Some traits aren't necessay but are although a plus for me :
    Ability to propose solution, loving challenges...
    I tend not to rely to much on experience...


    As you see technical skills/diploma aren't my first interest (although I require BASIC skill in the technical fields needed...)

    And of course, this is by no mean : THE WAY to interview people, but only my humble opininion
    (technically biased as I'm not HR).
    (Just note that I've never been deceived until now)
[reply]
Re: Perl Interviews
by TheoPetersen (Priest) on Feb 13, 2001 at 20:12 UTC
    Before I can help you, I have to interview you :)

    Are you interviewing for immediate help (people who will hit the ground running, as it were), or are you working to build a good team in the long run?

    It would be nice to do both, I'm sure, but the interview styles are different. When looking for immediate help, you should ask technical questions focused on your problem: do you know how to work with sockets in Perl? Have you scripted with CGI.pm?

    To build a good team long-term, interpersonal issues are as important as technical skills. First and foremost, everyone has to get along with you (assuming your interviewing position indicates some degree of team leadership too) so you should be checking for the kind of things that you like in co-workers, and also for things that drive you crazy in people you have to put up with.

    You can try asking about what the interviewees like to do off work, but of course they have every right to turn down personal questions. Do ask about their experiences in programming teams previously, and try to get them to air their gripes and talk about what they enjoyed.

    If you aren't hiring to fill an immediate niche position, the main thing to establish is learning ability and enthusiasm. Does the interviewee wince at your choice of language or tools? Why? Do they display an interest in languages, and in the subject matter?

    You just changed jobs; why? What interested you in the project and company? That should provide some good questions for others considering the same move.

    As for figuring out who is faking it, there isn't a simple answer. Barring a really bad blunder, you have to go with your feelings. If someone gives you a bad vibe, then ask yourself, do I want to work with this person? If you have any misgivings, don't hire them. It's far better to go short handed for awhile than to hire someone you have doubts about.

    People who are bad interviewees are even more difficult. Ask them to expand on answers. Ask them easy questions first to get them in the habit of answering. If necessary, start with what they had for lunch :) If someone seems promising but is hard to figure, ask them for another interview, at a different time of day; maybe even a different location.

    If you have doubts about a person who seems promising, try another tactic. Ask them to discuss a program they've written in detail (bearing in mind that non-disclosures prevent you from seeing the code most of us write for a living). Good programmers love to talk about their best hacks. A little used technique is to ask them to bring a co-worker or friend to an interview. Engage the other person to help draw out the interviewee. You may even find yourself two employees at once.

[reply]
Re: Perl Interviews
by KM (Priest) on Feb 13, 2001 at 20:32 UTC
    Along with the good advice others have mentioned, let me add one thing. I find it useful (and actually enjoyed interviews where this was done with me) to bring a practical problem to the interviewee. For example, 'If you had to solve problem X, how would you do it?'. Then, give them a piece of paper to allow them to write (maybe a short flow chart, or pseudo-code). Then you can interact with them as you see their though process. This was done at an interview with me, and I had a good time interacting with the fellow interviewing. Not only could he see how I think in real-time, but I was also able to follow his thought/design process. It allows you to ask other follow-up questions like 'Why are you using module Z and not module A?', and 'But what if X occurs?', etc...

    Cheers,
    KM

[reply]
Re: Perl Interviews
by seeker (Curate) on Feb 13, 2001 at 17:36 UTC
    You might ask if the person has ever been here or even knows about perlmonks or any other site devoted to Perl. Not that a negative answer would disqualify a person, but a positive answer would be an indication of interest in improving one's knowledge of and abilities in Perl.

[reply]
Re: Perl Interviews
by sierrathedog04 (Hermit) on Feb 16, 2001 at 21:35 UTC
    When I used to interview candidates for a SQL-related position, I would always ask the following:
    If A has three rows and B has three rows then how many rows will the query 'Select * from A, B' return?

    Most applicants got it wrong. The most common answer was six, but some people would say three. (The correct answer is nine.)

[reply]

      Heh! Any SQL programmer who doesn't recognise a cartesian product would definitely be a liability on the team :)

      --
      <http://www.dave.org.uk>

      "Perl makes the fun jobs fun
      and the boring jobs bearable" - me

[reply]
[reply]

Back to Meditations