Как показала практика, многие не понимают, зачем компании так делают. Я и сам долгое время не принимал эту модель собеседований, но со временем немного изменил свое понимание этого вопроса. В этой статье я выскажу свое мнение, почему так происходит.
На таких интервью чаще всего предлагают решить несколько задач на любом удобном Вам языке. Если формат собеседования удаленный, то могут использоваться такие платформы как HackerRank, LeetCode. Если же вы встречаетесь очно, то вас могут попросить написать код на бумажке или даже на доске.
Вполне логично после общения с компанией могут возникнуть такие мысли:
Я - высококлассный специалист! Более того, я отлично подхожу под описанную вакансию, и имею многолетний успешный опыт работы в той же области! Но им это все не важно, они просто попросили на листке бумажки решить алгоритмическую задачу, и я завалил собеседование, потому что решил ее не оптимально! Но ведь за столько лет работы мне ни разу не понадобился навык решения сложных алгоритмических проблем, а здесь они делают вывод ТОЛЬКО на этом основании!
Знакомо?
Попробуем разобраться, зачем и почему некоторые компании считают по-другому.
Встанем на место компаний
Представьте, что Вы - Google. И у вас много-много-проектов. Большинство из них написаны на C++. Это значит, что в Ваш офис в Цюрихе вам нужно непрерывно нанимать много С++ разработчиков, возможно, тысячи. Как Вы понимаете, на рынке столько разработчиков просто НЕТ.
Что делать? Нужно нанимать по другому критерию, а потом уже учить С++ и остальным необходимым технологиям. По какому критерию?
Можно попробовать нанимать сильных специалистов по другим языкам: Java, Python, Ruby, Rust и т.д. Довольно логично: если человек глубоко и хорошо освоил один язык программирования, то он способен так же освоить и другой.
А собеседовать будет кто?
А кто тогда будет проводить собеседования по всем этим языкам? Где в компании найти этих специалистов? Здесь люди занимаются по большей части С++. Те языки, которыми эти специалисты занимались раньше, имеют свойство забываться.
А технологии?
Я немного упростил модель. Конечно, даже в Google используется не один язык, а много разных. Да и С++ - это распространенный язык, на котором пишут множество специалистов.
Но работать то приходится не только с языком, а с системами, фреймворками библиотеками... То есть от кандидата требуется знание не только языка, но и еще каких-то технологий.
В том же Google большинство технологий - тоже свои, внутренние! Значит, спрашивать про технологии тоже смысла нет. Вы могли всю свою карьеру работать с Big Data и использовать Hadoop, или писать сайты на Ruby On Rails. Но у гугла хадупа нет! Да и "рельсов", наверно, тоже!
И как тогда проводить собеседования специалистов по разным направлениям?
"Мы нанимаем инженеров, а не узких специалистов!"
Кажется, мы и пришли к тому, что вариантов осталось не так много. И многие компании склоняются к тому, чтобы давать Вам алгоритмические задачи на собеседовании.
Если обратить внимание, то к такому виду интервью обычно склоняются большие компании: Google, Facebook (Meta), Amazon, Apple. В России - Yandex. Компании поменьше часто собеседуют "адекватно", индивидуально под конкретную позицию.
Я попробовал выделить несколько плюсов такого подхода:
- "Унификация" процесса собеседования. Организовывать интервью проще: в компании есть "алгоритмическая" культура. Ясны и понятны критерии приема на работу, легче определить уровень (или, так называемый, "грейд") нанимаемого разработчика
- Алгоритмы - это фундаментальное знание. Многие системы, фрейморки, библиотеки опираются на определенные подходы. Эти подходы, в свою очередь, часто опираются на алгоритмы. Если вы хорошо разбираетесь в алгоритмах, то вы понимаете принцип работы той или иной системы. Понимая принцип работы системы, гораздо проще переключиться на другую систему с той же концепцией. То есть, освоить внутренний фреймворк или систему при работе в компании Google вам не составит труда, ведь Вы уже обладаете фундаментальными знаниями, и нужно только адаптировать их
- В результате найма образуется "пул" универсальных разработчиков. Дальше этот "пул" можно распределять по всем проектам, где нужно усиление, или формирование новой команды.
Итого
Мне кажется, что такое подход к интервью - вынужденная мера. Если бы у компании был большой выбор из разработчиков с опытом на нужном стэке - она бы с удовольствием проводила собеседования, проверяя знания по этим технологиям.
Сейчас развелось такое разнообразие технологий, зачастую решающих одну задачу, что становится все труднее и труднее найти человека с нужным набором скиллов и фреймворков.
- Вы на ангуляре фронт делали? А у нас реакт..
- У нас Flink используется для стриминга. Ой, а вы только Spark Streaming знаете...
- Вижу, Вы использовали Kinesis и Pulsar? Вы нам не подходите, у нас Kafka
- Вы использовали Mercurial, как систему контроля версий? У нас Git, до свидания!
Неужели знание только смежных технологий может быть причиной для отказа?..
Заключение
Скажу честно, мне тоже не очень нравится, когда на собеседовании меня просят только порешать задачки. В то же время я тоже довольно раздражительно отношусь к зацикливанию на конкретную технологию.
Во всем важна "золотая середина". Далеко не все компании(даже большие), как Google, и часто можно попробовать найти много других точек соприкосновения с кандидатом. В конце концов, одна небольшая задачка среди вопросов другого типа тоже может быть полезна!
Если Вам понравилась статья, ставьте лайки и подписывайтесь. Поделитесь в комментариях, как Вы относитесь к таким собеседованиям