The other day I met a developer who went for a job interview and was asked to write a sorting algorithm. He was caught off-guard, didn’t do it very well, and failed the interview. But the company itself also failed, because it turns out they didn’t understand sorting algorithms either.
Here’s the test question: You run a company that creates software in high level languages. You have a collection of developers who want to work for you. How do you sort the ones who are most suitable from the ones who are least suitable?
The answer is to query each one in turn using questions that most closely match the actual work they’ll be doing.
If you need them to design domain models then give them a toy domain and ask them to model it. If they need to work particularly closely with other developers then get them coding next to one of your current team. And if, for some perverse reason, company policy bans the use of software libraries and they have to implement every basic software function from scratch every time, then it’s a good idea to ask them to write a sorting algorithm.
But if that last situation is not true of your company, then the correct answer to “Show me how to sort an array x of integers” is “x.sort()”. Or some variant according to your local tongue.
If you get that question wrong, then unfortunately you fail, and miss out on some really excellent hires.
niksilver.com 
I disagree with you here. Average developer might don’t know how sorting works, but every single great developer I know has this understanding and it is a deep one. It is good test to separate great from average. If you need average developer, then this test in pointless.
Michael, thanks for the comment, and I think you’re diving into a really interesting issue. I don’t think this is a black-and-white affair, and a consequence I kind-of agree with you in some respects, and have some more generally thoughts on your comment.
First, when interviewing someone for a job I don’t think you’re trying to find the greatest developer as such. I think you’re trying to find the greatest developer for that particular role. That’s an important distinction. Factors to consider are whether they are culturally suited to that organisation; whether they have an affinity for the work they’ll be doing; whether they’ll get on with the people they’ll be interacting with; and of course, whether they can actually code what’s needed.
That means a developer who is great in one organisation might terrible in another organisation. I can think of several developers and roles for which this is true, and I’m sure you can, too.
In fact, when thinking of such developers and roles I’m thinking of radically different companies and people. For example, I know some developers who produce really amazing front-end wizardry. They work with high level languages coding for environments with generous resources, and if one of them told me one day they’d struggle to write a sorting algorithm then it wouldn’t bother me at all — I know they do amazing things, and that’s what’s needed.
On the other hand (second point) I know some amazing back-end developers who have to frequently develop new and complex algorithms in situations where it’s too easy to become quickly starved of resources. If one of those developers told me they’d struggle to write a sorting algorithm then I’d be worried.
But such jobs involve much more than writing sorting algorithms, of course. So when I interview for such a role then I try to find more meaningful exercises or tests that examine much more than that. The idea is: if they can answer a more meaningful question then they can definitely handle a sorting algorithm; but if I only know they can handle a sorting algorithm then it’s still not clear to me that they can handle the bigger issues that the job actually entails. Such “more meaningful” issues might be about concurrency, garbage collection, or other knotty problems that that particular person would actually have to handle in that particular situation.
And that brings me onto the third thought. I’m really not against testing people with sorting algorithms at all. The post above was really trying to say that questions should be tied as close to the work as possible, and that having to write a sorting algorithm rarely is. It might be sometimes, but I do think that’s rare.
So, yes, I agree that great back-end developers, developing where resources are precious, should be able to write a sorting algorithm, but I also believe different kinds of developers need to demonstrate different skills, that testing someone on a sorting algorithm is rarely that useful, and that the best way to test someone in an interview is make the questions as close to the real work as possible.
Nik, I do agree with your main point
“best way to test someone in an interview is make the questions as close to the real work as possible.”
We have 2-round interview in our company for back-end developers. First round is to create an architecture of a relatively simple application. It takes ~2 hours. Then a developers presents his architecture and we discuss it. Usually 3-4 people attends this round from our side. Surprisingly, too many developers with decent CVs fail on this stage. Sometimes they create too complex solutions, sometimes they don’t think about important things upfront and create unscalable and hard to extend solutions.
Round 2 is quite usual 2hrs interview with relevant questions like how garbage collector works and why do you need reflection.
So basically we test 2 things: how a person can solve problems and what theoretical background does he have. So far this process worked very good, all 6 people we hired are great developers (or has a great potential at least :)