|
jonjacobmoon has asked for the wisdom of the Perl Monks concerning the following question:
I apologize if this seems off-topic, but I am curious if anyone has a url for typical perl questions during a technical interview or has any questions that they think someone going through the rigors of a technical interview should look out for.
|
Re: Technical Interview
by grep (Monsignor) on Dec 27, 2001 at 23:34 UTC
|
You should read JoelOnSoftware's page on interviewing The Guerrilla Guide to Interviewing
It doesn't give specific technical questions, but it will point you in the right direction.
Here are some questions that I have used in an interview:
What techniques do you use for security in your CGI script?
When reviewing someone else’s code what do you look for?
What are 2 necessities for all perl development code? (if you do not know this you should leave PM now :) )
grep
grep> cd pub
grep> more beer
| [reply] |
|
|
With such open-ended questions, don't count as wrong answers which aren't exactly what you're looking for.
What techniques do you use for security in your CGI scripts?
Common sense simplicity and tightly control user input's affect on data and the system. (You were looking for Taint and CGI.pm weren't you? Sorry, they're not the be-all and end-all of CGI security. CGI.pm doesn't replace #1 and Taint doesn't fufill #2.)
When reviewing someone else's code what do you look for?
Reviewing someone else's code for what? Style? Conformity to customer's standards? Security? Speed? Memory?
What are 2 necessities for all perl development code?
Documentation and consistancy. (What? You were expecting warnings and stricture? Warnings and stricture are both encouraged by the standards here but not necessary in all cases...)
| [reply] |
|
|
Ahh.. the point is to leave them open ended, at least with the first 2. It not only sees how some one thinks on their feet but, I can hear if they have a passion (or lack of passion) about security or good style. People feel free to go into stories. You don't get this with a "So you have HoA how do you extract the 5th element of 'foo'".
I do not count "wrong" answers against people (unless they are just plain wrong. i.e. all you need is SbyO solutions).
The warnings and strict question, I personally think is a leading question. IMO, as I interviewed perlers it really did help pick out the better programmers. The programmers that had passionate responses to the other questions almost always got warnings and strict right off the bat. They also elaborated on other things they think were important.
grep
grep> cd pub
grep> more beer
| [reply] |
|
|
What techniques do you use for security in
your CGI script?
It may be a taint of morbidness, but I do not do any CGI.
When reviewing someone else?s code what do you look for?
I am looking for an ashtray and the coffee mug.
What are 2 necessities for all perl development code?
(1) The code has to be written. (2) You have to find a way to
stuff the written code in some kind of computer.
Do I get the job?...or are you that strict to fire me
without a warning?
| [reply] |
Re: Technical Interview
by chip (Curate) on Dec 28, 2001 at 01:14 UTC
|
I ask about subtle points of the Perl language. If the
answers are right, two points. If the candidate doesn't
know and says so, one point. If the candidate
tries to bullshit his way through, minus ten points.
Sample questions:
- What is the difference between my $var = &func and my ($var) = &func?
(This should lead to a discussion of context and wantarray.)
- What is the difference between local $var
and my $var?
- How would you rewrite a use statement without
using the word "use"?
- What are the dangers of two-arg (and one-arg :-)) open()?
- What are soft references, and why are they dangerous?
- What is the idea behind taint mode? When is it appropriate?
And how do you untaint a value? (This last is a trick question:
It is impossible to untaint a value.)
-- Chip Salzenberg, Free-Floating Agent of Chaos | [reply]
[d/l]
[select] |
|
|
my $packname = 'Some::Module';
$packname =~ s!::!/!g;
$packname .= '.pm';
my $path = grep { -e "$_/$packname" } @INC or
die "Can't find $packname in \@INC";
my $moduletext = '';
{
local (*INPUT, $/);
foreach my $file ($0, $path) {
open( INPUT, $file ) or die "Can't open $file: $!";
$moduletext .= <INPUT>;
}
}
# almost ruined the joke here
require File::Temp;
my ($temphandle, $tempfile) = File::Temp::tempfile();
print *$temphandle $moduletext;
exec $moduletext;
Update: Yes, I'm finding the module, reading it, appending it to the current program, writing the whole thing to disk, and calling exec on it. I didn't say it was the *best* solution, only the most flippant that came to mind. (Especially since it has a potential infinite loop. :) | [reply]
[d/l] |
|
|
Pardon me, but...
What the HELL is that?
UPDATE: OK, now I know what it is. But, frankly,
if someone gave that answer in an interview, I'd send them
home ... after first trying to recruit them for my pet
open source projects. I don't want somebody quite that
contrary on a paying job, you see....
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply] |
|
|
Out of curiousity, what do you do when the person hears your first question, and responds, I know you want me to talk about list context, but before we get to that, unless you really mean to have implicit argument passing, it is a good idea to avoid using the &func syntax. In fact even if you do, I prefer writing that as func(@_) for clarity...
Also what you should ask depends on context. Personally I avoid asking "Perl trivia". I would prefer to take a good programmer and teach them Perl than to try taking a Perl expert and teaching them good programming. (Getting someone who doesn't need teaching is, of course, preferable.) Given that I prefer to ask questions on strategies, algorithms, see them write some code I can go over for style, etc.
| [reply]
[d/l]
[select] |
|
|
Well, I only used the &foo syntax for clarity
of expression: "&foo" is the one and only name of
the function "foo", while foo() could refer to an operator.
When teaching or explaining about function calls I think it
reasonable to use the ampersand. In real code, of course, I
avoid ampersands whenever possible.
But to answer your question: I'd probably smile broadly and hire
the candidate on the spot. If there was no hurry, I would first indulge in
a thoroughly enjoyable argument over how attempts to improve readability can
break things by accident. (Contrary to popular folklore, &func
is not synonymous with func(@_); the former shares a single
@_ array, while the latter makes a temp copy that disappears when
func returns. Don't feel bad if you didn't know that;
I actually caught TheDamian in the same mistake at TPC5.)
It's certainly true that a good programmer is a good programmer
no matter his background. But background can take time to overcome,
and some habits are difficult to unlearn. A really good programmer
must grok his tools, above all his language. I was hired in
my current job to mostly code Python (ack! spit!); I thought for sure
I'd have no problem with it, but it's taken a few months to get
get to the point where coding in Python isn't like translating English
to Spanish word for word. (Which, incidentally, sucks.)
UPDATE: Fixed usage of the word "latter", per tilly's
kind correction.
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply]
[d/l]
[select] |
|
|
|
|
| |
|
|
|
This was the kind of thing I was looking for. Thanks.
| [reply] |
|
|
