About three months from now, some perl programmer will have my job, and I'll be unemployed... or so I hope.
Currently I spend most of my time documenting procedures and practices and reviewing existing code and code-level documentation with two coworkers who will inherit said code. They're both relatively new to perl. They've each written two or three perl scripts, and are otherwise primarily Uniface programmers (think "visual basic database apps" but w/o microsoft).
I learned yesterday that managment has agreed that it would be wise to hire a perl person as my replacement. They also agreed that it would be ideal if this person could be hired before I leave. So, I'm in the novel (for me) position of having some say in hiring my replacement, and being the primary person to evaluate their technical qualifications.
We'll be asking for code samples. I'm thinking that I'd like to see something over 100 lines to get a sense of what sort of documentation they typically include, how focused and reusable their subs are, whether they copy/paste instead of using subs/modules, etc. I'll also be asking some perl questions to get a feel for how familiar they are with common idioms, how they approach problems, how well they can take in someone else's code (mainly my code, since that's most of what they'll be working with for a while).
I've already got some questions/problems in mind, but I'm wondering if anyone has input about what sorts of questions they've found useful or useless in the past (from the perspective of the employer) and also whether folks have input from the perspective of the interviewee. Feel free to throw in non-technical questions if you'd like. I'll be asking some communication-skills-type questions too.
Also, does anyone have input about soliciting/reviewing code samples? What sorts of code have you requested (or had requested of you), or was the request always stated in very general terms? What sorts of things did you look for in the code?
If things move smoothly, I expect we'll be looking at resumes within a couple of weeks. Depending on the quantity and quality of applicants we may begin interviewing anywhere from three weeks to ??? from now. In any case, I've got some time before interviews and reviews of code would begin.
Any input? :)
Oh, for the curious, this would be in Saint Louis, MO (USA). I can't say more than that as all of the applications need to go through HR for legal reasons (so don't send me any resumes/code). Yes, I will be posting this opening to relevant perl fora once I've been cleared to do so... probably the perl jobs list, and to STL.pm, and in this journal. I'll look to see if perlmonks has an appropriate section too. I expect I'll be able to do that some time next week (maybe later if HR needs to clear the exact text I use in the posting).
-matt
Update: the position is now available.
Surprisingly very few interviewers have more than glanced at it. I would be very surprised if you had time to read through 100's of lines of perl code.
In the past I have done about 6 or 7 perl quizes during interviews, I think they are a quite good indicator of knowledge but are very limited - after all much of the time you only actually use a small portion of perl modules and functions.
Asking an interviewee how to solve a particular problem is usually helpful too, not asking them to write pseudocode or perl but rather going through the steps of solving the problem - what modules and approach they use.
This is all from an interviewee perspective though - I have had about 25 interviews in the past 3 years so I have seen quite a bit, many interviews have been shockingly bad - some interviewers got distracted by dogma and politics too easily. Remember that if somebody has come for an interview they have probably already thought about how they would fit in with your choice of technology - that they probably want the job otherwise they wouldn't have gone for it.
I figure that someone who's been using Perl for a while will know all these. I don't like memorization questions, but if you don't what $1 is, then something is wrong.What are the differences between C<our>, C<my> and C<local>?
What is C<$!>?
What is C<$_>?
What is C<$&>?
What is C<$1>?
How do you delete a file?
What does C<TMTOWTDI> mean?
How do you implement a list of hashes?
For my/our/local, I'm OK with an answer like "I always use 'my'".
The "delete a file" is there to see who knows the difference between delete() and unlink().
Re:Questions
pudge on 2003-02-27T04:02:05
FWIW, I would not expect everyone to know what our() or $& is; the former is new, the latter is rarely used. I would not care if anyone knew what TMTOWTDI is. Of course, that they cannot answer the question accurately isn't a bad sign, necessarily.Re:Questions
petdance on 2003-02-27T04:15:52
Right, none of them are necessarily exclusionary. It's just to get a feel for what the person knows overall. None of them are make-or-break. (Well, maybe $_ is)I make a big point of starting out the interview by saying "You will not know the answer to everything I ask. You will not have experience in everything I ask about. Please don't think that any one question is going to kick you out the door."
It's not just Perl stuff that I make that comment for. For instance, I was looking over some sysadmin part of this guy's resume, and I said "Hey, have you done anything with LDAP?" He about fell over trying to look good while saying "No." LDAP isn't a requirement, I was just interested...
Re:Questions
ajt on 2003-03-03T16:28:34
Once upon a time I went for interview with amazon.co.uk. Overall I'd have to say I didn't like the location or the atmosphere, and I was glad I didn't get the job, however the random test at the interview was actually quite good.
Without any warning the sat me down with a glass of water, a pencil and a sheet of awful HTML and asked me to fix it. At once I said it was not possible without knowing the DTD I was correcting it too, they said "current", and left me to it. I know I scored well they told me so when the rejected me! I've always like the idea of a random simple test at interview ever since.
I liked:
- Random nature - you don't worry in advance.
- No tools to rely on - what you have in your head is all you get.
- Open-ended, they said put as many comments as you like on the page.
- Tests work under stress.
I know that tests are very artificial, and mostly test people's ability to do tests, but a short random test has some uses as part of an overall process.
As we are looking for a Perl/Web person at the moment, I think I'll have to come up with a few quick questions of my own. I hope you don't mind me borrowing yours?
