questions for programmers interview
category: code [glöplog]
So I started interviewing programmers. well, not actually interviewing them as I decided to test candidate with a preliminary test on a PC. The idea is to stop wasting time on pointless interviews.
I'm trying to put the test together and I'm looking for ideas.
Some guidelines:
- The test can be long with many questions (2-3 hours)
- It should be easy check (aka, no "what is your opinion on xxx?")
- It should mainly indicate about a persons ability and not less about his experience.
- Programmer position is a C++ / delphi / C# developer, with 1 or 2 years of experience.
I'm looking for advise regarding the follow:
- Testing in front of a PC or on paper?
- For questions where a program need to be written, should I ask for a compilable code or pseudo code?
- Do I allow internet access or not?
Beyond that, please share with me nice programming puzzles you encountered along the way.
Thanks for helping...
I'm trying to put the test together and I'm looking for ideas.
Some guidelines:
- The test can be long with many questions (2-3 hours)
- It should be easy check (aka, no "what is your opinion on xxx?")
- It should mainly indicate about a persons ability and not less about his experience.
- Programmer position is a C++ / delphi / C# developer, with 1 or 2 years of experience.
I'm looking for advise regarding the follow:
- Testing in front of a PC or on paper?
- For questions where a program need to be written, should I ask for a compilable code or pseudo code?
- Do I allow internet access or not?
Beyond that, please share with me nice programming puzzles you encountered along the way.
Thanks for helping...
http://codility.com/
short answer: closest to real working enviroment.
though i must say that more worthless then pointless interviews are pointless skill tests. unless you're trying to narrow down 1000 applicants to 5 or something like that, which i doubt. proper analysis of cv/portfolio and interview is always prefered. then if it seems like a match test them for a couple of months of real work. skill tests are useless unless they can solve your real work needs imho.
though i must say that more worthless then pointless interviews are pointless skill tests. unless you're trying to narrow down 1000 applicants to 5 or something like that, which i doubt. proper analysis of cv/portfolio and interview is always prefered. then if it seems like a match test them for a couple of months of real work. skill tests are useless unless they can solve your real work needs imho.
psenough: I actually did recruit in that way before and it was very effective, it helped me narrow down from 50 applicants to about 2 or 3. I'm simply trying to fine-tune and optimize this approach.
http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
Quote:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Quote:
The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution
as long as it isnt like my java exam ages ago. ppl need a chance!! :P
We were able to narrow down the numbers by 95% by asking them to write a recursive program for n!.
Some of the applicants even failed after giving them the edge case and the definiton.
Otherwise:
- allow internet access, after they shown knowing the basics. They will have it during the work anyways.
- not so easy to check, but tells a lot on experience: tell some WTF like situation, and ask for tips on what to do, what to check.
Some of the applicants even failed after giving them the edge case and the definiton.
Otherwise:
- allow internet access, after they shown knowing the basics. They will have it during the work anyways.
- not so easy to check, but tells a lot on experience: tell some WTF like situation, and ask for tips on what to do, what to check.
Give them a piece of Navis' code and ask them to explain it.
Curiously, I'm applying for jobs and have already gotten programming tests. What FooLman said: test iterative and recursive computation of n!, some operations on basic data structures like trees or linked lists, if applicable portability issues between diferent platforms, if applicable some basic 3d math knowledge (like meaning of dot/cross product). Give them enough work and 2 hours of time to solve. They won't have time to google around.
Finally don't expect them all to answer each question correctly ;)
Finally don't expect them all to answer each question correctly ;)
Gargaj: lol... I might actually do it :)
xTr1m & FooLman: will do as you suggested, having the tests tomorrow, will let you know how it went.
Ask them to try to figure out what does :
- some asm code (preferably a not-so-mainstream one, such as zilog, arm or motorola)
- some high-level language which isn't mentioned on their cv
This should narrow A LOT your selection. For me a good programmer adapts himself. Put them in a situation they didn't expected and watch how they handle it.
- some asm code (preferably a not-so-mainstream one, such as zilog, arm or motorola)
- some high-level language which isn't mentioned on their cv
This should narrow A LOT your selection. For me a good programmer adapts himself. Put them in a situation they didn't expected and watch how they handle it.
If you need graphics coders - ask them to write down trilinear interpolation with lerp instructions.
I went to an interview today, oh no.
What I'm doing now for the C++ tests is to give a already made project that builds a UnitTest++ set of tests on some classes (in my case a "SomethingManager" that manage things, create them, query them, iterate over them, destroy them) that show the usage pattern for each class.
There are some additional comments that explain what is allowed and what is not (using internet, third party libraries, pointing out flaws, asking questions), etc...
There's also a basic explanation about what UnitTest++ is, the various macros are explained in one-liners.
Then you clearly state the candidate how long they have, that we are more interested by the mental walkthrough than by the actual result, that it's better to have something incomplete but correct (and they can explain quickly how they would have done the rest), they have to speak out loud explaining what they are doing, why they are doing it, why they do this before that, etc...
If they are struggling on purely technical stuff (somebody who's used to makefiles and never used an IDE, does not know what unit tests are) you can give a hand, but else just let the person do the test without trying to interfer.
In the end, even if you don't plan on taking the person in, explain why, what they could have done, what they should probably work on, etc... this way at least it's not 100% wasted time :)
There are some additional comments that explain what is allowed and what is not (using internet, third party libraries, pointing out flaws, asking questions), etc...
There's also a basic explanation about what UnitTest++ is, the various macros are explained in one-liners.
Then you clearly state the candidate how long they have, that we are more interested by the mental walkthrough than by the actual result, that it's better to have something incomplete but correct (and they can explain quickly how they would have done the rest), they have to speak out loud explaining what they are doing, why they are doing it, why they do this before that, etc...
If they are struggling on purely technical stuff (somebody who's used to makefiles and never used an IDE, does not know what unit tests are) you can give a hand, but else just let the person do the test without trying to interfer.
In the end, even if you don't plan on taking the person in, explain why, what they could have done, what they should probably work on, etc... this way at least it's not 100% wasted time :)
To select a few from thousands a simple test with a handful of questions of 1-5 minutes each would be enough. The question themselves wouldn't need an applicant to write anything, but rather ask to explain what's going on in provided code snippets (like, will this compile? what will be this variable value or output? Checking that kind of answers would be easy even for a non-programmer, e.g. anyone from your HR dept). No need for a PC or internet access. No tricky questions, just the bare minimum basics.
For example, a C++ test would consist of:
1) Basic OOP; inheritance and constructors/destructors order. You'd be surprised how many people don't know this stuff
2) Pointers arithmetic (a bit plain-c-style, but nevertheless useful)
3) Bitwise operations
4) String operations, layout in memory and more pointers
5) Basic STL (sort a vector or something, nothing tricky -- it's completely ok to forget the details this stuff in real life)
For example, a C++ test would consist of:
1) Basic OOP; inheritance and constructors/destructors order. You'd be surprised how many people don't know this stuff
2) Pointers arithmetic (a bit plain-c-style, but nevertheless useful)
3) Bitwise operations
4) String operations, layout in memory and more pointers
5) Basic STL (sort a vector or something, nothing tricky -- it's completely ok to forget the details this stuff in real life)
Some people are good with tests, but not with actual work. Some fail miserably at the most basic stuff during a test, but do just fine under normal working conditions. Most tests yield rather arbitrary results, there are better ways to determine what's up.
Most "real" programmers have hobby projects and a source repo on the net. Look at their code, ask them about their old projects and how they approached them. Still wanna ask about "hello world" and "factorial" and "bubble sort" crap? How about something relevant? You're wasting my and your time. You don't ask an MBA what cost and demand is, or a physicists to explain the definition of an atom. Do your job, look at the material the applicants provide beforehand. If you want to ask about code-related stuff, go deeper than syntax, ask about some common concepts and algorithms. Why are they fast/slow/good/bad, what would be better under what circumstances.
And no, I don't do code quizzes over the phone and I don't code for free for a week, just because your idea of a job filling process is terribly misguided.
Most "real" programmers have hobby projects and a source repo on the net. Look at their code, ask them about their old projects and how they approached them. Still wanna ask about "hello world" and "factorial" and "bubble sort" crap? How about something relevant? You're wasting my and your time. You don't ask an MBA what cost and demand is, or a physicists to explain the definition of an atom. Do your job, look at the material the applicants provide beforehand. If you want to ask about code-related stuff, go deeper than syntax, ask about some common concepts and algorithms. Why are they fast/slow/good/bad, what would be better under what circumstances.
And no, I don't do code quizzes over the phone and I don't code for free for a week, just because your idea of a job filling process is terribly misguided.
which is why my method works best.
Make them read a defective piece of code (which is not from your organization or at least not anymore) and ask them what's wrong.
"WTF, no indentation?!" :P
ask him what this code do :
Code:
void Send(int * to, const int* from, const int count)
{
int n = (count+7) / 8;
switch(count%8)
{
case 0: do { *to++ = *from++;
case 7: *to++ = *from++;
case 6: *to++ = *from++;
case 5: *to++ = *from++;
case 4: *to++ = *from++;
case 3: *to++ = *from++;
case 2: *to++ = *from++;
case 1: *to++ = *from++;
} while (--n>0);
}
}
if they're a new hire, most of their time is gonna be spent with dealing with someone else's code anyway.
ask to demonstrate why the Singleton pattern is great
Conduct brief interviews with a bunch of candidates and select a few that shows promise -- and by that I mean someone that both you and the team likes, that knows how to communicate and that seems to understand you and your company.
Then you hire the few people you like on a one-month contract and allow your existing team to interact with them. At the end of the month, pick the one that you like the best. Done.
Then you hire the few people you like on a one-month contract and allow your existing team to interact with them. At the end of the month, pick the one that you like the best. Done.
gloom: Have you tried this in practice? I can help imagining that the social dynamic between the 'competitors' would become... awkward. At best.