Каким может быть алгоритмическое собеседование и как к нему подготовиться
Всем привет! На связи команда Практикума. Недавно мы проводили открытое алгоритмическое собеседование и теперь хотим поделиться записью. Это отличная возможность подсмотреть, каким может быть процесс, научиться на чужих ошибках или взять на примету удачные решения.
Мы попросили Самсонова Ивана рассказать о его критериях оценки кандидатов, а также поделиться советами по подготовке. На видео Иван выступал в роли тимлида, а в обычной жизни он разработчик со степенью в Computer Science и наставник курса «Алгоритмы и структуры данных».
Хочу сразу подчеркнуть, что я не профессиональный собеседователь. Расскажу именно о своём подходе, которым пользуюсь, когда провожу пробные собеседования в Практикуме.
Обычно до написания кода я прошу проговорить решение вслух. Иногда человеку сложно это сделать без кода перед глазами — для меня это микроминус. Но я нормально отношусь к рисованию на листочке.
Если кандидат сразу озвучивает верный алгоритм, решает без ошибок — оценивать тут нечего. Либо он знал задачу, либо он хорош. Интересны остальные случаи.
Я слушаю рассуждения, но не оцениваю их с точки зрения правильности. Нормально, если сначала человек идёт в неверном направлении — он пока не знает, как решать, и пытается прийти к решению.
Если он сам приходит к нужному алгоритму без подсказки — это огромный плюс.
Если он предлагает неправильный подход, я привожу контрпример, чтобы направить в нужную сторону. Чтобы это сделать, нужно знать задачу очень хорошо, — каюсь, в ролике заметно, что первую задачу я не изучил заранее, поэтому подумал, что у кандидата баг, хотя он решил верно.
Если алгоритм придумать не получилось, я подсказываю, но это уже минус.
Я ожидаю, что кодинг после озвучивания верного алгоритма проблем не вызовет. Прошу также озвучивать все действия вслух. Как правило, проблемы возникают с рекурсией и неверной реализацией известных алгоритмов — это, конечно, минус. Если код идёт совсем не туда, я прерываю и задаю вопросы. В тяжёлых случаях помогаю с кодом (напоминаю, что я провожу пробные собеседования, поэтому стремлюсь к тому, чтобы человек всё же решил задачу, пусть и с помощью).
После написания кода приступаем к самостоятельному поиску ошибок — без запуска. Всегда есть тестовые примеры, на которых можно проверить код. Фатальных ошибок, когда весь алгоритм неверный, быть не может — за этим я слежу на предыдущем этапе. Обычно всё исправляется несколькими символами или строчками.
Я смотрю, как человек проверяет краевые условия и находит ошибки, которые увидел я. Если была найдена ошибка, которую я не заметил, — микроплюс. Тут есть прямая зависимость: если мы решали задачу долго, то у человека иногда не хватает сил внимательно проверить — в итоге ошибок много. Конечно, случается, что код и без ошибок вообще.
Ошибки исправленные в результате проверки — это плюс. Если я указал на одну из проблем, а остальные человек нашёл самостоятельно, то ставлю микроминус за первую, остальные зачитываю. Если исправили правильный алгоритм на неправильный — минус. Всё, что кандидат не нашёл, обговариваем отдельно.
Если собеседующий не заметил баг — значит, бага нет. Кандидату задача зачтена :)
Организация кода, имена переменных — это всё важно, хотя я делаю поправку на временные ограничения и стресс. Комментарии вообще не важны, но если кандидат их делает для себя — без проблем.
Код не запускаем, поэтому, если какие-то библиотеки не подключены и код не скомпилируется, — это не критично. Опечатки (именно опечатки, а не ошибки) я игнорирую, если их число не превышает разумные пределы. Когда наблюдаешь за написанием кода со стороны, достаточно хорошо видно, где опечатка, а где человек действительно не понимает, что он делает.
В задачах, которые я даю, не требуется мастер-теорема для оценки, но некоторые познания в теории сложности алгоритмов нужны. В зависимости от результатов по самой задаче я могу копнуть глубже и попытаться запутать кандидата, если он дал верную оценку. Если кандидат отбивается от моих запутывающих вопросов — это жирный плюс, а если изменил мнение — это микроминус.
По совокупности плюсов и минусов я выношу вердикт: срочно нанимаем, рекомендуем к найму, не рекомендуем к найму, не нанимаем. Например, Павел на открытом собеседовании показал отличный уровень — он допустил баг только в одном месте, в бинарном поиске. Я бы рекомендовал его к найму.
Алгоритмические собеседования в Яндексе: как подготовиться и чего ожидать — советую эту статью, если хотите узнать, как проходит алгоритмическая секция в Яндексе. В конце авторы дают советы по подготовке — последую их примеру.
Советы по подготовке
Много практикуйтесь — для уровня прохождения собеседований углубляться в теорию не обязательно. Теория должна идти «по требованию»: получил базовую — идёшь решать, увидел незнакомые подходы — изучил — снова за практику. Главная цель — набрать достаточный набор структур данных и алгоритмов, научиться понимать, на какой алгоритм конкретная задача.
Не суметь решить какую-то задачу на собеседовании — это нормально. Время ограничено, иногда просто не везёт. Я считаю, на 100 задач среднего уровня, нужно уметь решать 75 в стрессовых условиях, а 95 — дома на диване.
Начните решать задачи с лёгкой ступени и быстро шагайте выше, если всё даётся легко. Если нет идей, подсмотрите решение. Если идеи есть, но что-то не идёт, отложите и вернитесь к задаче позже. У LeetCode есть три уровня сложности, а у Codeforces их гораздо больше — можно отсортировать и спокойно решать в своём темпе.
Не пишите код в блокноте — пользуйтесь IDE. Если очень хочется, отключите автодополнение и убедитесь, что помните основные методы и объекты вашего языка. Если возник баг, попытайтесь найти его без отладки, если не получается — отлаживайте.
Начинайте приходить в форму заранее, если планируете сменить работу. Вспоминайте, что забылось, решайте по чуть-чуть каждый день и побольше на выходных. Сходите на пару собеседований в малоинтересные конторы, чтобы выйти на важное собеседование в форме.
Habrahabr.ru прочитано 2810 раз
