Поскольку большинство программистов обычно используют IDE, а также документацию API для выполнения задачи, мне не нравятся интервью, в которых основное внимание уделяется синтаксису или реальному имени метода (если только это не является общеизвестным).
Внимание должно быть сосредоточено на том, как собеседник подходит и решает проблему. В идеале они должны делать это таким образом, чтобы продемонстрировать, что они хорошо осведомлены о принципах, на которых вы их тестируете.
Поэтому я бы больше сосредоточился на духе кода, который они пишут, а не на письме :) (Просто мое мнение - я открыт для выслушивания контраргументов и встречных мнений).
EDIT
Чтобы ответить на ваш вопрос, это действительно зависит от того, что вы подразумеваете под своими критериями:
Правильность - Что это значит? Синтаксис? Я не думаю, что синтаксис должен быть слишком большой проблемой (если он не кажется ужасно неправильным). Возможно, вы можете ограничить правильность подхода. Например, если они используют алгоритм или подход, который явно неверен.
Краткость и простота - В каком контексте? Подход вообще? Конечно, вы можете проверить, что они не слишком многословны (т. Е. Насколько элегантно решение).
Чистый дизайн / API - Я не знаю, насколько хорошо вы можете это проверить. Слишком сложно придумать очень чистый дизайн и API всего за 1 час. То, что вы можете искать, это то, имеют ли они правильную идею или движутся в правильном направлении.
Тестируемость - Это слишком широко, и вы не должны быть слишком строги в этом. То, что вы можете сделать, это спросить их, как они будут тестировать свое решение после того, как они его разработали. Позвольте им вносить изменения и не привязывайте их к своему дизайну. посмотрите, как они подходят к задаче его тестирования или разработки тестов для него. Когда вы пишете код и разрабатываете что-то, это не разовая сделка. Вы постоянно улучшаете это.
Масштабируемость, производительность и параллелизм - Не указывайте это, когда говорите о дизайне и, как я уже говорил выше, не наказывайте их, если они не принимают решение, которое не хорошо работать или хорошо масштабироваться на первый взгляд. Вместо этого, если вы видите, что он не масштабируется или плохо поддерживает параллелизм (или даже если это так), спросите их, как будет работать их решение - масштабируемость и параллелизм - это проблема.
Ваша цель - увидеть как они думают и как они подходят к решению. Дело не в том, насколько хорошо они запомнили API или запомнили определения. Кроме того, если бы вы просто руководствовались своими критериями, было бы очень сложно найти кандидата. Как я уже говорил, программисты не работают изолированно только от того, что у них в голове. Они полагаются на несколько источников, чтобы выполнить то, что они пытаются сделать.