When I have taught C, a quick assignment was for the student to derive the implementation of each of the strcmp(), strtok() and strncpy() functions, complete with O-notation and any shortcomings in unexpected data inputs. I have even asked the same of applicants. Why? Because I'd seen a pattern of CompSci graduates who had no practical understanding of pointer arithmetic, working to a rigid spec, deriving behavior from example, and the inherent dangers of data assumptions.

--
[ e d @ h a l l e y . c c ]

As an extension of this thought, its always more beneficial to get an prospective employee into problems they know little to nothing about.

This leads to views of thier basic underlying skill/mind set. Do they turn to the manpages? Hit google? Try to bluster their way out? Throw in the towel per se? Have enough of a basic grasp of concepts to make "edjucated guesses" and provide contingencies for what might alter the situation? Try to get you to provide "hints" to the answer? When the answer is provided, how do they deal with the new info? Do they appear to assimilate it? Try and make it seem as if the question were a trick one, and had the right language been used would have provided just the answer you gave?

At first I thought interviewing was showing how much you know in a particular domain. I guess it is, but I have found the best interviews to be when its almost a game of cat and mouse. Pushing to see what they know, and the confidence level there. Jumping to a topic either completely opposite, or maybe even personal (where ya from? what do you do for fun?), and back to a hard technical topic. Not to say we should scar potential employees, but by the same token we don't want to allow people who know topic A and nothing about B or even how to go about learning B in the door. There are exceptions, but I think they are relatively few and far between.

I guess I should note that this is an approach for mid to senior level, though at a junior/entry level, a certain level of enthusiasm and the ability to link previous questions/topics with current questions would be good.

use perl;

With all due respect to the Anonymous, if you can't work your way through this problem on your own, I feel for the person who must prove their own value to you.
...
In my view, interview questions are not to be doled out by the shovelful. You should decide what are the desirable characteristics of an applicant for the position, and then probe applicants according to those issues.

That seems a bit unfair.

It's perfectly reasonable for an interviewer to want to gauge an applicants abilities under pressure, ability to deal with unexpected problems, willingness to ask questions,and generic "problem-solving" skills.

In situations like that, the specific question is usually irrelevant, what does matter is that there are some number of "logic problems" that the interviewer has handy to see how the interviewee responds.

Personally, I like to have a few such questions handy. I make sure i have time to ask one, and then if there's extra time towards the end, ask more untill the time is filled.

Good point, I'll put in the time and work through some on my own.
Thanks again!

O-notation? O-notation? Are you O-notation? Nobody said there was gonna be math on this test.

O-notation!?!?!

That's a valid, albeit disappointing response to the question. If you don't know what O-notation is, I learn something about the boundaries of your skills and training. If you think you know what it is, but think it's onerous, again, I learn something. If you muddle through the problem, give bad analysis, or don't give an answer at all, I learn something. That's the point of asking, right? It's not to lord my skills over you (the applicant). It's to see if and how you can help me accomplish projects together.

--
[ e d @ h a l l e y . c c ]

Use Super Search for titles with the word "interview." You'll find nodes like these:

• Interview questions
• Technical Interview
• Interview with a Programmer
• Phone interview
• Assessing Perl skill level in job interviews
• (OT) Interview questions -- your response?

For technical aspect, I probably would come up with three or four types of questions: 1) general (but programming specific) problem solving and modelling, 2) business sense, or basic organizational and managerial sense, 3) language-specific, and 4) mind-twister, reserved for good candidates the interviewer want to explore their limits.

Example of 1) general (but programming specific) problem solving and modelling could be: use a short product idea description or wishlist in form of, say, an email; ask the candidate to come up with a model, such as ER diagram or class diagram. Interviewer should observe the candidate's thinking process as much as its output.

Example of 2) business sense or basic organizational and managerial sense question: Top management just bought a bunch of new software for its developers in hope of boosting productivity. But the project manager removed the new software. Train the developers based on the old software instead. Why?

3) language-specific questions have been plentily provided in this thread.

Example of 4) mind-twister: A newly developed software has unknown number of bugs. How would you estimate the number of bugs without using an exhaustive testing (which could be way too impractical)?

For "people" aspect, having a would-be hire talk with his would-be coworkers would be a good start.

Here's an oldie but goody.

Consider the following code:

#!/usr/bin/perl -w ################################ use strict; my $str="ABC"; $str++; printf "%s\n",$str; exit(0); [download]