Как я оцениваю тестовое задание.

[gliv]

Один из кандидатов стал расспрашивать про свой код, как мы оцениваем и т.п.
Я начал ему отвечать, и понял, что это тянет на пост в ЖЖ.

Comments

[gliv]

Да, каждое задание тестировалось на нескольких разработчиках.
Без учета Docker:
resm: 2 часа на задание
traffic-light: 3-4 часа

Docker для тех, кто им пользовался - еще полчаса.
Для тех, кто не пользовался - 4 часа с учетом чтения документации, борьбы с bash и пр.

[demmonoid]

Я объединяю пункты 2-5 в категорию одной важности, а дальше считаю примерно так:

1 пункт соблюден - плохо, надо отсылать учиться дальше
2-3 пункта соблюдены - есть над чем поработать, но человека можно доучить
4 пункта - совсем хорошо

Т.е., если ищем джуниора, то можно ожидать 2-3 любых (эффективности алгоритмов или вменяемой культуре кода и эксплуатации обучить всегда можно). Если ищем сильного штанги^W программиста, ожидаем все 4.

[gliv]

Спорно, для меня, например, очень важна хорошая читабельность кода.
Ты бы посмотрел на некоторые задания, которые присылают кандидаты - там иногда бывает все выполнено в одном файле в одной функции ;)

Читать невозможно, глаза сломаешь.

Т.е. такого человека я буду брать только если он реально хорош, остальные пункты сделал без ошибок, и при этом готов мириться с тем, что его код плохо структурирован, и его будут носом в это тыкать.
Просто иногда бывают "звезды", которые в штыки воспринимают любые пожелания - это тоже важно отслеживать на собеседовании.

[gliv]

А в остальном - да, согласен, тут многое можно объединять

[demmonoid]

Ну, ты же эффективность алгоритмов и использование памяти вообще поставил выше читаемости и удобства эксплуатации :) Я тоже за то, чтобы нанимать сбалансированных людей, но поднятый мной вопрос был в том, чем и когда можно жертвовать (если ты согласен и на новичка), и пойнт такой, что жертвовать можно любым из этих пунктов, при условии, что человек вменяемый

[ext_827501]

Мммм.. определенно тянет на пост в ЖЖ!

Лучше скажите, где условия почитать?

[gliv]

http://machinezone.ru/challanges

А как же смекалка?

[se_la_vy]

По поводу первого пункта: а вы смекалку кандидата не проверяете? Ведь в IT довольно часто задачи ставятся некорректно - это жизнь. Был у меня, например, такой случай...
Задачу на собеседовании поставили следующим образом: есть некий Java-интерфейс public interface IReport { void readObject(ObjectInputStream ois); void writeObject(ObjectOutputStream oos); } - его нужно реализовать и что-то с ним сделать. Я начал с того, что сразу переименовал методы контракта, поскольку понял, что контракт некудышний, эти методы нарушают соглашения для базового интерфейса Serializeble (которые обязательно должны быть private, т.е. их не всунешь после этого уже никак) - в итоге класс, реализующий этот интерфейс не сможет нормально управлять своей сериализацией. Это было принято за правильный ответ и со мной продолжили общение. Боюсь, при расписанном тобой алгоритме я бы пролетел, как фанера...

Re: А как же смекалка?

[gliv]

Во-первых, не уверен, что любой подвох добавлять в постановку задачи - хорошая идея.
Во-вторых, у нас задача более высокого уровня, какие уж методы будет кандидат писать - это его дело (и, кстати, очень интересно посмотреть, какие решения предпочтет кандидат).
В-третьих, умение размышлять над постановкой и выбирать варианты лучше проверять в очном собеседовании, а не на этапе домашнего задания, т.к. это много разговоров и уточняющих вопросов, размышлений "а вот если...". А домашнее задание - это больше проверка умения решать четко сформулированную задачу.

Re: А как же смекалка?

[se_la_vy]

Т.е. постановка задачи для домашнего задания - это не архитектура в виде контрактов, а просто требования? И кандидат с нуля делает микро-проект, когда у него развязаны руки городить что угодно? Но тогда вопрос другой - как вы тестируете способность кандидата работать именно с legacy-кодом, встраивая функционал в имеющуюся порой довольно неудобную архитектуру? Или у вас таких задач не стоит?

Re: А как же смекалка?

[demmonoid]

Если человек не нанимается на какой-то очень конкретный спектр задач, то нафиг не нужно тестировать его частные скиллы, достаточно общих. Во-первых, все его способности все равно не протестируешь, если, конечно, не дать ему пятнадцать тестовых заданий. Во-вторых, ну и хрен с ним, что инженер не очень хорошо работает с говнокодом - я его посажу делать то, что он делает хорошо (например, архитектурирование новых компонентов). В-третьих, люди как бы обучаются, даже будучи сеньорами.