📚 Какие книги читать Java-разработчикам, чтобы вырасти в Senior?

Книги редко бывают единственным ключом к уровню Senior, но для некоторых именно они становятся трамплином: дают структуру, глубину и понимание там, где статьи / видео не справляются

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

Вот 10 книг, которые я рекомендую на пути к Senior:
➡️ PostgreSQL Изнутри. Чтобы понимать, как СУБД работает под капотом: планировщик, индексы, транзакции. Если много работаете с SQL или хотите в компанию, где с ним нужна плотная работа, то эта книга — прекрасный выбор

➡️ Kubernetes для разработчиков. Без понимания того, как твое приложение развертывается и масштабируется (хотя бы на базовом уровне), сложно претендовать на высокие позиции

➡️ "Чистый код" Роберта Мартина. Учит писать код, который будет легко читать, поддерживать и развивать — тебе и твоей команде. Классика

➡️ Теоретический минимум по Computer Science (Владстон Феррейра Фило). Чтобы перестать плавать в основах CS на собеседованиях. Хорошо подходит тем, у кого не было хорошего профильного универа

➡️ Микросервисы Spring в действии. Spring Boot есть почти везде. Даёт знания, как строить отказоустойчивые микросервисы. Код автором выложен на GitHub

➡️ Java Concurrency in Practice. Старенькая, но актуальная база по многопоточке. Глубоко и понятно объясняет JMM, основы синхронизации и построение thread-safe классов. Must-have для любого разработчика

➡️ The Software Engineer’s Guidebook. Для тех, кто не хочет останавливаться на Senior. Эта книга — о навыках и стратегическом мышлении: как принимать архитектурные решения, как управлять своими задачами и карьерой. Показывает путь до Tech Lead/Staff Engineer

➡️ Kotlin в действии (2-е изд). Kotlin стал стандартом на многих проектах. Эта книга — лучшее введение, чтобы понять философию языка

➡️ Практика реактивного программирования в Spring 5. Лучшая книга по реактивщине в Java и Spring. Книга показывает использование Spring WebFlux и Project Reactor на реальных примерах

➡️ Высоконагруженные приложения (Мартин Клеппман, "Кабан"). Ещё одна классика, которая обязательна к прочтению всем, кто хочет работать с highload. Здесь есть всё: от баз данных и кэширования до распределенных систем и шаблонов проектирования

Книги отлично закрывают конкретные пробелы в знаниях. Не пытайся осилить всё сразу. Выбери 1-2 книги:
🪵 Путаешься в основах многопоточности? → Concurrency in Practice
🪵 Хочешь понимать, как масштабировать системы? → "Кабан"
🪵 Мечтаешь о роли архитектора? → The Software Engineer’s Guide

Завалил собес из-за вопросов по архитектуре? Чувствуешь, что не знаешь, как расти дальше после Middle? Не понимаешь, по какому пути развития идти именно тебе?

➡️ Пиши сюда слово "книга": @idkhokhlov. Составим твой персональный план развития, чтобы ты наконец начал зарабатывать столько, сколько хочешь

📌 Чек-лист для написания своего Spring Boot стартера

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

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

1️⃣ Conditional — условные аннотации
Практически на каждом втором собеседовании можно услышать вопрос про @Conditional или про то, на основе чего пишутся стартеры и как они работают. Использование @Conditional крайне важно для того, чтобы иметь возможность создавать бины только тогда, когда это необходимо (например, @ConditionalOnProperty или @ConditionalOnExpression, чтобы включать стартер по feature-флагу, или @ConditionalOnMissingBean)

2️⃣ Single Responsibility и переиспользуемость
Стартер пишется для реализации конкретной задачи (клиентский стартер для вызова API, добавление конкретной функциональности и т.д.) и для того, чтобы переиспользовать его в других микросервисах. Это значит, что в стартер не нужно тянуть неуместную логику (например, тянуть spring-boot-starter-data-jpa в стартер-клиент для вызова REST — да-да, и такое видел!). Среди зависимостей и классов стоит писать только то, что нужно для работы стартера. Достаточно посмотреть на то, как написаны стандартные Spring Boot-стартеры

3️⃣ Параметризация
Выставляйте переменные окружения и присваивайте им осмысленные значения по умолчанию. Добавляйте метаданные, чтобы упрощать понимание того, зачем нужен тот или иной параметр. По возможности подготовьте README.md с примером подключения стартера в проект. Придумывайте адекватные понятные названия согласно конвенциям. Упрощайте жизнь другим разработчикам

4️⃣ Тестирование
Не забывайте про Unit- и интеграционные тесты. Благодаря ним вы избежите часть очевидных ошибок и не придётся повторно дорабатывать и пересобирать стартер

5️⃣ Обратная совместимость
Думайте про обратную совместимость и старайтесь поддерживать её настолько, насколько возможно. Если депрекейтите какие-то методы / поля / классы, то делайте это постепенно (@Deprecated —> forRemoval = true —> remove). При этом указывайте, что стоит использовать вместо устаревающего компонента. Обязательно обновляйте версию стартера при внесении изменений (видел, когда пересобирали и публиковали стартер с перезатиранием версии)

6️⃣ Таблицы в БД вместе с миграциями
Если стартер требует наличия какой-то таблички в БД, а у вас в компании используется одинаковый инструмент для миграций (Liquibase, Flyway и т.п.), то можно вместе со стартером поставлять миграции

7️⃣ Единые версии зависимостей для стартеров
Если у вас много стартеров и общие версии библиотек в командах, их можно объединить в один репозиторий в многомодульный проект. В корне можно прописать все версии библиотек, чтобы все стартеры и их компоненты были совместимыми по их зависимостям. Из минусов — если микросервисы написаны на разных версиях Spring Boot, то придётся поддерживать две ветки стартеров — Spring Boot 2 / 3

8️⃣ Импорт автоконфигураций
Добавляйте META-INF/spring.factories (Spring Boot 2) или META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 3) сразу в стартер. Не заставляйте разработчиков дополнительно донастраивать стартер в своём проекте

9️⃣ Метрики и Health
Если уместно, то не забывайте писать свои корректные healthcheck-и (HealthIndicator). Также можно добавлять кастомные метрики с помощью MeterRegistry

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

➡️ Если вы хотите отточить свой навык в написании стартеров или научиться писать их с нуля, то пишите слово "стартер" в личные сообщения. Буду рад стать вашим ментором!

⭐️ Как пройти собеседование в Revolut?

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

Что нужно знать о Revolut?
Revolut — европейский онлайн-банк, работающий во многих странах мира. Компания ведет найм в ОАЭ, Испанию и Польшу. Удалёнка. Процесс собеседований — на английском языке. Перед каждым этапом — созвон с HR, который подскажет, к чему готовиться и на что обратить внимание. Советую вести запись

1️⃣Live Coding Interview
60-минутный live-coding в IDE, где нужно реализовать небольшую библиотеку, покрытую тестами

Какие задачи дают?
➡️ Load Balancer с разными стратегиями маршрутизации (random, round-robin, weighed round-robin). Нам достался именно он
➡️ URL Shortener
➡️ Money Transfer

На что обратить внимание:
🪵 Обязательно собираем требования к решению. Сколько должны хранить адресов, нужно ли их валидировать и т.п.
🪵 Обязательно делаем решение поэтапно. На этапе 1 реализуем хранение адресов и их выдачу, на втором реализуем случайную выдачу, на третьем — приходим к паттерну «Стратегия» и добавляем Round-Robin. На каждую секцию — по 15-20 минут, как успеете
🪵 Подход TDD обязателен — описываем happy-path, покрываем базовые сценарии (добавили больше адресов, чем допустимо — какую реакцию ожидаем?). И только потом пишем реализацию, подгоняем её под тесты. В процессе написания тестов можно извлечь полезные требования. Но не тратьте на них сильно много времени, иначе не успеете написать код
🪵 Важно предусмотреть потокобезопасность, но стоит спросить об этом интервьюера (будет ли код исполняться в нескольких потоках?)
🪵 Используем DDD подход — правильное доменное моделирование
🪵 Пишем без спринга — на чистой Java + JUnit/Mockito

О чем помнить?
➖Нельзя гуглить или использовать AI. Встроенные агенты в IDEA необходимо отключить
➖Время строго 60 минут
➖Экран шарить с первой минуты. Можно подготовить шаблонный проект до собеседования
➖Код должен быть сразу production-ready

2️⃣Technical Conversation Interview (Задача + теория)
60 минут, из которых первые 30 — небольшая live-coding задача, вторые полчаса — техническая дискуссия о том, как сопровождать и масштабировать ваше решение

Первая половина
Реализация thread-safe перевода денег с одного счета на другой (Money Transfer Service). Не забываем, что у нас 30 минут. Главный упор тут на принципы DDD — обязательно их знать к этому этапу, понимать, как они реализуются в коде (большинство проектов так или иначе следуют этим принципам)

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

Теоретическая часть
➡️Оптимистичные/пессимистичные блокировки, уровни изоляции транзакций
➡️Микросервисы: как деплоить (blue-green, …), rollback, migration
➡️Мониторинг: распределенная трассировка, метрики (за чем следим, какие бизнесовые метрики будет делать)
➡️Паттерны отказоустойчивости: circuit breaker, bulkhead, retry

О чём помнить?
➡️ Вы должны вести интервью, а не ждать вопросов
➡️ Объяснять trade-off‘ы каждого решения

3️⃣System Design Interview
60 минут на проектирование системы целиком. Классический системный дизайн

Обычно дают что-то из этого:
➖Physical Card Issuance & Delivery System
➖Global ATM Network & Cash Withdrawal
➖Hotel / Airline Booking Platform

Что важно:
⭕️Вести интервью, а не быть ведомым. Самое важное на этом этапе
⭕️Умение собирать требования (ФТ и НФТ)
⭕️Обосновывать свой выбор, не усложнять решение
⭕️Умение рисовать и объяснять архитектуру, понимать тонкости задач (для отелей — overbooking, для банкоматов — как их пополнять заранее?)

4️⃣Final Team Interviews
Встречи с тимлидами и командой. Помните, что в первую очередь смотрят на soft-skills

Что будет?
➡️Culture fit - насколько вы впишетесь в команду
➡️Behavioral Interview (погуглите, там много вопросов)
➡️Обсуждение Вашего опыта работы

Последние месяцы активно менторил. Возвращаюсь к публикациям — напишите в комментарии, разбор какой темы хотите видеть в следующих постах?

🐞 Анонс программы "Java Bugs"

Ищу Java-разработчиков любого уровня, заинтересованных в устранении пробелов в коммерческой практике

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

Что я предлагаю?
Программу на 1 месяц, на которой будем разбирать частые ошибки, встречаемые на реальных проектах в коммерческой разработке. Что внутри:
🪵 Банальные баги (NullPointerException, UnsupportedOperationException и др.)
🪵 Ошибки при работе с БД, индексы, работа с Liquibase
🪵 Проблемы Hibernate: N + 1, LazyInitException, генерация CROSS JOIN и др.
🪵 Ошибки проектирования Spring-микросервисов и REST-интеграций
🪵 Ошибки при работе с транзакциями
🪵 Баги многопоточного выполнения

Что нужно будет делать?
В определенные дни буду публиковать Pull Request’ы, в которых нужно будет находить ошибки в коде на указанную тему и предлагать исправления. Также будем вести рейтинг разработчиков: тому, кто найдёт больше всего дефектов, полагается приятный бонус

Как устроена программа?
➡️У каждого участника — личный GitHub-репозиторий, в который публикуются Pull Request'ы с кратким описанием багов, которые нужно искать и исправлять
➡️Затем: публикация ответов и материала, где подробно расписаны причины багов и к чему они приводят, а также правильные решения
➡️Еженедельные созвоны с обсуждением проблематики и всего, что связано с Java-разработкой
➡️Общий чат, где можно обсудить код и решения
➡️Два тарифа: групповой и индивидуальный с личным код-ревью

Что вы получите?
✔️ Навыки прохождения live-coding собеседований, так как проблемы сильно пересекаются
✔️ Меньший процент багов на коммерческих проектах и более чистый код
✔️ Улучшение качества код-ревью
✔️ Покрытие практических и теоретических пробелов (узнаете что-то новое)

🦞 Тариф "Групповой". 30 000 ₽
Включает в себя:
➡️ Доступ к группе со всеми участниками и теоретическими материалами
➡️ Индивидуальный репозиторий для проведения код-ревью
➡️ Еженедельные групповые созвоны

🦞 Тариф "Индивидуальный". 60 000 ₽
Включает в себя всё из группового тарифа плюс:
➡️ Индивидуальный чат со мной
➡️ Индивидуальный созвон раз в неделю
➡️ Личное код-ревью ваших исправлений неправильного кода

⭐️ Старт — 26 января. Чтобы узнать больше и забронировать место — пишите в ЛС @idkhokhlov слово "Баг"

↗️ Как расти внутри одной компании?

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

1️⃣Рост зарплаты
Забавный факт, но многие люди не задумываются о том, что они уже сейчас заслуживают повышения. Поэтому первое, что вы можете сделать — спросить себя:

🪵 Как давно меня повышали?
🪵 Стал ли я брать больше ответственности?
🪵 Есть ли у меня достижения с момента последнего повышения?
🪵 Знаю ли я свой план роста ЗП в компании?

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

🏆 Узнать о повышении — win-win стратегия. Даже если вас не повысят, во-первых, вы узнаете намерения компании относительно вас, а во-вторых, это может послужить сигналом для вашего роста или смены работы

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

2️⃣ Технический рост
Тут несколько вариантов в зависимости от возможностей в компании:

➡️ Смена команды / проекта внутри компании. Это эффективный способ сменить привычную обстановку и выйти из зоны комфорта. В новой команде может быть другой стек, другие подходы к разработке (в идеале попасть к очень опытным разработчикам с высокими требованиями), интереснее задачи. Не бойтесь узнавать о такой возможности

➡️ Брать инициативу и просить сложные и амбициозные задачи. Если вы замечаете, что отлыниваете от сложных и интересных задач или видите, что в некоторых местах можно провести дополнительный анализ и предложить своё решение — берите инициативу и предлагайте взяться за такие активности. Добавится еще один повод вас повысить

➡️ Проанализировать свой подход к разработке. Возможно, вы забиваете на код-ревью. Может, ленитесь писать тесты или пишите их халтурно? Может, быстро делаете бизнесовые задачи, не задумываясь о правильной архитектуре? Не продумываете фича-флаги или другие механизмы? Или же слишком много думаете о мелочах? Тогда этот пункт для вас

➡️ Участвовать в командных взаимодействиях. А именно: помогать другим командам в разработке, активно проводить код-ревью, ходить на встречи разработчиков. Любые подобные мероприятия могут прокачать вас технически. Общайтесь с другими разработчиками, обсуждайте ваши решения

3️⃣ Личные качества. Найдите слабые стороны, которые вы проявляете на проекте. Скорее всего это те моменты, когда вы испытываете негативные эмоции. Может быть, вы не справляетесь с критикой. Может, вы слишком много времени тратите на задачи. А может, вы не переносите какого-нибудь человека в вашей команде? Любой подобный пункт можно превратить в задачу сделать себя сильнее. Стрессоустойчивость и умение концентрироваться в наше время — ценные навыки

📤 Один из самых быстрых способов роста — взять себе ментора. Если хотите прокачать технические навыки или найти работу с повышением, напишите слово ментор ➡️ @idkhokhlov

🐞 Java Bugs. Обновлённый анонс

Всем доброго времени суток! Недавно я проводил опрос на тему того, что вы думаете о программе "Java Bugs". По вашей драгоценной обратной связи доработал свой анонс. Изменения внёс следующие:

💡 Структура программы
Теперь программа охватывает 15 ключевых тем, выстроенных последовательно от основ к сложным enterprise-проблемам. Мы пройдём полный цикл: от Runtime-исключений и Stream API до тонкостей многопоточности, Apache Kafka, кэширования, тестирования и мониторинга. Каждая тема — частые и критичные ошибки, которые я и мои коллеги и ученики встречали на реальных проектах

👩‍💻 Практический формат
Основа обучения — ваш личный приватный репозиторий на GitHub. В понедельник, среду и пятницу я публикую новый Pull Request с кодом в ваш репозиторий, содержащим типичные баги на заданную тему. Ваша задача — провести код-ревью, найти проблемы и предложить исправления. На следующий день вы получаете развёрнутое решение с теорией и лучшими практиками

🧑‍💻 Сообщество и геймификация
➡️ Еженедельные созвоны по средам в 19:00 для разбора задач, вопросов и всего, что связано с Java
➡️ Рейтинг разработчиков с еженедельным обновлением. Соревнуйтесь, находите больше багов и качайте свои навыки. Победитель получит бонус на выбор в конце программы
➡️ Все материалы доступны в течение месяца после окончания программы. Программа требует около 1 часа в день и легко интегрируется в ваш график

📈 Результаты, которые получит каждый
➡️ Прохождение собеседований. Разбираемые задачи напрямую пересекаются с live-coding на интервью
➡️ Меньше багов. Вы научитесь предвидеть и предотвращать ошибки, что напрямую влияет на качество вашего кода — ключевую метрику для любого разработчика, на которую часто смотрят тимлиды
➡️ Навык качественного код-ревью. Вы не только будете получать меньше замечаний, но и сами станете проводить ревью на совершенно ином уровне
➡️ Закроете пробелы и расширите экспертизу в Spring Boot, Hibernate, SQL, многопоточке и не только

🤑 Стоимость программы изменена
Групповой формат: 30 000 ₽ ➡️ 25 000 ₽
🪵 Доступ к группе и материалам
🪵 Индивидуальный репозиторий для код-ревью
🪵 Еженедельные групповые созвоны

Индивидуальный формат: 60 000 ₽ ➡️ 50 000 ₽
🪵 Всё из группового тарифа, плюс:
🪵 Индивидуальный чат и созвон со мной раз в неделю
🪵 Персональное код-ревью ваших исправлений
🪵 Обсуждение развития вашей карьеры

🗓 Старт — 26 января. Чтобы глубже погрузиться в детали программы, подготовил для вас презентацию. В ней всё разложено по полочкам

❓ Как присоединиться?
Написать в личку слово баг ➡️ @idkhokhlov . Буду рад вас видеть!

👩‍💻 Java Bugs. Первый урок

Друзья, всем привет! Принял решение выложить для вас первую тему моей программы Java Bugs — чтобы вы своими глазами увидели пример и оценили, насколько такой формат будет полезен лично вам

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

➡️ Вот Pull Request с первым заданием:
https://github.com/IDKhokhlov/java-bugs-public/pull/1/files

Что внутри?
🤩 Код с несколькими типичными ошибками на тему Runtime-исключений (NullPointerException, ConcurrentModificationException и другие)
🤩 Задача — провести code-review: найти баги, понять их причину и предложить фиксы
🤩 Формат — как будет в самой программе: код в PR, который нужно анализировать. После каждой темы будет детальный разбор всех ошибок и исправления багов

Зачем я это делаю?
Хочу, чтобы вы:
1️⃣ Прочувствовали формат — каково это работать с практическими задачами через ревью
2️⃣ Проверили себя — сколько ошибок сможете найти самостоятельно
3️⃣ Увидели ценность — насколько разбор таких кейсов может закрыть ваши пробелы

Что дальше?
Уже через пару дней я опубликую в этом же репозитории решение с подробным разбором:
➡️ Почему это вообще баг
➡️ К чему баги могут привести в реальной разработке
➡️ Как правильно исправить и избежать в будущем

Для кого?
Для Java-разработчиков любого уровня, кто:
⭕️хочет прокачать навык code-review
⭕️стремится находить ошибки до того, как они уйдут в прод
⭕️готовится к собеседованиям (часто дают задачи на ревью с целью найти баги)
⭕️просто любит разбирать интересные баги и узнавать что-то новое

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

↗️ Если такой формат вам нравится — жду вас на полной программе Java Bugs, где будет 15 тем, еженедельные созвоны, рейтинг и постоянная обратная связь

Старт — уже в понедельник, 26 января. Чтобы присоединиться, напишите слово Баг ➡️ @idkhokhlov

Увидимся в коде! 🐞

🔥 Менторство. Март 2026

В последнее время выдалось много работы над разными проектами. Давно не выходил на связь, думал, чем порадовать вас. Пришла идея — буду каждый месяц показывать ситуацию на рынке по моим ученикам. Суммы буду указывать в рублях до вычета налогов (gross)

↗️ Первый месяц весны выдался хорошим на офферы. Статистика за март по моим менти ниже

💰 Офферы
Получено офферов: 4
Сумма всех офферов: 1 161k
Максимальный оффер: 320k
Минимальный оффер: 276k

🧑‍💻 Собеседования
Скрининги HR: 23
Технических этапов: 10
Финалов с командой: 4

🪄 Интересный кейс
Один из подписчиков пришел с запросом подготовить его в Revolut на позицию New Grad на Python. Попросил провести моки по всем техническим этапам. Раньше на питоне технички не проводил, но с другой стороны, суть собеседований от языка к языку в Революте не меняется. Взялся помочь. Итог: 2 технички, успешно пройденные собесы и полученный оффер. Горжусь подписчиком, красавец. Очень быстро всё схватываешь, успехов в революте!

Как ваши дела? Сколько собеседований было, какие офферы получали за последнее время?

💳 Spring @Transactional. Вопрос с собеседования

Вопрос с реального собеседования в зеленый банк на позицию Middle/Senior, задача чуть изменена с сохранением изначального замысла. По итогу получили ответ от интервьюера: "Почитайте про механизм прокси". Подобные задачи про механизм транзакций встречаются очень часто. Давайте разбираться. Задача ниже

В Spring Boot приложении есть сервисный класс с двумя методами:

@Service
public class EmployeeService {
    
    @Transactional
    public void updateSalary() {
        // 1: UPDATE employee SET salary = 50000 WHERE department = 'IT'
        
        try {
            validateDepartment();
        } catch (Exception e) {
            // логируем, не пробрасываем дальше
        }
    }
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void validateDepartment() {
        // 2: UPDATE employee SET salary = 30000 WHERE department = 'SALES'
        throw new IllegalArgumentException("Invalid department");
    }
}

Метод updateSalary() вызывается из контроллера. Комментариями имитируется работа с БД. После выполнения в БД окажутся изменения:
1️⃣ Только первое обновление (salary = 50000)
2️⃣ Только второе обновление (salary = 30000)
3️⃣ Оба обновления
4️⃣ Ни одного обновления

Опрос ниже. Пересылайте знакомым, посмотрим, кто как ответит
P.S. Комментарии содержат спойлеры

⭐️ Совместый стрим с Антоном Назаровым

Приходите послушать в субботу, 30 мая, в 14:00 по МСК. Буду одним из спикеров. Поделюсь своими знаниями о том, как точно и без воды рассказывать про свой опыт работы, что притягивает и сразу отталкивает работодателей, на чём ловят кандидатов и какими вопросами "валят". Также будут другие коллеги-менторы, которые расскажут про то, каково сейчас входить в IT в 2026 году. Присоединяйтесь, буду рад

https://t.me/m0rtymerr_channel/3520
https://t.me/m0rtymerr_channel/3520
https://t.me/m0rtymerr_channel/3520

Эфир пройдёт здесь:
https://www.youtube.com/live/9YM4PeiYG4o