I've been working in my first job for about 2 years now, and I've been "asked" to interview a potential teammate (whom I might have to mentor as well) on pretty short notice (2 days from now). Initially, I had been given a free rein(or so I thought, and hence agreed), but today, I've been told "not to pose bookish questions" - implying I can only ask basic programming puzzles and stuff similar to the 'fizbuzz' question. I strongly believe that not knowing basic algorithmic notations(the haziest ideas of space/time complexities) or the tiniest idea of regular expressions would make working with the guy very difficult for anyone.

I know i'm asking for a lot here, but according to you, what would be a comprehensive way to test out the absolutely basic requirements of a CS guy(he has 2 yrs of exp) without sounding too pedantic/bookish etc ? It seems it would be legit to ask C questions/simple puzzles only....but I really do want to have something a bit different from "finding loops in linked lists" that has kind of become the opening statement of most techie interviews !! This is a face-to-face interview with about an hour or more of time - I looked at Steve's basic phone-screen questions, and I was wondering if there exists a guide on "basic face-to-face interview questions" that I can use(or compile from the community's answers here).

EDIT: The position is mostly for a kernel level C programming job, with some smattering of C++ required for writing the test framework.

  • 2
    I read the title as "The first time-travellers interview...." :\ – TWith2Sugars Mar 16 '11 at 7:33

When it is a C# position give him a string programming puzzle to solve with regular expressions. In this way you could ask your questions anyway.

The most important thing for an interview is to verify people will fit in the team (on a professional level, and also on a personal level). If you think it is important to ask these questions to verify if the candidate will fill I would suggest discussing this with the people telling you not to ask those questions.

Try to find out why they don't want you to ask these questions.

  • Its a C position, and seeing that we are looking for kernel driver programmers, we'd almost never be dealing with string processing !! I guess, knowing bit-arithmetic would be vert important - know any good "fundamental" problems that I can use ? – TCSGrad Mar 16 '11 at 7:33

You don't have to be bookish , but you can test the level of understanding of the concepts . For example , the way the guy explains inheritance and abstraction itself speaks a lot about the guy .

I do not believe in having ready made puzzles (that you know the answer to) and expect the guy on the other side to give the answers .

What you have to figure out is

  1. The passion for work .
  2. Will he be a good fit into your company's culture .Being technically good is only one side of the story. (I am a good programmer but I will be disappointed if you don't give me internet access)

  3. Try to analyse what he wants and what you want and come to a conclusion .

Good luck .


In that case I would suggest testing how the person actually solves the problem you have.

We have a case study here from a real going-live scenario where we have a very big log file that contains lines from various places in the multi-threaded program. It turned out that one specific value caused the program to loop until an external condition was fulfilled, so that thread stopped logging until then. The challenge is then "what value gave this behaviour" and "at what time was it resolved"?

This requires you to do a lot of thinking, analysis and using tools to dissect the log file, so it will show you how good this person is for approaching a new task, what tools he will use and if there is anything you didn't know already.

If you have time, then you should let the programmer program a simple task while you watch.

  • +1: Actually try to work with the candidate instead of play arbitrary fizbuzz games. – S.Lott Mar 16 '11 at 9:59

The first thing I would do is to tell my boss that it was not possible for me to give an honest evaluation without asking some bookish questions.

That said, depending on what area of the kernel the guy will be working in, he may well not be doing much coding where a strong background in algorithms/complexity matter.

Either way, some non-bookish questions you'd probably want to ask are things related to bit-twiddling, differences between kernel space and user space, kmalloc/vmalloc, common kernel structures, how to debug the kernel, etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.