Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: On Interviewing and Interview Questions

by spurperl (Priest)
on Aug 26, 2005 at 05:58 UTC ( [id://486810]=note: print w/replies, xml ) Need Help??


in reply to On Interviewing and Interview Questions

First of all ++, nice post with useful links :-)

I won't post any questions, there are tons of those, easily found on the web. I just want to stress the importance of one or two *serious* technical questions where the interviewee is required to (1) think and (2) write code.

I've seen quite a few people with glittering resumes and good presentational skills (i.e. they look/sound great on paper and in describing themselves), but who are hopelessly incompetent in writing code. People with "5 years of high-level super-complex C development" don't remember trivial things like pointer arithmetic and the idioms of memory allocation. Others were good in solving a question algorithmically, but when faced with a paper'n'pen couldn't produce anything coherent.

Therefore, I feel that technical questions are very important. An interviewee simply MUST write code. It may be small code, but he must write it. Even trivial stuff like (important especially in Perl) - read every line in a file and find how many times "BUBBA" appears in it, is important.

Replies are listed 'Best First'.
Re^2: On Interviewing and Interview Questions
by DrHyde (Prior) on Aug 26, 2005 at 08:40 UTC
    but when faced with a paper'n'pen couldn't produce anything coherent

    You don't use paper and pen to program in real life, so asking people to do so in an interview is not very useful. We test peoples' technical aptitude by first giving them a little programming task. It's the same task for everyone, they have an hour and a half to get as much done as possible, and we don't expect people to complete it. They have access to the interweb and all the online docs.

    Then we go through their code with them, and talk about other relevant stuff.

      When I'm faced with an unfamiliar computer, with an unfamiliar text / code editor, unfamiliarly configured, it's not too comforting. At least pen an paper are common for everyone :-)
        If you can't log into a random system and edit a file using whatever editor is on that system in order to fix a crashbug at 3am on a Saturday, you don't have enough moxie to work on my team. That's just a fact of life.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        We provide people with a Unix-like machine. If they can't use that, then they are not qualified. We let people use whatever reasonable editor they like. If they aren't at least minimally competent with vi(m), emacs or pico/nano, then I don't want to know. They also have perl pre-installed and a working interwebnet connection. Anyone who finds that too unfamiliar is interviewing for the wrong job.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://486810]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-03-29 07:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found