Что заменит алгособесы?
Он много раз проходил интервью, наблюдал за рынком, собирал чужой опыт и, когда строил уже свои собеседования, решил отказаться от «алгосов». Потому что сделал вывод — если ты решаешь алгоритмы на интервью, это доказывает, что ты умеешь их решать на интервью, но не показывает, как ты будешь работать.
Поговорили с Денисом Аникиным, техническим руководителем крупной компании, лидером сообщества питонистов и спикером VTT#32, и узнали, какие альтернативные инструменты можно использовать, чтобы понять, подходит человек на должность или нет.
Тестовые дни
Этап отбора на работу, когда человек приходит на несколько дней в компанию, чтобы выполнять реальные задачи. Это подход, который может дать более понятную картину не только для тех, кто нанимает, но и для того, кто претендует на должность. Лучший способ проверить, как человек работает, — это дать ему поработать. Тестовые дни практикуют некоторые компании, но пока это не самый популярный способ найма, хотя, на мой взгляд, самый эффективный.
Устное техническое интервью
Оно должно быть чётко структурировано по отделам. Важно пообщаться с человеком на все ключевые темы, которыми занимаетесь, и избегать слишком теоретических вопросов. Например, вместо просьбы назвать все виды типизации лучше уточнить, как утиная типизация проявляется в Python. Или вместо «Как устроен паттерн CQRS» — «Как ты его внедрял?». Часто в LLM содержатся довольно теоретические знания, а практические нередко вообще в интернете отсутствуют, а значит, как следствие, отсутствуют и в LLM.
Практические задачи
Их тоже можно давать, но лучше разбирать их устно, а не в формате лайвкодинга или тестового задания. Лайвкодинг плох тем, что более 60 процентов людей очень сильно стрессуют и только поэтому проваливают собеседование. Кто из нас в обычной жизни пишет код под присмотром? Поэтому хороший вариант — обсудить с человеком, как бы он решал задачи, что бы применял и как оптимизировал.
Код-ревью (code review)
Люди привыкли, что на код-ревью происходит конфликт программистов друг с другом, привыкли в этих обстоятельствах отстаивать своё мнение и спорить. Поэтому можно дать заготовленный кусочек кода и разобрать с человеком, какие ошибки он здесь видит. Да, это не всем нравится, но это рабочий формат. Не стоит от человека ожидать идеальное попадание в ваши внутренние стандарты, но если человек видит многие ошибки на ревью, это хороший признак.
Тестовые задания
По ним действительно что-то можно увидеть. Но, во-первых, мы не знаем, кто их делал. Во-вторых, на тестовые задания ни у кого нет времени. Ни у проверяющих, ни у делающих. Потому что первым нужно проверить целый вал ответов и дать какой-то фидбэк каждому, а те, кто выполняет эти задания, обычно тоже работают. Им просто некогда разбираться с большими задачами. А с маленькими справляется LLM’ка. Да, тестовые задания можно давать, но я бы не стал их использовать.
GitHub-профиль
Если человек регулярно делает какие-то опенсорс-проекты, да ещё и популярные, это уже само по себе хорошая рекомендация. Но иногда бывает комично: просишь, чтобы тебе прислали ссылку на GitHub-профиль, а оказывается, что он пустой, хотя и создан 10 лет назад. По таким профилям можно судить, что человек умеет создавать учётную запись.
Личный бренд
Если человек контрибьютит в профессиональные конференции, митапы и другие хардовые форматы, то это тоже неплохой признак.