At the company I am in, being able to express solutions on a whiteboard is fundemental. I have turned down applicants who were brilliant programmers because they could not express their solution on a whiteboard (I find this is highly correlated with a - "I can code therefore I don't have to talk to people" persona, which is fine in some companies, just not ours)
Nearly every software project begins in a room with a whiteboard, we often spend days mulling over massive whiteboard drawings with lines, boxes, psuedo code etc. But once we have finished with the whiteboard everybody goes away and the code is written by multiple developers, in parallel and the end of the week (sometimes the end of the day) it is finished and it all integrates perfectly.
Repeat the above over the lifetime of a larger system, and the hours spent expressing the ideas on the whiteboard save 10 times themselves in implementation and test.
Some developers hate this approach and see it as robbing them of their "artistic freedom", but the fact is, large scalable solutions aren't designed, developed, tested and integrated by lonewolf coders (at least not as a rule). By being up front, pooling ideas, knocking them down and arguing them out in a "public" setting I have never seen a software project fail, be late, over budget or not meet requirements (at least as far as a project can meet dynamic requirements) - we call it the House diagnostic approach - throw ideas out there, see what makes sense - only differences are the domain (not medicine) and the fact that "House" becomes the group.
As a note: I don't expect candidates to be perfect at expressing themselves, or even have any experience with white board design at all. But if they can grasp the problem domain (and they should, all the sample problems I set are really basic (design a system to collect and sample some basic census survey data i.e. design a record structure (a class, a database, a file - i really don't care), define an efficient way of accessing the data (hash table of classes, database queries, a novel file directory structure - again don't care, I want to see that they can grasp and spout ideas about), and define some algorithms to work out averages, aggregates, max, min range, sort etc. (testing basic algorithm knowledge, and they they can apply this to their solution).
The breakdown of the last group, of 400 applicants:
300 were rejected in the paper sift because they failed the paper test....(like the above, but on paper, simpler and you have as much time as you want to do it.....there is a serious lack of good talent!)
79 were failed at the first interview because they had problems explaining themselves on a problem like the one described.
18 were failed at the second interview because they were not deemed to have enough experience in computer science, mathematics or physics (or whatever domain they were supposed to be expert in)
3 passed and were offered places, and have settled right into the company.
Nearly every software project begins in a room with a whiteboard, we often spend days mulling over massive whiteboard drawings with lines, boxes, psuedo code etc. But once we have finished with the whiteboard everybody goes away and the code is written by multiple developers, in parallel and the end of the week (sometimes the end of the day) it is finished and it all integrates perfectly.
Repeat the above over the lifetime of a larger system, and the hours spent expressing the ideas on the whiteboard save 10 times themselves in implementation and test.
Some developers hate this approach and see it as robbing them of their "artistic freedom", but the fact is, large scalable solutions aren't designed, developed, tested and integrated by lonewolf coders (at least not as a rule). By being up front, pooling ideas, knocking them down and arguing them out in a "public" setting I have never seen a software project fail, be late, over budget or not meet requirements (at least as far as a project can meet dynamic requirements) - we call it the House diagnostic approach - throw ideas out there, see what makes sense - only differences are the domain (not medicine) and the fact that "House" becomes the group.
As a note: I don't expect candidates to be perfect at expressing themselves, or even have any experience with white board design at all. But if they can grasp the problem domain (and they should, all the sample problems I set are really basic (design a system to collect and sample some basic census survey data i.e. design a record structure (a class, a database, a file - i really don't care), define an efficient way of accessing the data (hash table of classes, database queries, a novel file directory structure - again don't care, I want to see that they can grasp and spout ideas about), and define some algorithms to work out averages, aggregates, max, min range, sort etc. (testing basic algorithm knowledge, and they they can apply this to their solution).
The breakdown of the last group, of 400 applicants:
300 were rejected in the paper sift because they failed the paper test....(like the above, but on paper, simpler and you have as much time as you want to do it.....there is a serious lack of good talent!)
79 were failed at the first interview because they had problems explaining themselves on a problem like the one described.
18 were failed at the second interview because they were not deemed to have enough experience in computer science, mathematics or physics (or whatever domain they were supposed to be expert in)
3 passed and were offered places, and have settled right into the company.