pkgbox

Teaching new colleagues the wonders of Perl can be a tough thing because it’s not clear where to start. Do I have to start from scratch with just the basic things or does someone who had Perl mentioned in his CV qualifies as a Perl person already?

That’s a difficult question. Having interviews, talks or even exams might not give the right answer but you will get a certain feeling about someone and his skills. However, even the old geeks tend to be silent when Gabor Szabo (blog) is asking stuff about regular expressions in his talks on conferences. That’s interesting. People who are able to do the most complicated stuff with regex are quiet when they are asked simple regex. Is that the kind of people we are referring to as DevOps? Probably not.

So how do we find those multitalented people who are using Perl for sysadmin stuff, understand the complexity of J2EE and its architectures and are communicative to their colleagues – even when they can’t provide the answer at this time (referring to the regex problem). Actually, I don’t know. During interviews I have used the following simple questions to get a feeling about the Perl knowledge of the candidate:

1. What’s the correct way to test if two scalars are the same – string comparison?
2. What does the keyword “say” do?
3. What is the meaning of the code fragement $c = $a // $b ?
4. What is the purpose of the command line tool prove?
5. What is the taint mode of Perl?

Those are just 5 simple questions. Let me explain why I like to ask them and why I think they can give you more insights into the job candidate.

Question 1 – Tries to sort out if the person is actually using Perl. The most common answers for this are: “==”, “=” or “$string1=~ /$string2/”. Once again, Gabor has some answers for this in a short YouTube video – Comparing scalars. If the candidate is very nervous and fails instantly, be nice and start a dialogue. Discuss the different options – if he has no clue at all, he will fail anyway in this question.

Question 2 – Asking about “modern” Perl knowlege. Most of the Google code snippets don’t show results about the keyword say. However, if the person is using a more current version or if he read the history he knows about the keyword.

Question 3 – Tricky one and might even be complicated for professionals. Code constructs like this one are common:


if ( ! defined $a ) {
$b = $a;
}
else {
$b = "Hello world";
}


Haven’t seen constructs like this – check your legacy Perl code. There are nice examples in the perlop documentation it. This is something special, however, there is a reason why this operator exists – if you want someone working for you who knows how to use the tools – check if he really knows them.

Question 4 – Huh, don’t know the answer? That doesn’t matter – really. A lot of people are using Test::More for a long time and know about TAP. If the person knows TAP and Test::More already, it’s ok that they don’t have the meaning of prove handy. If they don’t know anything about TAP or Test::More, you will have another hint of their level of Perl knowledge. Do you expect a DevOp person to be the glue between development and sysadmins without knowledge of testing stuff?

Question 5 – wow, that’s legacy stuff. Really, I mean it – what was the last time that you’ve use the taint mode for old CGI stuff? But is it such a bad idea to use the taint mode? Actually, the taint mode is something unpopular today. I wrote several scripts some decades ago which used the taint mode. I will fail horribly when I am trying to use the taint mode today – however, understanding about the history stuff is never a bad idea.

Those are just some questions which might help you to check the knowledge of Perl of a candidate. You’ll understand their ways of thinking – their way to solve problems. If you can use the interviews to ask them face to face – that’s awesome and might give you an even deeper insight. If you are asking these questions on the phone – be nice! They are not as easy as you might think now when you are relaxed and not in a situation of job application. Help them on their way – test their knowledge, look at their problem solving skills and motivate them to pass the tests.

When you want to attract DevOps – try to be as nice and communicative as you expect them to be!