Как я оцениваю тестовое задание.
Один из кандидатов стал расспрашивать про свой код, как мы оцениваем и т.п.
Я начал ему отвечать, и понял, что это тянет на пост в ЖЖ.
Если уж вы интересуетесь, попытаюсь ответить чуть более развернуто, и для этого я хочу, чтобы Вы представили себя в "нашей шкуре".
Представьте себя в компании, которая ищет работников, и представьте, что у Вас помимо основной работы, которой всегда очень жадная до ресурсов, есть еще поток входящих кандидатов. У каждого кандидата своя история и свой уникальный опыт, а его еще нужно как-то оценить (что достаточно сложно)
Присылаемые задания, после пятого или десятого (двадцатого?) перестают удивлять новизной или подходами. Разных способов решить задачу очень мало - по пальцам пересчитать. Поэтому к математике вопросов обычно не возникает, от слова "совсем". Эту бизнес логику все чаще всего реализовывают без ошибок.
Критерии, на которые лично я обращаю внимание (в порядке убывания важности):
- Соответствие тех. заданию. Самое важное требование, оно показывает, как человек умеет решать задачи. Если кандидат идеально решил задачу, написал все возможные виды тестов, прогнал нагрузочные тесты, проверил покрытие, но при этом сделал другую задачу, а не ту, что ты поставил - этот человек не подходит.
- Алгоритмическая сложность (как изменится скорость работы, если будет одновременно работать с системой миллион пользователей? O(n^2) при таких числах уже наверняка убъет систему)
- Требования по памяти (иногда бывают быстрые решения, но очень затратные по памяти)
- Читабельность кода
- Легкость в эксплуатации и обслуживании
- Краевые случаи (вызовы API без параметров, с некорректными параметрами, "левые" вызовы, которых нет в ТЗ)
При этом корректность логики проверяется всегда acceptance тестами, они у нас написаны, и проверяют весь интерфейс, а все остальное проверяется руками и глазами.
Т.е. Вы видите, что из 6 критериев только 1 имеет отношение к коду (читабельность), еще два относятся к выбранным алгоритмам, а остальные три, включая самый важный - имеют очень слабое отношение непосредственно к коду, но при этом очень сильно влияют на то, сколько времени вы тратите на поддержку продукта на реальных серверах, разбор ошибок, какой-то анализ и расследования.