Про то, код во время интервью это прям смешно, конечно. Стоимость false positive гораздо выше, чем false negative.
Попросить реализовать какую-то максимально простую штуку в конце интервью помогает гораздо лучше, чем очередная пачка шаблонных вопросов. Обычно даже не требуется, чтобы она собиралась.
При желании, кстати, вопросами можно закопаться так глубоко, что просьба реализовать какую потоко-безопасную очередь покажется просто раем. (Я хз, что там модно в Unity сейчас. Я смотрел на него, в основном, через IDA, ILDasm и исходники самого движка. Просто привел пример, который заменяет собой 333 вопроса)
Лет эдак 7 назад я, например, завалился именно на этой части, хотя там требовалась на выходе готовая утилита. И отлично понимаю, почему меня не взяли. Вместо того, чтобы написать за полчаса в лоб - я изобрел длинное сложное решение, которое тупо не нужно было для поставленной задачи.
Попросить реализовать какую-то максимально простую штуку в конце интервью помогает
Увы, но это не помогает ¯\_(ツ)_/¯
Я хз, может у Вас просто какая-то зверская интуция, но я таким вещам не доверяю :-)
Более того, по моим наблюдениям техдрочево и лайвкодинг используется в 2 случаях:
А) Народ сам не знает чего хочет, но краем уха слышал про лайвкодинг.
Б) Максимально по возможности снизить самооценку соискателю, сбить его цену, ну а заодно оценить сколько на нем можно ездить.
Стоимость false positive гораздо выше, чем false negative.
Именно поэтому лайв-кодинг на собеседовании и есть бесполезное дрочево и нецелесообразная трата времени. Никакой корреляции между лайв-кодингом и рабочими скиллами потом не обнаруживается.
А если надо действительно как-то объективно оценить скиллы человека, а заодно быстро отсеить лишних, то всего-то нужно отправлять соискателям тестовые задания на дом.
Во-первых, часть народа еще на этапе получения тестового задания самоотсеятся. Всегда какой-то процент соискателей отваливается увидев тестовое задание (в перевую очередь поофессиональные ходоки по собесам), а это уже экономия времени. К слову это еще и поможет самим соискателям оценить туда ли они вообще идут или нет.
Во-вторых, среди тех кто все-таки тестовое задание осилил, будет уже хорошо видно какой у человека стиль программирования, откуда он привык копипастить код и каким образом он вообще подходит к решению конкретной задачи в нормальной обстановке. А именно это всем и нужно.
Ну а затем уже на техсобеседовании можно будет подробно обсудить решение тестового задания, и там уже сразу будет видно насколько хорошо человек в принципе в технической части ориентируется и как поддерживает предметный разговор.
В конце-концов можно будет сравнить решения (и подходы) разных людей. Сделанный человеком за пару вечеров небольшой проект говорит о нем куда лучше, чем его ответы во время дрочево-собеседования, т.к. IRL никто не работает в режиме лайв-кодинг и глупых вопросов. А вот решение какой-нибудь простенькой задачки на собеседовании за короткое время будет говорить только о том, что соискатель наверное умеет решать примитивные задачи за ограниченное время. В реальной же жизни человек на работе получает таску и пилит ее сам по себе какое-то время, и каждый может пилить по разному. На митингах все тоже будут обсуждать конкретные вопросы по проекту, а не пузырьковую сортировку, очереди и заполнение матрицы змейкой. Если надо оценить соискателя, то оценивание должно быть все же приближенным к реальным условиям.
Прохождение отбора через тестовые проекты можно хорошо формализовать, а такие вещи хорошо автоматизируются. А вроде как любая IT компания должна стремиться к автоматизации всего и всея, дабы сократить издержки, а не дергать рэндомных инженеров чтобы они на тех-интервью задавали рэндомные вопросы, получали на них рэндомные ответы, а потом давали рэндомную оценку соискателю.
В конце-концов по тестовому проекту потом и развернутый фидбэк легко написать.
Ещё как вариант это попросить человека рассказать о самой памятной задаче, которую он делал. А самые запоминающиеся задачи это как правило самые сложные и нетривиальные, и по тому что и как человек в итоге расскажет сам о себе, тоже можно сделать какие-то выводы. Но это если дофига свободного времени.
Ну по крайней мере это вот все наиболее эффективные практики, а за 10+ лет я чего только не испробовал.
Другое дело что придумывать хорошие тестовые задачи (а не копипастить их из интернета) тоже еще надо уметь, и с этим проблема, далеко не все это умеют делать как надо (к слову это тоже проверка на вшивость, если сеньор не может составить нормальный блок тестововых задач для соискателей, то значит он не соответсивует занимаемой позиции).
Про код во время интервью. Я пожалуй уточню. В целом, это хорошо, когда быстро и по делу. Но бывает, устраивают дрочева на несколько часов. Не поссать, ни кофе налить 😀
Про то, код во время интервью это прям смешно, конечно. Стоимость false positive гораздо выше, чем false negative.
Попросить реализовать какую-то максимально простую штуку в конце интервью помогает гораздо лучше, чем очередная пачка шаблонных вопросов. Обычно даже не требуется, чтобы она собиралась.
При желании, кстати, вопросами можно закопаться так глубоко, что просьба реализовать какую потоко-безопасную очередь покажется просто раем. (Я хз, что там модно в Unity сейчас. Я смотрел на него, в основном, через IDA, ILDasm и исходники самого движка. Просто привел пример, который заменяет собой 333 вопроса)
Лет эдак 7 назад я, например, завалился именно на этой части, хотя там требовалась на выходе готовая утилита. И отлично понимаю, почему меня не взяли. Вместо того, чтобы написать за полчаса в лоб - я изобрел длинное сложное решение, которое тупо не нужно было для поставленной задачи.
Попросить реализовать какую-то максимально простую штуку в конце интервью помогает
Увы, но это не помогает ¯\_(ツ)_/¯
Я хз, может у Вас просто какая-то зверская интуция, но я таким вещам не доверяю :-)
Более того, по моим наблюдениям техдрочево и лайвкодинг используется в 2 случаях:
А) Народ сам не знает чего хочет, но краем уха слышал про лайвкодинг.
Б) Максимально по возможности снизить самооценку соискателю, сбить его цену, ну а заодно оценить сколько на нем можно ездить.
Стоимость false positive гораздо выше, чем false negative.
Именно поэтому лайв-кодинг на собеседовании и есть бесполезное дрочево и нецелесообразная трата времени. Никакой корреляции между лайв-кодингом и рабочими скиллами потом не обнаруживается.
А если надо действительно как-то объективно оценить скиллы человека, а заодно быстро отсеить лишних, то всего-то нужно отправлять соискателям тестовые задания на дом.
Во-первых, часть народа еще на этапе получения тестового задания самоотсеятся. Всегда какой-то процент соискателей отваливается увидев тестовое задание (в перевую очередь поофессиональные ходоки по собесам), а это уже экономия времени. К слову это еще и поможет самим соискателям оценить туда ли они вообще идут или нет.
Во-вторых, среди тех кто все-таки тестовое задание осилил, будет уже хорошо видно какой у человека стиль программирования, откуда он привык копипастить код и каким образом он вообще подходит к решению конкретной задачи в нормальной обстановке. А именно это всем и нужно.
Ну а затем уже на техсобеседовании можно будет подробно обсудить решение тестового задания, и там уже сразу будет видно насколько хорошо человек в принципе в технической части ориентируется и как поддерживает предметный разговор.
В конце-концов можно будет сравнить решения (и подходы) разных людей. Сделанный человеком за пару вечеров небольшой проект говорит о нем куда лучше, чем его ответы во время дрочево-собеседования, т.к. IRL никто не работает в режиме лайв-кодинг и глупых вопросов. А вот решение какой-нибудь простенькой задачки на собеседовании за короткое время будет говорить только о том, что соискатель наверное умеет решать примитивные задачи за ограниченное время. В реальной же жизни человек на работе получает таску и пилит ее сам по себе какое-то время, и каждый может пилить по разному. На митингах все тоже будут обсуждать конкретные вопросы по проекту, а не пузырьковую сортировку, очереди и заполнение матрицы змейкой. Если надо оценить соискателя, то оценивание должно быть все же приближенным к реальным условиям.
Прохождение отбора через тестовые проекты можно хорошо формализовать, а такие вещи хорошо автоматизируются. А вроде как любая IT компания должна стремиться к автоматизации всего и всея, дабы сократить издержки, а не дергать рэндомных инженеров чтобы они на тех-интервью задавали рэндомные вопросы, получали на них рэндомные ответы, а потом давали рэндомную оценку соискателю.
В конце-концов по тестовому проекту потом и развернутый фидбэк легко написать.
Ещё как вариант это попросить человека рассказать о самой памятной задаче, которую он делал. А самые запоминающиеся задачи это как правило самые сложные и нетривиальные, и по тому что и как человек в итоге расскажет сам о себе, тоже можно сделать какие-то выводы. Но это если дофига свободного времени.
Ну по крайней мере это вот все наиболее эффективные практики, а за 10+ лет я чего только не испробовал.
Другое дело что придумывать хорошие тестовые задачи (а не копипастить их из интернета) тоже еще надо уметь, и с этим проблема, далеко не все это умеют делать как надо (к слову это тоже проверка на вшивость, если сеньор не может составить нормальный блок тестововых задач для соискателей, то значит он не соответсивует занимаемой позиции).
Про код во время интервью. Я пожалуй уточню. В целом, это хорошо, когда быстро и по делу. Но бывает, устраивают дрочева на несколько часов. Не поссать, ни кофе налить 😀
Интересный опыт - даешь статью :D