Как устроены собеседования в SberDevices — Максим Сидоров

Второе интервью с Максимом Сидоровым из SberDevices, в котором он рассказывает про процесс собеседований в компании.

Ты проводишь довольно много собеседований, сколько всего ты их уже провел?

Сложно посчитать, но думаю что за цифру 500 я уже давно перевалил. В среднем около 100 в год.

Недавно был случай, когда собес начался с фразы «И снова здравствуйте» :). Оказалось, что кандидат уже третий раз на моем собесе. Это мой личный рекорд.

Вообще, в последнее время довольно часто стали попадаться разработчики, которых я уже собеседовал несколько лет назад. Тесен круг мобильной разработки :).

Расскажи, как проходят собеседования в SberDevices?

В SberDevices это три отдельные, часовые секции. Первая по Android, вторая по Java + Kotlin и третья по архитектуре.

В целом, есть общие рекомендации, как проводить собес.

Короткое знакомство, можно немного пошутить, чтобы снять напряжение и расположить к себе кандидата.

Далее есть набор обязательных тем, по которым нужно задавать вопросы и понимание которых важно абсолютно для всех проектов. Это структуры данных, многопоточность, дженерики, DI, фрагменты, жизненные циклы и другие базовые вещи.

Есть специфические темы, которые важны для конкретных проектов. Например, в мою команду мы дополнительно спрашиваем про архитектуру Android, про пермишены, про работу в фоне, про какие-то системные вещи.

Самое главное, это стараться не задавать избитые вопросы. Вопросы должны быть интересными и должны раскрывать знание кандидата по этой теме.

Основной упор делается не на знание фреймворков и не на широту знаний кандидата. А на знание основ и базы. Хороший кандидат легко освоит любой фреймворк, когда это станет необходимо для работы. А вот без знания и понимания основ он просто не станет хорошим специалистом.

Есть ли Leetcod-инг и алгоритмы? Насколько они важны?

Да, обязательно. На каждой секции кандидат решает задачу и на это отводится примерно треть времени от всей секции.

Объясню, почему это важно. Теоретические вопросы позволяют оценить только уровень знаний кандидата. А написание кода помогает понять, как он их применяет в реальной работе. Понять, как он думает, как оценивает сложность алгоритмов и как применяет структуры данных. Видит ли он корнер кейсы. Тут важно абсолютно все. Важно даже как он именует переменные в коде. Насколько читаемый и понятный код пишет кандидат.

Мы стараемся не давать каких то сложных алгоритмических задач. Все задачи достаточно простые. Но нам важно оценить, как кандидат пишет код и как он думает. Он может даже не решить задачу, но если мы видим, что он пишет хороший код, предлагает интересные идеи, то эта задача ему зачтется.

Почему-то абсолютное большинство кандидатов боится решать задачи. Все думают, что им сейчас придется писать алгоритм сортировки массива или обход графа. Опять же, необходимость писать код в текстовом редакторе, без привычных подсказок Студии, добавляет свою долю стресса.

Тут важно подбодрить кандидата, помочь ему справиться со стрессом, расслабить его. Чтобы он начал думать о коде и алгоритме, а не о том, что его оценивают и записывают каждую его ошибку. Здесь очень важно помогать кандидату. Сыграть в игру парного программирования. Создать иллюзию, что вы вместе решаете задачу. Ты задаешь наводящие вопросы и помогаешь с синтаксисом, а кандидат думает об алгоритме и о том, как сделать его эффективным.

А ты изучал как устроены собесы в других компаниях?

Да, конечно. Я интересуюсь этой темой уже давно и пару лет назад я специально прошел собесы и получил офферы во все крупные компании-конкуренты.

Меня интересовали их мотивационные схемы, процессы найма и, самое главное, как у них устроены технические интервью.

В целом все компании можно разбить на две большие группы:

• Компании, в которых видно, что они занимаются организацией процессов проведения интервью. Как правило, это крупные компании. Скорее всего здесь не будет избитых вопросов. Обязательно будет решение задач. И в таких компаниях стараются понять именно глубину твоих знаний, а не кругозор. Проходить интервью в таких компаниях интересно и ты часто узнаешь что-то новое. Обычно в таких компаниях минимум две технические секции, но бывает и до четырех для сильных кандидатов.
• Компании, в которых технические интервью отданы на откуп разработчикам. По ним видно, что никто не занимается организацией технических интервью как процессом. В таких компаниях задают достаточно избитые вопросы и ждут простых ответов. Например: Как устроен хешмап, разница между LinkedList и ArrayList, Handler, типы ссылок в Java. Это все избитые вопросы из списков топ Х вопросов для собеседований Android разработчика.

Я одно время даже тролил таких интервьюеров и отвечал вопросом на вопрос, причем мой встречный вопрос показывал мое знание темы. И очень часто интервьюер уже сам не мог ответить на мой встречный вопрос.

Не хочу называть здесь компании из плохого списка. Но в нем есть много достаточно крупных и известных компаний.

Скажу лишь про хорошие примеры. Мне нравится подход Яндекса, и я считаю их модель процесса технических интервью близкой к идеалу. И мой абсолютный лидер в этом исследовании — это компания Авито. Ни в одной другой компании мне не задавали таких технически сложных и глубоких вопросов. Может быть мне просто повезло с Авито, потому что на двух секциях из трех меня собесил известный всем Сергей Боиштян, и у нас с ним даже был небольшой батл по Kotlin и Android.

И, кстати, я позаимствовал в Авито свою самую любимую задачу на кодинг, которую теперь часто задаю на собеседованиях. Спасибо им за это.

Вообще, нет ничего хуже, чем начать задавать сеньору глупые вопросы. Кандидаты ведь тоже оценивают компанию. И они оценивают ее не только по деньгам и плюшкам, но и по уровню технических специалистов. Сможет ли он расти в этой компании, есть ли здесь люди, у которых он может чему-то научиться.

Когда он видит на интервью откровенно слабого интервьюера, то это очень плохо для компании, и скорее всего она потеряет сильного кандидата.

И еще хочу добавить. Мне очень часто после интервью говорят спасибо именно за необычные вопросы. За возможность взглянуть на, казалось бы, типовые вещи под другим углом. Это цепляет кандидатов и я думаю именно этим мне удалось заманить к нам довольно много сильных разработчиков. Многие из которых намного круче меня самого.

Как у вас устроен конвейер работы с кандидатами? Кто оценивает резюме? Как выделиться?

Есть канал, в который HR скидывает резюме кандидатов. Их отсматривают опытные разработчики, входящие в Hire комитет.

Если резюме нравится эксперту, он ставит плюс, если не нравится, то ставит минус и пишет почему. Если минусы никто не опротестовал, то резюме с минусами не проходят дальше по потоку.

Если эксперт видит в потоке потенциальную звезду, то тогда он ставит на резюме «*» и этот кандидат попадает в поток CITO:

CITO – это как в медицине, нужно срочное техническое интервью.

Такие кандидаты продвигаются по потоку максимально быстро. Все интервью назначаются им вне очереди. И на интервью с ними ставят только экспертов.

Как выделится:

• Обязательно указывайте в резюме, что именно вы делали на проекте. Но никогда не пишите воду и общие фразы типа «исправлял баги», «разрабатывал фичи». Пишите только значимые и конкретные вещи, если они есть. Например, разработал модуль профиля клиента или работал в платформенной команде, отвечал за разработку модуля аналитики.
• Указывайте основной технологический стек по проектам, но без воды. Это помогает оценить, насколько кандидат матчится со стеком, принятым в компании. Помогает оценить его опыт и знание альтернативных технологических стеков. Например, опыт работы с Protobuf, GraphQL, Json API, WebSocket.
• Еще важно иметь опыт работы на нескольких проектах и не прыгать по проектам каждый год, а работать на каждом проекте хотя бы 2-3 года. Компаниям важна лояльность, и если человек часто меняет работу, то это звоночек, что что-то с ним не так. Если у вас есть короткие интервалы или большие перерывы, то укажите причину. Иначе скорее всего ваше резюме заминусуют.
• Очень важно иметь в резюме опыт работы в крупных IT-компаниях. Кандидаты, работавшие сразу в нескольких крупных компаниях, вроде Сбера, Яндекса, VK, Авито, Касперского и Тинькофф, обычно попадают в поток CITO.
• Если у вас есть какие-то значимые достижения в виде известных проектов, докладов, исследований или разработанных фреймворков. Это обязательно надо указывать в резюме. Это выделяет вас из основной массы и на это обращают внимание при просмотре резюме.

Как подготовиться к собеседованию и стоит ли вообще готовиться?

Я могу дать один отличный вредный совет, который позволит вам относительно легко пройти собеседование в 90% компаний. В интернете полно статей из разряда «Топ 100 популярных вопросов на собеседованиях по Android». Достаточно прочитать и по возможности заучить их все. Вы гарантированно пройдете собеседование в большинство компаний, а возможно, даже узнаете что-то новое.

Но этот способ скорее всего не поможет вам пройти собеседование в такие компании, как Сбер, Яндекс, Авито, Касперский, Тинькофф. Потому что в крупных компаниях, как правило, оценивают не поверхностные знания ответов, а знание основ.

Хороший способ прокачать скилы — попробовать на каждый вопрос из списка Топ-100 спросить себя, а почему задают этот вопрос.

Почему он важен и входит в этот список топовых вопросов. И когда вы найдете ответ, то, скорее всего, у вас появятся знания целой темы, а не только ответ на конкретный вопрос.

Приведу пример такого вопроса. Он очень хорошо показывает разницу в подходах к собеседованиям в крупных и обычных компаниях.

На всех собесах задают глупый, но популярный вопрос:

Назовите основные компоненты Android.

Абсолютно все знают ответ на этот вопрос. К сожалению, ответ на этот вопрос не дает нам абсолютно никакой информации о знаниях кандидата. Но когда я изменяю форму этого вопроса и задаю его вот так:

А почему Activity, Service, Receiver и Content Provider называют основными компонентами Android?

то большинство кандидатов садятся в лужу. Они не знают почему и даже не задумываются об этом. Очень редкие кандидаты говорят о том, что это точки входа в приложение.

Ну а если серьезно то для подготовки к собесу я бы рекомендовал следующее:

• Изучить все основные структуры данных и для каждой структуры понять ее ключевые плюсы и минусы. Понять в каких кейсах используется эта структура и какие задачи она решает.
• Изучить принципы SOLID. Я почти никогда их не спрашиваю, но в 90% случаев вас спросят о них на реальных собеседованиях.
• Почитать книжку про Kotlin, например «Kotlin in action«.
• Почитать документацию. Там можно найти много всего интересного.
• Почитать и поэкспериментировать с корутинами.
• Почитать и поэкспериментировать с основными DI-фреймворками.
• Почитать популярные вопросы с собеседований на Android. На самом деле из ответов на них можно узнать много нового и полезного. Но только надо читать их правильно. Не с целью заучить ответы, а с целью узнать что-то новое и интересное.
• Изучить базовые принципы многопоточности: synchronized, volatile, блокировки. Это пожалуй самая сложная часть, потому что информации мало, а тема очень сложная и объемная. Если вы не претендуете на позицию сеньора, то можно даже не начинать.

Я, кстати, планирую сделать доклад на эту тему, потому что вижу, что большинство опытных Android-разработчиков плохо понимают базовые принципы многопоточности.

Например 90-95% разработчиков не знают, зачем нужна синхронизация. Как бы парадоксально это не звучало, но это реально так.

Все рассказывают мне про монитор объекта и блокировки потоков, но суть синхронизации совсем не в этом.

И, конечно, тренироваться решать задачки на Leetcode.

Вы можете встретить на Leetcode очень сложные задачи. Например, я сам недавно решал задачу с Leetcode целую неделю. Я потратил на ее решение примерно 15-20 часов и уверен, что любой другой, кто не занимался олимпиадным программированием, потратил бы на нее не меньше.

Но на реальных собесах вы не встретите таких задач. У задач на собесах совсем другие цели и, как правило, на реальных собесах дают задачи только легкого уровня.

Достаточно решить 20-30 легких задач на Leetcode и вы скорее всего без проблем пройдете секцию на кодинг в любой компании.

Не надо бояться программирования. Надо просто немного натренировать навык. Большинство алгоритмических задач похожи и решаются по единым принципам. Все эти задачи на анаграммы и векторы, по сути, сводятся к типовым ходам с использованием HashMap и однопроходных циклов.

И еще очень важно на секции кодинга рассуждать вслух. Не просто писать код, а комментировать свои мысли, обсуждать идеи и решения. Очень часто бывают ситуации, когда кандидат молча пишет какой-то код и интервьюер не сразу понимает по коду, что кандидат идет по неверному пути. Если бы кандидат рассуждал вслух, то интервьюер мог бы раньше направить его в верном направлении.

Как вы оцениваете софтскилы?

На технических собеседованиях мы, как правило, не оцениваем софтскилы. Этим обычно занимаются HR на входе и нанимающие менеджеры на финалах. Наша задача оценить технический потенциал кандидата.

Но, конечно, мы записываем в протокол отметки, если возникают трудности или нюансы в общении с кандидатом.

Для меня самый главный софтскил кандидата — это его увлеченность программированием.

Когда я вижу блеск у него в глазах, когда я помогаю ему своим вопросом вскрыть пробел в его знаниях и понимании какого-то вопроса. Когда я вижу у него интерес к знаниям, интерес к пониманию того, как система устроена под капотом. Это очень важный фактор для меня и я обязательно отмечаю это в протоколе собеседования.

Еще один важный для меня критерий — это умение кандидата рассказать о своей работе. Например, я почти всегда начинаю интервью с вопроса:

Расскажи о необычных задачах, с которыми ты сталкивался.

Очень немногие кандидаты могут рассказать что-то в ответ. Хотя я считаю, что любая, даже самая типовая задача, может быть интересной. Например, ты можешь годами пилить модули по чистой архитектуре, монотонно копируя шаблонный код, а можешь написать плагин, который автоматизирует эту рутину. И если человек сталкивался в своей работе с необычными задачами, а тем более, если он сам делал их необычными, то это очень важный показатель.

Если уже решал эту задачу, стоит ли говорить?

Сложный моральный вопрос :). Я считаю что да, стоит. Честность тебе в любом случае зачтется и это отметят в протоколе.

Опытный интервьюер скорее всего все равно это поймет и отметит это в протоколе как минус, либо тебе надо быть очень хорошим актером, чтобы достоверно изобразить муки поиска решения.

Когда мне говорят, что уже решали эту задачу, я обычно предлагаю решить ее снова. Потому что хорошую задачу можно решать разными способами. И ее можно усложнять, вводя дополнительные критерии или немного меняя условие задачи.

Могу рассказать интересный пример, когда я взял и изменил принципы работы виртуальной машины в рамках одной задачи. Кандидат уже решал эту задачу и это было видно. Тогда я ввел новое искусственное правило в JMM, касающееся volatile, и привычная задача вдруг засияла новыми красками :).

В конце концов, нам ведь важно не само решение, а процесс. Как ты пишешь код, видишь ли ты граничные условия, обрабатываешь ли ошибки. Насколько эффективно ты решаешь задачу.

Кто и как оценивает результаты? Что больше всего влияет на принятие решения?

В SberDevices несколько секций, поэтому по итогам каждой секции интервьюер фиксирует в протоколе уровень кандидата и свою отметку hire/ hire?/no hire.

Дальше, когда кандидат проходит все секции, результаты протоколов попадают на hire комитет, и там уже принимается финальное решение о найме.

Вообще, принятие решения по кандидату – это сложный процесс. У тебя есть много факторов, ты видишь ответы на вопросы по разным темам. Видишь сильные и слабые стороны. Ты думаешь, важно ли то, что кандидат не знает в чем профит inline функций, или важнее то, что он отлично рассказал про делегаты свойств.

Меня часто спрашивают, как понять, какое решение принять по кандидату? Мой ответ очень простой.

Спроси себя, готов ли ты взять его к себе в команду? Готов ли ты прямо сейчас нанять его, если бы у тебя была ставка. Ответ на этот вопрос и должен стать твоим решением.

Лично для меня самым важным критерием является интерес кандидата к программированию, его желание учится и развиваться. Желание разбираться в системе и в том, как все устроено. Это обязательно должно быть подкреплено более глубокими знаниями по нескольким темам. Кандидат может не знать все, но какие-то темы он должен знать глубоко. И если я вижу это в кандидате, то как правило принимаю положительное решение.

Были ли какие-нибудь занятные случаи?

Был один смешной случай. Я начал интервью и как-то так получилось, что кандидат не смог ответить ни на один из первых пяти вопросов. После этого он сам предложил закончить интервью. Когда я спросил его, почему он хочет закончить, он ответил «Потому что ты токсичный».

Еще однажды мне попался очень опытный сеньор, и мы так увлеклись беседой о программировании и о каких-то нюансах и оптимизациях java, что совсем забыли о времени. Собес был вечерний, начался в шесть вечера и продлился 3 часа. Под конец это уже был не собес, а скорее дружеская беседа. Мы уже никуда не торопились и просто общались. И вот когда мы в целом закончили и начали прощаться, то вдруг раздался голос с небес «Уф, ну наконец то вы закончили». Это был HR менеджер. Мы совсем забыли про нее. Оказалась, что она по долгу службы все это время тихонько сидела на собесе и слушала нашу беседу). Представляю ее проклятия на наши головы «когда же вы уже наговоритесь» :).

Есть ли у вас внутренние интервью, например, при повышении грейдов? Как происходит рост?

В SberDevices нет. Мы смотрим скорее на фактические достижения разработчика. Насколько сложные фичи он делает, предлагает ли улучшения системы, как он участвует в комьюнити и процессах разработки. Помогает ли он другим разработчикам. Насколько большую пользу он приносит комьюнити и компании.

Мне кажется, рост компетенций разработчика может происходить по-разному и в разных областях. Важно как он реализует эти компетенции, важно что он делает и оценивать надо именно это.

Объясню, почему я считаю, что повышение грейда через внутреннее интервью – это плохая практика.

Мы оцениваем кандидатов через интервью, потому что мы ничего не знаем про кандидата. На входе кандидат для нас — это кот в мешке, и нам надо за 1-2 часа понять, хотим ли мы его нанять.

В случае сотрудника, у нас на порядок больше информации. Мы знаем как он перформит, какой у него технический уровень. Знаем все его сильные и слабые стороны. В конце концов мы можем открыть его пул-реквесты и посмотреть, какой код он пишет. Так зачем тогда нам интервью, если мы и так все знаем про нашего разработчика.