[mgaw]

For me there are two reasons:

(1) We want to hire people who are able to solve programming-related problems. Now how do you find out if a candidate can do this? Looking at their CV doesn't tell you much. You can build up a long impressive CV without being able to program. So it would be nice to see them solve a problem right here and now.

Ideally, that would be a problem of the type you would often encounter in your actual work. But there are few programming-only problems in my work. And the hard ones are about designing a larger part of a system, or fitting something new into the context of something old, or trying to understand some old code to be able to adapt it.

My point is: All of these take a massive amount of context into account. Giving a candidate all that context would take weeks.

An algorithm challenge works because it has a good ratio of "time it takes to explain the problem" to "the problem is actually non-trivial to solve".

(2) We do these algorithm questions on a whiteboard, with one interviewer also standing and talking through the development of the solution with the candidate. I believe this gives me a sense of whether I can and want to work together with the candidate either on an actual whiteboard when sketching solutions to problems or when pairing.

[rimliu]

I think you are mistaking a programming-related problem for a CS-related problem.

[mgaw]

Hm I would say writing an algorithm is both programming-related and CS-related.