I need some tricky things
That's the last thing you need. You shouldn't be trying to trick applicants with obscure questions during interviews. Instead focus on the important areas:
- Look for a language independent understanding of programming, not just 463 ways to use unpack. Afterall, Perl isn't the best tool for every job, and even when it is their code will still benefit from the knowledge.
- Make sure they know the basics and can find the answers to more detailed questions if they're unsure. For example, ask them to write code to access a database, let them view the DBI docs if they haven't done this before.
- Look for code reuse. Ask them why they wouldn't write an XML or HTML parser in Perl from scratch.
- Get them to write some code, ask them about its maintainability and security.
The list goes on. As larsen noted, check out (OT) Interview questions -- your response? for many more good approaches.
| [reply] |
For example, ask them to write code to access a database, let them view the DBI docs if they haven't done this before.
Excuse me? I refuse to write a single line of code without having the documentation in plain view at all times (not just if i haven't done it before).
Now it is true in the case of DBI i personally wouldn't really need to, but come on, it's so easy to forget function/method names, that not having the docs in plain view you are in effect resorting to shooting in the dark (also known as suicide).
MJD says you
can't just make shit up and expect the computer to know what you mean, retardo!
** The Third rule of perl club is a statement of fact: pod is sexy.
|
| [reply] |
