«Почему вы хотите у нас работать» или техника 3️⃣🩸

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

Техника 3P отлично подходит, чтобы ответить на этот вопрос:

1️⃣ Practical - показать, что ты реально знаешь, что компания делает и её масштабы.

Пример:

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

2️⃣ Professional - показать, как твои профессиональные навыки закрывают позицию, на которую ты подаешься.

Пример:

Помимо этого, я обладаю всеми навыками, чтобы выполнять работу на высшем уровне. Например, позиция требует сильных лидерских качеств: я руковожу командой уже на протяжении 3 лет, и за это время мы сделали X и Y, увеличив прибыль компании на Z. Также я работаю с Java на протяжении 10 лет и знаю, как строить высоконагруженные системы с ее использованием.

3️⃣ Personal - показать химию, совпадение по ценностям или искреннюю симпатию к культуре/бренду.

Пример:

И конечно же, я считаю, что быть частью компании, которая является лидером на рынке - это огромное удовольствие и большой челлендж. По моему мнению, Uber в сфере такси - это как Google в сфере поиска. Также интересный факт: хоть в Казахстане и нет «чистого» Uber из-за коллаборации с Яндексом, люди в моем окружении все равно часто говорят «закажу Убер» вместо «закажу такси».

Мы часто говорим о первых двух пунктах, когда отвечаем на этот вопрос, но personal часть - самая интересная, так как она позволяет тебе выделиться из массы других кандидатов. Тебе просто нужно сделать ресерч и выбрать несколько нетривиальных вещей, которыми занимается компания, и подумать, как это может матчиться с тобой. Будь то твоя мысль о том, что Uber 🚓 в такси - это как Google в поиске, или какое-то личное воспоминание из прошлого, вроде: «Для меня Microsoft 💻 занимает отдельное место в сердце, потому что я до сих пор помню, как у меня появился первый компьютер и, будучи ребенком, я играл в свои первые игры на Windows🪟».

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

Примерно полгода назад мне звонил рекрутер из Meta и спросил, знаю ли я C++. Я сказал, что нет. Меня переспросили: «А может, всё-таки когда-то работал с C++?» Я ответил, что, возможно, немного писал на C++ в универе. Меня попросили добавить C++ в резюме в виде коммерческого опыта и скинуть обновлённую версию. После этого рекрутер сказал, что назначит интервью 😂. Я решил уточнить, будут ли у меня спрашивать C++ на собеседовании. Конечно же, мне ответили, что нет и что я могу использовать любой язык программирования.

А накрутка, которую предложил рекрутер, считается вообще накруткой? 🤪

Что думаешь?

Зависть - это плохо?

Расскажи свою историю, когда зависть помогла тебе 🤟 или создала ещё больше проблем 🤢 в жизни.

Я начну: как-то давно я увидел, что коллега с моей первой работы, которого я собеседовал и принимал решение о его найме, попал в Microsoft. У меня так подгорело, что я начал готовиться 😂

Как мой оффер отозвали за день до выхода

Как-то давно я проходил собеседования и получил оффер от одной казахстанской компании, назовём её XXX Digital. Сам проект мне очень понравился, а мой будущий тимлид, который собеседовал меня на последнем этапе, рассказал про планы и о том, как в компании и команде всё круто.

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

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

К счастью, тогда у меня был ещё один активный оффер + я поговорил со своим тимлидом в компании, где работал, и он поговорил с руководством, сказав им, что убедил меня остаться. 🧠😂

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

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

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

А у тебя бывало, что оффер отзывали?

Как успешно пройти System Design Interview? [Часть 1]

В странах типа моей System Design Interview - это, скорее, не стандартная практика. Обычно спрашивают Java, если нанимают Java-разработчика, и тому подобное. Но если ты решишь пособеседоваться в Т-Банк (он же Тинькофф) или Яндекс, то дизайн систем - нормальная практика.

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

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

Например ☝️:
• "design Uber"
• "design YouTube"
• "design ChatGPT".

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

Окей, с этим разобрались, но что именно нужно делать, чтобы построить условный Uber?

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

Во-вторых, от тебя не ждут готового дизайна всего Uber, YouTube и т.д. От тебя ждут, чтобы ты узнал(а) требования и сузил скоуп до того, чего ждёт интервьюер. Очень похоже на жизнь, когда тебе дают проект и тебе нужно разобраться, что именно от тебя хотят, так как требования очень расплывчаты.

Теперь давай разберёмся со step-by-step планом:

1️⃣ Собираем функциональные требования

Этот пункт отвечает на вопрос: что именно мы должны построить?
Например, тебе говорят: «Design Uber». Твоя задача здесь не сразу рисовать блоки 20ти сервисов, а начать задавать вопросы. Какую часть Uber мы проектируем и т.д.?

Например, что мы должны задизайнить:
• поиск машины рядом;
• matching водителя и клиента;
• отображение машины на карте в real time;
• создание поездки;
• платежи;
• история поездок?

За 45-60 минут построить весь Uber невозможно. Поэтому нужно вместе с интервьюером выбрать несколько основных use cases и дальше работать именно с ними.

2️⃣ Собираем нефункциональные требования

Теперь нужно понять не что делает система, а как хорошо она должна это делать.

Например:
• сколько у нас пользователей?
• сколько запросов в секунду / в день / в месяц / в год?
• важнее consistency или availability?
• какая допустимая latency?
• глобально ли расположены наши пользовальтели?

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

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

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

Например:
• Cats Eat Sweet Lemons, Drinking Sugar-Free Coffee 👇

🔠 - CAP Theorem
🔠 - Environment
🔠 - Scalability
🔠 - Latency
🔠 - Durability
🔠 - Security
🔠 - Fault Tolerance
🔠 - Compliance

Можно придумать что-то своё, чтобы можно было пробежаться в уме на интервью и выбрать то, что нужно на твоем собеседовании.

3️⃣ Делаем back-of-envelope estimations

Или, говоря проще, грубые подсчёты.

Если мы будем знать, сколько пользователей в секунду пользуются сервисом, будет легче аргументировать предложенные идеи. Например, если у тебя получилось 500 RPS, возможно, тебе вообще не нужен тот распределённый монстр, который ты уже начал(а) рисовать.
А если получилось 500 000 RPS, то разговор совсем другой.

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

Другой пример: если мы знаем пропускную способность одного сервиса и сколько нужно обработать данных в секунду, мы будем знать, сколько нод / серверов нам будет нужно в единицу времени.

Главное, помни, что не нужно высчитывать всё с точностью до последнего байта. Цель - подсчитать грубо, как будто ты подсчитываешь на обратной стороне конверта, как на черновике. Точные цифры не помогут, но потратят твоё ограниченное время.

Как успешно пройти System Design Interview? [Часть 2]

4️⃣ Model

Какие основные сущности есть в нашей системе?

Например, для Uber это могут быть:
• Пассажир
• Водитель
• Поездка
• Локация

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

5️⃣ API

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

Например:

POST /rides

Headers:
• JWT

Request Body:
• pickupLocation
• dropoffLocation

Response Body:
• rideId
• status
• estimatedPrice
• estimatedArrivalTime

Это не обязательно должен быть REST API, но так проще всего объяснить, какие методы будут использоваться.
Главная задача - показать основные взаимодействия между клиентом и системой и понять, какие данные проходят через эти запросы.

6️⃣ High-level design

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

Не всегда хорошая практика добавлять что-то, потому что ты использовал это на прошлых проектах, и по этой причине добавлять, например, Kafka, когда может быть достаточно чего-то попроще или вообще синхронного вызова. Если ты видишь, что без Kafka / Streaming Platform / Queue не обойтись, то при добавлении этого блока нужно объяснить причины и потенциальные проблемы.

По моему мнению, в хорошем дизайне систем важны не технологии сами по себе (лучше сказать Streaming Platform / Queue, чем Kafka / Rabbit MQ), а набор концепций с объяснением, почему ты принимаешь именно такое решение.

Главное, не делай слишком сложный дизайн сейчас, сделай быстрые наброски основного флоу. Остальное - в следующей секции.

Что же использовать для рисования диаграммы? Компания либо предоставит свою рисовалку, как, например, делает Google, либо разрешит использовать свою, например Excalidraw, Miro и тому подобное.

Также некоторые люди используют Apple Pencil ✍️ и их аналоги, но будь аккуратен с почерком: всё должно быть понятно. Плюс, если ты используешь блоки в Excalidraw или Miro, то дизайн легко переделать/доделать вместо того, чтобы стирать его и рисовать заново.

На этом этапе все базовые требования должны быть закрыты.

7️⃣ Deep Dives

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

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

Например, если мы проектируем Uber 🚘, то один из интересных вопросов - как быстро находить ближайших водителей.

Можно начать обсуждать:
• Как хранить и постоянно обновлять локацию миллионов водителей?
• Как эффективно искать водителей поблизости?
• Что произойдет, если тысячи пользователей одновременно запросят машину в одном районе?
• Что делать, если водитель принял поездку, но её успели предложить другому пользователю?
• Бывает ли вообще так, что поездка может быть предложена нескольким водителям?

Здесь уже можно глубже разобрать Geospatial Indexing, Partitioning, Cache, Consistency, и закапываться в детали можно и нужно до бесконечности, пока не кончится время собеседования.

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

Чем выше твой уровень, тем меньше стоит ждать, пока интервьюер сам найдёт проблему. На Senior / Staff необходимо самому посмотреть на дизайн, найти потенциальное "узкое горлышко" и предложить его разобрать.

Помни: ты должен лидить собеседование и решать неопределённости.

Читерство на техническом интервью?

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

Сам по себе быстрый ответ ничего не доказывает. Возможно, кандидат сразу увидел нужный паттерн или раньше решал похожую задачу. Но меня насторожило другое. Я решил более 700 задач на LeetCode и прошёл десятки алгоритмических интервью, однако до предложенного кандидатом подхода сам не додумался. А Claude, получив описание задачи, первым же решением выдал практически идентичное решение.

Разумеется, это не доказательство читерства. Совпадение вполне возможно. Поэтому проверять нужно не сам ответ, а понимание кандидата.

Может ли он последовательно объяснить ход мысли? Доказать корректность решения? Оценить сложность? Адаптировать алгоритм, если немного изменить условия?

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

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

Об этом - в следующем посте.

Нужно ли говорить на интервью, что ты уже решал эту задачу?

Допустим, на техническом интервью тебе дают знакомую задачу. Ты помнишь идею или даже готовое оптимальное решение. Стоит ли сразу сообщить об этом интервьюеру? 🤔

Я знаю людей, которые признавались. Иногда им оставляли ту же задачу, потому что интервьюеру было важно, как кандидат сможет объяснить решение - был важен ход мыслей. А иногда задачу сразу меняли - и новую кандидат либо решал успешно, либо не решал, и приходилось ждать cool-down-период 🧊, обычно длиною в год, чтобы попробовать свои силы ещё раз.

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

На интервью в Uber 🚘 мне однажды попалась задача, которую я действительно решал раньше. Я не стал об этом говорить: именно ради такой форы я и готовился. Однако, я знаю много людей, кто считает это нечестным и 100% признались бы, что решали задачу ранее.

Насчёт собеседований в Meta 🥸 я вообще молчу - если прорешать топ-50 вопросов, которые спрашивали за последний месяц, то вероятность, что попадётся знакомая задача, очень высокая. У меня, например, из 6️⃣ задач (по две задачи на интервью) попалось 5️⃣ из этого списка. 😕

Вернёмся к варианту, в котором ты не признаешься, что уже решал(а) эту задачу, несмотря на то что ты знаешь её решение. 🧠

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

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

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

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

Не так давно у меня был звонок с рекрутером одной знаменитой российской компании. 🙄

Как только я зашел на звонок, сразу услышал автоматическое уведомление о том, что разговор записывается. И самое интересное, что мне не объяснили, зачем она нужна, кто потом сможет ее посмотреть и сколько вообще она будет храниться. Просто: This meeting is being recorded.

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

То есть, вопрос скорее не в том, нажал ли рекрутер кнопку записи, а в другом: зачем компании вообще нужна полная запись интервью?

Допустим, чтобы другой интервьюер мог пересмотреть разговор.

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

Потому что фразы: "мы вас уведомили" и "вы согласились" все-таки немного отличаются друг от друга.

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

Кстати, самое забавное было еще до этого звонка.

Я спросил рекрутера: "нужно ли мне прислать вам свое резюме❓"
На что получил ответ: "нет, у нас ваше резюме уже есть в базе 😅"

И тут появляется сразу следующий вопрос: А откуда оно там? Какая его версия? Сколько лет оно хранится? И что еще кроме резюме находится в этой базе?

В общем, чем больше думаю об этом, тем меньше меня волнует непосредственно кнопка записи. 🤦‍♂️

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

Дедовщина на собеседованиях 🤔

Представь: ты проходишь собеседование, и тебя там задалбливают по всем фронтам:
• задачами, которые почти невозможно решить за одно интервью;
• вопросами на знание какой-нибудь никому не нужной детали языка программирования;
• задачками по типу «посчитай, сколько людей нужно, чтобы заполнить ими автобус до верха 🚌».

Ты всё это каким-то образом проходишь и устраиваешься в компанию. 😎

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

И ты начинаешь задалбливать следующих кандидатов примерно так же, как когда-то задалбливали тебя. 🤦‍♂️

Ведь это прям прямая аналогия с дедовщиной в армиях, innit?
Человек, который сам прошёл через унижения, тупые задачи, устои и правила, со временем может начать воспринимать их как нормальную часть системы:
• «Все через это проходили»;
• «Меня это сделало сильнее»;
• «Я выдержал - значит, и ты должен».

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

Выглядит будто с собеседованиями происходит что-то похожее.

Причём проблема даже не обязательно в желании самоутвердиться. Люди могут искренне считать процесс правильным именно потому, что сами когда-то его прошли.

Если я смог пройти - значит, хороший инженер тоже должен.

Хотя на самом деле это доказывает только одно: инженер научился проходить такой формат интервью.

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

И вот тут, я считаю, хороший интервьюер отличается от инженера.
Его задача - не придумать интервью, которое сложно пройти. Его задача - за 45–60 минут получить как можно больше полезного сигнала о кандидате и принять максимально адекватное решение. Это далеко не одно и то же.

То же самое происходит, когда инженеры предыдущих поколений пытаются навязать другим «правильный» карьерный путь, советуя, например, посетить какие-нибудь говно-конференции, поконтрибьютить в опен-сорс и тому подобное, а уже потом искать работу.

Также тебе могут говорить, что, прежде чем начать нормально зарабатывать, нужно выстрадать, прочитать N-ное количество книг и бесплатно поработать «ради опыта».

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

Никогда такого не было, и вот опять 🤦‍♂️

Собеседования собеседованиями, но давай немного отвлечемся и посмотрим на моего псыну 🐕😜

Твоё интервью может пойти не по плану 🤔

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

Разговор у нас был получился довольно странный.

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

Окей, следующий вопрос, подумал я.

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

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

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

Считаю, что хороший интервьюер иногда должен уметь просто помолчать и дать кандидату подумать.
Пусть он(а) ошибётся. Посмотреть, заметит ли он(а) ошибку сам. Если не заметит - дать небольшую подсказку и посмотреть, что он(а) с ней сделает.

Мораль сей басни такова 🧐:
Даже если ты готов(а) на 100%, это ещё не значит, что интервью будет пройдено. Поэтому при поиске работы «не класть все яйца в одну корзину» или, если переформулировать, не подаваться только в одну компанию - единственно верная тактика.

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