Как продавать свои достижения без стыда и кринжа
(и зачем вообще это делать)

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

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

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

А теперь правда номер два:
это не хвастовство. Это умение формулировать ценность своей работы.

Как делать это без кринжа:
1. Говори фактами
Не "я затащил проект", а
→ "запустили фичу за 3 недели вместо 6, потому что я упростил архитектуру"
→ "повысили конверсию на 12%, внедрив рекомендационную логику"
Цифры делают любое достижение внятным.

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

3. Рассказывай через "было — стало"
→ Было: legacy, баги, страдания
→ Сделал: внедрил CI, автоматизировал, переиспользовал
→ Стало: стабильнее, быстрее, дешевле, проще

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

Это пригодится и в резюме, и на собесе, и в performance review.

И главное:
Говорить про свои достижения — это не задирать нос.
Это уважать свой труд.
А если ты сам себя не уважаешь — с чего вдруг это должен делать кто-то другой?

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

Разберёмся, как не допустить этого.

🧱 1. Шаблон — важнее, чем кажется
Не надо изобретать велосипед.
Популярные шаблоны вроде HH или Хабра — это не просто мода.
Они читаемые, привычные и понятные HR'ам.
В них нужная информация быстро находится, а визуальный шум минимален.

❗️Креативные и необычные резюме — это риск.
Хочешь выделиться — лучше сделай это содержанием.

📉 2. Никто не будет читать 10 страниц
Если ты не подаешься на роль CTO в Google — укладывайся в 1–2 страницы.
Большинство резюме открывают на 10 секунд.
Если важное закопано в текст — его просто не найдут.

📌 Сухо, конкретно, по делу.
Твоя задача — зацепить и вызвать желание поговорить.

🏆 3. Забудь про “обязанности” — пиши про “достижения”
Все и так понимают, что ты "разрабатывал", "поддерживал" и "фиксил баги".
Вопрос — что ты при этом сделал полезного?

Вместо:
🛑 “Разрабатывал внутренние сервисы”
Пиши:
✅ “Разработал сервис аналитики, который ускорил отчётность на 60%”

📊 4. Цифры — язык, который понимает бизнес
Достижения без цифр — это просто слова.
Как только ты показываешь эффект — ты говоришь на языке пользы.

🔹 Снизил время ответа API с 500ms до 80ms
🔹 Увеличил конверсию на 15%
🔹 Автоматизировал задачу, экономя 10 часов в неделю команде

Вот такие формулировки работают.

🎯 Главное правило — резюме должно продавать твой опыт
Чем понятнее, лаконичнее и конкретнее оно будет — тем выше шанс, что тебя позовут.

Если тебе сложно оценить своё резюме — покажи его другу, ментору или коллеге.
А ещё лучше — попроси у них честный фидбек: «Ты бы меня позвал на собес по этому резюме?»
(Ну или вы можете написать мне и получить отличный фидбек)

Когда мы говорим "развиваться", чаще всего в голове всплывает одно — новый грейд, новая роль, повышение.
📈 Рост = апгрейд в тайтле на hh.

Но это не всегда так.

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

🔧 Бывает рост вширь — ты начинаешь закрывать больше зон: разговариваешь с продактом, декомпозируешь фичи, пишешь техдолг в беклог, предлагаешь решения, смотришь на метрики.
Ты начинаешь понимать, как устроен продукт, как думает бизнес, какие цели у команды.

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

Хочешь расти?
Задай себе три простых вопроса:
— В какую сторону я иду сейчас: вглубь или вширь?
— А не застрял ли я только в одной точке?
— Что я могу прокачать, чтобы стать сильнее и полезнее?

🚀 Настоящий рост — это не всегда про новую роль.
Это про то, чтобы каждый день становиться собой на +1.
Без выгорания, без спешки. Но честно и стабильно.

Я начал уважать себя, когда перестал доказывать, что чего-то стою.

В начале пути я, как и многие, был сильно неуверен в себе.
Если я не знал ответа на вопрос — чувствовал себя плохим специалистом.
Любую критику воспринимал как приговор.
Жил с ощущением, что всё делаю не так, ничего не знаю, и вообще меня взяли по ошибке.

И вот однажды — я сменил работу.
Новое окружение, новые люди… и вдруг оказалось:
я знаю и умею сильно больше, чем казалось.
Моя работа ценится. Мнение имеет вес.

Да, я вырос как специалист.
Но дело не только в опыте.

Я перестал пытаться доказать, что достоин.
Перестал жить с мыслью «я недостаточно…»
— недостаточно умный
— недостаточно опытный
— недостаточно уверенный

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

Очень многое зависит от коллектива и руководства.
Но ещё больше — от того, как ты сам на себя смотришь.

Ты уже достаточно.
Ты не случайно на своём месте.
И с этого стоит начинать.

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

В этой статье я подробно разбираю:

✅ Зачем на собеседованиях спрашивают алгоритмы
✅ Как к ним подходить без паники
✅ Разбор реальной задачи и разные подходы к её решению
✅ Почему алгоритмы — это не про LeetCode, а про инженерное мышление

📌 Если ты когда-то думал(а), что алгоритмы — это бессмысленно, загляни и взгляни на них под другим углом.

👉 Читать статью

Спорт для тех, кто весь день сидит

Я пришёл к спорту не из желания «прокачать тело» — а потому что стало просто невозможно жить.

Когда ты целыми днями за компом, сначала вроде всё нормально. А потом:
– голова болит постоянно
– спина ноет, как у 60-летнего
– шея не поворачивается
– настроение в минус
– устаёшь быстрее, чем успеваешь начать

Я через это прошёл.
С 140 кг я похудел до 99.
Сейчас стараюсь стабильно ходить в зал.
И как только пропускаю спорт — организм сразу напоминает, каким было «до».

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

Совет от души: найдите в жизни место для физической активности. Не потом. Сейчас.

Собеседования: Скрининг

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

📌 Формат
🔹 Отдельная встреча с инженером.
🔹 Первый звонок с HR.
🔹 Первая часть большого собеседования.

❓ Зачем это вообще нужно?
Скрининг проверяет два ключевых момента:

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

2️⃣ Адекватность и коммуникация — умеете ли вы разговаривать, уважаете ли чужое время и воспринимаете ли процесс серьезно. HR не просто так настаивают на звонке, даже если всё уже есть в резюме. Они проверяют, приходите ли вы вовремя, можете ли общаться без мата и насколько заинтересованы в работе.

🎯 Как подготовиться?
✅ Изучи вакансию и компанию — подготовь пару нетехнических вопросов (про условия работы, ценности компании, бенефиты).
✅ Спроси у HR про формат — если будут технические вопросы, тебе об этом скажут.
✅ Повтори основы — сети, ОС, базовые алгоритмы. Например, чем отличается UDP от TCP?
✅ Освежи своё резюме — вспомни ключевые проекты и достижения.

🔍 Как обычно проходит скрининг?
1️⃣ Тебе рассказывают про проект и команду.
2️⃣ Ты можешь задать вопросы.
3️⃣ Просят рассказать о себе.
4️⃣ Уточняют детали по твоему опыту.
5️⃣ (Опционально) Технический мини-опрос.

Если в вакансии есть Kafka, можешь ожидать пару вопросов про неё. Если указаны PostgreSQL или Docker — жди проверки по этим темам.

На скрининге важно не только знание технологий, но и внимательность, заинтересованность, честность (не придумывай того, чего нет в резюме).

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

Например, у моих коллег был случай: на встрече кандидат встал, пошел с ноутом на кухню и начал резать какой-то уроп
А у меня был кандидат, который подключился к созвону в дырявой майке и начал с «Бл*ть, нах** вам этот Zoom, лучше бы в Google Meet пошли», вместо нормального приветствия.
Спойлер: дальше они не прошли.

Скрининг — это первое знакомство. А, как известно, встречают по одёжке.

Вот это новости конечно, придется готовится к аттестации походу...
—

Госдума предложила лицензировать IT-специалистов: без аттестации — работать нельзя
В России может появиться обязательная сертификация для разработчиков, тестировщиков и DevOps-инженеров. По новому законопроекту, внесенному в Госдуму, IT-специалисты должны будут проходить государственную аттестацию раз в три года. Без сертификата о квалификации работать в отрасли станет невозможно.

«Сегодня IT — это стратегическая сфера, и нам важно контролировать уровень подготовки специалистов», — заявил один из авторов инициативы. Аттестация будет включать тестирование на знание алгоритмов, баз данных, сетей и даже основ цифрового этикета. Разработчики, работающие без лицензии, могут получить штраф до 500 000 рублей, а компании — до 5 миллионов.

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

Авторы инициативы уверены, что сертификация поможет повысить качество кадров и «защитить рынок от дилетантов». Законопроект планируют вынести на первое чтение уже в ближайшие месяцы.

Ссылка на источник

Как я справляюсь с синдромом самозванца

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

💭 Почему это вообще происходит?
Мы сравниваем себя с другими – но не целиком, а по отдельным навыкам. Видим разработчика, который пишет идеальный код, другого – который блестяще решает алгоритмические задачи, третьего – который круто шарит в архитектуре. И в итоге кажется, что все вокруг гении, а ты один – “середнячок”.

⚡ Как я с этим справляюсь?
Я принял тот факт, что всегда найдётся кто-то, кто в чём-то конкретном лучше меня. Но не существует человека, который превосходит меня абсолютно во всём.

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

💡 Что ещё помогает:
✅ Фокус на росте, а не на сравнении – задавай себе вопрос «Каким я был год назад?» и радуйся прогрессу.
✅ Общение с опытными людьми – чем больше говоришь с “гениями”, тем больше понимаешь, что у них тоже есть пробелы.
✅ Фиксация достижений – веди список своих побед, даже мелких. Со временем увидишь, сколько всего уже сделал.

Синдром самозванца никуда не денется – но можно научиться не давать ему управлять собой.

Как и обещал, начинаю серию постов про собеседования!

Это вводный пост, в котором я расскажу, как устроены технические интервью, чего от них ждать и на чем основаны мои выводы.

🤔 Откуда я беру всю эту информацию и можно ли мне верить?
1️⃣ Я сам провел 100+ технических собеседований в разных компаниях и на разных этапах отбора.
2️⃣ Регулярно прохожу интервью сам и знаю, как это работает изнутри.
3️⃣ Общаюсь с разработчиками, которые ищут работу, слежу за трендами, мониторю инсайды и держу информацию актуальной.

Опираться на это или нет - решай сам, я лишь хочу поделиться своим опытом и знаниями.

🔎 Как устроены собеседования?
Каждая компания выстраивает процесс по-своему: где-то 4–7 этапов, где-то всего один, но длинный. Уже по этому фактору можно многое понять:

⚡ Много этапов?
Скорее всего, процесс найма похож на воронку. Вас поэтапно оценивают, присваивают грейд, а конкретную команду подбирают потом.
🎯 Один-два созвона?
Скорее всего, вы сразу общаетесь с будущей командой — тимлидом, техлидом или senior-разработчиком.

🔥 Основные этапы технического интервью
Независимо от количества встреч, весь процесс можно разложить на несколько секций:

📝 Скрининг — базовая проверка знаний. Может быть в виде анкеты, опросника или разговора с HR.

🧠 Алгоритмы — задачи на сортировки, поиск, структуры данных, Big O и т. д.

💻 Язык программирования — формат зависит от компании. Это могут быть вопросы-ответы, задачи на глубокое понимание языка, а может быть и то, и другое.

⚙️ "Экспертная" секция — самая важная для middle+ и senior-разработчиков. Может включать system design, базы данных, обсуждение опыта, архитектуру или устройство инструментов.

Важно понимать, что эти секции могут объединяться в одно интервью или растягиваться на 5+ встреч.

📌 Пара общих советов по подготовке:

✔ Читайте вакансию! То, что там написано, с вероятностью 90% будут спрашивать.
✔ Не стесняйтесь спрашивать у HR, какие этапы вас ждут, будут ли задачи, какие темы важно знать. Обычно рекрутеры идут навстречу.

💬 В следующих постах разберу каждую секцию подробнее. Если у вас есть вопросы — пишите в комментариях!

Я немного пропал, довольно сильно был загружен, но исправляюсь! Сейчас снова в деле.

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

А пока можно глянуть несколько прошлых постов:
📌 Почему не стоит бояться собеседований?
📌 Задача на алгоритм Кадане.
📌 Секретный этап собеседования, или перестаньте хамить HR.

Дебют в публичных выступлениях.
Одна из причин, по которой я пропал — подготовка и участие в «Гофер-ферме» Олега Козырева. Выступил с докладом про то, как перестать писать CRUD-сервисы и начать думать как инженер.
Это был мой первый опыт выступлений на живую аудиторию. Было непривычно и местами непонятно, но мне понравилось.

После доклада поболтали на разные темы. Обсудили не только код, но и карьеру в IT, SCRUM и процессы в компаниях.
Вообще я вдохновился и теперь точно хочу выступить еще.

Немного отдохну и начну прорабатывать посты про собесы.
Дальше больше!🔥

Всем привет, срочные новости!

Помимо этого канала, я веду блог в Instagram* — и недавно один из моих рилсов набрал 1🍋 просмотров! Я в шоке и в восторге одновременно.

Еще я заметил, что здесь тоже прибавилось подписчиков, и это безумно радует! Спасибо вам за поддержку — мне правда важно, что вам нравится мой контент.

Дальше больше! 🚀 А пока хочу провести небольшой опрос ⬇️

*Instagram — продукт компании Meta, которая признана экстремистской организацией в России.

Нужны ли знания Scrum для разработчика?

Scrum — один из самых популярных фреймворков в IT. Если вы работаете в команде, скорее всего, сталкивались с ним. Но нужно ли разработчику вникать в Scrum или достаточно просто писать код?

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

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

�� Подробнее рассказал тут

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

🔹 10 лет назад я думал, что к 25 у меня будет четкое понимание жизни, устойчивое мнение на любой вопрос и ясный план на будущее.
Сейчас я думаю, что мнение может меняться, и это нормально. Главное — просто жить и просто делать.

🔹 Везения не существует. Конечно, есть факторы, которые от нас не зависят, но они есть у всех. "Везение" — это совокупность упорного труда и умения подстраиваться под ситуацию.

🔹 Я добился большего, чем ожидал от себя 5–10 лет назад. Но сегодня мне этого уже недостаточно. И что-то мне подсказывает, что мне никогда не будет «достаточно».

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

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

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

Секретный этап собеседования, или перестаньте хамить HR

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

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

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

1️⃣ Разработчика, который спокойно, уважительно и по делу общается, даже если вопросы кажутся ему очевидными.
2️⃣ Или гениального инженера, который показал, что считает рекрутера «hr-юшей» и еле сдерживал раздражение?

Софтскилы сегодня важны не меньше хардов.
Умение договариваться и работать в команде ценится выше, чем токсичный перфекционизм. В следующий раз, когда вам покажется, что HR задает странные вопросы, вспомните — он не просто «закрывает вакансию», а ищет человека, с которым его коллеги захотят работать.

Как не слить собеседование при общении с HR?

✅ Относитесь к HR-интервью как к деловому общению. Не ждите технических вопросов — это не их задача. Будьте готовы рассказать о своем опыте, объяснить мотивацию и ответить на организационные моменты.

✅ Не пренебрегайте софтскиллами. Вас оценивают не только по коду, но и по тому, насколько комфортно с вами работать.

✅ Если что-то раздражает — держите это при себе. HR не виноват, что вас уже в пятый раз спрашивают, почему выбрали именно этот стек.

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

✅ Помните, что HR тоже влияет на процесс. Они могут рекомендовать вас, ускорить процесс, помочь с условиями оффера. А могут и нет. Как думаете, для кого постараются больше?

Мир разработки тесен. Хорошее отношение к людям всегда окупается.

Как писать код, который понимают другие?

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

Почему это важно?
– Через месяц твой код станет для тебя же «чужим».
– Другие разработчики должны быстро разобраться в твоих изменениях.
– Плохочитаемый код усложняет поиск багов и затягивает разработку.

Как сделать код понятным?

📌 Используй хорошие имена.
Переменные, функции, файлы — всё должно говорить само за себя. getOrders() лучше, чем getords().

📌 Пиши короткие функции.
Одна функция — одна задача. Если приходится прокручивать экран вверх-вниз, чтобы понять логику, это плохой знак.

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

📌 Простота важнее умности.
Хороший код не должен выглядеть как загадка для собеседования.

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

Что делать, если код уже есть?

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

🔹 Улучшай постепенно. Не надо пытаться переписать всё сразу — точечные улучшения дадут больше пользы.

🔹 Пиши так, чтобы следующий разработчик сказал «Спасибо», а не «Что за...?»

Читаемый код = удобная разработка + меньше багов + уважение коллег.

А какие у вас правила понятного кода?

Иногда я сталкиваюсь с вопросом «Зачем нужен ментор?».
Вопрос очень резонный, и я бы хотел постараться на него ответить
А еще привести в пример реальную историю успеха.

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

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

Как ментор решает эти проблемы?

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

🔥 Как Виктор за 3 месяца сменил стек и вышел на 500К

Виктор работал PHP-разработчиком и мечтал перейти на Go, но считал БигТех чем-то недосягаемым. Вместе мы разобрали его сильные и слабые стороны, составили план, прокачали алгоритмы, подготовили к собеседованиям и сделали резюме, которое «продает».

Через три месяца у него было три оффера (от Авито, Озона и WB). Он выбрал самый лучший и уже работает в новой команде.

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

🔗Подробнее про его историю можно прочитать тут

P.S. Виктор, ты крутой!

Как я всё успеваю и откуда беру энергию?

Недавно я провёл мини-опрос, и один из самых популярных вопросов был: «Как ты успеваешь столько всего делать?».

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

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

🔗 Читайте здесь

Буду рад вашим мыслям в комментариях! 🚀

Как понять, что ты готов на повышение?

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

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

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

✅ Ты видишь проблемы до того, как они случаются
Не просто кодишь по ТЗ, а думаешь наперёд: как этот сервис будет масштабироваться, где узкие места, что сломается при росте нагрузки.

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

✅ Ты закрыл пробелы в скиллах для следующего грейда
Посмотри грейд-систему компании: если для Senior нужно понимание высоконагруженных систем или менторинг, а ты всё ещё живёшь в CRUD — расти есть куда.

Если ты набрал 2 галочки, то я тебя поздравляю ты готов к повышению.

❓ Что делать, если ты соответствуешь чек-листу?
🔹 Проси фидбек от лида и узнай, что тебя тормозит.
🔹 Подготовь кейсы, доказывающие, что ты уже работаешь на следующий уровень.
🔹 Если роста в текущей компании нет — иди туда, где он есть.

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

CAP-теорема: почему идеальных систем не существует?

Все распределённые системы сталкиваются с треугольником компромиссов: Консистентность (C), Доступность (A) и Устойчивость к разделению сети (P). Это и есть CAP-теорема. Она утверждает, что в реальной системе можно гарантировать только два из трёх свойств.

🔹 Консистентность (Consistency) – все узлы системы видят одни и те же данные в один момент времени.
🔹 Доступность (Availability) – каждый запрос получает ответ (даже если система работает частично).
🔹 Устойчивость к разделению сети (Partition Tolerance) – система продолжает работать, даже если связь между узлами нарушена.

❌ Главный минус CAP-теоремы в том, что она слишком жёсткая. В реальности системы могут балансировать между этими характеристиками. Например, можно ослабить строгую консистентность ради доступности (eventual consistency).

💡 PACELC – улучшенная версия CAP
CAP-теорема не учитывает важный момент: что происходит, когда сеть работает нормально?

🔹 В нормальном режиме системы всегда выбирают между Задержкой (Latency) и Консистентностью (Consistency) – это дополнение формулируется как PACELC:
- PA (Partitioned Availability) – если есть сетевые сбои, система должна выбрать между доступностью и консистентностью.
- ELC (Else Latency vs. Consistency) – когда сеть работает, система балансирует между быстрыми ответами и строгой консистентностью.

📌 Пример:
- CP (консистентность + устойчивость, но не 100% доступность) – Zookeeper, HBase.
- AP (доступность + устойчивость, но без строгой консистентности) – Cassandra, DynamoDB.
- PACELC в действии – Amazon DynamoDB жертвует строгой консистентностью ради доступности и низкой задержки.

👉 Вывод: абсолютного выбора нет, и в каждой системе приходится искать баланс. CAP – хорошая стартовая модель, но в реальности всё сложнее.

Нужны ли алгоритмы в реальной работе?

Очень частый вопрос: «А вот мы их на собесах учим, но в реальной работе-то они вообще нужны?»

Кажется, что нет. Ведь большинство задач – это работа с БД, написание API, обработка данных. Там не нужно писать свой quicksort или реализовывать графы… Или всё-таки нужно?

Разберёмся, где реально применяются алгоритмы в работе разработчика:

⚡ Производительность кода
Когда запрос работает 5 секунд вместо 500 мс, разница колоссальная. Если ты понимаешь, что O(n²) — это плохо, а O(log n) — хорошо, ты сразу видишь узкие места и можешь переписать код эффективнее.

🔍 Оптимизация работы с данными
Любая работа с БД — это алгоритмы. Индексы, хеши, B-деревья — все они используются для поиска и фильтрации данных. Если понимаешь, как они работают, ты сможешь писать быстрые запросы и не грузить сервер миллионами ненужных операций.

📦 Структуры данных в реальных задачах
Ты не будешь писать свой hashmap, но понимание разницы между массивом, хеш-таблицей и деревом поможет выбрать правильную структуру для задачи. Например, где быстрее искать элемент? В массиве O(n), в хеше O(1), в дереве O(log n).

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

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

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

А ты сталкивался с алгоритмами в реальной работе? Если да - напиши, будет интересно почитать реальные кейсы👇

«А почему бы и нет?» – мой путь в IT и БигТех

Многие разработчики думают, что им ещё рано идти на повышение, проходить собеседования или пробовать себя в БигТех. Кажется, что нужно ещё подучиться, подтянуть алгоритмы, разобрать пару архитектурных паттернов… Но правда в том, что идеального момента не будет никогда.

💻 Как я попал в IT
На втором курсе универа я познакомился с преподавателем, который позже стал деканом, и он предложил мне работу C# разработчиком в своей компании. Два года я просто сидел и кодил. Без роста, без повышения зарплаты, без понимания, куда вообще двигаться дальше.

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

⏳ Работал я много. Очень много. Настолько, что к четвёртому курсу у меня было 17 академических долгов. В это же время все вокруг говорили, что айтишники получают космические зарплаты, а я чувствовал себя неудачником – моя зп была ниже средней по Брянску.

🚪 Меня отчислили. И это было лучшее, что могло случиться.

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

🔄 Переход на Go
Один из офферов предполагал полный переход на Go. Фактически – начать с нуля.

💡 Я задал себе вопрос: «А почему бы и нет?»

Я устроился в небольшую аутстаф-компанию и начал «пожирать» информацию – теперь вуз не съедал мои силы и время, и я мог учиться по-настоящему. Поработал на крупных проектах, прочитал больше 20 технических книг, увеличил доход в несколько раз и наконец-то начал понимать, что такое настоящая разработка.

🚀 Выход в БигТех
Спустя год мой коллега и хороший друг сказал: «Ты должен идти в БигТех. У тебя всё для этого есть».

Эта идея меня испугала. Но я снова спросил себя: «А почему бы и нет?»

😳 Мне прислали оффер в первую же БигТех-компанию, куда я проходил собеседование. Я буквально прыгал от счастья.

А потом пришли ещё три оффера.

Я выбрал самый крутой.

🏆 Сейчас я Senior Backend Developer в БигТех. И когда передо мной появляется новая возможность, я больше не думаю «смогу ли я?» или «зачем мне это?».

Я просто спрашиваю себя:
«А почему бы и нет?»

Как считать алгоритмическую сложность и зачем это нужно?

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

🕒 Time Complexity (временная сложность) — показывает, как меняется время выполнения алгоритма в зависимости от размера входных данных.
💾 Space Complexity (пространственная сложность) — оценивает, сколько памяти потребуется программе.

Пример: func sum(arr []int) int {
sum := 0
for _, num := range arr {
sum += num
}
return sum
}

✅ Временная сложность — O(n), потому что цикл проходит по каждому элементу.
✅ Пространственная сложность — O(1), так как не создаётся дополнительных структур данных.

📌 Как считать сложность?
1️⃣ Игнорируем константы и низкоуровневые детали: O(2n) → O(n), O(5n² + 3n) → O(n²).
2️⃣ Смотрим на самые затратные операции: вложенные циклы O(n²), рекурсия O(2ⁿ).
3️⃣ Учитываем сложность структур данных:
- Хеш-таблица даёт O(1) для поиска,
- Сортировка требует O(n log n).

💡 Как упростить подсчёт?
✔ Оценивай худший случай (*Worst Case*).
✔ Запоминай базовые паттерны:
- 🔹 Цикл по списку → O(n)
- 🔹 Вложенные циклы → O(n²)
- 🔹 Двоичный поиск → O(log n)
- 🔹 Разделяй и властвуй (*Merge Sort, Quick Sort*) → O(n log n)

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

🚀 Go 1.24 — новая реализация map! Что изменилось?

В новой версии Go произошел реворк структуры map, вдохновленный SwissTable. Теперь map работает быстрее, особенно на больших объемах данных.

🔍 Как это устроено?
✅ map теперь использует линейное пробирование вместо связанных бакетов.
✅ Каждый бакет хранит до 8 ключей + метаданные (H2 hash bytes).
✅ Поиск происходит через SIMD-векторные инструкции, что ускоряет работу на 30%.
✅ Удаленные ключи не создают "мусор" — их место переиспользуется.
✅ Записи и итерации стали быстрее, так как ключи и значения хранятся раздельно.

⚡️ Что это значит?
🔹 Меньше коллизий → быстрее работает map.
🔹 Оптимизированное удаление → меньше аллокаций.
🔹 Лучше кэш-локальность → прирост скорости на больших данных.

📌 Подробнее:
🔗 SwissTable Design
🔗 Go 1.24 Release Notes

😎 Как думаете, как скоро начнут спрашивать на собеседованиях про новую реализацию map?

Всем привет,
Небольшое обновление по менторским встречам:

Теперь можно посмотреть и забронить слот прямо в Гугл-календаре по ссылке.

Это сильно удобнее:
✅ Сразу видны все доступные слоты
✅ Можно выбрать слот заранее, не дожидаясь, пока я отвечу в личке
✅ На почту, которую вы укажете, придет письмо с ссылкой на встречу

На Solvery все так же остается - нужно бронить через чатик с менеджером, но доступный слот вы можете посмотреть в этом календаре.
Также напоминаю, что solvery берет комиссию, а при записи напрямую этой комиссии нет

Как перестать писать CRUD-сервисы и начать думать как инженер

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

Как выйти за рамки CRUD?

1️⃣ Разбирайся в бизнес-логике — API не просто возвращает данные, а решает конкретные задачи. Понимание продукта помогает проектировать правильную архитектуру.

2️⃣ Изучи архитектурные паттерны — CQRS, Event Sourcing, DDD, работа с очередями и асинхронной обработкой. Это основа масштабируемых систем.

3️⃣ Думай о нагрузке — индексы, нормализация, денормализация, кэширование. Оптимизация базы важна не меньше, чем сам код.

4️⃣ Изучи масштабируемые системы — разбирай архитектуры крупных проектов, экспериментируй с распределёнными системами.

CRUD — это просто инструмент. Настоящая инженерия начинается там, где ты начинаешь думать о системе в целом. Чем раньше сменишь подход, тем быстрее выйдешь на новый уровень.

Немного о себе

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

💻 В IT уже 5 лет
💍 Счастлив в браке
🏡 Родился в Брянске, живу в Москве
🐶 Две собаки — Кузя(поменьше) и Мия(побольше)
⚡ Похудел на 40 кг и теперь регулярно хожу в зал

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

Рад, что вы здесь! 🚀

Чем БигТех в России отличается от небольшой компании?

🚀 Темп работы
— В БигТехе процессы отлажены, но бюрократия замедляет изменения.
— В стартапе хаос: одна задача утром, другая вечером. Но зато всё быстро.

📚 Рост и обучение
— В корпорациях сильная и разнообразная экспертиза.
— В маленьких компаниях приходится решать задачи самостоятельно.

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

💰 Зарплаты и бонусы
— В корпорациях стабильность, бонусы, ДМС, RSU (акции).
— В стартапах оклад ниже, но можно получить долю в компании (но это не точно).

🔄 Гибкость и влияние
— В крупной компании ты винтик: работаешь над кусочком кода.
— В стартапе можно влиять на продукт, предлагать идеи, менять стратегию.

🤔 Что выбрать?
— Если хочется стабильности, роста в глубину, сложных задач — БигТех.
— Если важна свобода, скорость, возможность делать всё — стартап.

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

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

Я, например, практически не готовлюсь к собеседованиям. Просто потому, что регулярно тренируюсь:
✔ Раз в неделю решаю пару алгоритмических задач
✔ Обсуждаю базы, сети и многопоточность с коллегами и менти
✔ Читаю материалы по ключевым темам по ходу работы
В итоге, когда приходит интересное предложение, я уже в форме. Это не стресс, а просто еще одно обсуждение технических тем.

Как встроить подготовку в рутину?
✅ Разбирай задачи по одной в неделю — без марафонов на выживание
✅ Участвуй в разборе архитектуры на работе — интересуйся, почему так?
✅ Обсуждай базы, сети, ОС — чем чаще говоришь, тем увереннее звучишь
✅ Делись знаниями — веди заметки, менторь, объясняй другим

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

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

❌ Страх: Меня завалят сложными вопросами ✅ Реальность: Вопросы подбираются под позицию. Если ты джун, от тебя не ждут глубоких знаний архитектуры или асимптотики. Да, могут спросить сложное, но это не тест на гения, а попытка понять твой уровень.

❌ Страх: Я забуду всё, что знаю ✅ Реальность: Даже опытные разработчики иногда зависают. Главное — не молчать. Лучше вслух рассуждать и показывать ход мыслей.

❌ Страх: Если я провалюсь, обо мне сложится плохое мнение ✅ Реальность: Нет. Не подошел на эту вакансию — найдешь другую. Многие проходят 5–10 собеседований, прежде чем получить оффер.

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

Собеседования — это не стресс, а возможность. Чем раньше ты перестанешь их бояться, тем быстрее выйдешь на новый уровень.