This problem is not great. It is a classic of the programming puzzle kind, and does not measure metrics which are important for most engineering. For some role

This problem is not great. It is a classic of the programming puzzle kind, and does not measure metrics which are important for most engineering. For some roles, like working deep in the weeds of a compiler or database optimizer, I think it's not that bad. That kind of programming has a puzzle feel: searches for near optimality in combinatorial (or worse) solution spaces. But it's not very applicable to most engineering. On the point of committees, though. Hiring committees make a hire/no-hire decision. They don't approve questions, but they do make decisions based on the results of asking a question. So they rely on the signal that the question generates, and if a question is not giving good signal, they will have an opinion. There's a different reason for wanting to standardize on interview questions. It's very easy to embed cultural bias. If the topic of a programming problem uses the rules of a game, for example, that will probably mean that people who are familiar with the game will understand the gist of the problem much faster than people who've never played the game.