Keep It Simple, Stupid | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I would be worried about hiring anyone for a perl job where at least some specific perl questions like this were not asked.
Consider: 1) perl gives you enough rope to "hang yourself from several trees while blowing your own foot off with it" 2) for those who can swim to the surface of programming language agnosticism, there's a justifiable reason for perl having the stereotype of being a "write once language"--it's called the swiss army chainsaw for good reason. 3) in the real world, that of businesses, deadlines, changing requirements and general idiocy will force all of us at some point down the slippery slope of committing bad code, designs or architecture decisions, so at least try to minimize these flaws as an act of charity towards the poor sap who will end up maintaining your code. A good perl programmer should be aware of a small handful of "bad perl idioms" and related gotchas, or at the very least be aware of the the dichotomy between perl's blessing and curse: the flexibility of the language comes with a cost--you have to be careful with what you do or you can hang yourself with bad code. (Of course this is countered by the rewards gained by the smart use of tricks in the language.) Someone who would walk obviously isn't interested in any of the above, and I'd also think twice about taking on a developer who isn't generally interested in puzzles related to programming languages themselves. In reply to Re^2: Evil Interview Questions
by Withigo
|
|