Это ответ на статью, что алгоритмические собеседования не нужны. Простите за кликбейтный заголовок, но он такой и там.
Я утверждаю, что алгоритмические интервью - лучший вариант для ФААНГА из всех пока придуманных.
Еще раз акцентирую внимание, что моя статья относится лишь к условному ФААНГУ. Многие аргументы из этой статьи теряют значимость в других случаях: если у вас маленькая фирма, мало кандидатов или у вас всего 10 пользователей, то вам может гораздо лучше подойти какая-то альтернатива.
У ФААНГА есть несколько особенностей:
Очень большое количество кандидатов. Вы проводите очень много интервью.
Найм регулярно ведется из других городов а то и стран с релокацией.
Многие кандидаты хотят попасть в компанию даже не надеясь остаться там надолго. Ради строчки в резюме, ради релокации, ради хотя бы нескольких вкусных зарплат.
Своя внутренняя кухня: там часто используются технологии, не использующиеся снаружи. Зачастую, потому что они появились на несколько лет раньше публичных аналогов.
Огромное количество данных с которыми постоянно что-то надо делать. Поэтому большая часть разработчиков там регулярно действительно решает алгоритмические задачки.
Поэтому, собеседование должно удовлетворять следующим критериям (в порядке важности):
Высокий процент отсева. У вас итак десятки или сотни кандидатов на место. Отсюда вытекают следующие требования:
Собеседование должно быть сложным.
Нужна широкая градация оценок.
Нужно постоянно генерировать новые вопросы/задания. Иначе всякие конторы будут натаскивать кандидатов отвечать на известное множество вопросов.
Низкий false-positive. Тут довольно высока цена ошибки найма. Многие кандидаты релоцируются, зарплаты высокие.
Поэтому еще и важна сложность считерить. Поскольку многие хотят хоть тушкой, хоть чучелом попасть на теплое место, а там как-нибудь просимулировать деятельность какое-то время, если интервью можно обмануть - у вас будет очень много таких умников и false-positive возрастет.
Стандартизируемость и наличие объективных критериев. Когда у вас тысячи интервьюверов по всему миру, вам надо как-то привести все к общему знаменателю. Объективные критерии также необходимы, ибо иначе вас завалят судебными исками. Вроде того, где Гугл обвинили в дискриминации по возрасту за вопрос о количестве бит в байте (мол, во время молодости кандидата и по 40 бит было в байте! Вопрос специально сконструирован для отсечения немолодых кандидатов).
Масштабируемость. У вас тысячи интервьюверов, которые регулярно тратят свое рабочее время на подготовку, проведение и проверку интервью. Поэтому должна быть возможность относительно легко натренировать много собеседующих, а сами собеседования не должны быть очень длинными.
Релевантность. Хочется, чтобы навыки, позволяющие проходить интервью, также позволяли кандидату хорошо работать.
Низкий false-negative. Хорошо бы, чтобы отличные кандидаты не заваливали интервью, потому что, например, оно слишком стрессово, или им не повезло с заданием. Как жестоко это не звучит, но этот критерий - самый последний. С таким количеством кандидатов, можно мириться с тем, что кто-то из них интервью завалит, если метод собеседования удовлетворяет другим критериям лучше.
Алгоритмические интервью, часто прежде всего ругают за релевантность (хотя я с этим не согласен, о чем поговорю ниже), но забывают про все остальные критерии. А они важнее релевантности из-за масштабов ФААНГов.
Вот как на эти критерии ложатся алгоритмические интервью:
Они достаточно сложные. Есть огромная вариация оценок: задачу часто можно решить несколькими способами с разной эффективностью, можно оценить читаемость кода, простоту кода, способность объяснить свое решение, как кандидат свой код проверяет и т.д.
Тут низкий false-positive. Поскольку задачек довольно много, то вряд ли кандидат просто выучил попавшуюся ему задачу. А если кандидат способен, условно говоря, развернуть бинарное дерево, то уж json-ы перекладывать он точно сможет (чем, правда, ему и придется заниматься львиную часть рабочего времени). И код он писать точно может не только случайно меняя исходник, пока оно не заработает.
Так же тут весьма сложно считерить. Видно, если кандидат пытается гуглить или с кем-то консультируется.Тут все стандартизовано и составлены объективные критерии. Кандидат или написал код, или не написал. Видно, работает ли код за O(n log n) или O(2^n). Код может удовлетворять объективным критериям качества: понятные имена, обработка крайних случаев, переусложненность и т.д.
Эти интервью масштабируемы. Проверять их относительно просто. От интервьювера не требуется каких-то очень высоких навыков - много кого можно натренировать их проводить. Они не требуют много времени интервьювера: 45 минут на само интервью и 30 минут написать отчет.
Я утверждаю, что эти собеседования более-менее релевантны.
Начнем с того, что абсолютно все программисты всегда пишут алгоритмы: любой ваш код - это последовательность действий, объясняющая компьютеру, что делать. Даже если вы "джейсоны перекладываете". Иногда это совсем тривиальные алгоритмы, но все же алгоритмы.
Далее, эти интервью в значимой степени проверяют умение мыслить алгоритмически и знание каких-то чуть-чуть нетривиальных структур данных и алгоритмов (стеки, хеш-таблицы, обход графа, бин поиск, динамическое программирование и т.д.). Конечно могут быть индивидуумы, которые довели решение задач до автоматизма не имея этих умений, или им попалась заученная задача, но это очень большая редкость. А эти умения в ФААНГе применяются относительно часто. Я лично коммитил в прод и динамическое программирование, и бинарный поиск по ответу и всякие структуры данных из хитрых стеков или очередей. И на интервью спрашиваю ту задачу, которую лично коммитил. И она на фоне других литкод задач ничем не выделяется.
Часто встречаю мнение, что алгоритмы нужны только разработчикам библиотек и фреймворков, а "инженеры-прикладники" просто используют эти готовые решения. Но в ФААНГах значимая доля разработчиков именно такими библиотеками и занимается! И даже остальные разработчики относительно часто вынуждены писать именно алгоритмы уровня medium литкод задач.
Потом, часто вы можете просто думать, что вам алгоритмы ни разу не понадобились. Если их не знать, то у вас даже не возникнет мысль, что вот тут надо Алгоритм применить. Посмотрите задачки на литкоде: часто они сформулированы в виде "сделаейте вот это и вот это" и можно буквально перевести условие в медленный код. А когда у вас еще и нет сформулированной задачи а лишь баг в треккере, вы сами у себя в голове формулируете "надо сделать вот это и вот это" и делаете это даже не задумываясь, "а может тут хеш-таблицу стоит впендюрить".
Плюс, такие интервью проверяют умение писать код, а это и есть основная работа программиста.
Да, такие интервью не проверяют другие навыки: например, умение проектировать системы, работать в команде или какие-то специфичные знания под проект. Но для этого в ФААНГах проводятся отдельные интервью: system design, behavioral и domain specific knowledge interview.
Еще я встречал аргумент, что такие интервью дают приемущества олимпиадникам. Во-первых, их очень мало, чтобы сильно повлиять на общую популяцию работников в компании. Во-вторых, а чем они хуже? Единственный их минус, с которым я согласен - свежие олимпиадники пишут плохо читаемый олимпиадный код, заточенный под очень быстрое написание. Но в ФААНГах почти везде код-ревью, и этот дефект лечится буквально за 2 недели. Где-то утверждали, что олимпиадники усложняют код на ровном месте, я с этим не согласен. Такое поведение в том числе мешает и олимпиадные задачи писать. Да и код-ревью эту проблему тоже решает.Высокий false-negative - слабое место таких интервью, да. Многие отличные разработчики принципиально отказываются готовиться к таким интервью и заваливают их. Многие слишком стрессуют писать код под присмотром или тупят над задачами.
Это несколько нивелируется правом на ошибку. В гугле, например, аж до 5 алгоритмических секций дается. И если вы одно из них завалите а в другом чуть затупите - это не приговор. В самом интервью прощаются мелкие ошибки вроде опечаток. Никто не требует знания наизусть стандартных функций. Я лично, когда проходил интервью, забыл, что про lower_bound или upper_bound: какой там порядок параметров и что конкретно оно возвращает. Интервьювер разрешил предположить, что мне удобно, и лишь в комментарии написать, что эта функция по моему предположению делает. Интервью я прошел.
Но, как я выше уже говорил, этот критерий - не самый определяющий для ФААНГов. Все еще достаточное количество отличных разработчиков справляются с такими интервью.
А теперь я сравню алгоритмические собеседования с альтернативами, которые люди предлагали в комментариях к разным статьям:
Испытательный срок. На мой взгляд, почти по всем критериям этот метод сильно лучше алгоритмов. Это вообще самый релевантный метод почти без ошибок. Но он физически невозможен в ФААНГах. Критерий масштабируемости тут на нуле.
Тестовое домашнее задание. Это лучше алгоритмических задачек тем, что оно более приближенно к средней работе, которую надо будет выполнять. Но тут хуже масштабируемость: задания сложнее придумывать, дольше и сложнее проверять. На тестовых заданиях легче читерить. Как только условный гугл введет такие задания, вместо "курсов по подготовке к интервью" появятся конторы по выполнению за вас задания и обучению, что и как говорить, как будто это написали вы. Можно давать его под присмотром, но все-равно это будет занимать слишком много времени интервьювера. Если же его сокращать для масштабируемости, то в итоге или придем к слишком простым заданиям, или тем же литкод-задачам.
Дать задачу из багтрекера. Вроде как испытательный срок на минималках. Но тут проблема в том, что большинство задач в баг-трекере объяснять кандидату будешь только 3 часа. Плюс там все жутко секретное. Если же что-то и можно выделить и абстрагировать, то там будет или та же самая литкод задачка уровня easy и реже medium, или будет что-то большое, что нужно пару часов только ковырять. Да и хороших для интервью задач из багтрекера много не наберешь. Тут сильно хуже масштабируемость. И потом, в ФААНГах своя кухня, свои IDE, свои системы, которые кандидату и за пару дней не объяснишь. Так что особо приблизить условия к боевым все-равно не получится.
Дать кусок кода и попросить исправить в нем ошибку. Такие задачи сильно сложнее придумывать. Такие интервью слишком простые и у них недостаточный процент отсева. Если же задания запутывать специально, то там с релевантностью будет не лучше, чем у алгоритмов. Это не проверяет умение писать новый код, так что false-positive тут выше. Тут хуже с градацией оценок.
Посмотреть github кандидата. Во-первых, это вообще неприменимо к джунам. Да и без этого, у матерых программистов может быть и другое хобби, а рабочий код - под NDA. Во-вторых, тут все плохо со стандартизацией и объективными критериями. И с масштабированием тут хуже. Проверять чужие проекты сильно дольше. Оценить решение задачи гораздо проще, чем въезжать в какой-то чужой проект - пул возможных интервьюверов сильно сужается. Тут очень легко читерить. Уже сейчас есть предложения о github-профиле под ключ. Если условный гугл станет их проверять, это станет очень массовым явлением.
Тест на знание технологии/языка программирования. С технологиями сложно - в ФААНГах своя кухня. С языками - придумать много разных вопросов очень тяжело. Ограниченное количество существующих вопросов будут зазубривать (false-positive). Не проверяет умение писать код (false-positive). Это еще более отдалено от обычной работы программиста. Тут все плохо с отсевом и релевантностью.
"Разговор по душам" о какой-то технологии. Не проверяет, что кандидат может писать код (false-positive). Стандартизация и объективные критерии тут хромают. Потом, в ФААНГах своя внутренняя кухня. А собеседующие не работают с фреймворками, которые знает кандидат. О чем им говорить? О каких-то общих подходах? Тут больше хорошо подвешенный язык будет проверяться, а не навыки кандидата (опять false-positive). Плюс, оценить чьи-то словесные аргументы сильно сложнее - такие интервью только матерые сеньеры смогут проводить. Это плохо масштабируемо.
"Разговор по душам" о старых проектах. Вроде: "расскажите о каком-нибудь интересном проекте из практики". Это неприменимо к джунам. И, как и в предыдущем случае, тут хуже false-positive, стандартизируемость и объективность и масштабируемость.
"Разговор по душам" о выданном куске кода. Не проверяет что кандидат может писать код. Как и в предыдущем случае, тут хуже false-positive, стандартизируемость и объективность и масштабируемость.
"Обсудить задачу из практики интервьювера". Обычно что-то интересное будет сильно большое. Если его абстрагировать и упрощать, или выдмывать, то или получится стандартное system design interview, или те же литкод задачки, но без кодинга. Обсуждать что-то сильно сложнее чем оценивать решение алгоритмической задачки, поэтому тут сужается пул интервьюверов. И такие задачи сложнее придумывать. Как и с остальными интервью с "поговорить" в названии тут хуже false-positive, стандартизируемость и объективность и масштабируемость.
Интервью такого же формата, но задачи не настолько алгоритмические. Тут все будет плохо или с отсевом или масштабируемостью. Если из задач выкинуть все алгоритмы, то они будут слишком просты. Один способ их усложнять - это увеличивать объем кода и тогда станет дольше их проверять. Или можно усложнять размер системы, и тогда интервью выродится в system design и увеличиваются требования к интервьюверам, что тоже снижает масштабируемость.
Есть ли какие-то еще альтернативы? Добро пожаловать в комментарии.
