3 ms·

On paper? Or with a computer and compiler/interpreter?

• silentbicycle 17y ago
  Writing pseudocode on paper will shift focus from correcting minor syntax errors to how well they understand concepts, which is arguably more important. It's still worth requiring them to produce at least a tiny piece of working code, though. I helped interview someone who couldn't explain the trade-offs between a couple different designs for a simple class hierarchy, even an obviously wrong one included as a canary. Then we asked him to write one out, and, after stalling and getting several hints from us, he nervously scratched out a (naive) MySQL schema. Despite what his resume claimed, his only programming experience consisted of PHP and a fairly shallow understanding of SQL.
• RiderOfGiraffes 17y ago
  Some couldn't produce either. I look for someone to sketch a correct algorithm using any notation they choose. Independently I look for someone to produce working code with an editor and compiler. The former is usually for something like linked lists or quicksort, the second for something like FizzBuzz and then recursive and iterative Fibonnaci. Working code is essential for something, anything, at some point, although really what I want is someone who can then talk sensibly through the issues. Even so, working code for trivial problems is still only seen in about 10% of cases.
• gjm11 17y ago
  I like to ask candidates to write real code (not pseudocode) on paper, but emphasize to them that I don't really care about superficial syntax errors. Most of the point of this is not in seeing the code they produce, but in watching them think and seeing how they react to questions and suggestions.