Владимир Балун

📹 Недавно записали интересный выпуск, в котором разобрали две системы, спроектированные на реальных System Design интервью

Обсуждали вместе с Александром с канала @youareageek два реальных System Design интервью: одно успешное - в ZenRows, а второе - в Inworld AI с компенсацией около $350 000 в год, которое завершилось отказом.

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

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

Посмотреть разбор можно по ссылке: https://www.youtube.com/watch?v=aHsi-OHI_i8

Кто я | Навигация | Спасибо

💭 Мне кажется, что все уже устали от разговоров про состояние IT-рынка

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

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

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

❗️Но внешние обстоятельства - это именно внешние обстоятельства.

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

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

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

Кто я | Навигация | Спасибо

⚡ Розыгрыш в честь Дня знаний

В преддверии 1 сентября разыгрываем три приза для развития ваших профессиональных навыков:

• Курс на выбор от balun.courses
• Интенсив на выбор от balun.courses
• Mock-собеседование от it-interview.io

Все условия участия и подробности розыгрыша - по ссылке: https://t.me/balun_courses/431

Кто я | Навигация | Спасибо

💭 Отлично знаете тему, но на собеседовании не смогли нормально о ней рассказать?

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

"Я же это знал. Почему не смог нормально объяснить?"

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

Один из навыков, который здесь помогает, - умение структурировать свои мысли. Например, с использованием фреймворка SCR - Situation, Complication, Resolution. Он помогает выстроить мысль в понятную последовательность: сначала обозначить ситуацию, затем показать проблему или сложность и после этого перейти к решению.

Без структуры:
У нас сервис начал тормозить. Мы добавили кеш, но потом оказалось, что проблема еще и в базе. Нагрузка тогда как раз выросла, хотя раньше всё работало нормально. В итоге пришлось оптимизировать запросы, а кеш мы оставили.

С SCR:
S - Situation: Нагрузка на сервис выросла, и он начал тормозить
C - Complication: Добавление кеша не решило проблему - узким местом оказалась база
R - Resolution: Оптимизировали запросы и оставили кеширование

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

И SCR - только один из инструментов. На тренинге по Soft Skills для IT-специалистов мы разбираем разные фреймворки, техники и подходы, которые помогают лучше формулировать мысли, аргументировать свою позицию и увереннее общаться в рабочих ситуациях.

Кто я | Навигация | Спасибо

Вам доклады по Go или Java? VK приглашает на митап с двойной начинкой

26 августа VK собирает Go- и Java-инженеров, чтобы прокачать знания. В программе два трека - Go и Java, по три доклада в каждом.

Трек Go:
• «Компиляция Go в динамическую либу, или как мы ускорили выкатку фичи в два раза, но нам не понравилось», Михаил Кичигин, бэкенд-разработчик, Avito Tech
• «Go-платформа VK: как мы построили единую основу для создания Go-сервисов», Александр Апанасенко, руководитель команды SDK Backend, VK
• «Почтальон от Kubernetes до Palo Alto. Как осуществляется доставка информации об адресах», Дарья Кулькина, бэкенд-разработчик, Точка Банк

Трек Java:
• «Перформанс-трюки в поисковой платформе Ozon», Пётр Портнов, ведущий разработчик среднего поиска, Ozon
• «Архитектура современного движка платёжной системы и переход к новой архитектуре», Игорь Крикунов, технический лидер разработки DBC, Альфа-Банк
• «Переход от федерации S3-кластеров в пользу коммунального и мультитенантного кластера», Кирилл Боблак, ведущий разработчик One-cloud, VK

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

Встречаемся в 17:00, начало в 18:00. Участие бесплатное, регистрация обязательна.

Кто я | Навигация | Спасибо

📹 Записали новое видео вместе с Олегом Козыревым

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

В видео задавали вопросы по Go, базам данных и Kafka, а также смотрели, где AI действительно помогает, а где знаний и опыта пока не хватает. Получился довольно любопытный результат - некоторые ответы нас действительно удивили!

Посмотреть видео можно по ссылке: https://youtu.be/RfvfHMRLrNE

Кто я | Навигация | Спасибо

💭 Периодически провожу бесплатные консультации в формате Q&A-встреч, где можно задать вопросы про программирование, карьеру, собеседования, развитие в IT и просто обсудить разные рабочие ситуации

Мы специально разделили встречи на два формата:
- отдельно для новичков и тех, кто только пытается войти в IT
- отдельно для разработчиков с опытом, которые уже с опытом

Обычно на таких встречах обсуждаем:
- как эффективнее учиться и что именно изучать
- как готовиться к собеседованиям
- выбор языка, стека или направления
- архитектуру, backend, Go и смежные темы
- проблемы на текущей работе и карьерные тупики

Следующие встречи пройдут 18 и 25 августа.

Участие бесплатное, но записи не делаем - только онлайн присутствие вживую. Если интересно, можно присоединиться по ссылке: balun.courses/open_lessons/qa

Кто я | Навигация | Спасибо

💭 Почему высокая зарплата может тормозить карьеру

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

У многих в голове есть определенная цифра дохода, после которой жизнь станет заметно комфортнее. И вот что интересно: как только эта цифра достигается, отношение к развитию часто меняется. Появляется ощущение, что основная цель уже выполнена. Новые технологии изучаются реже, собеседования откладываются на потом, а дополнительные активности кажутся необязательными. Возникает вполне логичная мысль: «Мне хватает, зачем бежать дальше?»

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

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

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

Замечали ли вы такое у себя или коллег?

Кто я | Навигация | Спасибо

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

Хочу поделиться каналом моих знакомых - https://t.me/+iJkpbcZjJpRjN2Y6

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

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

Кто я | Навигация | Спасибо

💭 «Сейчас сделаем по-быстрому, потом переделаем»

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

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

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

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

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

Кто я | Навигация | Спасибо

💭 В разработке за последние несколько лет произошло много изменений, но если посмотреть глубже, то фундаментально изменилось не так уж много...

Новые подходы? Нет. Новые алгоритмы? Особо тоже нет. Новые паттерны проектирования, которые полностью перевернули индустрию? Тоже не припомню.

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

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

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

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

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

А как считаете вы: AI действительно меняет профессию разработчика или пока что меняется в первую очередь только инструментарий?

Кто я | Навигация | Спасибо

💭 Сегодня в 21:00 проведем эфир с Артемом Бабенко

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

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

Эфир пройдет сегодня в 21:00 по ссылке в YouTube: https://www.youtube.com/live/oAW-IThz3wQ

Кто я | Навигация | Спасибо

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

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

В новом видео рассказал про особенности проектирования и разработки таких систем. Причем не с точки зрения теории или очередного пересказа статей по System Design, а на основе реального опыта работы над системой рейсинга в Яндексе, через которую проходило 10–11 ГБ трафика в секунду.

Посмотреть видео можно по ссылке: https://www.youtube.com/watch?v=4smZmksvLR8

Кто я | Навигация | Спасибо

💭 Технический долг есть не только в коде

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

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

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

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

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

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

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

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

А вы сталкивались с подобным «нетехническим долгом» в командах или своей работе?

Кто я | Навигация | Спасибо

💭 17 октября в Екатеринбурге пройдет HardFest

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

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

Если есть что рассказать про архитектуру, эксплуатацию, инфраструктуру или AI/ML-системы - CFP открыт до 17 августа, а зарегистрироваться можно по ссылке

Кто я | Навигация | Спасибо

💭 Кто уже распланировал весь сентябрь конференциями, митапами и другими IT-мероприятиями?

Ловите анонс мероприятия, которое, возможно, еще не успели добавить в свой календарь. Авито возвращается с Avito.Tech.Conf - конференцией от лидов и для лидов в IT от команды Авито. Нравится, что они каждый раз собирают не просто мероприятие, а реально формируют комьюнити тех, кто привык работать со сложными системами, командами и продуктами.

В программе - доклады, воркшопы, мастермайнды и много возможностей пообщаться с коллегами из индустрии, до кого сложно «дотянутся» в рабочей рутине. Конференция пройдёт 26 сентября в Москве (AG Loft), а зарегистироваться на нее можно по ссылке.

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

Кто я | Навигация | Спасибо

💭 Почему некоторые разработчиков никогда не станут тимлидами

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

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

И тогда я понял одну важную вещь - многие разработчики, которые хотят стать тимлидами, готовятся совсем не к той роли, на которую претендуют. Они думают:
• «Нужно еще глубже изучить базы данных»
• «Нужно лучше разобраться в Kafka»
• «Нужно прокачаться в System Design»

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

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

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

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

Кто я | Навигация | Спасибо

💭 Представьте, что вы решили открыть кофейню

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

Продолжаем или закрываем?

Допустим, вы решили продолжать. В конце концов, уже вложено полмиллиона рублей. Вы инвестируете еще 300 000 рублей в рекламу, обновляете интерьер и пытаетесь привлечь новую аудиторию. Проходит еще несколько месяцев, но ситуация почти не меняется. Клиентов по-прежнему мало, выручка не растет, а убытки продолжают накапливаться.

Продолжаем или закрываем?

Вы решаете дать проекту последний шанс. Берете кредит, вкладываете еще 700 000 рублей, расширяете меню, закупаете новое оборудование и надеетесь наконец переломить ситуацию. Однако спустя полгода рядом открываются конкуренты, аренда дорожает, а кофейня все так же приносит убытки. На этот момент в проект уже вложено 1,5 миллиона рублей.

Продолжаем или закрываем?

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

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

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

Кто я | Навигация | Спасибо

📉 Готовим образовательный продукт про ElasticSearch и поисковые системы

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

• Для каких задач используете?
• Какие сложности возникают в работе?
• Насколько уверенно себя с ним чувствуете?
• Какие темы хотелось бы разобрать глубже?

Подготовили небольшой опрос - займет около 10 минут: https://docs.google.com/forms/d/e/1FAIpQLScftHPWY7zhmuwzQxtW029Gewn2u0O4fG8W3AqiJXN3SICQag/viewform

🎁 Всем, кто даст развернутые и полезные ответы, отправим промокод на скидку 15% на любой курс или интенсив balun.courses

Кто я | Навигация | Спасибо

🎙️ Первый раз побывал не на видео, а на аудиоподкасте

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

Поделился своими увлечениями, рассказал, как они появились в моей жизни и какую роль играют сейчас - послушать подкаст можно по ссылке: https://script.mave.digital/ep-5

Кто я | Навигация | Спасибо