Connect with us

Разработка

Ответ на интервью, который стоил мне работы в 314+ тысяч долларов

Опубликовано

/

     
     

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

Рекрутер описала пакета так:

  • Годовая зарплата 150 тыс. евро (Зарплата составляет 100 тыс. евро, однако в ЕС работодатель заботится и о медицинской страховке. Он обещал ее для всей моей семьи. Кроме того, есть месячные каникулы в сочетании с отпускными бонусами)
  • Опционы на акции на 170 тысяч евро на 4 года

Если я суммирую эти цифры за 4 года и предположу, что акции вырастут в 3 раза по сравнению с их текущей стоимостью, общая сумма составит около 1.1 миллиона евро. Обратите внимание, что 3x является наиболее консервативной оценкой, поскольку он достиг 1,5x только за последние 4 месяца в условиях мировой экономики, пораженной COVID.

Если разделить на 4, то получится около 277 тысяч евро (314 тысяч долларов).

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

Важно понимать, по какой схеме они действуют.

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

Звонок рекрутера

Это был краткий и предметный разговор.

Рекрутер проинформировал меня о вакансии. Затем он спросил меня о моем опыте. Я резюмировал все технологии, с которыми я работал, которые имели отношение к роли.

Он был рад узнать, что я идеально вписываюсь в образ многогранного (Т-образного) разработчика.

Узнав об этом, он раскрыл детали пакета (те, которые я описал выше). Его тон выдавал высокую степень позитивности и доверия. Учитывая, что он был инсайдером компании (а не каким-то нанятым сторонним рекрутером), у меня возникли большие надежды. Я чувствовал себя так, словно уже одной ногой был в компании.

Звонок от менеджера по найму

Менеджером по найму был парень с опытом работы в области науки о данных. У меня не было опыта в этом, но, к счастью, у меня была неделя, чтобы кое-что понять. Найм должен был производиться в команду по привлечению пользователей. Я читал о некоторых концепциях UX, которые были тесно связаны с привлечением пользователей. Я также читал о том, как мобильные платформы обрабатывают НЛП и другие вещи, связанные с ИИ.

Интервью началось очень тепло. На менеджера произвела впечатление моя 20-летняя карьера в различных областях: настольные, мобильные и облачные приложения, в сочетании с некоторыми back-end навыками.

Возник самый главный вопрос: почему именно эта компания? Какая мотивация?

Чтобы показать себя во всей красе (компенсируя недостаток моего опыта в области науки о данных), я сказал: «Я много читал обо всех концепциях, связанных с data-driven привлечением пользователей. Все, что мне нужно, — это рабочее место, где я смогу реализовать эти концепции, чтобы оказать максимальное влияние».

Мой ответ произвел на него большое впечатление. После формального прощания меня быстро перевели к следующему раунду: упражнению в программировании.

Упражнение в программировании

Это был этап, которого я больше всего боялся. И он оказался непростым.

Упражнение состояло из 3 задач. Было заявлено, что кандидат может не пытаться решить их все. Скорее, было целесообразно предоставить полные, безошибочные решения для двух из них.

№1: Найти, есть ли в массиве хотя бы один раз все числа от 1 до K

Эта проблема не нуждалась в программировании. Мне нужно было только найти ошибку. Однако, поскольку это сложная задача, я сомневался в ее относительной простоте. Из 90 минут собеседования мне потребовалось более 35 минут, чтобы исправить неустойчивое поведение.

№2: Обрезать строку до K символов, не разбивая (разделяя) слово и не заканчивая его пробелами

Например, если ввод = «I want to eat an apple» и k = 10, то вывод должен быть «I want to». Если k = 13, вывод будет «I want to eat».

Это заняло немного времени, но я все сделал хорошо. У меня осталось очень мало времени для самой сложной задачи.

№3. Учитывая два месяца в качестве входных данных, узнайте максимальное количество дней отпуска, которое можно взять в течение этих 2 месяцев. Отправной рейс выполняется только по воскресеньям, а обратный рейс — только по субботам.

Например, если входными данными являются апрель и май 2021 года, вывод будет (4 апреля — 29 мая) = 27 + 29 = 56 дней.

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

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

Через 10 дней, когда ответа не последовало, я уже потерял половину уверенности в том, что справился.

На 11 день пришел ответ от рекрутера:

У меня захватывающие новости — как, возможно, упомянул <другой мой коллега по подбору персонала>, мы хотели бы перевести вас на следующий этап и организовать для вас видеозвонок с <Разработчик A> и <Разработчик B>!

Я испустил победоносный крик.

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

Перед следующим раундом рекрутер позвонил мне, чтобы выразить свою радость по поводу моих успехов. Он сообщил, что в следующем раунде два разработчика рассмотрят мои программные решения. Ссылаясь на них, он также поделился результатом моих упражнений в программировании. Он сказал, что последнее решение (проблема отпуска) не играет никакой роли в моем выборе. Я победил своих конкурентов, используя только первые две задачи! Я был счастлив узнать об этом.

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

У меня была ровно неделя на подготовку, прежде чем я встречусь с разработчиками A и B, и это интервью определит мое будущее.

Последние приготовления

Хуже всего в интервью с senior-разработчиками то, что вы не можете их предсказать.

Чтобы ответить на сложные вопросы (алгоритм, API и т.д.), вы должны войти в поток. Чтобы войти в поток, вы должны писать код.

Однако, когда вы постоянно пишете код, ваше внимание отвлекается от более широкой картины: архитектуры, шаблонов проектирования, более масштабных идей в программировании (функциональных по сравнению с ООП), процессов инженерии программного обеспечения и так далее.

Я хотел коснусь как можно большего числа областей. Но у меня оставалось очень мало времени на подготовку к работе с конкретными API (по крайней мере, я так думал). Однако одно я сделал — изучил все проекты с открытым исходным кодом, над которыми работала моя будущая команда. Я был вполне уверен в понимании глубочайшей технической сложности этих проектов.

Однако в самый последний момент я обнаружил, что читаю о самых приземленных темах разработки программного обеспечения (Agile, TDD и т.д.). Я понятия не имел, будут ли о них спрашивать вообще, но я не хотел оставлять какие-то темы не освещенными.

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

День интервью

Когда начался звонок Zoom, я очень нервничал. Оба разработчика меня поприветствовали. Ведущий разработчик взял слово и задал мне несколько вопросов для разминки. Я почувствовал облегчение, но не такое, как я ожидал.

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

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

Затем последовал вопрос о проектировании программного обеспечения:

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

В моем ответе были обобщены некоторые классы, которые использовались для загрузки по протоколу HTTP, а затем последовал подход сериализации с использованием XML/JSON. Я также упомянул разделение кода загрузки и сериализации. Это заставило его спросить:

Что такое сегрегация кода? Зачем это вообще нужно?

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

Это вызвало на его лице более теплую улыбку. Он похвалил меня за знание ООП и архитектуры.

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

Именно в этот момент все начало разваливаться.

Вопрос с троянским конем

Троянский конь определяется как Невинность, скрывающая смертельное намерение.

Если один из членов вашей команды не делится с вами достаточной информацией, что вы будете делать?

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

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

Вместо этого я выбрал вот такой:

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

В этот момент их лица были невыразительными. Поэтому я подумал о том, чтобы расширить ответ за счет рационализации:

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

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

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

Троянский конь открывается

Именно в этот момент немой парень впервые решил вступить в разговор.

Если возникает ошибка, что делать, чтобы ее исправить?

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

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

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

Как только решение будет найдено, я проанализирую проблему. Найдя решение, я бы создал частную ветку. Затем я сделал бы запрос на проверку (запрос на слияние не был термином, используемым в этой организации, поэтому я пропустил слово «запрос на слияние»).

После утверждения я бы слил код с мастер-веткой.

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

Поэтому я решил спросить:

Если это не ответ на ваш вопрос, не стесняйтесь спрашивать меня более конкретно!

Это был самый громкий мой запрос о конкретности. Но они отказались обращать на это внимание.

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

Я подумал про себя:

Что это за разговор?

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

Чтобы завершить формальность, немой парень потратил некоторое время на разбор моих упражнений по коду. Я продолжал описывать свою логику (и некоторые ошибки, которые обнаружил позже). Отзывов не было.

Когда нам не хватило двух минут в графике, он спросил (ставя галочку, как будто это все еще было необходимо, но уже неважно):

Когда вы считаете, что продукт готов к производству?

Когда-то я был руководителем доставки. На тот момент я выпустил максимальное количество релизов. Но времени рассказывать про эту роль уже не оставалось. Я просто резюмировал точку принятия решения:

100% прохождение тестов и почти 100% покрытие кода.

Как обычно, без всякой обратной связи, они обменялись тонкостями и завершили интервью.

Результат

Прошло две недели, прежде чем я получил самое страшное письмо, в котором говорилось:

Мы решили не продвигать вашу заявку.

Когда я читал подробный отзыв, мой гнев накапливался:

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

Как, черт возьми, я мог знать, что они просят о принятии ответственности? Кроме того, все, что я описал, было моим собственным опытом. Я привел наглядные примеры. Что, черт возьми, происходило?

Затем меня осенило: именно «структурированный взгляд» (его отсутствие) подвело меня. Это был ответ, который я дал о «схватке с парнем, который не предоставляет информацию».

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

Единственный способ структурировать это был такой:

  • Классифицировать тип информации, которая была заблокирована от проблемного парня.
  • Похвалить его усилия по обмену информацией и, например, создать систему обмена знаниями.
  • Если необходимо, поднять решение выше.

Но если бы у меня было время создать структуру, я бы сказал правду? Разве такая структура не требовала бы знания вопроса заранее и оптимизации ответов?

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

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

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

  • Разнообразие развертываний (CI, Jenkins), потоки разработки (PR, MR, Git, SVN, ветвление) и управления проектами (Agile, JIRA)
  • Разнообразие культур и команд, с которыми я работал

Рекрутер поблагодарил меня за дополнительную информацию, но выказал свою неспособность сделать что-либо после принятия решения. Он посоветовал мне снова подать заявку через 6 месяцев, в основном предлагая мне снова пройти все 3 изнурительных раунда, чтобы встретиться с теми же интервьюерами, которые знали, что у меня недостаточно навыков, чтобы быть парнем из продуктовой компании (несмотря на то, что я работал с продуктами из Fortune 500 продукт раньше — все это было в резюме, которое они отказались просматривать).

Я был отвергнут.

К моему отчаянию, все было кончено:

  • Двухмесячный процесс, состоящий из 3 раундов с перерывами в 2–3 недели.
  • Чтение концептов (+ просмотр видео), которые я уже реализовал в живых проектах.
  • Мечта получить работу за 314 тыс. долларов+

Вывод

Интервью с senior-разработчиками печально известны неприятными сюрпризами.

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

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

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

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

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

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

Спасибо!

Теперь редакторы в курсе.