the Schwartzian transform
Do they get extra points for knowing there is a drink named the Schwartzian Transform? (Which, like the transform itself, wasn't named by me.)
the difference between my, our, and local
Do they get extra points for knowing the difference between "our" and "use vars"?
closures
Do they extra points if they can demonstrate anonymous subs that aren't closures, or closures that aren't anonymous subs?
my $this_is_an_anonymous_sub_that_is_not_a_closure = sub { print "hell
+o" };
BEGIN {
my $message = "this is a closure that is not an anonymous sub";
sub here_it_is {
print "$message\n";
}
}
| [reply]
[d/l] |
To the peanut gallery, its not being inside the BEGIN block that matters. This too is a closure:
{
my $msg = "Hi randal!";
sub hi {
print "$msg\n";
}
}
(Yes merlyn, I know you know this... My coworker that just pointed out your message does not.) | [reply]
[d/l] |
Hmmm...
- For the first 2 (of 4) years I have been using perl, I would have given you a blank stare at "Schwartzian transform". I hope your question is to give them a snippet of code and ask them to explain the snippet.
- Simple syntax questions are good for telling the difference between a perl4 programmer and a perl5 programmer ... although I'm not sure you really get much out of it.
- I didn't really know anything about CPAN for the first year or so. Yet I was still turning out good, reliable code (I think), based solely on past experience in other languages (mostly C++).
- Again, dumb stares for about my first 2.5 years. Although, admittedly, if you had given me a snippet inside the first 12-18 months, I wouldn't have been able to answer that question, either.
- My answer, still today, would be, "I don't know how to parse CGI params." You'd ask how I got any CGI experience on my resume, and I'd simply say, "I use the CGI module - but I don't know how to parse the CGI params."
- In short scripts, I don't always bother with strict, unless it doesn't work on the first try, or I'm posting it to perlmonks ;-)
I realise that you're just giving brief bullets on what you'd ask about, I'm just pointing out what I think could be misunderstandings which could mislead you into dismissing the wrong person (not to say that I'd be the right person, though ;-}).
I usually ask candidates to explain their past work, their roles in that work, what difficulties they've faced, how they've overcome it. But I've never interviewed for professional hires nor contractors - pretty much only students and new graduates (where working with us would be their first "real" job), and I am not restricted to perl (we use C/C++; Java; Perl; Bourne, Korn, and C shells, all depending on what we're doing), so what I'm looking for may be quite different from what the OP is looking for.
| [reply] |
| [reply] |
Actually, the original question was solely "senior developer", which, and here's my hubris again, yes, I think I should be applying for - since that is really what I am right now (over 10 years with C/C++ should qualify, and more soft-skills on my resume which I won't get in to). Even before I started with perl, I was already pretty close to calling myself a "senior" developer (at least, relative to the team I'm on, I already was the senior developer, which may say more about the team than about me, but I'll cling to the term "hubris" again for this).
Sure, I may not be in a position to train people in Java. But it would likely take me about a year to be at the point of calling myself a "senior" Java developer for most projects. It's just a language.
Same thing here. What is more important - length of time in perl, or simply real amount of knowledge of programming principles? I've known some contractors with significant amounts of perl experience whom I would probably avoid for long-term permanent hiring. On the other hand, there is one student who I want back badly, and would have every confidence that he would pick up Perl in no time, and be extremely productive at it.
Training someone in a language is easy, if they have the skills in programming that you need. The other way around is much more difficult (and thus expensive).
At least in the company I work for, this is delineated by the ways we hire contractors (based largely on language skills: "we want to transform this spec to this language, do it.") and students/permanent hires (based largely on general experience and ability to learn).
| [reply] |
Can't resist:
- the Schwartzian transform
Obsolete sorting method. Inferior to the Guttman-Rossler Transform.
- the difference between my, our, and local
The number of letters. 'my' and 'local' and two different things - it's like comparing apples and oranges. And 'our' is like an orange, with an apple flavour. Its main purpose is to make Perl scoping even harder to explain.
- CPAN
Like CTAN, but then for Perl stuff. Lots of junk and trinkets, and some nuggets as well.
- closures
Like LISP. Subs that remember the environment they were created in.
- how to parse CGI params
Huh? Over 10 years of web, and we still let each program parse their parameters? Can't the server do that for us?
| [reply] |