Технические собеседования#
На технических собеседованиях проверяют вашу способность приносить пользу на будущей работе.
Структура технических собеседований#
Технические собеседования в разных компаниях следуют достаточно похожему сценарию. Наиболее типичная структура технического собеседования:
Введение, короткий разговор о вашем опыте. Вопросы про технологии, с которыми вы работали.
Технические вопросы.
Решение задачи или кейса.
Ваши вопросы.
Разговор о вашем опыте как правило проверяет, насколько вы разбираетесь в нужных компании технологиях или подходах. На этом этапе вас спросят о том, какие задачи вы решали, какие приняли решения и почему. Последняя часть очень важна: собеседующему важно увидеть, как выглядит ваш процесс принятия решений.
Технические вопросы это как правило вопросы в закрытой форме про конкретные технологии. Ответы на эти вопросы вы или знаете, или нет. К счастью, они типовые и ответы можно подготовить заранее, так как в интернете полно списков таких вопросов, а собеседующие часто берут вопросы из этих же списков. К тому же эти вопросы обычно не являются главным критерием принятия решения.
Note
Например, для разработчика Python часто встречаются такие:
Что такое декоратор в Python?
Что такое GIL и зачем он нужен?
Какие вы знаете магические методы?
Решение задачи или кейса это самый важный этап собеседования.
Задача это как правило алгоритмическая головоломка. Вам требуется написать код решения под наблюдением интервьюера, без возможности исполнять и “дебажить” код. Интервьюер ожидает, что вы не только решите задачу, но и покажете ход своих рассуждений.
Note
Пример простой задачи: two sum. Дан массив чисел и число. Нужно найти два числа в массиве, которые в сумме дают это число.
Под кейсом я понимаю задачу открытого вида, которая не имеет однозначного решения и требует совместной с собеседующим проработки.
Note
У разработчиков этот типа задач называют system design. Пример задачи: “Как бы вы спроектировали сервис стриминга видео?”
Почему технические собеседования именно такие#
У технических собеседований очень плохая репутация. Люди часто жалуются, что технические собеседования похожи на лотерею, несправедливы и не дают никакой информации о том, как вы будете работать. Каждый рано или поздно встречается с ситуацией, когда он точно подходит на позицию, но заваливает собеседование на какой-то не имеющей отношения задаче. Почему работодатели продолжают делать такие собеседования?
Некоторые типичные вопросы кандидатов:
Зачем нужны алгоритмические задачи не имеющие отношения к работе?
Почему компания просто не может посмотреть, как я пишу код, например на Github?
Почему компания не может просто обсудить мой опыт и понять, что я хороший специалист? Ведь у меня есть резюме, опыт и даже рекомендации.
Дело в том, что очень тяжело оценить технического специалиста за сорок пять минут собеседования. Вот какие ограничения есть у компаний:
В воронке сотни кандидатов, поэтому невозможно тратить на каждого много времени.
Необходимо понять, что человек не только красиво говорит, но и умеет программировать.
Во время собеседования нет времени погружаться в контекст, поэтому очень тяжело рассматривать близкую к реальной работе задачу.
Необходимо собеседовать кандидатов параллельно. Для этого требуется несколько собеседующих. У них могут быть разные подходы, поэтому нужно построить стандартизированный способ оценки кандидатов.
Я много раз пытался придумать более эффективный способ собеседований, чем типичный процесс с алгоритмическими задачами, который одновременно удовлетворяет всем ограничения. И не смог. Если у вас получится, то вы можете сделать революцию в HR. До тех пор мы имеем такие выводы:
Поведенческие собеседования и рассказ о вашем опыте позволяют понять, что вы не лжец и не псих. Так же помогают оценить ваш опыт.
Алгоритмические задачи позволяют проверить навыки программирования, знание подходов к решению задач программиста и наличие общей базовой подготовки в computer science. Да, это не отражает реальной работы, но это лучшее, что есть.
Кейсы позволяют понять вашу способность решать масштабные задачи, вашу степень знакомства с подходами в индустрии.
Таким образом технические собеседования являются тяжелым компромиссом между естественными ограничениями. Ваша задача как кандидата: перестать бороться с действительностью. Бесполезно. Нужно принять правила игры и научиться проходить собеседования. К счастью, это не так трудно, как может показаться.
Как проходить технические собеседования#
Рассказ о своем опыте#
Рассказ на техническом собеседовании отличается от рассказа на поведенческом собеседовании.
Здесь в первую очередь хотят слышать о вашем техническом опыте: с чем работали, какие задачи решали, какие принимали решения и почему. Поэтому вам стоит начать с конца и говорить о том, о чем вы бы хотели поговорить подробнее. Если вы делали сайты на Django то стоит говорить про это. Постарайтесь донести целостный посыл: “вот в чем я хорошо разбираюсь и вот что мне интересно”.
Самое важное: подготовьте свой рассказ заранее.
Note
Вот структура, которой я сам придерживаюсь на данный момент.
Я тимлид ML в компании P, моя команда занимается компьютерным зрением и ML Engineering для фабрик. В текущей компании я построил ML инфраструктуру с нуля.
У меня богатый опыт software engineering, data engineering, а также есть опыт в ML исследованиях. Я и ML делаю, и пишу хороший код.
Я ищу <вставить почему я ищу работу, чем хочу заниматься и куда расти>.
О чем вы хотите услышать подробнее?
Технические вопросы#
Здесь всё решает подготовка. Вопросы скорее всего задаются или исходя из вашего опыта, или исходя из требований вакансии.
Ответы на типичные вопросы, связанные с вашим опытом вам в любом случае, нужно заранее подготовить и выучить.
С требованиями к вакансии сложнее. Перед собеседованием стоит сделать небольшую подготовку, насколько позволяет время: посмотреть на вакансию и подумать, о чем могут спросить. Например, если компании требуется Python разработчик со знаниями Postgres, то стоит как минимум повторить не только вопросы про Python, но и SQL, а также общие принципы работы с базами данных. Вам не нужно становиться экспертом, но сделайте так, чтобы вы могли ответить на базовые вопросы и вас не застали совсем “безоружным.”
Ваша цель: произвести впечатление, что вы понимаете основные принципы всего необходимого, а в деталях сможете разобраться.
Решение алгоритмических задач#
Решение алгоритмических задач — это самый сложный этап собеседования, требующий наибольшей подготовки.
К счастью, можно сильно “прокачать” свой навык просто используя верную структуру ответа. Я предлагаю свой алгоритм решения алгоритмических задач, созданный на основе опыта на обоих сторонах собеседований:
Прочитать условие и задать уточняющие вопросы.
Написать несколько тест кейсов, чтобы ещё раз убедиться, что вы поняли условие. Прямо комментариями в коде берем и пишем тесты в формате “входные данные - ожидаемый результат”. В некоторых компаниях пишет человек тесты или нет даже является одним из критериев оценки.
Проговорить свои наблюдения вслух и спросить у интервьюера, верно ли вы поняли задание и его ограничения. Не страшно, если нет, ведь интервьюеру важно понять, как вы думаете.
Проговорить вслух наивное решение проблемы. Как правило — это полный перебор вариантов. Обозначить его алгоритмическую сложность (чаще всего O(n^2)) и объяснить, почему вам кажется, что можно найти более оптимальное решение. Например, укажите какие вычисления делаются дважды.
Подумать и проговорить оптимальное решение проблемы. Убедиться у интервьюера, что вы нашли верное решение и спросить разрешения приступать к реализации. Только после утвердительного ответа переходить дальше.
Написать код решения.
Проверить код решения, мысленно проверить, выполняются ли все тесты. Исправить ошибки: они точно найдутся.
Сообщить, что решение готово.
Как избежать самых типичных ошибок:
Убедитесь, что вы правильно поняли условие. Много раз на моих собеседованиях кандидат сначала писал код, а в середине собеседования выяснялось, что он не понял условия.
Не бросайтесь сразу писать код. Никогда не пишите код до того, как интервьюер подтвердит, что вы нашли верное решение. Пожалуй, самая частая ошибка — это потратить все время собеседования на реализацию неверного решения.
Не молчите. Не пытайтесь решить задачу в уме. Рассуждайте вслух. Интервьюер вам не враг. Лучше написать решение с подсказкой, чем не написать вообще.
Проверяйте свой код!
🤗 Если этот материал был для вас полезен есть два способа отблагодарить меня:
Прислать ссылку на методичку своему другу.
Подписаться на мой телеграм канал.