Interview questions

[zigster]

I have been tasked with interviewing for a new perl position. My first task is to come up with come questions that test the candidates technical ability, both as a programmer and as a perl programmer. I confess I am at a loss with regard to perl questions. I have so far thought of:

• What arguments do you frequently use for the perl interpreter and what do they mean.
• What does the command 'use strict' do and why should you use it?
• What do the symbols $ @ and % mean when prefixing a variable.
• What elements of the perl language could you use to structure your code to allow for maximum re-use and maximum readability.
• What is a JAPH?
• What are the characteristics of a project that is well suited to perl.
• Why do you program in perl.

As you can see I am not really concerned with information that a candidate could trivially get from the perl books that I would expect them to have easily to hand. I am more interested in information that could only really have come from experience. Do you have anything to add or anything to remove?
--

Zigster

[dws]

I'm a hiring manager, though I don't get to play one on TV. (That's probably a Good Thing :-)

One of the challenges in interviewing is to plan out a set of questions that gets at

• what a candidate knows right now,
• how the candidate solves problems, and
• how they'll fit in with the culture

  "Closed-ended" questions ("what do the symbols $ @ % and * mean...") will tell you how well a candidate knows the mechanics of Perl, but if you limit yourself to them, you're liable to hire a complete doofus who happens to know some facts about Perl.

  "Open-ended" questions can get at how a candidate thinks ("tell me about a gnarly problem you solved with Perl") and what their values are ("what are the characteristics of a project that is well suited to Perl"). You want a few "values" questions thrown into the mix to help judge how the candidate will fit in with the culture. But, if you limit yourself to open-ended questions, you risk hiring a thinker who can't produce.

  To complicate this, imagine that you have a 30 minute interview slot.

  What to do?

  A technique I picked up from a good manager a while back, and have since refined, is to pose a "vague problem with no right answer¹" and ask the candidate how they would approach it. The value of being vague is that you'll quickly see whether the candidate will stop and ask questions. (A candidate who jumps right in without taking the time to determine whether they're solving the right problem is not someone I want on my team.) I'll often throw a few hints to a candidate who gets stuck. (Would you want someone on your team who would rather stay stuck or plunge headlong down a blind alley rather than take a hint?)

  The vague problem typically involves some simple elements of OO modeling (simple enough to tell me within a few minutes whether the candidate "gets" objects). After getting them to do a sketch on the whiteboard (which tells something about how the candidate will communicate in design meetings -- doubly important here since many of the folks I work with aren't native English speakers). I ask them to sketch out a class definition in whatever language they're most comfortable with, and pseudo-code one or two methods. (This tells me whether they can implement with objects.) As necessary, I'll toss in a few close-ended questions.

  Finally, if we've gotten this far and have some time left, I'll ask them to discuss the strengths and weakness of their approach. (Can this candidate reflect on their work? Are they self-critical?) The candidate who asks how I would solve the problem gets extra points (for showing that they can seek new viewpoints, not for stroking my mighty ego).

  With a little practice using this approach, here's what you can find out in 30 minutes:

  1. Can the candidate cope with vague problems? Will they try to get requirements clarified, or will they charge blindly ahead?
  2. Will they take input (hints, clues, ideas) from others, or will they burn up valuable project staying stuck or pursuing dead-ends?
  3. Can they explain themselves at a whiteboard?
  4. Do they understand objects, and can they implement with them?
  5. Are they thoughtful about what they do?

  It's been my experience that a candidate who nails these is the one you want, unless you have really narrow technical requirements that they can't satisfy within your time window.

  * * *

  ¹ I ask the candidate how they would model and implement the inner workings of Minesweeper (avoiding UI details unless I'm hiring a UI developer). There are several approaches to Minesweeper that "work", and several wrong approaches. A few candidates have demonstrated that there are also seriously wrong approaches. I've had candidates use C++, Java, and Perl. (The few who've tried straight C tended to flunk badly.)

[jamiguet]

Where is it that nice dreamland you work in? I want to get hired there !!!!!!

---

Where is my mind. Oh yes, Down the pub.

[Jenda]

I once implemented Minesweeper in Prolog and another time in Concurrent Clean. In both cases the minesweepers could optionally solve the easier cases for you. It was up to the level of "this square needs one more bomb, so these three squares may contain only one bomb so if that square needs two bombs, then the square over there must be a bomb, and the other will be in one of those two so this square is safe, ..." Shame I lost the code. I wonder though how much would it tell you about my understanding of objects ;-P

[davorg]

I like 'compare and contrast' type questions and find that anyone who can clearly explain the differences between:

• my and local
• use and require

will be reasonably competant.

I also like to give people code with the comments removed and ask them to talk about it - tho' I've not yet done this with the source to Symbol::Approx::Sub :)

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

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

[Trimbach]

I personally like "What's your favorite module and why?" Tells you alot about someone's programming experience and their programming preferences, and it gives the interviewee a chance to be clever if they want. "CGI.pm", and "DBI.pm" are solid, straightforward answers... "Quantum Superpositions", however, tells a completely different story. :-D

Of course if they can't answer it at all that tells you something, too. The idea is not to rigidly test the applicants (which can be problematic for a variety of reasons) but rather to elicit the sorts of responses necessary to find out if they have skills and competencies to do your work.

Gary Blackburn
Trained Killer

[neophyte]

Hi Zigster,
a Super Search on the words interview questions would have yielded this node. You will find many interesting suggestions in there.
HTH

neophyte Niederrhein.pm

[zigster]

I did do a search but not a -super search- ;-) Thanks for the pointer .. I am so there.
--

Zigster

[clemburg]

After the pre-screening interview, I would suggest to make them write a semi-trivial script in real time, that is, in the interview situation, on a prepared PC with the standard tools (editors etc.), for a standard problem situation that comes up in your domain (e.g., web script, DBI connector, traverse directories, etc.).

Look at *how* they approach the problem. Do they re-invent the wheel? Do they consult the online documentation? How do they use the tools provided (editor, debugger, ...). Which questions do they ask you about the problem? Do they make an "analysis" of your requirements? How do they react to this stressful situation? And so on.

Since this procedure is pretty hard-core (emotion- and time-intensive), you will probably want to make sure to limit the number of candidates invited, to make sure you have adequate time for this procedure (e.g., 30-60 minutes).

Just my 2 cent.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

[Fastolfe]

"What level are you on PerlMonks.org?"

I wish that made a difference in job/salary for me.

[jptxs]

I would say the "JAPH" question might be a little unfair. That is more of a perl community quetion than a perl question. There have been more than one very good perl programmer who had no taste for the community or anything even remotely like a JAPH.

"A man's maturity -- consists in having found again the
seriousness one had as a child, at play."   --Nietzsche

[zigster]

I did consider this, however failing to know the answer would not stop a candidate getting the job. A positive response would start a conversation that should be very revealing.
--

Zigster

[cat2014]

If you get a the chance, you should try to ask them to bring a code sample with them to the interview, or to email it to you a few days before. There are really few things quite as useful as looking at 2-3 pages of code which they've written & asking them questions about it.

You might also want to look into some logic puzzles to ask. I have mixed emotions about asking those types of questions now, but I know that a lot of people swear by them. -- cat

[zigster]

Code sample is a nice idea, the logic puzzles. Natch dont like those. They test all the wrong things. People are too easily thrown in interviews I try and keep the questions as simple as possible. Logic puzzles and the like are hard, as a few hard questions and the candidate is likely to get flustered and then the interview is blown.
--

Zigster

[cat2014]

Flustering/stressing out candidates in an interview is not always a bad thing, though. I guess it mostly depends on the job that you're interviewing for. If it's for a sys admin or webmaster or programmer who will have to quickly fix broken production systems, I'd want someone who can think on their feet. I'm not a fan of finding out at a bad moment that someone chokes up & can't hack together code when they're stressed. So there's no point of unnecessarily stressing out every interview candidate, but if it's useful for making a hiring decision, I'm all for asking tough questions that they might not know the answers to & getting them a little stressed out. -- cat