Почему на собеседования стоит ходить, даже когда не ищешь работу

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

4 года без собеседований. Была загружена, проекты шли один за другим, всё устраивало. Зачем?

А когда вышла на рынок - столкнулась с реальностью. Сначала нужно пробиться через фильтр HR и AI-скрининга и если это удалось, первые 3–5 собеседований после долгого перерыва могут оказаться провальными не потому, что ты не умеешь работать, а потому, что навык самопрезентации без практики атрофируется.

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

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

Вывод: собеседование раз в полгода — это гигиена карьеры: калибровка с рынком, обмен опытом и поддержание формы.

А вы когда последний раз были на собеседовании до того, как начали искать работу?

Если давно — напишите в комментариях, устроим друг другу тренировочное интервью ❤️

Успевает ли рынок онлайн-образования за технологиями?

Российский EdTech вырос за 6 лет в 10 раз. 154 млрд рублей по итогам 2025 года (Smart Ranking, февраль 2026).

Давайте посмотрим на эти курсы глазами тимлидов, к котором придут выпускники этих курсов.

Курсы по вайбкодингу растут как грибы. Учат работать с Cursor, писать промпты, подключать API. Результат за две недели — готовый Telegram-бот.

Архитектура ПО? В лучшем случае шестой месяц полугодовой программы. Бонусом.

Спрос на базовые IT-курсы уже упал на 13% — рынок перенасыщен (Smart Ranking). Но вместо того чтобы поднять планку — рынок просто переклеил этикетку с “junior developer” на “вайб кодер”.

Исследователи это уже зафиксировали: вайбкодинг разрушает механизм формирования системного мышления и понимания архитектуры (TAdviser, 2025). Человек получает работающий код — но не понимает почему он работает и что сломается первым.

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

Пока этого нет — джуны будут приходить на рынок с красивым инструментом и без понимания как им пользоваться по-настоящему.

По деньгам образование за технологиями успевает. По содержанию — нет.

Давайте поговорим 🙌
Вайбкодер без знания архитектуры — это специалист или дорогой генератор багов?

В комментариях к моему посту про интервью зацепил коммент: «звёздюки базу знают, а токсины от них в команде, увы самопрезентация не выявит». Абсолютно согласна. И вот почему.

У меня был кандидат, который блестяще прошёл интервью.

Вся команда сказала — берём.

Через две недели — ни строчки кода, зато критики на всю команду. Но знаете что? Команда оказалась взрослее и сами разобрались с назначенными на токсика задачами.

И вот тут важное.
Токсик — это не тот, кто спорит.
Спор — это нормально.

Токсик — это тот, кто:
— не берёт ответственность
— не может сказать “я ошибся”
— объясняет провалы внешними причинами
— обесценивает чужие решения фразами вроде “ну это же очевидно”.

И да, можно отрепетировать “я командный игрок”, но на собеседовании всегда есть стресс, по которым проявляется паттерн.

Опыт плюс интуиция обычно не подводят. Иногда просто чувствую — не моё, а потом понимаю почему.

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

Потому что один токсик — это не просто конфликт.
Это падение скорости работы команды.

А скорость — это деньги.

А вы как распознаёте сложных людей на входе? Есть свой приём — или доверяете интуиции? 👇

Начались длинные выходные 🥳
Всех девушек с праздником! 💐

Кто вы из этих двух типов?

1️⃣ Полностью отключаюсь от работы
2️⃣ Читаю статьи, смотрю доклады, разбираю что-нибудь из стека

Я, честно говоря, периодически ловлю себя на втором варианте.

А вы?

Где брать цифры для резюме?

Работодатели любят метрики.

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

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

Вопросы логичные. Но возникает другая проблема — где брать эти цифры?

Несколько лет я вела метрики команды в Excel. В какой-то момент стало интересно сравнить себя с другими тимлидами. Но чужих данных нигде нет.

На длинных выходных я собрала небольшого бота с помощью Claude Code.

15 вопросов, около 5 минут — и в итоге получаешь:
— персонажа по каждому блоку
— примерную позицию среди тимлидов с командой такого же размера.

Персонажи шуточные, инсайты — иногда не очень 😄

У меня, например, в блоке «Здоровье команды» получился Реаниматолог. Совпало примерно на 70%.

Теперь интересно посмотреть статистику.

Какой вы тимлид?

Пройдите тест и делитесь в комментариях, что получилось.
Можно скрином или просто названием персонажа 🙌

НФТ. Их не видно, пока система не падает.

Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет. Их нельзя показать на демо, за них не платят отдельно и в бэклоге всегда есть фичи «поважнее». До первого инцидента.

Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.

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

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

Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?

Продолжаем тему нефункциональных требований

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

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

Очевидно? Да. Но именно это забывают заложить до начала разработки.
Декомпозиция этих пунктов будет зависеть от вашего стека и инфраструктуры — универсального чеклиста нет. Это отправная точка для разговора с архитектором.

А у вас был случай когда безопасность закладывали уже после инцидента?

Почему НФТ не выживают в отдельном эпике в бэклоге и чему меня научили 2 спринта рефакторинга перед релизом.

После фейла с нагрузочным тестом перед релизом и двух спринтов на рефакторинг я перестала выносить НФТ отдельным эпиком.

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

На такие задачи я закладываю 10–25% времени плюсом к базовой оценке в зависимости от сложности и требований.

Единственное условие: команда понимает что и зачем заложено. Иначе это просто раздутые оценки.

Как закладываете НФТ вы — явно или негласно?

Аналитики и дизайнеры в спринте: в общем потоке или отдельно?

Мы делали и так, и так. Дизайн и аналитика шли в один спринт с разработкой — задачи начинали реализовывать синхронно.

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

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

Это частая история и пока демо проводят "для своих", все понимают правила без слов, но при росте продукта и количестве стейкхолдеров, присутствующих на демо, процесс рассыпается.

А как устроено у вас?

Аналитика в спринте: схема, которая работает

И это выделенный спринт на опережение. Пока команда закрывает техдолг — аналитики и дизайнеры уходят вперёд на 1–2 спринта.

Техдолг перестаёт быть простоем и становится окном. Раз в квартал такая синхронизация просто необходима каждой команде.

Плюс мне удобно вести задачи аналитиков и дизов на отдельной доске, изолированной от основного спринта. Никакой путаницы на демо и это "на новый од ещё не готово, это аналитика".

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

Как у вас — аналитика живёт на общей доске или отдельно?

Каждый второй спринт — срыв scope

Это были мои первые полгода в управлении командой.

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

Мне казалось: вот задачи, вот люди, вот дедлайн. Что тут может пойти не так?

Оказалось, всё.

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

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

Что изменилось:

Первое: декомпозиция до старта. Мы перестали брать в спринт задачи формата «сделать фичу Х». Каждая задача дробится до уровня, где можно оценить и проверить по отдельности. Это больно и долго на планировании, зато спринт перестаёт быть чёрным ящиком.

Второе: буфер. 15–20% ёмкости спринта — на незапланированное. Не на конкретные задачи, а просто на то, что обязательно прилетит. Потому что оно ВСЕГДА прилетает.

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

Четвёртое: команда стала точнее декомпозировать и оценивать задачи т.к. мы стали разбирать ретроспективы честно. Ошибся в оценке на два дня? Давай поймём почему, без обвинений. Через 3–4 спринта точность выросла как будто сама.

А 20%, которые остаются? Бизнес меняет приоритеты потому что рынок не ждёт и постоянно прилетают уточнения, которых не было на этапе аналитики. Или другие команды задерживают API, от которого зависит твоя задача. Идеальных условий не бывает.

Предсказуемость спринта — одна из метрик, по которой можно понять, как на самом деле работает поставка. Не velocity, которую легко подкрутить размером задач, а именно процент спринтов без срыва scope. Ни Jira, ни Яндекс Трекер эту метрику автоматически не считают — burndown покажет scope change внутри спринта, но накопленную статистику по спринтам придётся вести руками.

А у вас какой процент срывов? И что помогло его снизить?

Штатная команда: когда все свои

Первый пост (и очень длинный) из серии про типы команд. Начну с классики — все в одной компании/группе компаний, один работодатель.

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

Но у любой модели есть цена. Хотя если команда распределённая — часовые пояса и доступы догонят и тут.

Сначала плюсы)

Всё внутри. Кодовая база, документация, архитектурные решения, экспертиза по продукту принадлежат компании. Единые стандарты качества, CI/CD и инфраструктура под контролем. Решения принимаются быстрее — не нужно согласовывать изменения с внешним подрядчиком. И команда живёт с последствиями своих решений поэтому техдолг не копится бесконтрольно.

Безопасность коммуникации. Вся переписка по продукту — внутри корпоративных средств. Меньше риск утечки, проще контролировать доступы.

Единая среда. Корпоративные мероприятия, общие стандарты разработки, одинаковые праздники и выходные. Снижает трение в ежедневной работе т.к. одни правила для всех.

Долгий и глубокий контекст. Нет резкого переключения между проектами — человек живёт в продукте месяцами. Но дело не только в коде. Корпоративная среда даёт понимание, для кого ты строишь. Я однажды ездила на площадку добычи нефти помогать проводить конкурс профмастерства. После того как познакомилась с мастерами, которые каждый день работают с планшетами — фраза «проектируем интерфейс под крупные руки операторов» перестала быть абстракцией. Всегда есть контекст, который сложно передать в ТЗ. (фото с той самой поездки. 2018г.)

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

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

Менторинг, обучение, рост грейдов — всё это имеет смысл, потому что человек остаётся в компании. По крайней мере, вероятность сохранить сотрудника выше. Риск «научился и ушёл» есть всегда, но в внутри компании есть возможность повлиять на среду, которая удерживает — от корпоративного обучения и ДМС до нематериальных вещей вроде причастности к продукту.

Но у инхауса есть своя цена.

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

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

Скорость масштабирования. Нужно ещё два разработчика на следующий месяц? Это найм, онбординг и 2–4 месяца до продуктивности. В других моделях может быть быстрее (при определенных обстоятельствах).

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

Штат — это фундамент. Но фундамент работает, когда на нём строят осознанно, а не "как пойдет".

Следующий пост будет про смешанные команды, где штатные разработчики и подрядчики работают бок о бок.

Какая у вас модель? Полный инхаус, миксуете или полный аутсорс?

Аутстафф: одна команда, два работодателя

Второй пост из серии про типы команд.

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

Это самая распространённая модель в крупных компаниях. И самая коварная потому что выглядит как единая команда, а управляется как две.

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

Что работает

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

Гибкость. Нужно усилить команду на три месяца под релиз — подрядчики. Без расширения штата и долгосрочных обязательств.

Свежий взгляд. Люди из других проектов приносят практики, о которых инхаус-команда могла не знать.

Где обычно болит.

Два контекста. Штатные знают продукт глубоко, подрядчики — поверхностно. Со временем разрыв растёт, если с ним не работать.

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

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

Операционка множится. Таблица отпусков, отгулов, контактов на случай экстренной связи, рискует переехать во внешний контур, потому что вести две неудобно, хотя команда как будто одна. Важно с самого начала организовать единый инфраструктурный слой — хранилище кода, CI/CD, трекер, вики. Это можно разместить как на мощностях заказчика, так и на стороне подрядчика. Обычно выбирают где проще и дешевле.

Code review. Стандарты кода у штатных и подрядчиков часто разные. Без жёстких гайдлайнов и линтеров — ревью превращается в бесконечный пинг-понг.

Как с этим жить

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

Единые стандарты кода — не рекомендация, а требование.

Онбординг для подрядчиков — такой же, как для штатных.

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

Код — заказчику. Об этом договариваются на старте, а не при расставании. Хранилище на стороне заказчика, версионность обязательна и вся экспертиза и кодовая база остаются внутри, даже если пишут её подрядчики.

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

Следующий пост про аутсорс — когда проект передают в разработку целиком.

А у вас как — штатные и подрядчики сработались или живут параллельно?

Тимлид, Engineering manager, Delivery Manager — три роли, ноль подходящих вакансий

Месяц поиска работы. Ни одна вакансия не совпадает с тем, что я делала последние годы.

В Газпромнефть-ЦР у меня было всё сразу: код, развитие людей, планирование релизов, коммуникации с заказчиками. Внутри компании это работало — все знали, кто я и что делаю. Снаружи — ступор. Опыт есть, а вакансии под него как будто нет.

Потребовался месяц разбора вакансий и десятки отказов, прежде чем я поняла: моя основная роль — Delivery Manager. Не чистый тимлид, не чистый EM. Человек, который держит процесс, сроки и мост между командой и бизнесом.

Три роли — если коротко:

Тимлид — технический лидер. Код, архитектура, ревью, рост инженеров.
EM — про людей. Менторство, культура, конфликты, развитие.
DM — про систему. Планирование, риски, коммуникации, delivery.

На практике границы размыты. Особенно в компаниях, где тимлид — это «и швец, и жнец». Ты делаешь работу трёх ролей, но в резюме это не укладывается ни в одну.

Самое полезное, что я сделала — перестала искать вакансию, которая совпадает на 100%. Вместо этого разобралась, какая роль в моём опыте основная, а какие — дополняющие. Сразу стало понятно, куда откликаться и как описывать себя.

Если вы тимлид и чувствуете, что переросли чистую техническую роль — возможно, вы уже делаете работу DM или EM. Просто ещё не назвали это правильным словом.

Кто проходил через такой же ступор при поиске — как разобрались?

#лебедева_ит #лебедева_команды

Аутсорс: скорость на входе, сюрприз на выходе

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

Звучит удобно: не нанимаешь, не управляешь, платишь за результат. На практике — самая непрозрачная модель из всех.

Что работает.

Скорость старта. Команда уже собрана. Если дедлайн горит, а нанимать некогда — аргумент реальный.

Доступ к экспертизе, которую нет смысла растить внутри. Разовая задача на незнакомом стеке — логичнее отдать, чем учиться.

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

Где обычно болит.

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

Код приходит в конце. Демо не было совсем или раз в месяц — формальные, без возможности задать вопросы. Посмотреть код в процессе и хотя бы верхнеуровнево оценить архитектуру — не предусмотрено договором. Принимаешь то, что есть. Качество как лотерея: код не по стандартам, документация отсутствует, архитектурные решения спорные. Разбираешь, переписываешь, затыкаешь дыры.

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

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

Нет продуктового контекста. Внешняя команда проектирует по ТЗ, а не под реального пользователя. Разница видна сразу — в интерфейсных решениях и в приоритетах при конфликте требований.

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

Без прозрачного процесса аутсорс — это чёрный ящик с дедлайном. Что внутри узнаешь только когда откроешь.

Был опыт приёмки аутсорс-проекта? Что обнаружилось первым?

#лебедева_ит #лебедева_процессы