Re^2: Interview Questions

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.

Comment on Re^2: Interview Questions

Replies are listed 'Best First'.
Re^3: Interview Questions by tilly (Archbishop) on Apr 04, 2005 at 01:45 UTC
In your first 2 years with Perl, do you really think that you should have been applying to be a senior Perl developer? What you're saying pretty much applied for me as well back when I was learning, and I certainly wasn't ready then to do things like mentor other Perl developers.	[reply]
Re^4: Interview Questions by Tanktalus (Canon) on Apr 04, 2005 at 04:10 UTC
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]
Re^5: Interview Questions by tilly (Archbishop) on Apr 04, 2005 at 17:17 UTC
It is easy to have 1 year of experience 10 times, and think that you have 10 years of experience. I have no idea whether this is true for you. But it has been true for a number of people that I've worked with. Back to the topic at hand, Perl is a very different language than C or C++. Sure, it is easy to write C in Perl. Just like you can write Fortran in C. If your C coding habits are clean, the result won't be that bad. But it won't be anything close to idiomatic Perl. Your answer a couple of posts ago demonstrates exactly how non-idiomatic. Which is why I'd prefer to see more Perl experience in a potential mentor or lead programmer on a Perl project. (And I'd like to see experience of the sort that leads to "5 years of experience" rather than "1 year of experience repeated 5 times".) On your comments about ability to learn being more important than existing expertise with a language, that can be very true. I've been in the position of hiring people who I was supposed to teach Perl to, and have some idea how to do it. However it is somewhat hit or miss, you can't know in advance whether a given person will readily adapt to new ways of thinking or not. And there is always a learning curve. So if I'm hiring to lead, I want to pick someone who I think can grow, and who also has the skillset I want. I want both.	[reply]