So I have an interview tomorrow with a prospective employer. The job is supposedly a Perl Software Engineer position, but the skill set they want is all over the place. So we will see, really, what they want.
But I like to prepare as much as possible for interviews. And it depends on the interviewer what kind of questions they will ask, but I like to cover my bases by reading over the existing core documentation. That includes all of the obscure things inside perlvar, and even the deltas to know just when I can't use some modern feature. It seems like every interviewer has their "gotcha" question: the one question they weigh the heaviest in their assessment of your skills. Even I have them.
The Perl knowledge space is rather large when you consider what is packed into the core language. Everything from complex data structures, special global variables, an entire compact, and somewhat hard to parse-by-person, sub language (regular expressions), context depending expressions, and so much more is all crammed into Perl. There are bits that I am very much not intimate with: perlguts or XS in general, formats, pack/unpack, and I am sure there are others. Generally when I need to venture into those parts of the language, I will grok the concepts for the duration of my need and then it is back into the ether with those. But sometimes, those hard parts end up as someone's pet interview question. "Write me a format that produces this output." "Here is a specification for a message encoded as binary, write me a pack/unpack string that produces/consumes it." "We have a simple C library that we want to use in Perl, write some XS that encapsulates this functions usage."
And then sometimes, I am handed a dry erase marker and told to start writing code. That is very hard. Not that I consider a proper text editor with syntax highlighting and brace matching a crutch, but it is a rather limiting experience to write on a whiteboard. In front of people. People that are critical.
And even though I am critical of the tests that are sometimes given, I prefer them over a live whiteboard session. I guess part of my insecurity is that I have not done a lot of pair programming so I am not used to idea of someone looking over my shoulder constantly with a critical eye toward what I am doing.
How tomorrow is going to go, I am not sure. I am nervous. I am brushing up on the esoterics just in case. I just hope these guys have taken the time to go over my public work and save themselves some effort when it comes to asking the silly questions such as "What keyword would I use to sort an array?"
Subscribe to:
Post Comments (Atom)
Good luck with the interview!
ReplyDeleteHow did it go?
ReplyDeleteI've interviewed a lot of candidates and filtered out 90% with three simple questions:
ReplyDelete- what versions of perl have you used?
- what modules have you used?
- what modules do you like?
The remaining 10% gets real perl questions, including about internals (how does an AV work).
Hope your interview went well.
I have had 4 perl interviews in the past 6 months, and two were the standard questions on perlmonks. Like, what's the difference between system and exec and what do the sigils stand for. The other two were much more serious, like "When you were using mod_perl and you got a 'variable will not stay shared' what sort of error was that and how did you fix it?" Other questions were "Explain closures" and "How would you determine the number of gas stations required in X city?" Wild stuff. But fun. I try not to be outcome-oriented (I have a gig, so I'm not pressed for work), and look at them as fun learning experiences.
ReplyDelete