Комментарии 16
Не понял чем не подходит испытательный срок(естественно после хоть каких-то других шагов типа очного собоеседования и проверки общей адекватности).
Тем, что компании придется искать заново, если кандидат не подходит? Ну так риски они есть, тут без них никак.
Тем, что компании придется искать заново, если кандидат не подходит? Ну так риски они есть, тут без них никак.
Возвращаемся к тому, что набор сотрудников это не автоматизируемый процесс требующий внимательного подхода к каждому кандидату. Если вы большая компания с огромной текучкой и потребностью в конвейерном найме сотрудников. Допустим 12 000 человек из них постоянно уходят приходят человек 100, то надо обработать несколько тысяч чтобы этих 100 отобрать. Прикрепите HR к команде, отделу, подразделению, а не централизируйте аппарат найма сотрудников. Ну или миритесь с издержками и тратами.
Наём сотрудников не заканчивается успешным собеседованием, просто HR передаёт кандидата проджекту или тимлиду для дальнейшего изучения объекта. А там уже будет видно, кто и что умеет, и устраивает ли это команду.
За весь мой опыт найма (он не сильно большой) и работы с нанятыми людьми по известным мне процессам найма (тут побольше), я пришел к выводу, что для очень широкой категории разработчиков (исключая особые случаи типа исследовательской работы, например) лучше всего таки подходит проверка практикой: может ли человек самостоятельно, с приемлемой скоростью и качеством писать код примерно в той области и с помощью тех инструментов, которые нам нужны. Если ответ на этот вопрос «нет» — такой человек никогда не будет полезен команде, вне зависимости от любых других факторов. И если вдруг человека наняли, не попытавшись прояснить это, и столкнувшись с тем, что в рабочих условиях он просто не может писать код или делает это слишком плохо — то исход очень печален, мало того, что человека нужно срочно увольнять (а не всегда это сделать просто), так еще и пока этого не сделали — он не просто не помогает, но еще и мешает.
Ну а чтоб выяснить это, самый лучший способ — это проверить именно это: может ли человек писать код. Дальше уже начинаются компромиссы: покодить на собеседовании было бы прекрасным вариантом, но типичные задачи редко бывают на 30-45 минут (это максимум собственно программирования, который можно уместить в часовое собеседование), а проводить более долгие собеседования — крайне неудобно для кандидатов и крайне дорого для конторы, потому что собеседующий тоже будет отвлечен от своей работы.
Поэтому для проверки инструментария и области — подходят тестовые домашние задания. С ними тоже много проблем, потому что плохо составленное задание — долгое, плохо написанное, и т.д. — будет фильтровать кандидатов нежелательным образом, хорошие разработчики распознают плохое качество раньше, и, будучи востребованными спецами, просто пойдут смотреть другие предложения. Ну и они не проверяют самостоятельность, поэтому даже при наличии тестового FizzBuzz на собеседовании всё равно будет необходим.
Что работает хуже: любые окольные пляски, от экзаменационных вопросов до олимпиадных задач — работает хуже, чем тестовое, примерно похожее на типичные задачи конторы. Например, от деятельности крутых олимпиадников, делающих ужасный overengineering простых задач — я в свое время очень много натерпелся лично, вычищая переусложнения. Обычно после того, как сей олимпиадник таки убежит в свой гугл или подобное, а тебе нужно будет поддерживать оставшийся от него код.
Любые попытки прособеседовать кандидата, не выяснив, может ли он писать код — вообще ужасны: даже если «поговорить за жизнь» в целом скорее работает, чем нет, то найм даже одного человека, прошедшего этот фильтр, но не могущего писать код — выливается потом в существенные проблемы, падение морали, и прочие долговременные сложности. Говорить за жизнь — штука очень хорошая, но вместе с проверкой способности писать код, а не вместо.
Ну а чтоб выяснить это, самый лучший способ — это проверить именно это: может ли человек писать код. Дальше уже начинаются компромиссы: покодить на собеседовании было бы прекрасным вариантом, но типичные задачи редко бывают на 30-45 минут (это максимум собственно программирования, который можно уместить в часовое собеседование), а проводить более долгие собеседования — крайне неудобно для кандидатов и крайне дорого для конторы, потому что собеседующий тоже будет отвлечен от своей работы.
Поэтому для проверки инструментария и области — подходят тестовые домашние задания. С ними тоже много проблем, потому что плохо составленное задание — долгое, плохо написанное, и т.д. — будет фильтровать кандидатов нежелательным образом, хорошие разработчики распознают плохое качество раньше, и, будучи востребованными спецами, просто пойдут смотреть другие предложения. Ну и они не проверяют самостоятельность, поэтому даже при наличии тестового FizzBuzz на собеседовании всё равно будет необходим.
Что работает хуже: любые окольные пляски, от экзаменационных вопросов до олимпиадных задач — работает хуже, чем тестовое, примерно похожее на типичные задачи конторы. Например, от деятельности крутых олимпиадников, делающих ужасный overengineering простых задач — я в свое время очень много натерпелся лично, вычищая переусложнения. Обычно после того, как сей олимпиадник таки убежит в свой гугл или подобное, а тебе нужно будет поддерживать оставшийся от него код.
Любые попытки прособеседовать кандидата, не выяснив, может ли он писать код — вообще ужасны: даже если «поговорить за жизнь» в целом скорее работает, чем нет, то найм даже одного человека, прошедшего этот фильтр, но не могущего писать код — выливается потом в существенные проблемы, падение морали, и прочие долговременные сложности. Говорить за жизнь — штука очень хорошая, но вместе с проверкой способности писать код, а не вместо.
У процесса найма есть две задачи:
1) Нанять хорошего кандидата
2) Не нанять плохого
Обратите внимание, тут нет пункта «нанять всех хороших людей которые пришли и никого не упустить».
Тот же пример с Эйнштейном.Компания обычно пытается минимизировать ошибку первого рода, ложноположительное срабатывание. Разумеется, при этом начинает расти ошибка второго рода — ложноотрицательный результат, т.е. отсеяли годного специалиста, того же Эйнштейна. Ну и что? Что хотели, то и получили — к нам идут только хорошие спецы, а плохие (плюс еще часть хороших) отсеиваются.
Поэтому да, для каждого способа и метрики из статьи можно найти примеры когда она не сработает, просто выбрав ошибку другого рода (не ту, которую минимизирует эта метрика). О чем это говорит? Ни о чем.
Но в итоге отсеянные такими метриками приходят на Хабр и начинают тут изливать свою боль и гнев. Ну ок, обидно когда не взяли. Но метрики и методики-то тут не особо виноваты, они свою работу делают (ну хотя бы пытаются) — просто их работа не в том, чтобы гарантированно взять такого хорошего вас, а в том чтобы гарантированно не взять плохого сотрудника. А вы просто под раздачу попали.
1) Нанять хорошего кандидата
2) Не нанять плохого
Обратите внимание, тут нет пункта «нанять всех хороших людей которые пришли и никого не упустить».
Тот же пример с Эйнштейном.Компания обычно пытается минимизировать ошибку первого рода, ложноположительное срабатывание. Разумеется, при этом начинает расти ошибка второго рода — ложноотрицательный результат, т.е. отсеяли годного специалиста, того же Эйнштейна. Ну и что? Что хотели, то и получили — к нам идут только хорошие спецы, а плохие (плюс еще часть хороших) отсеиваются.
Поэтому да, для каждого способа и метрики из статьи можно найти примеры когда она не сработает, просто выбрав ошибку другого рода (не ту, которую минимизирует эта метрика). О чем это говорит? Ни о чем.
Но в итоге отсеянные такими метриками приходят на Хабр и начинают тут изливать свою боль и гнев. Ну ок, обидно когда не взяли. Но метрики и методики-то тут не особо виноваты, они свою работу делают (ну хотя бы пытаются) — просто их работа не в том, чтобы гарантированно взять такого хорошего вас, а в том чтобы гарантированно не взять плохого сотрудника. А вы просто под раздачу попали.
Под заголовком всегда написано, что перевод, тем не менее, всегда найдется кто-то, кто это не увидит. И даже в самом конце немного написано об авторе. Тоже прошло незамеченным.
Никто ничего не изливает. Это перевод. Автор оригинала поработал в интел, оракл, гугл и амазон. Так что вряд ли он тоже что-то изливал.
Никто ничего не изливает. Это перевод. Автор оригинала поработал в интел, оракл, гугл и амазон. Так что вряд ли он тоже что-то изливал.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ссылку на историю о необходимости иметь опыт строительства коричневых домов. И смешно и грустно.
Эмулирует настоящую работу.
Вот тут ссылка не работает
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наём сотрудников никуда не годится. И ваш тоже