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

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

(На старте статьи - ребята с опытом, если не сложно, накиньте свои мысли в комментах. Возможно, наши советы действительно кому-то помогут. Хотелось услышать не только про "накрутку опыта", а и про боевые кейсы)

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

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

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

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

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

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

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

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

Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.

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

Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.

Представь, Бро. У тебя в команде есть один человек, который держит в голове все тонкости проекта. Архитектура - его. Сборки - его. Логика в бекенде, деплой, связи между модулями - тоже он. Всё работает идеально, пока он рядом. Но стоит ему уйти в отпуск, заболеть или, как говорится, попасть под автобус - и всё, команда в ауте, сроки летят, клиенты в шоке.

Это и есть тот самый bus-фактор. В этой статье разберём, почему это не круто, как он возникает, почему так распространён, и главное - как его снизить. Поделюсь личными кейсами, проверенными практиками и нетривиальными приёмами, которые реально работают. Без воды, честно и с примерами из боевого менеджмента.