Here's one of my favorite examples that can work for almost any language.
Remember, before any of this happens, I have already helped the candidate get comfortable and have made the purpose of the exercise clear: to assess where they're at and how/where they might fit in. It is not a test. Just an exercise to help us both. I offer them a soda or coffee, a little privacy, and this little problem...
You have an array. Call it "a" or whatever you want. It has a bunch of elements, numeric, alphanumeric, or whatever. You decide. Sort it. Without using a second array or a pre-existing function or routine. While I'm explaining this I'm sketching it out with my own pencil and paper. I suggest that they sketch out what they want to do themselves and then write some code (in the language being evaluated) or just pseudo code for general purposes. Be prepared to discuss whatever you want to present. Don't go nuts, just a few pages and 15 to 30 minutes. And have fun.
When I return, I have them explain how they approached it. (Here's what my code will do...) Then we go through the code line by line. At this point, it's incredibly easy for me to ask questions, such as...
Why did you name that variable that name?
Why did you use a for loop?
How else could you have done iteration?
How would you do it with 2 loops?
How would you do it with 1 loop?
Which variables are global? Which are local? Why?
Why did you reuse the variable "i" in the inner loop? (Oops)
How can you make it faster?
How could you make it clearer?
How would you change it if you knew the probability of the original order?
How would you refactor this?
How would you extend this to do...?
Which code would you put in a library for reuse?
You kinda get the picture. No 2 interviews are the same. Imagine the programmers you already know having this discussion with you and how much you'd learn about them.
There are no right or wrong answers, just learning. Which is what you want.
This simple test eliminates the 90% of applicants who are not suited for this work and 100% of the posers. You can tell right away who they are.
OTOH, good programmers shine on this. It's actually fun to hang out and talk about this stuff with them. I have even had candidates email me later with revised code based on our discussion. Those are the motivated ones. Big points for that.
If you know how an insertion sort (for example) works, then you can pretty much answer all your questions fairly easily. Knowing algos is good, but does not in itself make you competent in every respect.
Having said that, I am not trying to be critical. I completely agree that having a discussion like this is extremely valuable and can let you find out a lot about a person and even eliminate most of the chaff (although I have met a couple of people who I wouldn't necessarily hire, but who could have done well in a discussion like that).
After your discussion, you might even decide you really like a person, but does your team like them? How about this, can you tell if a person can stick to a deadline? A longer discussion is necessary before this becomes apparent.
Remember, before any of this happens, I have already helped the candidate get comfortable and have made the purpose of the exercise clear: to assess where they're at and how/where they might fit in. It is not a test. Just an exercise to help us both. I offer them a soda or coffee, a little privacy, and this little problem...
You have an array. Call it "a" or whatever you want. It has a bunch of elements, numeric, alphanumeric, or whatever. You decide. Sort it. Without using a second array or a pre-existing function or routine. While I'm explaining this I'm sketching it out with my own pencil and paper. I suggest that they sketch out what they want to do themselves and then write some code (in the language being evaluated) or just pseudo code for general purposes. Be prepared to discuss whatever you want to present. Don't go nuts, just a few pages and 15 to 30 minutes. And have fun.
When I return, I have them explain how they approached it. (Here's what my code will do...) Then we go through the code line by line. At this point, it's incredibly easy for me to ask questions, such as...
You kinda get the picture. No 2 interviews are the same. Imagine the programmers you already know having this discussion with you and how much you'd learn about them.There are no right or wrong answers, just learning. Which is what you want.
This simple test eliminates the 90% of applicants who are not suited for this work and 100% of the posers. You can tell right away who they are.
OTOH, good programmers shine on this. It's actually fun to hang out and talk about this stuff with them. I have even had candidates email me later with revised code based on our discussion. Those are the motivated ones. Big points for that.