Coder Doesn’t Know

Теперь о серьёзном. Никто не желает в зопе поработать?

Чем отличается Middle, Senior и Staff на примере Google?

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

Возьмём для примера 🔠0️⃣0️⃣🔠🔠🔠.

🔤4️⃣ a.k.a. Middle Software Engineer

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

Это видно и по интервью: основной упор на миддла идёт на алгоритмы + поведенческое, а отдельного полноценного дизайна систем обычно вообще нет. Скажу сразу, это только у Google нет дизайна систем на миддла, в остальных компаниях он всё же есть, но требования не слишком жёсткие ☕️.

🔤5️⃣ a.k.a. Senior Software Engineer

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

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

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

🔤6️⃣ a.k.a. Staff Software Engineer

Стафф - это не сеньор, который просто ещё лучше знает дизайн систем (хотя и это тоже). Здесь сильно растёт масштаб ответственности. Вообще, это происходит на всех уровнях: растёт масштаб ответственности, задачи становятся всё менее конкретными, появляется больше неопределённости и делегирования.

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

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

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

Из этого следует:

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

Уже видели новый складной айфон? 😍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Астане новую ветку ЛРТ возвели, слыхали?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Насколько ты готов(а) к интервью?

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

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

К чему именно я готовлю:

За 11 лет в разработке я прошёл множество интервью, в том числе в бигтех, и сам провёл под сотню технических собеседований.
Люди, которым я помогал готовиться, получали офферы в Google, Meta, Amazon, Uber, Microsoft, Waymo, Revolut, Bolt и другие компании.

Я помогаю подготовиться к этим типам интервью:
• Algorithms;
• System Design;
• Behavioral;
• Object-Oriented Design;
• Java Low-Level Design.

Если у тебя скоро интервью, ты уже получал отказы или просто хочешь понять, насколько готов(а) сейчас - пиши:

@coderdoesntknow_support 👈

Как успешно пройти 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 необходимо самому посмотреть на дизайн, найти потенциальное "узкое горлышко" и предложить его разобрать.

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

Как успешно пройти 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, то разговор совсем другой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вроде рекрутер boeing пишет, а вроде и @gmail.com