Как разработчику готовиться к собеседованиям

Продолжаем разговор с Андреем Белоусом (@tzkt1 в Телеграм) о  поиске работы для мобильных разработчиков.

В прошлой статье мы говорили немного о резюме — что все-таки хотят рекрутеры видеть в нем?

Чаще всего вижу рекомендацию писать как можно больше цифр. Условно, должна быть информация не “работал работу на работе” или, в переводе на язык разработчиков, фиксил баги и писал фичи, а что-то более конкретное. Например, написал алгоритм, улучшивший что-то на 75%, или ускорил build time приложения на 20%, или разработал фичу, увеличивающую прибыль компании на 3%.

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

И даже тот-же багфикс можно преподнести по другому. Не пофиксил 100500 багов, а улучшил crash rate приложения с 95% до 98.60%.

Какие конкретно достижения стоит вписывать в резюме сказать сложно, но можно “оттачивать” своё резюме итерациями.

Отклик на 30 вакансий -> мало звонков от рекрутеров -> скорее всего что-то нужно поменять в резюме.

И так по кругу, пока не получится нужная конверсия.

Также стоит посмотреть образцы «идеальных» или «желаемых» резюме на карьерных сайтах. Вот тут, например, можно посмотреть какое ожидается резюме для рынка США. Еще можно искать открытые резюме людей на нужных рынках и в вашей профессии и смотреть, как оно заполнено у них. Какие шаблоны они используют, какие достижения пишут.

А для понимания, насколько хорошее изначальное резюме есть сервисы анализаторы. Например https://resumeworded.com/ посмотрит ваше резюме и даст ему оценку.

Еще очень рекомендую прочитать этот пост. Это просто кладезь полезной информации по поиску работы.

Есть ли и какова стандартная структура собеседований в иностранных компаниях?

Стандартная структура очень похожа на структуру собеседований в России. Сначала это звонок с рекрутером — чаще всего не технический человек. Вопросы в стиле «Почему хотите поменять работу?», «Сколько денег хотите?». Еще могут быть небольшие технические тесты по чек листу.

Потом серия технических собеседований. В зависимости от компании может быть от 1 (очень редко) до 3-5 (скорее надо быть готовым к этому числу).

В технические этапы могут входить:

• Code review — когда вам дают код и просят провести реальный code review
• Алгоритмические секции — задачки с Leetcode
• Платформенное интервью — вопросы по Android или iOS
• System design — навыки проектирования
• Лайв кодинг приложения — вы вместе с интервьюером за час пытаетесь написать рабочий прототип

В результате этих этапов собеседующие ставят оценки и пишут фидбек — то, насколько они бы рекомендовали нанять кандидата.

А решение уже принимается на последних этапах, в конце обычно есть собеседование с hiring manager — человеком, который непосредственно ищет людей себе в команду.

В больших компаниях, вроде Google или Apple, есть еще этап team matching. Это этап после прохождения всех технических собеседований. На этом этапе собеседования проходят с разными командами, в которых открыта вакансия. И тут выбираешь ты, и выбирают тебя.

Кто обычно проводит разные этапы?

Это могут быть абсолютно разные люди. В больших компаниях это часто случайные люди, у которых в обязанностях есть проведение собеседований. У этих людей просто появляется встреча в календаре “Interview with %username%”, они подключаются и проводят стандартное интервью.

Если это “платформенное” интервью, то есть интервью, на котором будут обсуждаться специфические вопросы по платформе iOS или Android, то тут будет специалисты по платформе.

На других этапах, кодинге (решение задач с Leetcode) или system design секции могут быть разработчики из других сфер.

В маленьких компаниях наоборот, один человек может провести все этапы. Как-то раз у меня было собеседование по платформе, и проводил его CTO компании. Он довольно мало знал про Android с технической точки зрения, но тем не менее вопросы были интересными. Например, «Можно ли сериализовать объект класса в Java в массив байт, передать их на сервер и десериализовать внутри другой JVM».

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

Кто принимает решение? На какого надо произвести впечатление? (например, может ли, утрированно, мнение HR перевесить мнение CTO)

Решение принимается hiring manager’ом на основании того фидбека и оценок, которые поставили остальные интервьюеры.

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

В Google, например, есть Hiring committee, и там даже hiring manager не может сказать финальное «да» кандидату. Чтобы решение было максимально объективным, «да» кандидату должны сказать еще и на этом комитете.

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

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

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

Конечно, другой вопрос, насколько эти задачки помогают в реальной работе, но тем не менее, хочешь работать в условном FAANG — нужно решать Leetcode.

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

В предыдущей статье говорилось про soft скилы и end to end ownership, к каким еще “нетехническим” вопросам стоит готовиться?

Самый главный вопрос, к которому можно подготовится, это «Расскажите о себе?».

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

На втором месте вопрос от интервьюера “Теперь ваша очередь. Может быть у вас есть какие-то вопросы ко мне?”.

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

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

Чаще всего такие вопросы можно пропустить, т.к. спрашивают именно о реальном опыте. Например, как-то раз у меня спросили, “Расскажите о новой фиче, которую вы предложили, проанализировав фидбек пользователей?”. Понятно, что есть вероятность того, что такая ситуация никогда не происходила.

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

Как разнятся собеседования в зависимости от грейда?

На треке IC — individual contributor, к стандартным алгоритмическим и платформенным этапам с ростом грейда добавляются System Design — этап, где проверяется способность проектировать системы, и в зависимости от компании, команды и ожиданий, могут добавить какой-нибудь этап, где проверят менеджерско-лидерские качества.

Если знаешь ответ на вопрос, стоит ли говорить?

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

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

Как подготовиться к собеседованию с точки зрения языка? 

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

Я, например, наработал этот минимальный разговорный уровень посмотрев сериал “Друзья” раз 7. Сначала на русском с английскими субтитрами, потом на английском с русскими, потом на английском с английскими несколько раз. Схема с просмотром любимых ситкомов — рабочая.

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

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

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

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

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

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

По итогу, оказалось, что этот этап я прошел, хотя был на 100% уверен, что будет отказ.