Big Tech сделает твое резюме конкурентным (или нет)?

Сегодня решил затронуть достаточно горячо обсуждаемую тему: идти ли в Big Tech

TL;DR правильного варианта нет 🙂

Меня очень часто спрашивают такого рода вопросы и я всегда отвечаю:

"Отталкивайся от своей долгосрочной цели"

✔️ Идти в случае

1️⃣Ты хочешь связать свою будущую карьеру с ИТ

2️⃣Ты хочешь перенять best practices (разработка, процессы, управление людьми) для своего проекта

3️⃣Ты хочешь быть конкурентным на рынке труда

4️⃣Ты хочешь поехать в западные компании (да и в целом за границу)

5️⃣Тебе важно, что твоя компания занимается каким-то существенным продуктом (не казик, only fans и тд. FYI не осуждаю, если человек работает в этих сферах)

6️⃣Получить network топовых инженеров, руководителей


👎 Не идти в случае

1️⃣Хочется иметь самые высокие вилки в моменте, а не на горизонте n лет

2️⃣Цель - заработать/отложить денег, но не строить долгосрочную карьеру

3️⃣Не смущают юр риски, которые часто бывают в более маленьких компаниях


В целом со всех сторон слышу, что в 2025 найм упал, все стало плохо и тд 😵

Лично я всегда хотел поработать в больших ИТ компаниях, чтобы перенимать опыт. И так получается, что сейчас в резюме есть Сбер, Т-Банк, Яндекс (а офера были чуть ли не в каждую большую компанию РФ)

Так вот, в рамках этого года ко мне приходили сами многие компании (большие и маленькие) и я получил несколько оферов с доходом 500k+ net. А большей части отказывал, так как их предложения были неконкурентные❌

И особенно на секциях с архитектурой и про прошлый опыт мне сильно помогал опыт работы в Big Tech

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

Как большие системы могут сами себя чинить?

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

За этой магией стоят два механизма: Hinted Handoff и Read Repair

Проблема: узел-реплика недоступен

Представь, ты пишешь данные с W = QUORUM и RF = 3 (подробнее можешь прочитать в этом посте). Координатор должен записать данные на узлы A, B и C. Узел C молчит. Кворум (2 из 3) есть, твое приложение получает "ОК". Но что будет с данными для узла C?


🔖Hinted Handoff

Координатор видит, что узел C недоступен. Он создает "подсказку" (hint), содержащую данные для С, и сохраняет ее у себя. Как только узел C вернется в строй, координатор отправит ему все накопленные подсказки.

Важный нюанс: Это временная мера для краткосрочных отказов. По умолчанию подсказки хранятся 3 часа. Если узел лежит дольше, считается, что он выведен из строя надолго и его нужно чинить вручную.


🔖Read Repair: Лечение во время чтения

Данные на репликах все равно могут рассинхронизироваться. Read Repair чинит это прямо во время чтения

Как работает:

1. Ты делаешь запрос на чтение

2. Координатор запрашивает у реплик не сами данные, а их дайджест

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

3. Если дайджесты совпадают — отлично, данные идентичны

4. А вот если дайджесты не совпадают, координатор понимает, что на репликах беспорядок. Тогда он запрашивает полные данные, но не со всех реплик, а только со всех N реплик, ответственных за этот ключ (в нашем примере — с узлов A, B и C)

5. Он сравнивает полученные версии и определяет самую свежую. Для этого он применяет правило Last Write Wins (LWW)

Что за LWW? Мы подробно разберем это в следующем посте, но если кратко: побеждает версия с самой свежей временной меткой (timestamp)

6. Эту свежую версию он возвращает тебе

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

Ключевая мысль: Каждое чтение в Cassandra — это потенциальная мини-операция по починке данных. Система постоянно лечит сама себя.

Итог

- Hinted Handoff помогает пережить краткосрочные отказы при записи
- Read Repair исправляет расхождения между репликами во время чтения

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


НО ты можешь спросить: "Если я использую R+W > N для строгой согласованности, отменяет ли это Hinted Handoff и Read Repair?"

Краткий ответ: Нет, не отменяет, а делает их работу еще важнее

- Настройка кворума (R+W > N) — это гарантия для тебя, что одна конкретная операция вернет самые свежие данные
- Eventual Consistency (и ее механизмы Hinted Handoff / Read Repair) — это гарантия для кластера, что в итоге все данные на всех репликах сойдутся к единой версии

Поэтому "строгая" операция чтения, обнаружив расхождение на репликах, как раз и становится триггером, который запускает Read Repair для лечения кластера в фоне

В следующий раз мы копнем в сердце механизма разрешения конфликтов — Last Write Wins (LWW) и выясним, почему для Cassandra так важна синхронизация времени

Если разобрался в механизме починки больший систем, то бахни 👍

Пример задачи на траблшутинг из желтого банка

Сегодня давай разберем реальную задачку с интервью

Приложение выкатывается в prod, но первые 5 минут видим в балансере ошибки tcp connection reset и no healthy backends. Потом всё магически стабилизируется. Как это решить?

У данной задачи есть 2 уровня решения


Первый уровень

В кластере настроена политика деплоя recreate

При стратегии Recreate:​
🟢Все старые поды убиваются сразу
🟢Новые создаются и поднимаются
🟢Приложению нужно время на прогрев (инициализация, подключение к БД)

За это время балансер шлёт в пустоту → ошибки

Решение:

Меняем стратегию на RollingUpdate. Пример конфигурации (также можно делать через % от общего кол-во подов):

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0  # Ноль подов недоступны
      maxSurge: 1   # На 1 под больше, чем replicas
  
  replicas: 3

Вместо full downtime старые поды работают, пока новые поднимаются

Второй уровень

Добавляем пробы: Startup → Readiness → Liveness

containers:
- name: app
  
  # 1️⃣ Startup — проверяем, поднялось ли приложение (долгая операция)
  startupProbe:
    httpGet:
      path: /health/startup
      port: 8080
    failureThreshold: 30      # 30 попыток = ~150 сек на прогрев
    periodSeconds: 5
  
  # 2️⃣ Readiness — готово ли обслуживать трафик
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10
  
  # 3️⃣ Liveness — живо ли приложение
  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10
    failureThreshold: 3

Как это работает:​

🟢Startup блокирует остальные пробы, пока app поднимается
🟢Readiness исключает под из балансера, пока он не готов
🟢Liveness выбивает под из балансировки и рестартит контейнер, если он зависнет


Таким образом мы гарантируем безопасную выкатку приложения и мониторим состояние нашего сервиса

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

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

Сегодня для ребят более 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.

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

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