Assessing Perl skill level in job interviews

[isotope]

This is based on a Chatterbox discussion yesterday...

My supervisor asked me to meet with an applicant this week to assess his Perl and Tcl/Tk programming prowess. What kind of things should I ask?

I've already made my list, which follows, but somebody suggested this might make a good node, and it might be of use to others.

My list:

• What purpose does each of the following serve: -w, strict, -T ?
• What is CPAN?
• Write a Perl program that does the following:
  1. Opens a file whose name is given on the commandline
  2. Replaces all occurrences of 'Y' with 'K'
  3. Writes the results to a new file with ".mod" appended to the original filename
  4. Runs the external command "swizzle" with the original filename as an argument
• What is the difference between for & foreach, exec & system?
• Where do you go for Perl help?

In the programming section, obviously I'm going to be looking for a lot of things, such as proper file I/O, argument handling, string manipulation/regular expressions, extra credit if the applicant happens to think to make the program accept multiple filenames, proper handling of nonexistant files, method for calling the external program, and, of course, use of -w and strict 8-)

[le]

If I were an applicant for a job where I need Perl skills and the boss asked me questions like these, I would get up and leave and forget the job. Not because I can't answer the questions, but because I'm here to work for them and not to answer questions like in school. If they ask me "Do you have Perl experience?" and I say yes and give them some references, it should be enough.

Maybe I got your node wrong at all, but, come on: This looks like a test to get a "Perl Certified Engineer" degree.

[Ovid]

le, I disagree. Why should I trust your Perl just because a previous employer is happy? If you own a gun and haven't shot yourself in the foot, it doesn't mean I should trust you with my gun.

Elizabeth Castro wrote "Perl and CGI for the World Wide Web". She clearly has Perl experience. Further, some of her previous employers may be happy with the work she has done (if they haven't been hacked yet). However, her actual Perl appears to be pitiful. It's poorly written and has tons of security holes. The same thing can be said of Matt from Matt's Script Archives. Having Perl experience and having good references (can't we all get good references if we list the right names?) doesn't mean we know Perl well enough to be trusted.

If an applicant simply walked out on me, I would rush over to hold the door for them. That says to me one of two things: bad attitude or bad programmer. I've hired too many people to simply trust them and their references to tell me the truth. I need to know for myself.

Cheers,
Ovid

[Anonymous Monk]

Elizabeth Castro wrote "Perl and CGI for the World Wide Web". She clearly has Perl experience.
...
However, her actual Perl appears to be pitiful.

Is this really necessary? I'll keep this in point form so it doesn't turn into a flame:

1. There is a second edition out that most likely fixes 90+% of your complaints. Insulting an older edition of an author's book is like me making fun of a report you did in grade 2.
2. The original book is accessible. It's an inexpensive, short, easy to read introduction to Perl. Insult its quality all you like, it got many people (including myself) interested in Perl. In my opinion that's far more important than explaining things like strict, warnings, and all the other frequent regurgitated complaints around here.
3. As for security, you're looking in the wrong places. If someone who has only read a visual quickstart guide is placing code online for any type of serious organization, their problems already runs far deeper. Do not concern yourself with locking doors when you have no walls.

I should also point out that your criticism of Matt Wright is also somewhat invalidated. He recently changed his site to support the NMS project and provide a secure alternative to his scripts. Perhaps you need to find some new scapegoats?

If an applicant simply walked out on me, I would rush over to hold the door for them. That says to me one of two things: bad attitude or bad programmer.

How about if they flat-out told you that based on your questions they weren't interested in working for your company? An interview is just as much about the employee judging the employer as it is vice versa.

[Anonymous Monk]

Ha! I just read this entire thread thinking it was recently posted (due to a reply showing up in newest nodes), then looked at the last comment's date. Please feel free to ignore my reply :)

[KM]

I disagree here. Not only have I done technical interviews, but recently had a few (since I am moving I had a few interviews). I expect that people will ask a few questions (basic to advanced) on Perl to help guage skill level. You would be surprised at how many people have programmed Perl for a few years and don't know what CPAN is, or the difference between chop and chomp, or about ties, or anything you may expect them to know. At an interview 2 weeks ago (which I got an offer from, yay me!) one of the guys read an unpublished article I did on ties and he said 'Just to make sure you really wrote it, explain how you would write a package to tie to a database'. I was happy he did since I know the interviewer is doing their homework on me.

Something I like to do when interviewing is take a recent or current problem being worked on and ask them how they would solve it. This way you can see how someones mind works, as well as their technical ability since they may mention various modules or techniques in the process which will demonstrate their clue level.

So, to make a short comment long... I think asking strategic and pointed questions about Perl is a Good Thing when interviewing. If the interviewee is offended by it and leaves, then they were simply not a fit.

Cheers,
KM

[Anonymous Monk]

CPAN is the Comprehensive Perl Archive Network, it's a good source for anything and everything Perl. For Perl help, there's a bunch of places including perl.org and perl.com as well as cpan.org

For good easy to use online books I suggest going to http://pats.east/BOOKS/oreilly/PERL/index.htm

[jeffa]

I would not be insulted by those question at all isotope - I mean, you have to draw the line somewhere and if you have to ask questions, those are pretty good.

I recently had a technical interview (via phone), and I was asked much simpler questions:

• what is use strict
• name an instance where you used a CPAN module
• how do you open a file for writing
• how would you replace a char in string and how do you store the number of replacements

What is interesting is to find out how someone rates themselves on a scale of 1-10. I would rate myself at a 5, but that's because I look at this site (PM) everyday and am constantly introduced to many slick and efficient ways of solving problems in Perl that I never would have thought of myself. I feel like a guppie swimming with sharks. But if I were asked that same question by an employer/interviewer, I would rate myself at 8, because they rarely understand just how much there is to Perl. I pointed that out to a headhunter a while back - where I would have a rating of 8 in Java or VB, it just doesn't apply the same to Perl.

[mikfire]

Ask for a code sample. Ask for their favourite/best bit of code they have written recently. This can tell you a lot about the code your interviewee can write and something of their style. It has the advantage of letting them show their abilities at their best. The "pop quiz" approach shows you what they can do under pressure.

mikfire

[Ozymandias]

I would seriously do both. Code samples they bring in they already know are as perfect as they can make them; or, if they don't, you probably don't want them, anyway. It's good to know that, and to see what they can do, but it's also just as good to put them on the spot and see how they handle it.
- email Ozymandias

[tilly]

ABSOLUTELY!
If you want technical skill, well I think that Brainbench does a reasonable job of testing that. But there is no test for common sense that matches seeing some code. Personally I would prefer to hire a good programmer who knew no Perl than a Perl programmer with no programming taste...

YMMV on the strength of your opinion, but ask for a code sample.

[romandas]

I realize I'm responding to an ancient node but..

I have my doubts about Brainbench, due to a recent hire we had. The person in question was supposed to have Sharepoint and DBA experience, and their resume showed none of the former and little of the latter. On that, I recommended not to hire (I wasn't part of the actual interview, just asked to do a technical review of the resume).

However, the person went out, took a Brainbench test on Sharepoint, came back and fought for the job, claiming ability via Brainbench. They were promptly hired..

..and were completely inept. They couldn't even navigate Sharepoint's default interface, let alone tell me how to set up a usable site. As for their DBA abilities.. also non-existant. (If someone asks you what kind of degree you have, and they say 'Databases', there is likely a problem.)

I definitely believe in at least some technical questions during an interview for a technical job. It comes with the territory.

[btrott]

I like this guide to interviewing candidates: Joel Spolsky's The Guerrilla Guide to Interviewing. It's definitely not Perl-centric, but it's a good guide for technical interviewing.

In general I definitely agree with the fact that you need to get a sense of how good a programmer your interviewee is. And you can't do this by asking trivia questions; I think you really need to see code samples, and you need to get the interviewee to describe how they go about solving problems.

[Anonymous Monk]

I'm surprised no one has mentioned:

http://www.snowdrift.org/cgi-bin/eperl/computers/perl/pt/index.ep

I learned a few things myself -- specificially, that there were a number of command-line options that I only *thought* I knew.

Jon

[Anonymous Monk]

OH okay

[turnstep]

I was the one that mentioned the differences between for & foreach and between exec & system in the chatterbox. My entire list is:

What is the difference between:
• for & foreach
• exec & system
• map & grep
• sysread & read
• pack & sprintf
• chop & chomp
• local & my
• time & times
• qq & qx
• rand & srand
• exists and defined
• print & printf
• perl4 & perl5
• use and require
• eval & study
• bless & tie
• select & select :)

I find this list to be a fairly good window into someone's perl skills. Some of the above are easy, some aren't even really "paired", and some are trickier than they look (e.g. the *real* differences between "my" and "local" (and "our" :) ).

Asking for sample scripts is good, as well as asking them to make a quick script on the spot. Asking them to solve a regex problem is also a nice indicator. You can fake things on your resume, but not on an actual interview "exam" ^[1] :)

It's also important to see how someone reacts to the above questions. How you handle questions you don't know or aren't sure of is very important too. You could be even throw in some answers that cannot be answered, such as asking the difference between "caller" & "sender." (The former is a rarely used, yet legitimate function, which makes the second one seem all the more likely to be legitimate too, even though it is not)

[1]It sure is easy writing about this from the "other side of the table" ;)- but it's one of the best ways to demonstrate perl knowledge, as we are not as standardized and certification-heavy as "other" IT skills (I shall name no names)

[BigJoe]

I am a person that truely believes that if they only read the book they are not experienced. These questions are very good, but anyone who read learning perl could do reasonably well.

I say give them a Unix terminal with a browser. Give them a module name like CGI.pm, something that most people don't know, and a small script not using anything like -w or -T and have them optimize it using any modules that they know of. Then you can see their trouble shooting skills, ability to look for answers and if they really know what they are doing pull it out of memory. I am just really against tests that can be answered by someone who read a book.

--BigJoe

Learn patience, you must.
Young PerlMonk, craves Not these things.
Use the source Luke.

[Russ]

Well, they asked me to be their advocate, so here is my opportunity. :-)

BrainBench provides technical evaluations via web-based "Computer Adaptive Testing," which tailors the test to the test-taker's abilities. The tests will take a maximum of two hours to complete (and should take far less -- it took me about 45 minutes), and will assess the test-taker's knowledge and understanding of various categories, like "Conceptual," "Problem-Solving" and "Terminology & Syntax."

The Perl exam has just completed its "beta" stage, and has been endorsed by the International Webmasters Association. You can find more information about the Perl exam at Perl Programmer Certification at BrainBench.

If you sign up with Brainbench as an employer, they will provide you with confirmation tests you can use at an interview. Tests are still free, though they have threatened to start charging for the certification exams. Costs will be small, but now is the time to get a certification if you are interested.

If you would like to see a "transcript" showing the results of an exam, go to BrainBench and enter "672022" in the "View Transcript" box near the bottom of the left-side nav bar. It's my transcript, and it'll give you some idea of the information available to employers, recruiters, etc.

As many others have said in this thread, there is far more to assessing an applicant than just knowledge. A good programmer with little Perl knowledge will be more valuable to you than someone with "book knowledge" of Perl, but little "instinct" for programming. This is probably the main reason why I like the Brainbench approach. If you don't know every trivial bit of Perl knowledge by heart, but know where to find the information quickly, you will likely be a very valued part of any team. The brainbench exams cater to those who are comfortable enough with the subject to find the answer.

There are a number of rather esoteric questions in the Perl exam. If you can consult the Camel book or other favorite writings (I'm very fond of the "One-liners" section in the back of merlyn's "Effective Perl Programming") or a quick Perl script to test something, you will score well on the test, even if you are not a Perl guru. As a team-leader-type, I value this ability. Knowing where to find the answer is almost as good as knowing the answer immediately.

So, when you go to take the Perl exam, have your reference materials handy.

<disclaimer>
For the record, I have agreed to be part of Brainbench's "MVP" program, where they ask me to assist with the exam's questions and other issues. I do not receive any money or other consideration from Brainbench.
</disclaimer>

Russ
Brainbench 'Most Valuable Professional' for Perl

[chromatic]

I just took the Perl test (and am now officially certified as a Master), however I'm not convinced this is the best way to gauge ability.

The test took me 15 minutes, without consulting any documentation, and there were a number of questions I found misleading... with more than one correct answer. These were largely conceptual.

I'll take another test, and see if I can get up around the 4.8 level, but I think giving people a chance to explain their answers (in an interview setting) is more valuable than the ability to pick one answer out of five, especially when the terminology's not what I'm used to from the Camel or perldoc.

Still, it's nice to be recognized as a master, better than 90-something percent of everyone else who's taken the test. :)

[Russ]

I have not yet heard back from Brainbench about the status of the latest test question changes.

The problems will only be found by those who score the highest on the exam, because most of the problem questions deal with more difficult topics.

If you remember any of the troublesome questions, feel free to let me know about them. I suspect they have not yet corrected the questions (since we only discussed them last week).

You are, of course, correct that a test like this cannot be a completely adequate judge of ability. However, remember that you fall well outside the normal curve. You should rank as a guru in nearly any ability measure, so a general test such as this will be less precise in your case.

Of course, if the interviewer is very Perl-knowledgeable, sample code and test problems will always be better. But, for any interviewer who may be less technically qualified than the interviewee, another tool is necessary. I think Brainbench makes a good tool in that case.

Russ
Brainbench 'Most Valuable Professional' for Perl

[petemar1]

Has Brainbench approached Larry Wall, to receive an endorsement for their Perl exam?

[petemar1]

Larry speaks on certification here.

[Adam]

Reading through these nodes I see that some people are in favor of hiring tests and others are not. The difference of opinion though tends to be based on who the tester is. I for one can't stand to be tested by a computer (I agree completly with chromatic's complaints) or even worse by some head hunter who's knowledge of perl consists of, "variables start with a dollar or at sign." On the other hand I've had real interviews with programmers (or "engineers" if you prefer) where the questions were, "what modules are you familliar with" and "What kinds of perl code have you written" and I was able to tell him what I had done. No code writing (syntax errors are all to easy when you are nervous) and no third degree about the difference between my and local (not that I could have answered that question... I can now though <grin>). I appreciated the level of respect given to me by the interviewer, and they could quickly assess my skill level. Of course, this only works if the interviewer is qualified for the job!

[larsen]

What about these two questions?

i. Why using Perl?
ii. Why not using Perl?
So you can check if you're in front of a fanatic.
See you

[princepawn]

My favorite way to asssess pertinent skill is to pull out some code that was already written and have them explain it and also mention any shortcomings of the code that they see.