Привет, Хабр!
Многие знают, что один из четырех всадников апокалипсиса типов собеседований в Бигтех – это так называемое "Behavioral interview". Этот тип собеседований вполне заслуженно считается самым недооцененным среди всех остальных. Казалось бы… Прийти и поговорить про опыт и поотвечать на всякие дурацкие вопросы непонятно зачем.
Процесс собеседований в Бигтех разнится от компании к компании, но везде есть Behavioral. На это собеседование приходят интервьюеры, как правило выше чем тот, на который вы собеседуетесь.Очень часто это человек, который будет принимать решение, брать ли вас к себе в команду. Почему же это настолько важно, что 25% вашего успеха (возможно, даже больше) на финальном этапе зависит от прохождения этой части?
На текущий момент у меня было 6 собеседований в Бигтех, и только один раз у меня получилось пройти эту часть. 5 раз я слышал что-то вроде "Не хватило конкретики, на ваш опыт мы ожидали большего".
Почему Behavioral важен нанимающей стороне
Поведенческие паттерны
Несмотря на отсутствие гарантии, вероятность, что человек в похожей ситуации ведет себя похожим образом достаточно высока. А это значит, что есть смысл проанализировать опыт, чтобы понять, как человек будет себя вести, если эти ситуации наступят (а они, вероятнее всего, наступят). Как человек будет реагировать на критику? Как человек будет вести себя, когда его технический дизайн будет отвергнут? Как человек будет вести себя, когда он не согласен с чужим решением? Ответы на все эти важные вопросы кроются в опыте. Интервьюер будет смотреть на поведенческие паттерны (также называемые "repeatable patterns")
Соответствие уровню
На каждую вакансию должен присутствовать релевантный опыт. Хотели бы вы нанять на роль middle разработчика человека, который не написал ни строчки кода в жизни? Хотели бы вы на роль топ менеджера нанять человека, который не имеет никакого опыта в менеджменте? Скорее всего нет. Это не значит, что невозможно продвигаться по карьере. Но даже если вас берут на должность с некоторым "авансом", пото��у-что в вас поверили, этот аванс не может быть 100%. Нанимающая сторона хочет понимать, что у вас есть уже сейчас, релевантного вакансии. Умеете ли вы брать на себя ответственность, умеете ли вы проявлять инициативу.
Умение делать выводы
Крупные компании очень ценят навыки рефлексии и планирования. Насколько вы задумываетесь о том, что из последних лет было удачным решением (закрепляем, оставляем), что было неудачным (устраняем, улучшаем). Эти навыки очень важны для построения долгосрочных взаимоотношений. Когда онбординг может занимать до 6 месяцев компаниям становится невыгодна сильная текучка. При этом навык рефлексии важен для роста. Долгое сотрудничество + постоянно растущий сотрудник – это именно то, к чему стремятся корпорации.
Почему Behavioral важен собеседующемуся
Новые методы для решения старых проблем
Каждый из нас регулярно сталкивается с одними и теми же проблемами, например:
оверинжиниринг от коллеги, с которым вы постоянно спорите
холивары на работе, съедающие все время
необходимость донести негативную/корректирующую обратную связь, но при этом не хочется скатываться в негатив и выяснение отношений
не успеваете в дедлайн
не получается презентовать свою работу
ВНЕЗАПНО, для каждой до боли знакомой ситуации есть вполне себе четкие и понятные методы и идеи для решения, которые могут сделать жизнь немного проще. И вместо того, чтобы каждый раз искать индивидуальный подход можно иметь план: "попробуй А, попробуй В, попробуй С". Намного лучше проверенного "паникуй, попробуй случайное действие, меняй работу".
Появляется некоторый образ "Как действует профессионал", на который можно немного опираться.
Помогает экономить силы на собеседовании
Когда опыт хорошо проанализирован, и разложен по полочкам – почти на любой вопрос по резюме и опыту есть уже готовый ответ. А это значит, что вы практически не тратите ресурс на то, чтобы что-то вспомнить, или корректно объяснить (особенно касается собеседований на английском). В результате к моменту перехода к технической части можно оставаться свеженьким, что положительно сказывается на эффективности этой самой технической части. Будь то алгоритмы, системный дизайн, либо просто набор вопросов про язык или технологии.
Бонусом – вы будете более хорошо создавать первое впечатление. Потому-что представление и краткий рассказ о себе будет тоже на более серьезном уровне, чем экспромт
Помогает грамотно подсвечивать сильные стороны
Этот пункт особенно актуален для нашего менталитета. Установка "Хвастаться плохо!" мешает очень многим специалистам. В то же время установка "Надо хвастаться!" может сделать презентацию себя самого весьма неуклюжей. Реализация установки "Надо хвастаться, но так, чтобы это не отталкивало" требует навыка. Который нужно так же оттачивать, тренировать, обкатывать, получать обратную связь, править, и доводить до хорошего уровня.
Слово "грамотно" здесь также неспроста. Если вы очень круто расскажете "Реализовал низкоуровневую оптимизацию", а на деле подключили готовый пакет, а проблему нашли не вы, а тимлид и вообще он вам даже этот пакет скинул – то лучше подумать над другим примером, который покажет ваши сильные стороны лучше.
Всегда есть "Прогретый кеш" про опыт
Однажды я собеседовался в очень крупную компанию (среди мирового топа). Я долго готовился по хардскилам, но не очень серьезно отнесся к Behavioral части. Меня спросили "расскажите пример решения, которое вы приняли в сжатые сроки". Я ничего не вспомнил адекватного, и сказал "ну, мы договорились на формат API с клиентом, а они старый endpoint вызвали… А он не умел то, что надо было… В общем я в старом API вызове добавил новую функциональность".
И вот представьте, что вы нанимаете человека, которого хотите видеть одним из ключевых в команде. На должность Старший/Ведущий разработчик. И хотите понимать, как он себе поведет в моменты, когда все реально горит. Эта история звучит очень блекло. Не понятно, сталкивался ли человек вообще с дедлайнами, или старался по возможности пересидеть где-то тихонечко, чтобы никто не трогал.
После собеседования я повспоминал, и думал: "блин, а надо то было вот это рассказать…"
Сейчас у меня есть одна-две историй из опыта, когда все горело, и нужно было что-то решать (да и по другим вопросам тоже заготовки есть). Чтобы вспомнить нужное в нужный момент, еще и структурировано подать – нужен какой-то совершенно феноменальный талант (у меня такого нет).
Как готовиться
Точно так же, как и с остальными блоками собеседований готовиться необходимо загодя. По хорошему нужно заложить несколько недель, чтобы была возможность отдыхать, не возненавидеть эту секцию совсем сильно, а также чтобы получить на выходе результат достаточно высокого качества. Я бы не надеялся подготовиться за несколько дней, а тем более, часов.
Just be a S.T.A.R.
Каждая из историй про релевантный опыт должна иметь четкую структуру (некоторый фреймворк). Именно эта структура дает интервьюеру возможность быстро понять, что было и как это вас характеризует. STAR это:
* S/T - Situation/Task
* A - Action
* R - Result
После подготовки я стал использовать этот шаблон в повседневной работе. Например, презентация результатов на Performance Review. Еще, кстати, замечательно подходит для фидбека коллеге когда что-то пошло не так. Вы обсуждаете ситуацию и результат. Это помогает оставаться в конструктивном русле.
Этот подход здорово помогает сфокусироваться на результатах. А что же все-таки стало хорошо после этого? Часто оказывается, что мы недооцениваем свой труд, и это замечательное упражнение, чтобы это исправить.
S.T.A.R.туем! Шаг 1: Делаем заготовки
Я ровно 5 раз ходил с отношением "не, ну понятно, буду в это целиться". Так не работало. Что сработало – Word документ, в котором собраны истории, в формате Вопрос + ответ-таблица. Пример:
Расскажите о конфликте на работе?
S/T: Расхождение во взглядах на реализацию с архитектором в $КОМПАНИЯ_ИЗ_РЕЗЮМЕ, тратили много времени на холивары
A: Договорились собирать легковесные POC (Proof Of Concept), по результатам голосовали с командой, что берем
R: Перестали тратить излишнее время команды на холивары, стали применять этот подход и в других местах.
Как сделать чтобы заготовки звучали хорошо
Опираясь на умение ЛЛМ структурировать информацию, я задавал промт в стиле (чуть более детально расписывал чем здесь, но принцип такой): "Ты Senior Software Engineer, готовишься к собеседованию в FAANG. Составь ответ в формате STAR. Провалидируй, достаточно ли это хорший пример для FAANG и почему".
После чего описывал словами историю "Постоянно конфликтовали с архитектором по поводу решения. Он предлагал вот такие варианты, мне не нравилось вот поэтому, я предлагал вот это, долго спорили, потом решили делать легковесные POC (Proof Of Concept) и более предметно решать". ЛЛМ очень хорошо структурируют поток сознания, и делают его практически готовым к применению as is.
Использовать целевой язык собеседований
Если планируете выходить на англоязычный рынок - лучше все заготовки/моки (чуть позже об этом) вести именно на английском. Если планируете на русскоязычный - лучше на русском, и т. д. Особенно важно с английским, потому-что в моменты стресса на собеседовании нужные слова обязательно будут выпадать из головы.
Практика. Много практики
Это один из не самых очевидных моментов. В этом плане даже алгоритмы проще. Открываешь LeetCode, и решаешь много. Через какое-то время рука набивается. Behavioral тоже нужно практиковать. Что помогло мне:
.1 "Мок-интервью" с приятелем-разработчиком. Это звонок на час, где полчаса один выступает интервюьером, затем другой. Я делал на английском, так как выходил на англоговорящий рынок. Важно давать обратную связь. Было ли понятно, или не очень? Понятен ли импакт (результат) от действий? Так как я общался с приятелем-коллегой мы помогли друг другу понять, что действия каждого из нас на самом деле принесли больше результатов, чем нам казалось до этого. Что тоже очень здорово.
.2 Регулярное повторение. Сейчас прошло уже 3 месяца с момента, когда я собеседовался, и немного подзабылось. Но держаться в форме мне также помогало приложение, которое раз в день присылало пуш со случайным вопросом из моего списка (который составил около 12 вопросов). Я отвечал на этот вопрос, и потом смотрел заготовки, не упустил ли я чего. Любая регулярная рутина поможет. У меня была вот такая. Заодно нашел мотивацию навайбкодить написать приложение на Flutter. Сейчас как раз борюсь с тем, чтобы его выпустить.
Релевантные примеры
Примеры из опыта должны быть релевантными. Представим, что вы нанимаете синьора-помидора, от которого ожидаете, что он сможет нести ответственность, и вы сможете на него положиться. В качестве вопроса вы выбираете "расскажи какой-нибудь пример ошибки на работе, которую ты допустил", либо "самая твоя большая ошибка, как разработчика". К слову, в одной компании в которой я работал и проводил собеседования очень любили этот вопрос. И всегда было интересно послушать про какие-то неудачные запуски, ошибки в расчетах, падения, инциденты. Я полюбил этот вопрос, потому-что часто можно было что-то подчерпнуть в копилку собственного опыта.
Антипаттерны. Приведу несколько "плохих" ("слабых") историй, которые могут показать кандидата с негативной стороны:
Плохая история 1: Итак, вы задали вопрос об ошибке, кандидат отвечает: "Ну, у меня 10 лет опыта, но я честно говоря особо не ошибался и ничего не ронял". Я мало знаю людей, которые вносили действительно важный вклад, и никогда не было проблем. Если человек работает много лет, и он не ошибался, и даже рядом с ним никто не ошибался и не возникало недопониманий и проблем, то с 99% вероятностью варианта 2:
.1 Этот человек врет
.2 Этот человек никогда не брал на себя ответственность
Случай .1 плох тем, что он сразу подрывает доверие, случай 2. плох тем, что вы не можете ожидать автономности от человека. Возможно, вы в него поверили по каким-то другим причинам, и можете все-равно нанять. Но это хороший сигнал для вас, как для интервьюера
Плохая история 2: Вы задали вопрос об ошибке, кандидат отвечает: "Я буквально пару месяцев назад уронил продакшен. Получилось это потому-что меня пинговали о дедлайне, я психанул и выкатил сразу в прод без теста". Здесь все в целом понятно. Есть риск, что человек вспыльчивый, и в то же время есть проблемы с ответственностью.
Плохая история 3: История об ошибке: "Мы выкатили релиз, выросло количество ошибок. Мы релиз откатили - ошибки остались. Я позвал тимлида, он пришел и все разрулил". Эта история "слабая" с точки зрения сигнала. Она никак не раскрывает кандидата и не показывает его сильных сторон. Если смотреть на это через призму того, что за 10-летний опыт самое яркое что случилось с инженером - это позвать тимлида, то остается открытым вопрос, насколько вы хотите этого человека нанять.
Выдать "слабую" историю намного проще чем кажется. Когда вы на собеседовании сидите перед камерой, вам задали вопрос о котором вы особо не думали, ну или не можете вспомнить ничего релевантного, и повисает пауза – можно легко рассказать какую-то ерунду, или "не знаю, не могу вспомнить"
Архетипы
Есть еще один важный аспект для того, чтобы сделать ваши истории более наглядными – умение опираться на классические сценарии. Такие классические повторяющиеся сценарии называются архетипами. "Технические разногласия с коллегой" / "Не успели в дедлайн" / "Растущий техдолг", и т. д.
Бóльшая часть этих проблем широко известна каждому разработчику и менеджеру. Использование архетипов помогает задать контекст без лишних переусложнений.
Рассмотрим примеры вводной (Situation/Task). Один "плохой", другой – хороший:
Плохой пример: В компании Мяумяу мы делали проект, отвечающий за доставку. Недооценили объем работы, а потом еще и коллега уволился (Вася. Он вообще-то долго работал очень и все знал), потом ребята пришли из команды инфраструктуры, и потребовали обновить пакеты, в связи с требованиями безопасности. Там пришлось рефакторить, потому-что поменялись названия методов в библиотеке Libname. В общем, так сложились обстоятельства, и мы ну никак не могли успеть к дедлайну.
Хороший пример: В компании Мяумяу мы делали проект, отвечающий за доставку. За 2 недели мы поняли, что не можем реализовать всю заявленную функциональность в срок.
Хороший пример 2: В компании Абракадабра у меня возникали регулярные разногласия с архитектором по поводу технической реализации. Мы тратили заметно большое количество времени на обсуждения.
Нацеленность на результат. Zero blaming
Да. Часто есть конкретный "виновник". Кто-то что-то недопроверил, недосмотрел, и так далее. Очень легко сказать "Вот просто Петя ошибся, и прод упал". Именно за этим идет фокус на "Ситуация -> Действие -> Результат". Задача специалиста – решать проблемы. Там где ошибся один мог ошибиться и другой. Чего хотят от вас – это подхода "Что-то уронилось, пришел, разобрался, убедился, что больше не уронится". Это зрелый подход. Таких людей как правило и ищут в команду. Чем больше "блейминга" и поиска крайнего будет сквозить в историях кандидата – тем для него самого будет хуже.
Иногда эмоций бывает много. Иногда и правда накипело. Иногда это действительно может быть неадекватное давление по срокам / нереалистичные требования / хамство. Но все же, лучше воздержаться от обвинений, и придерживаться более прагматичного подхода при донесении информации.
Системные подходы вместо паники
Для решения проблем нужен системный подход. Либо по крайней мере, навыки его применить. Такие крайние меры как работа на выходных могут применяться практически в любой компании. Но нужно относиться к этому как к крайней мере, когда 99% ситуаций можно решить и без этого.
Плохо: «Мы не успевали, поэтому мы просто пахали на выходных»
Хорошо: «Мы не успевали, поэтому договорились, что было обязательным и самым‑самым критичным для запуска, определили, что может подождать (при наличии определенного количества ручной работы), и вы��атили в срок только обязательную часть.»
Дедлайны срываются, и чем раньше «неудобные вопросы» начнут обсуждаться — тем лучше. «Ой, мы не успеем завтра отдать, мы сделали только половину» — нежелательный сценарий.
Сначала костыль. Потом хорошо
Еще один совет (или шаблон), на который можно опереться – сначала временное решение, потом постоянное (Mitigation + fix). Это очень популярный подход к решению проблем. Сначала нам нужно, чтобы работало хоть как-то, потом делаем хорошо. У такого подхода масса преимуществ, и его очень любят в крупных компаниях.
Ситуация 1: Упал прод. Шаг 0: залили железом. Шаг 1: оптимизировали.
Ситуация 2: Хотим новую штуку. Шаг 0: быстрая дешевая реализация, проверка через A/B. Шаг 1: рефакторинг, делаем как положено. (Многие компании пропускают Шаг 1 здесь, это правда. Но нам все равно нужно понимать, как делать более эффективно)
Ситуация 3: Не можем определиться с архитектурой. Шаг 0: Делаем POC (Proof Of Concept). Шаг 1: Выбираем среди нескольких РОС, делаем полноценную реализацию.
Эпилог
Это очень большая часть работы, которую мне, как инженеру, не хотелось делать. Я очень много где переосмыслил свой опыт за время подготовки. Анализировал, чего от меня хотят, и почему это хорошо. Честно скажу, мне не хотелось столько сил тратить на это дело, и я не особо верил, что оно может быть полезным. Даже статья эта далась сложнее, чем статья про алгоритмы =)
Сейчас, оглядываясь назад, могу сказать, что я много где поступил бы иначе. Возможно, переосмысление опыта и модели поведения �� это и есть ключ к дальнейшему карьерному росту. Заодно, это дает уверенность, что в конкретной ситуации следует поступить именно так.
Всем удачи в карьерном пути!
