isotope has asked for the wisdom of the Perl Monks concerning the following question:
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:
- Opens a file whose name is given on the commandline
- Replaces all occurrences of 'Y' with 'K'
- Writes the results to a new file with ".mod" appended to the original filename
- 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-)
(jeffa) Re: Assessing Perl skill level in job interviews
by jeffa (Bishop) on Aug 15, 2000 at 22:01 UTC
|
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.
| [reply] [Watch: Dir/Any] |
Re: Assessing Perl skill level in job interviews
by turnstep (Parson) on Aug 15, 2000 at 23:25 UTC
|
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)
| [reply] [Watch: Dir/Any] |
Re: Assessing Perl skill level in job interviews
by btrott (Parson) on Aug 15, 2000 at 22:25 UTC
|
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. | [reply] [Watch: Dir/Any] |
RE: Assessing Perl skill level in job interviews
by mikfire (Deacon) on Aug 15, 2000 at 22:14 UTC
|
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 | [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
|
|
|
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
| [reply] [Watch: Dir/Any] |
Re: Assessing Perl skill level (Brainbench plug)
by Russ (Deacon) on Aug 16, 2000 at 01:00 UTC
|
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 | [reply] [Watch: Dir/Any] |
|
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. :)
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: Assessing Perl skill level in job interviews
by Anonymous Monk on Aug 15, 2000 at 22:26 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
RE: Assessing Perl skill level in job interviews
by BigJoe (Curate) on Aug 15, 2000 at 23:40 UTC
|
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. | [reply] [Watch: Dir/Any] |
RE: Assessing Perl skill level in job interviews
by Adam (Vicar) on Aug 16, 2000 at 03:59 UTC
|
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! | [reply] [Watch: Dir/Any] |
RE: Assessing Perl skill level in job interviews
by larsen (Parson) on Aug 17, 2000 at 00:59 UTC
|
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 | [reply] [Watch: Dir/Any] |
Re: Assessing Perl skill level in job interviews
by princepawn (Parson) on Apr 19, 2001 at 21:00 UTC
|
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.
| [reply] [Watch: Dir/Any] |
A reply falls below the community's threshold of quality. You may see it by logging in. | A reply falls below the community's threshold of quality. You may see it by logging in. |
|
|