Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by KM (4) on 2004.04.09 10:34 (#29984) Journal
    But, since I usually interview a company as they are interviewing me, I'd ask you for use cases to the program to see if the company writes things on napkins and say "MAKE THIS WORK" or actually thinks things out.

    I was once being interviewed and one of the people had a real-life problem he wanted worked out. We brainstormed on a whiteboard together. This was excellent to do. I, as the interviewee, got to see what a brainstorming session with a possible co-worker would be like, and he got to see what it would be like with me. We could see eachothers thought process, knowlege of what modules could do certain things, and various options to be a solution. That may even be more valuable to do than make them write a script before an interview. You should already have some code samples, know if they know about the CPAN, what they use for reference material, etc... But, seeing someones thought process in action, and how they may interact with teammates while designing is a good idea since you don't get that from a resume or pre-interview exercise.