How to get good people: Two phase code tests
It is fairly common in job interviews to request some sort of a code sample. Generally a solution for a problem that the prospective employer gives the candidate. An interesting twist on that is to go over the code, give a single additional requirement, then see what the result it.
Comments
Wouldn't a real example make the readers of your blog test it?
An interview by Oren ;)
When I was interviewing people for my team, I had a twist on that.
I'd have asked people to tell me which is their strongest language (usually c#), and which languages they do not know at all (usually ruby/python/lisp).
Then I would have them do a simple fizz-buzz/string-reverse thing in their favorite language. As people already have pointed out, 90% of candidates CANT WRITE CODE so they couldn't have done that, even with VS2005 (and google) open in front of them.
Of the lucky ones who could code that, I'd have asked to translate their code to the language they do not know ... that was fun !
Yes, please, a real example would be great ;)
@Ken Egozi
Which one did they prefer? recursive one or the loop one, or another?
Damn, i thought i could write programs, but i don't even know what w fizz-buzz is, so I clearly cant do any thing good in a coding enviroment.
And the scary part: my coworkers need my to help them write code. But try to get them to write tests? And why do I ever try to get dem to refactor.
Plz, hire me, I cant make coffee, but I know how to make a pretty tasteful sandwich!
A technique I recently tried was to ask the candidate to provide a sample of their code which demonstrates some of their areas of ability. I told them it was OK to provide old code which they found slightly embarrassing as they would be asked to criticise it.
I spent about an hour reading their code and writing down what I thought could be improved (it would have been shorter but they provided quite a lot!). I then asked the candidate to write down how they thought it could be improved.
I then compared their analysis with mine and sent a copy of mine to them, while letting them know I would be happy to discuss any differences of opinion.
I think this worked well, as hopefully the candidate was relaxed and able to give a good account of themselves, meaning that I was able to perform a decent analysis of their abilities.
Not blinking ?
http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9072119
I've been interviewing lately. I've now had to take two tests which amounted to a bunch of picky details about the .net framework.
Dals - Interesting article. As a aspie myself, I recommend noise-canceling headphones. ;-)
I make people write code in interviews and am always astounded at when people can't write something simple, like filtering an array of duplicate values or finding prime numbers (I was once asked what a "primary number" was). I am also usually asked to write code in interviews. However, my attitude on submitting sample code or on writing something prior to the interview (or writing something in order to be considered for the interview) is that I generally don't want to do it. I don't mind doing it if I really want to work at that particular company or if I've approached them and they guarantee that they'll interview me if I send them a simple program, but generally for every job that requires that I submit a code sample, there are three jobs that don't. My time is valuable and I don't want to spend it writing code for you for free, particularly when I could better spend the two hours or so that it would take me to write your program talking to recruiters or interviewing for other jobs that pay just as much as yours does and has the same benefits and writes the same business applications. If you make code part of the interview, even if it's an all-day interview, that's fine with me, but don't ask me to do something on my own time just so that you'll consider interviewing me because I probably won't do it.
using Ayende.FizzBuzz;
using NUnit.Framework;
namespace FizzBuzz
{
}
One of our tests is to give them the starting point example from Martin Fowlers "Refactoring". We get them to add new requirements to the already terrible code.
We do this twice, the second time the requirement is aimed at being difficult based on their current design. To see if they will modify it to or fight with the current design.
"...I was once asked what a "primary number" was"
Ho-hum Jeff ;-) I'm so unconvinced that being able to write a program to find a Prime number is going to give any clue how good someone is. I might fall asleep during your interview. Get some creativity into your coding exercises! ;-) That's what you want?
Adam Mills, I like your tests with refactoring, this is more like it. Designing, creating and refactoring/dealing with existing code is what it's all about, as I see it.
You don't ask them what a Prime Number is at the end I hope.
A simple test can be: «Refactoring, what do you do when you read that:
if (testOK == false)
{
}
»
Some would immediately write:
args.IsValid = testOK;
but they miss that when testOK is true, args.IsValid can remain false...
I would only rename testOK in a first move. Then think about what is stinky when a variable is named testOk... Something to change, for sure !
@ Joak
if (testOK == false)
{
args.IsValid = false;
}
Refactored
if(TestIsNotOk())
{
}
Comment preview