What do you need to have to be considered a Master at Perl?

[Tad J McClellan]

[ Please excuse the piggyback. I don't see posts from cartercc ]

According to <[email protected]>:

This is absolutely true. I've seen it many many times.

Two of the test questions that I like to use in interviews:

1)
What is the difference between my() and our()?

(followup if they get that right: What about local()?)

(followup if they have still not eliminated themselves:
When would you use one over the other?)

2) What is returned by mystery_func()?

sub mystery_func {
my @ra = 4;
push @ra, 2+3;
$ra[@ra] = 6;
return @ra;
}

I'll leave what is taken to be "the correct answer" as an
exercise for the reader...

 

[Vicky Conlan]

1)
What is the difference between my() and our()?

IMHO, /my/ correct answer here would be "can I borrow your computer
for a minute to check in perldoc, please?"
(having never actually come across our() before - thanks for giving
me something to print out and read on the way home, btw ;-)
On first glance, I can see the difference, but I'm failing to see a
real advantage or purpose to our().

--

 

[Randal L. Schwartz]

Tad> 2) What is returned by mystery_func()?

Tad> sub mystery_func {
Tad> my @ra = 4;
Tad> push @ra, 2+3;
Tad> $ra[@ra] = 6;
Tad> return @ra;
Tad> }

Tad> I'll leave what is taken to be "the correct answer" as an
Tad> exercise for the reader...

Depends on whether it's called in a scalar or list context.

 

[Tim Greer]

Having marked Perl tests a few times in the last year or two, I'm not
at all surprised you scored higher than you expected.

....

To be honest, most of the "tests" I've seen people have to take, are
very, very rudimentary. I'd hate to think someone took a basic test,
scored high and thought this might mean they are an expert at a
language they've only just started really learning. If they get the
job and can perform the tasks, and are willing to accept they always
have more to learn, then that's great.

 

[cartercc]

To be honest, most of the "tests" I've seen people have to take, are
very, very rudimentary.  I'd hate to think someone took a basic test,
scored high and thought this might mean they are an expert at a
language they've only just started really learning.  If they get the
job and can perform the tasks, and are willing to accept they always
have more to learn, then that's great.

Of the two tests I've taken, one was a programming test of three
programs with an hour to complete. The first two were pretty simple.
The third was more difficult, mostly due to the problem set rather
than language issues. I missed a significant portion of the third
question due to a misreading of the specification.

The second test was an objective test, and I thought it was a pretty
good measure of knowledge. I normally have a very poor opinion of
objective tests, but this one was a work-out. I did pretty well on it
but attribute it to a combination of luck and inspired guessing.

I believe that these kinds of tests are a good idea for employers as
long as their purpose is to weed out imposters. I don't think that
they do a good job of measuring proficiency from the standpoint that a
person's experience in writing a KIND of script says nothing about his
aptitude. (A test focusing on file manipulation might catch a person
who excels at writing sys admin scripts, and would reveal nothing
about his aptitude in general.)

CC

 

[sln]

Tad> 2) What is returned by mystery_func()?

Tad> sub mystery_func {
Tad> my @ra = 4;
Tad> push @ra, 2+3;
Tad> $ra[@ra] = 6;
Tad> return @ra;
Tad> }

Tad> I'll leave what is taken to be "the correct answer" as an
Tad> exercise for the reader...

Depends on whether it's called in a scalar or list context.

Right, what you you expect from somebody who doesen't know the difference
between a program written in C++ or a C++ program.

sln

 

[Charlton Wilbur]

TJM> This is absolutely true. I've seen it many many times.

It's common everywhere. It's very easy for a programmer to know enough
Perl to bamboozle a recruiter or HR person, and to be able to talk his
or her way through a phone screening interview.

My current company has a Perl test that touches on algorithms and data
structures, interaction with the user via CGI, and interaction with
databases via DBI. It's a problem that realistically should take a
competent programmer about two hours to finish, and the candidate is
told this and given an hour, so that we can see how far he or she gets
and what the partial solution looks like. This is very useful
information, even though (as I can attest, having taken the test myself)
it is stressful.

Then discussion of the problem and how far the candidate got and what
the more efficient solutions might be is more elucidating.

And we have a list of interview questions that elucidate weak points --
like the difference between defined and exists, or the difference
between system and exec.

TJM> Two of the test questions that I like to use in interviews:

TJM> 1) What is the difference between my() and our()?
TJM> (followup if they get that right: What about local()?)
TJM> (followup if they have still not eliminated themselves: When
TJM> would you use one over the other?)

We use a variant of this -- we ask about the difference between my, our,
and local.


TJM> 2) What is returned by mystery_func()?

TJM> sub mystery_func { my @ra = 4; push @ra, 2+3; $ra[@ra] = 6;
TJM> return @ra;
TJM> }

TJM> I'll leave what is taken to be "the correct answer" as an
TJM> exercise for the reader...

That one threw me for a loop until I realized I was mentally filling in
a @ for the $ because there was a @ inside the brackets....

One of my favorites:

You have a string that comes from a freeform text field where the user
is expected to enter a telephone number. Write a regular expression to
validate it and capture a usable phone number.

This is usually good for a lot of discussion about what should be valid,
and about the damnfool things that users do. It also shows whether the
candidate has a grasp of basic regular expressions: programmers who are
comfortable with them usually try to figure out what foolish things a
user is likely to do, while programmers who are not comfortable with
them usually try to remember what the syntax is for capturing.

Charlton

 

[sln]

TJM> This is absolutely true. I've seen it many many times.

It's common everywhere. It's very easy for a programmer to know enough
Perl to bamboozle a recruiter or HR person, and to be able to talk his
or her way through a phone screening interview.

My current company has a Perl test that touches on algorithms and data
structures, interaction with the user via CGI, and interaction with
databases via DBI. It's a problem that realistically should take a
competent programmer about two hours to finish, and the candidate is
told this and given an hour, so that we can see how far he or she gets
and what the partial solution looks like. This is very useful
information, even though (as I can attest, having taken the test myself)
it is stressful.

Then your company's test is written by 1 enginner vision of bloviated
code he/she's written that worked like shit and took hours and hours of
guessing to finally get it right. "Hahaha, solve this candidate, you can't
so my job is secure"!

What utter, utter nonsense!

If you were to test anybody, you must first let the candidate test you,
the decider's. You must publish that YOU, the EMPLOYER are available for
certification, and establish that you are eligable to be considered as such,
and pass a test, determined by the employee!!

The ultimate test is pseudo code, not context/syntax sensitive bullshit that
foams from the mouth of employers written by engineers under durress, under the
threat of termination or just plain scared shitless for thier jobs.

Pseudo-code is middle ground. After all, the goal is not context/syntax sensitive
is it? The goal is to find a genious in waiting. Einstien was never hired as I
remember it.

[snip]

sln

 

[Tad J McClellan]

[snip questions to test Perl knowledge]

TJM> Two of the test questions that I like to use in interviews:

TJM> 1) What is the difference between my() and our()?
TJM> (followup if they get that right: What about local()?)
TJM> (followup if they have still not eliminated themselves: When
TJM> would you use one over the other?)

We use a variant of this -- we ask about the difference between my, our,
and local.

I sure hope you give at least partial credit if the response
is something like:

my() and our() are ways to declare variables

local() does not declare a variable

(which is why I put local in a followup, as it doesn't really belong
with the other two.
)

TJM> 2) What is returned by mystery_func()?

TJM> sub mystery_func { my @ra = 4; push @ra, 2+3; $ra[@ra] = 6;
TJM> return @ra;
TJM> }

TJM> I'll leave what is taken to be "the correct answer" as an
TJM> exercise for the reader...

That one threw me for a loop

It is an obfu-push.

until I realized I was mentally filling in
a @ for the $ because there was a @ inside the brackets....

That prompts 2 more potential followup questions:

Q: what does @ra contain if there was an @ instead of a $ in $ra[@ra] = 6?
A: 4, 5, undef, undef, 6, undef

Q: what does @ra contain if there was an $ instead of a @ in $ra[@ra] = 6?
A: a program that does not run under "use strict"
or
A: 6, 5

Though those are both tricky enough that I'd count no points off
if they got them wrong.

And if they got them right, they may need to make more money than
the interviewer does.

One of my favorites:

You have a string that comes from a freeform text field where the user
is expected to enter a telephone number.

I sure hope that is restricted to "a US phone number"...

validate it and capture a usable phone number.

This is usually good for a lot of discussion about what should be valid,

I'll offer my unsolicited opinion below without accepting discussion.

and about the damnfool things that users do.

I think my solution will allow plenty damnfoolery and still
yield a usable US telephone number:

sub validate_phonenumber {
my($phone) = @_;

$phone =~ s/\D+//g; # allow hyphens, dots, parens, spaces etc
$phone =~ s/^1//; # no long-distance prefix needed

return $phone if $phone =~ s/^(\d{3})(\d{4})$/$1-$2/;
return $phone if $phone =~ s/^(\d{3})(\d{3})(\d{4})$/$1-$2-$3/;
return 0;
}

Do I get the job?

(only half-kidding, as I am available for hire right now, but it would need
to be telecommute or near Fort Worth...
)

 

[Tim Greer]

Of the two tests I've taken, one was a programming test of three
programs with an hour to complete. The first two were pretty simple.
The third was more difficult, mostly due to the problem set rather
than language issues. I missed a significant portion of the third
question due to a misreading of the specification.

The second test was an objective test, and I thought it was a pretty
good measure of knowledge. I normally have a very poor opinion of
objective tests, but this one was a work-out. I did pretty well on it
but attribute it to a combination of luck and inspired guessing.

I believe that these kinds of tests are a good idea for employers as
long as their purpose is to weed out imposters. I don't think that
they do a good job of measuring proficiency from the standpoint that a
person's experience in writing a KIND of script says nothing about his
aptitude. (A test focusing on file manipulation might catch a person
who excels at writing sys admin scripts, and would reveal nothing
about his aptitude in general.)

CC

Those are valid points, and I'm not saying they are pointless, to be
clear. I just have seen a lot of people take online tests to prove
their programming or sys admin abilities and score very high, and think
that it serves as a valid and legitimate certification of their skill
level, yet I've seen many of those people fall flat on their face when
faced with more than the basics or common problems presented. It's
certainly one step to consider. I've been able to successfully weed
out people that exaggerate their skill set with some quick questions
before having to bother administering any test. Sometimes a candidate
can teach the employer something in an interview, if they aren't
intimidated and worry about losing their job by hiring someone that
either knows things in areas they are weak, or are just flat out
better.

 

[sln]

Those are valid points, and I'm not saying they are pointless, to be
clear. I just have seen a lot of people take online tests to prove
their programming or sys admin abilities and score very high, and think
that it serves as a valid and legitimate certification of their skill
level, yet I've seen many of those people fall flat on their face when
faced with more than the basics or common problems presented. It's
certainly one step to consider. I've been able to successfully weed
out people that exaggerate their skill set with some quick questions
before having to bother administering any test. Sometimes a candidate
can teach the employer something in an interview, if they aren't
intimidated and worry about losing their job by hiring someone that
either knows things in areas they are weak, or are just flat out
better.

We own all your base.

sln

 

[Tim Greer]

We own all your base.

Why, is that a sense of humor I'm detecting?

 

[Charlton Wilbur]

TJM> I sure hope you give at least partial credit if the response is
TJM> something like:

TJM> my() and our() are ways to declare variables

TJM> local() does not declare a variable

TJM> (which is why I put local in a followup, as it doesn't really
TJM> belong with the other two. )

Well, we don't grade things objectively -- we've found, for instance,
that it's often better to hire a smart person who doesn't know Perl
details (and then teach him or her Perl) than to hire a dumb person
who's mastered Perl.

In my experience, either people can't articulate the difference at all,
or they know that my declares lexical variables, our declares global
variables, and local is something that they have heard of but haven't

TJM> I sure hope that is restricted to "a US phone number"...

Ah, that's one of the things that most candidates don't even consider --
the ones that tend to bring it up get points for it.

TJM> I'll offer my unsolicited opinion below without accepting
TJM> discussion.

Well, the discussion is often the most interesting part, because it
shows how the candidate approaches the problem.

(The correct solution, in the context of our work, is that if you're
using a phone number you use the form object for a telephone number, and
it handles the validation. But that's not interesting or especially
revelatory in an interview.)

TJM> I think my solution will allow plenty damnfoolery and still
TJM> yield a usable US telephone number:

[snip solution]

TJM> Do I get the job?

I think you're most likely more than qualified on Perl details. You
need to meet the members of the team to be sure....

TJM> (only half-kidding, as I am available for hire right now, but
TJM> it would need to be telecommute or near Fort Worth... )

Alas, telecommuting isn't an option, and Cambridge, MA is close to Fort
Worth (TX?) only if you're considering things in astronomical terms.

Charlton

 

[Xho Jingleheimerschmidt]

One of my favorites:

You have a string that comes from a freeform text field where the user
is expected to enter a telephone number. Write a regular expression to
validate it and capture a usable phone number.

Usable by whom? If by some kind of computerized system, then I'd need
to know more about that system it is going into. If the number is to be
regurgitated to a human for the human to use, I'd by inclined to not
validate at all, present it to the human as is and let the human do
whatever validation/interpretation may be needed.

And, am I allowed to make long distance calls? International? Call the
Waltons on Walton's Mountain?

This is usually good for a lot of discussion about what should be valid,
and about the damnfool things that users do. It also shows whether the
candidate has a grasp of basic regular expressions: programmers who are
comfortable with them usually try to figure out what foolish things a
user is likely to do, while programmers who are not comfortable with
them usually try to remember what the syntax is for capturing.

Charlton

Xho

 

[sln]

TJM> I sure hope you give at least partial credit if the response is
TJM> something like:

TJM> my() and our() are ways to declare variables

TJM> local() does not declare a variable

TJM> (which is why I put local in a followup, as it doesn't really
TJM> belong with the other two. )

Well, we don't grade things objectively -- we've found, for instance,
that it's often better to hire a smart person who doesn't know Perl
details (and then teach him or her Perl) than to hire a dumb person
who's mastered Perl.

In my experience, either people can't articulate the difference at all,
or they know that my declares lexical variables, our declares global
variables, and local is something that they have heard of but haven't

TJM> I sure hope that is restricted to "a US phone number"...

Ah, that's one of the things that most candidates don't even consider --
the ones that tend to bring it up get points for it.

TJM> I'll offer my unsolicited opinion below without accepting
TJM> discussion.

Well, the discussion is often the most interesting part, because it
shows how the candidate approaches the problem.

(The correct solution, in the context of our work, is that if you're
using a phone number you use the form object for a telephone number, and
it handles the validation. But that's not interesting or especially
revelatory in an interview.)

TJM> I think my solution will allow plenty damnfoolery and still
TJM> yield a usable US telephone number:

[snip solution]

TJM> Do I get the job?

I think you're most likely more than qualified on Perl details. You
need to meet the members of the team to be sure....

TJM> (only half-kidding, as I am available for hire right now, but
TJM> it would need to be telecommute or near Fort Worth... )

Alas, telecommuting isn't an option, and Cambridge, MA is close to Fort
Worth (TX?) only if you're considering things in astronomical terms.

Charlton

Ahh, its always thos "alas" things that getcha. I asked my brother for a job
and if I can telecomute, he said the same thing.

I haven't said shit to him since.

sln

 

[Vicky Conlan]

Well, we don't grade things objectively -- we've found, for instance,
that it's often better to hire a smart person who doesn't know Perl
details (and then teach him or her Perl) than to hire a dumb person
who's mastered Perl.

I agree. Which is why I like to make sure /I/ mark Perl tests for people
I am expected to work with, so that I can be lenient with people who get
the right idea but not the exact syntax on the programming tasks. Which
I know that most other people wouldn't bother with, they'd just mark
against the stock answer (hopefully testing things that weren't exactly
as written!). Unfortunately part of the test we currently use does seem
to focus on "do you know the precise syntax of this Perl function", which
seems a little pointless, imho.

--

 

[Peter J. Holzer]

I sure hope that is restricted to "a US phone number"...

And I hope it isn't. Local conventions for phone numbers, street
addresses, etc. differ a lot, and software tends to be used outside that
local context. Forcing a non-US customer to guess US conventions, or
worse, rejecting a phone number because it has too many or too few
digits is a major annoyance.

As a real-world example, some time ago I decided to subscribe to the
German Perl magazine $foo. I couldn't enter my street address because
the input validation insisted on a street name and a purely numeric
house number - "Nordwestbahnstraße 93-95/30" simply couldn't match
unless I mangled it so much that I doubted that the postman would
recognize it. Fortunately Renée Bäcker reads his email and fixed the
problem within a day. A larger and less flexible firm might have lost me
as a customer.

hp

 

[cartercc]

Well, we don't grade things objectively -- we've found, for instance,
that it's often better to hire a smart person who doesn't know Perl
details (and then teach him or her Perl) than to hire a dumb person
who's mastered Perl.  

I've had a number of different kinds of jobs, but never a programming
job, even though I've interviewed for quite a few of them.

We can all tell our stories of HR and management types interviewing
developers, so I won't share any of mine (unless we get into telling
war stories.)

However, I will relate the ASTONISHING FACT (!!!) that HR and
management types CANNOT UNDERSTAND (!!!) this simple truth:

Competent programmers can program in any language whether or not they
know it; incompetent programmers cannot program in any language
whether or not they know it.

(I'm not an especially competent programmer, but I've had the
opportunity to write projects in about a dozen different languages.
It's much better to use a language that you know pretty well, but it's
possible to use any language -- particularly true if you are in a MS
environment where you can pretty much figure it out whether you use
VB, C#, J#, C++, etc. and rely on the VS IDE to do your drags and
drops.)

CC

 

[Jürgen Exner]

Competent programmers can program in any language whether or not they
know it; incompetent programmers cannot program in any language
whether or not they know it.

I beg to differ on the first part of your statement

(I'm not an especially competent programmer, but I've had the
opportunity to write projects in about a dozen different languages.
It's much better to use a language that you know pretty well, but it's
possible to use any language -- particularly true if you are in a MS
environment where you can pretty much figure it out whether you use
VB, C#, J#, C++, etc. and rely on the VS IDE to do your drags and
drops.)

Those languages are very similar to each other and use the same
concepts. You get used to the different syntax and the quirks, an off
you go.
But have you ever tried programming in Prolog, APL, Lisp, Haskel, or
TeX/Metafont, PostScript, ...? Good luck! A competent programmer with
proper education will get aquainted with those eventually while an
incompetent programmer may never, but "can program in any language" is a
very long shot when looking at programming languages from different
paradigms.

jue

 

[cartercc]

I beg to differ on the first part of your statement

Why? Do you think that a competent programmer can't learn a particular
language? Obviously, you have to know a little bit of a language
before you start using it, but the main part is figuring out the
logic, and the logic isn't language specific. Unless you think it is,
but then you should give an example of some language specific logic.

But have you ever tried programming in Prolog, APL, Lisp, Haskel, or
TeX/Metafont, PostScript, ...? Good luck!

I wrote an application in Erlang within the past year for the purpose
of parallizing computation of a particular problem. I bought
Armstrong's book on Erlang, spent about twenty hours reading through
the book and a few hours actually writing the script. I've written a
few small Lisp scripts. The only project that I completely failed at
was one in Scheme.

A competent programmer with
proper education will get aquainted with those eventually while an
incompetent programmer may never, but "can program in any language" is a
very long shot when looking at programming languages from different
paradigms.

Can you write a flow chart 'in any language?' If so, you can program
in that language. Yes, a different paradigm (object-oriented,
functional, declarative) takes some getting used to, but the basic
structures (selection, iteration, recursion) don't differ from
language to language. I'm not saying that it's easy, but it's
possible.

Also, knowing C and Java means that you can pick up Perl and C# pretty
easy. Knowing Scheme and Lisp means that you can pick up Erlang pretty
easy. The more you know the easier it becomes.

CC