Эфир по паттернам надежности

Сегодня для ребят более 2-ух часов вещал про секцию с кодом в Big Tech. Разобрали траблшутинг, БД, задачку на написание load balancer и много других вещей. Короче теперь я уверен, что ребята больше готовы к своей секции💪


Во вторник проведу для вас второй урок. Всеобщим голосованием выбрали "Паттерны надежности"

Вся инфа об уроке здесь
⌛ Урок будет 23 декабря в 19:00 Мск

PS: если не будет работать переход с лендинга, то @reliability_patterns_bot

Как распределенные системы разрешают конфликты

В серии постов про Cassandra уже не раз упоминали правило Last Write Wins (LWW). Сегодня разберемся, что это такое, почему Cassandra выбрала именно его, и какая у этого выбора огромная цена 😳

Что такое LWW?

Представь, два пользователя одновременно редактируют один и тот же профиль:
🔵В 10:00:01 Маша меняет аватарку
🔵В 10:00:02 Вася (админ) меняет ее email

Оба запроса прилетают на разные узлы-координаторы и в итоге попадают на одни и те же реплики. Как системе понять, какая версия правильная? (Если не читал про координаторы в распределенных БД, то глянь пост)

LWW дает простой ответ: "Побеждает последняя запись". Cassandra просто смотрит на временную метку (timestamp), прикрепленную к каждой операции. Та, у которой timestamp больше, считается "победителем" и перезаписывает все остальные.

🔵Если у записи Васи timestamp больше, сохранится его email, а новая аватарка Маши будет потеряна
🔵Если у Маши — наоборот


Ловушка: что если часы врут? ⌛

У LWW, как и любого решения, есть trade-off. Cassandra слепо доверяет временным меткам

Представь, что и Маша, и Вася редактируют одно и то же поле — status в профиле пользователя

1️⃣Событие 1 (происходит позже в реальном времени):
🔵Реальное время: 10:00:02
🔵Сервер Маши (отстает): думает, что сейчас 10:00:00
Действие: Маша обновляет статус на "Working from home"
Результат: Запись отправляется в Cassandra с timestamp'ом 10:00:00

2️⃣Событие 2 (происходит раньше в реальном времени):
🔵Реальное время: 10:00:00
🔵Сервер Васи (спешит): думает, что сейчас 10:00:01
Действие: Вася обновляет тот же статус на "On vacation".
Результат: Запись отправляется в Cassandra с timestamp'ом 10:00:01.

Что видит Cassandra?
Она получает две конкурирующие записи для одной и той же ячейки (status):
🔵status = "On vacation", timestamp = 10:00:01
🔵status = "Working from home", timestamp = 10:00:00

Руководствуясь правилом LWW, она сравнивает timestamp'ы и видит, что 10:00:01 > 10:00:00.

💥Итог: Запись Васи ("On vacation") побеждает. Обновление Маши, которое в реальном мире произошло позже, будет безвозвратно потеряно, потому что ее сервер "жил в прошлом", и ее timestamp оказался меньше.
Вот это и есть классический пример "потерянного обновления" (lost update) из-за рассинхронизации времени.


NTP: не рекомендация, а требование

Для начала обязательно прочитай пост про NTP, чтобы вникнуть в детали подхода и что это такое

Для Cassandra работающий и настроенный NTP является жизненно важным требованием

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


А как же клиентские timestamp'ы? ⌚

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

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

Итог 👍

Выбрав LWW, Cassandra сделала ставку на простоту и скорость. Вместо сложных векторных часов (как в оригинальном Dynamo), она использует простой, но требовательный механизм

Поэтому на уровне инфры должна быть идеальная синхронизация времени во всем кластере. Без этого вся распределенная магия Cassandra не имеет смысла

👍 - если до этого не знал про LWW и теперь разобрался

Hard Skills открывают дверь на интервью, Soft Skills дают оффер

Вот ты прошел все технические секции и думаешь: "Оффер в кармане". И потом тебе прилетает отказ 🫨

И такие ситуации возникают все чаще и чаще. Именно поэтому вчера с senior из Booking провели эфир про финальные интервью, поведенческие вопросы и все вокруг этого

На западе обычно вопросы про твой опыт, про различные кейсы на работе выносят в отдельную секцию behavioral interview. В РФ же чаще всего это спрашивают на финальных интервью. Исключением является Яндекс. В этом посте подробно разбирал, как проходить секцию в Яндекс


Ниже давай пройдусь по пунктам

1. Запад vs РФ
На Западе поведенческие вопросы выносят прям в отдельную секция

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

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

2. Что такое culture fit

Западные компании особенно сильно уделяют внимание мэтчу ценностям компании. Допустим, Amazon Leadership Principles или Googliness

В РФ наиболее выделяющейся компанией являеся Авито. Именно на финальных интервью проверяется мэтч опыта кандидата и компании. Изучи перед финалом в Авито - https://github.com/avito-tech/playbook


3. Алгоритм ответа на поведенческие вопросы

Используем STAR
- Situation: что за ситуация
- Task: какую задачу поставили
- Action: какие действия сделали
- Result: какой результат

Важно говорить про свой вклад. Что сделал Я, а не МЫ

И круто в конце сказать про learnings: что именно ты вынес из ситуации

4. Что нельзя делать

При ответе на вопросы нельзя впадать в обвинение, пустую эскалацию

Situation: Был конфликт с соседней командой, так как изначально не подсветили срочность этой фичи и необходимость сделать именно костылем
Task: Договориться с смежной командой и успели допинать фичу в срок
Action: Собрали встерчу со смежной командой. Объяснили ситуацию. Завели тикет с высоким приоритетом, что в след месяце исправим этот костыль
Result: Успели выкатить костыль, который позволил запустить фикс. И проработали фиксы на будущее


5. Почему тех секции тоже оценивают софты

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

Так что во время тех секций будь внимателен и не веди себя как токс

6. Почему важно понимать импакт своей работы

Импакт/влияние это не про миллионны долларов, заработанных для компании. Или же про 100k RPS и супер популярный сервис

Здесь речь об осознанности своей работы. Насколько ты понимаешь, как твои технические задачи помогают компании. И как это влияет на метрики (в Западных и РФ Big Tech особенно любят про это спрашивать)

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

7. Будьте человеком

История инженера из Booking: прошел первый скрининг в Google не очень хорошо. HR предложила перепройти его. В итоге хорошо сказалось на этапе торговли за ЗП

Моя история: хорошо выстроенные отношения с HR помогли найти клевые команды в Яндексе. А также затем получить welcome bonus

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


И также ходи 1 раз в год на собесы. Более подробно можешь прочитать про это в этом посте

Если было полезно и узнал новое, то закинь 🔥

Как я не стал крутить опыт при устройстве в Т-Банк и получил +35% после 6 месяцев работы

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

Вот только момент, у меня опыта на тот момент было 1.5 года

И, как понимаешь, рекрутеры сразу шьют отказы (ну практически все)

Если говорить про Т-Банк, то я откликнулся на все вакансии на сайте, написал в личку нескольким рекрутерам. Даже дошел до C-Level чувака (увидел пост на LinkedIn, что они нанимают). И везде отказы...😢

Тогда я решил: "А почему бы не написать кому-то из разработчиков в ЛС на LinkedIn и после беседы попросить рефер?"

TL;DR: это сработало. Один из разработчиков подробно расспросил меня про опыт. Затем передал резюме знакомому рекрутеры и меня пустили на секции💃

Секции я прошел хорошо. Ну, было потно и несколько недель повторял очень много разных тем по JDK, databases и алгосы.

По итогу получил +32% к ЗП и клевый проект. А уже через 6 месяцев подал на повышение грейда и получил +35% и максимальную оценку на performance review 💸

Причем главным вкладом в эту оценку была процессная задача: организация и настройка дежурства в подразделении

Если же говорить про "нанимаем от X лет опыта" - здесь нет единого ответа. Я понимаю за и против

За это 👌
- Большой объем кандидатов. Всех не отсмотришь
- Читеры с накрученным опытом, с которыми компании борются как могут

Против этого 👎
- Глушит реально крутых кандидатов. Я видел чуваков с парой лет опыта, которые делали сложные вещи. А также видел "сеньоров" с 10 годами, которые не могли ответить на базовые вопросы

Именно поэтому при слепых отказах я рекомендую находить разработчиков, руководителей из компаний (LinkedIn, конференции) и заходить через них. В случае чего они попушат рекрутеров

Всем хорошей рабочей недели🚀

И ставь 🔥
Я подготовил много полезных постов для вас

Как убить продукт за 1 день: Урок Кинопоиска и стратегии раскатки

В 2015 году Яндекс выкатил абсолютно новый дизайн и движок сразу на 100% аудитории Кинопоиска. По итогу через пару дней пришлось откатывать релиз, так как пользователи были в ярости. А ТОПы покинули компанию

Почему так вышло? Проблема была не только в дизайне, но и в стратегии деплоя. Команда Кинопоиска выбрали стратегию Recreate (Big Bang) - убили старую версию и подняли новую.

Давай посмотрим на варианты раскатки приложения

1️⃣ Recreate (Big Bang)

Гасим версию А, поднимаем версию Б

Плюсы: Проще всего. Не нужно думать про обратную совместимость API и схем БД

Минусы: Даунтайм неизбежен. Если в новой версии критический баг - страдают ВСЕ пользователи. Откат долгий. Вердикт: Подходит только для dev-среды или сервисов, где простой в час пик никого не волнует

2️⃣ Rolling Update

Постепенно заменяем инстансы старой версии на новые. Было 10 подов v1, стало 9 v1 и 1 v2. И так до 100%. Это дефолтная стратегия в Kubernetes

Плюсы: Нет даунтайма

Минусы: В моменте в кластере живут две версии приложения. Если ты поменял контракт API или схему БД без обратной совместимости - 500-ки посыпятся у части юзеров


3️⃣ Blue-Green Deployment

У тебя два идентичных окружения: Blue (текущий прод) и Green (новая версия). Деплоишь на Green, гоняешь тесты. Все ок? Просто переключаешь балансировщик трафика на Green

Плюсы: Мгновенный rollback (просто свичнул трафик обратно)

Минусы: Дорого (x2 ресурсов железа). И если баг не обнаружили на Green, он все равно аффектит 100% юзеров сразу после переключения


4️⃣ Canary Release (Канарейка)

Пускаем новую версию на 1% пользователей (или только на сотрудников). Смотрим метрики (latency, error rate, бизнес-метрики). Всё ок? Раскатываем на 5%, 20%, 100%

Плюсы: Risk management. Если выкатили баг, страдает минимум юзеров

Минусы: Сложнее в настройке инфраструктуры и роутинга


История Кинопоиска учит нас, что System Design - это не только про архитектуру, но и про delivery. Пользователю плевать на твой чистый код, если сервис лежит

А вот кстати и статья от 2015 года, где рассказывали о факапе Кинопоиска: https://lenta.ru/articles/2015/10/15/kinopoisk/

Лучшие посты для твоего развития V2

С момента последнего такого поста прошло больше 2 месяцев. В канале появилось много постов по самым разным темам 💻

Сгруппирую их в топики, чтобы было удобнее выбрать интересующую тему

Если где-то будет вопрос, то не стесняйся спрашивать💃


Собесы

1. Самая важная секция в Big Tech

2. Разбор задачи на траблшутинг из Т-Банка

3. Hard skills открывают двери на собес, soft skills дают оффер

4. Как я провалил финал из-за плохой подготовки

5. Где попасть на собес, если рекрутеры кидают reject?

6. Секция с кодом в РФ Big Tech везде

7. Проблема с AI на собесах

8. Пример секции behavioral interview (поведенческое интервью) с Booking software engineer

9. Как проходит секция system design в Яндекс для backend разработчиков

10. Как проходит секция system design в Яндекс для frontend разработчиков


Архитектура

1. Самая подлая ошибка в распределенных системах

2. gRPC может быть медленнее REST

3. Сложная система с собеса в Big Tech

4. Механики раскатки приложений

5. Что заменит Kafka в скором будущем

6. Топ ошибок при проектировании API

7. Что такое NTP и почему это крит для распределенных систем

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

9. Как спроектировать сервис пробки

10. Как делать крупные задачи в Big Tech

11. Как я чуть не уволился из Т-Банк


Чек-листы/алгоритмы

1. Список лучших книг и статей по архитектуре

2. Сборник бесплатных ресурсов по system design

3. Алгоритм прохождения секции system design

4. Алгоритм по использованию C4


Карьера

1. Уволен из Яндекса за 1 косяк с БД

2. Как я стал team lead в 24

3. Big Tech прокачает твое резюме?

4. Как не получить плохую оценку на performance review

5. Куда расти после senior


Разбор общих архитектурных подходов на примере Apache Cassandra

1. Зачем вообще нужны кольцевые БД

2. Принципы, которые лежат в основе многих современных БД

3. Masterless архитектура в БД

4. LSM движок в БД как решение для write-heavy систем

5. Как ускорять запись в БД при большой нагрузке

6. Как LSM движки работают при чтении

7. Consistency levels как один из главных инструментов в распределенных системах

8. Как сделать автопочинку в распределенной системе?

9. Разрешение конфликтов в распределенных системах

В компании __подставь сюда любое__ нет повышения в рамках первого ревью

Решил поделиться историей из практики, которая может помочь многим при прохождении в Big Tech.

Дело было при прохождении собесов в Яндекс. Мне рекрутер говорит: "В Яндексе на первом ревью нет повышения ЗП. Только со второго"

Я такой думаю: "Ну, в целом окей. Если ЗП + премия (а они в Яндексе хорошие) будут норм, то по факту разберемся"

Прошел я все тех секции, затем прошел 7 финалов за 3 дня (это я еще далеко не во все команды сходил) и сделал выбор в пользу одной команды. Мне выкатили оффер, который я отклонил😁

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

TL;DR по оценке на ревью я даже перевыполнил, получив больше 1 млн, а по ЗП было именно как в плане.
TL;DR №2 Но повъ*бывал я знатно. Зато вырос как разработчик и руководитель

В общем суть истории такая:
• Не все так, как тебе говорят рекрутеры на входе. При хорошем прохождении + грамотном выстраивании коммуникации можно добиться более привлекательных условий
• В целом смотри на все моменты в жизни шире. Если есть какие-то границы, то почему бы не попробовать их подвинуть?

Ставь 🔥 и закину больше подобных историй с собесов

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

Мой ИПР в Яндекс, который я перевыполнил

Прошлый пост собрал много реакций 🙂

Поэтому в этом посте показываю свой ИПР, который skip level использовал для торгов со мной

Skip level - руководитель через 1 грейд. Проще говоря, руководитель руководителя

В Яндексе есть 6 видов оценок:
• + - в рамках ожиданий
• ++ - выше ожиданий
• +++ - еще выше ожиданий. В среднем показывает, что сотрудник работает выше ожиданий на след грейде
• ++++ - самая максимальная оценка. Фантастический результат, как его еще называют. Получают 2-3% всех сотрудников в рамках ревью
• +- - ниже ожиданий. 2 раза подряд приводят к увольнению
• - - отрицательный результат. На моей памяти видел такое 2 раза

В команду нужен был руководитель и никто из текущих сотрудников не подходил на роль team lead. У меня как раз был интерес попробовать руководство.

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

В целом так и произошло
• Январь 2024 - пришел в Яндекс и начал кодить
• Апрель 2024 - начал заниматься процессами
• Август 2024 - руководитель команды

Bсе это + вытащенный проект + участие в найме = ➕➕➕➕ на ревью и премии больше 1 млн

Осенью ЗП мне подняли на 15% и грейд-ап. На след ревью (формат поменялся и оно стало не весна-осень, а лето-зима) было ➕➕ и еще на 15% ЗП + премия около 800к

Итого мы видим
1. Договариваться можно и нужно, если ты нормально прошел секции и построил хорошие взаимоотношения с рекрутером
2. При выборе команды нужно быть максимально внимательным и продумывать как с точки зрения тех развития, так и карьерного
3. ИПР может позволить тебе обойти многих, кто "просто устраивается" и заключить внегласный договор между тобой и руководителем: "Я вкладываюсь и помогаю расти твоей команде. Ты же корректируешь меня и защищаешь на ревью"

❤️ - если было полезно. В одном из след постов расскажу про C&B и как происходит расчет повышений ЗП в Big Tech

PS: и да, ИПР я свой сильно перевыполнил даже

Ходи на конференции или упустишь возможность...

В субботу ходил на конфу Т-Банка под названием t-sync. Достаточно понравилась организация:
• Были доклады на разные темы (data, управление, llm, observability etc)
• Также были стенды, куда можно было подойти и подробно узнать про устройство какой-то системы (общая система инцидент-менеджмента, система для автоматизации workflow)

А еще было супер красиво💡

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

Но я всегда ставил 2 большие цели на каждую конфу:
• Узнать что-то новое технически
• Познакомиться с новыми людьми

Например, про metastable failures я узнал на конфе Яндекс Такси. И это знание потом помогло на ряде архитектурных собесов и в работе.

Или же, допустим, летом 2025 на Team Lead Conf слушал очень интересный доклад про уровни планирования задач и как это влияет на итоговую предсказуемость.

Ну и, конечно же, люди. На конференции можно познакомиться с интересными специалистами из разных областей. Допустим, на Yandex Open Source Day в 2023 году я познакомился с CPO Yandex Database (YDB). Было очень интересно пообщаться с человеком, который отвечает за такой масштабный продукт.

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

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

Как компании считают твои деньги

В посте про свой ИПР я упомянул фразу C&B. Для многих это выглядит как очередное непонятное сокращение.

C&B - cash and bonuses. В больших компаниях (не только big tech) это отдел, который занимается расчетом ЗП, выплатой премий, согласований повышений и так далее

Короче, это те самые ребята, которые в итоге могут отказать в повышении суммы оффера.

Алгоритм работы повышений ✖️

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

На примере Яндекса ❤️:
• Берется 3 последние перф ревью (включая текущее)
• Смотрится средняя оценка (у оценки с текущего ревью максимальный коэффициент)
• Далее смотрится положение твоей ЗП в вилке
• Также учитывается кол-во перф ревью на грейде

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

Как мне делали расчет после офера в VK

В конце декабря 2024 у меня был оффер в VK: 470 net + welcome bonus. HRBP отправила запроса в C&B для моделирования роста моей ЗП.

Можешь глянуть картинку поста с этим самым прогнозом😮

Прогноз был, мягко говоря, грустный. На тот момент в Яндексе я получал 365 net. То есть оффер в VK был практически на 100к жирнее.

Сам прогноз рассчитывался с учетом, что у меня будует 2 оценки в багаже, а не 3 (➕➕➕➕ за первое ревью и ➕➕ за грядущее). Если не понял, что за плюсики, то смотри пост

По итогу оценка на ревью была такая же, как в прогнозе. А вот ЗП подняли на 15% (это было лето 2025).

И да, забыл сказать, что в ❣️ так устроена система дохода, что часть ЗП ты получаешь премией. Это обсудим отдельно в следующих постах


Если было полезно - ставь ❤️

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

Задача с собеса в JetBrains

Дело было в 2023 году. Если быть точнее, в апреле☀️

Я тогда собесился в Т-Банк, Яндекс и JetBrains

Вообще с JB история была интересная. Никто на LinkedIn не хотел реферить меня и я решил пойти старым-добрым откликом. Закинул 10-15 откликов и подумал "Ну, пригласят - хорошо. Нет - переживу".

Мне начали сыпаться отказы на почту. Но потом случилось чудо.

Я тогда работал в Сбере и вышел покурить на улицу теплым апрельским вечером. Открыл телефон и вижу приглашение на интервью.

Далее было общение с рекрутером и потенциальным team lead. И потом сам собес.

На собесе было несколько задач. Но разберем одну из них.

Те, кто работают в JB IDE знают о такой фиче "Выделить код" (в оригинале expand selection). Нажал один раз - выделилось слово. Нажал еще - выделилось выражение. Потом вся строка, метод, класс.

Именно ее мне и дали задизайнить на интервью в JetBrains.

Главаный вопрос: как IDE понимает, что есть граница следующего блока? ❓

Прикол в том, что весь наш код парсится в абстрактное синтаксическое дерево (AST).

И у нас на старте есть два узла: leftSelection и rightSelection. Чтобы расширить выделение, нам нужно найти минимальный общий блок кода, который полностью охватывает оба этих узла.

Как некоторые уже поняли, задача из продуктовой моментально превращается в классические алгосы. Нам нужно найти Lowest Common Ancestor (LCA) - наименьшего общего предка в дереве 🌴

Как это сделать эффективно? В моем решении (на скрине к посту можешь глянуть структуру) у каждого узла ASTNode есть ссылка на parent. Это сильно упрощает жизнь.

Алгоритм получается такой 📎
1. Сначала обходим дерево от корня (root) до каждого из двух узлов и вычисляем их глубину (depth)
2. Смотрим, какой из узлов находится глубже в дереве
3. Начинаем поднимать более глубокий узел вверх (через атрибут parent), пока их depth не станет одинаковым
4. Как только узлы оказались на одном уровне - поднимаем оба узла вверх одновременно шаг за шагом
5. Двигаемся, пока они не сойдутся в одном узле. Этот узел и есть наш LCA

Именно этот найденный узел-предок и становится новым выделением в редакторе IDE.

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

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

Как устроен найм бэкендеров в Яндекс? И что важно знать перед устройством

На прошлой неделе в сообществе проводил эфир по процессу найма в Яндекс. Ниже собрал основные моменты для тебя

Грейды👨‍💻

В Яндексе используют магическую комбинацию из букв и цифр для грейдов.
• G15 - Middle
• G16 - Middle+
• G17 - Senior
• G18 - Senior+
• G19 - Expert

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

Часто senior из другого RU Big Tech заходит сюда на грейд ниже просто потому, что требования жестче.

Важно отметить, что в Яндексе можно развиваться достаточно высоко как по ветке руководителей (EM/TL), так и технарем (IC)

Продукт vs Инфра 💻

Часто слышу достаточно спорное заявление: "в продукте одни CRUD'ошлепы".

Это неправда. У каждого направления свои плюсы и минусы:

• Продукт: проектируешь архитектуру вширь (нужно изучать болшое кол-во смежных систем), много коммуникации с бизнесом, важно понимать time to market и уметь делать MVP
• Инфра/core: архитектура вглубь, сложный кусок системы, меньше доменов, но часто более хардкорно по технике

Расти до senior (G17) можно спокойно во многих продуктовых и инфровых командах

Из чего состоит сам собес 💃

Процесс найма поменялся, и теперь он выглядит так

• Advanced code: секция вокруг около-продовых задач. Пишешь базовую версию, тесты, потом дают усложнение. Главная проблема - у тебя всего около часа на все

Проходят примерно 50% кандидатов

• Алгосы: вместо трех секций теперь одна, но по сложности она равна третьей секции из старого найма

Из тех, кто прошел первый раунд, алгосы проходят только четверть кандидатов

• Архитектура: неблокирующая для IC, но именно она открывает путь к грейдам G17 и выше
• Technical Deep Dive: микс оценки твоего прошлого технического опыта и софтов. Могут накинуть грейд вплоть до G19

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

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

• Финалы с командами

Пресейл 🛒

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

Цель процесса - заинтересовать кандидата задачами и командой, а также проверить мотивацию


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

Советы от меня ⌨️
• Относись с уважением к участникам процесса интервью. Так как все фиксируется в логах и наличие красных флагов может стать стопом к найму
• Тренируйся решать не только алгоритмы, а также более прикладные задачи. Это позволит тебе выработать лаконичность и уложиться в тайминги
• Перед Technical Deep Dive обязательно отправь набросок того, что будешь рассказывать. Это позволит интервьюеру изучить твою задачу, а для тебя потенциально получить более высокую оценку

Почему я не ушел из Яндекса при более жирном оффере

В посте про C&B я упомянул, что не ушел из Яндкеса. Хоть и оффер от VK был намного жирнее 💰

Было 2 основные причины (обе равнозначные по важности)

Причина номер один

У меня была договоренность с моим руководителем, что до конца 2025 года я точно останусь в команде как Team Lead.

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

В целом мои взаимоотношения с руководителем были хорошие
• Он менторил меня, когда я только становился Team Lead
• Защищал на калибровках мои результаты на достойные оценки
• Никогда не забивал на мой фидбек по развитию и был готов уделить время, если потребуется

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

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

Причина номер два

Тут все просто - работа над собственным проектом.

Я понимал, что уход в другую компанию влечет за собой бОльшую трату времени на погружение, онбординг и вот это все ⌛️

И тут у меня стоял выбор:
• Пойти в новую компанию и поставть под риск проект (партнера, команду, планы)
• Остаться в Яндексе и наращивать время в проекте

Я выбрал второе, так как это больше совпадает с моими ценностями и долгосрочными планами


Также в посте про C&B я сказал, что, возможно, тебе не стоит уходить из текущей компании.

Что я имел в виду:
• Оценивай свои долгосрочные планы и текущую позицию. Важнее ли для тебя развитие с точки зрения скиллов или же больше ЗП здесь и сейчас
• Какие у тебя взаимоотношения с коллегами и в целом атмосфера в коллективе
• Как ты видишь сейчас через N лет

Если было полезно, то накидай 🔥

PS: фотка это зимний пейзаж из офиса Яндекса в Москва-Сити

Сможешь ли правильно ответить на эти SQL вопросы?

Сегодня посмотрим, насколько хорошо ты шаришь в работе индексов классической реляционной БД ✊

Кстати, подобного рода вопросы часто любят спрашивать на собесах (секция с кодом и архитектура)


Номер 1

Есть запрос

select * from post where likes_count > ? AND owner_id = ?

Далее мы создаем индекс

create index on post (owner_id)

Вопрос: будет ли использоваться индекс при запросе?

Ответ:


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

А еще нужно проверить через EXPLAIN работу индекса

Номер 2

Есть запрос

select * from post where owner_id = ?

Далее мы создаем индекс

create index on post (owner_id, likes_count)

Вопрос: будет ли использован индекс? А если бы вместо owner_id был поиск по likes_count?

Ответ:


Независимо от вида индекса нет гарантии его использования в реальном запросе. Оптимизатор запросов может как использовать индекс, так и проигнорировать его, в зависимости от статистики.

В целом будет, но нужно помнить такой момент: a multicolumn B-tree index can be used with query conditions that involve any subset of the index's columns, but the index is most efficient when there are constraints on the leading (leftmost) columns. Пример из доки PG

Если остались вопросы или не согласен с решением, то пиши в комменты 💬