🧠 Почему soft skills для IT-специалиста не менее важны, чем hard skills?

Многие разработчики фокусируются исключительно на технологиях — мучают фреймворки, библиотеки, паттерны. Это важно. Но есть вторая сторона — soft skills, и именно они часто становятся причиной успеха или провала.

💬 Что такое soft skills?
Это не «умение красиво говорить». Это про:
— умение донести свою мысль,
— адекватно воспринять критику,
— задать вопрос,
— объяснить техническое решение,
— понять бизнес-задачу,
— вести диалог с дизайнером, менеджером, коллегой.

📖 История из практики:
Один из моих учеников — крутой технарь. Он знал, как работать с оптимизацией, писал чистейший код, знал React буквально вдоль и поперёк. Но… его не брали на работу.

Почему? На собеседованиях он мямлил, не мог сформулировать, зачем использовал то или иное решение, а от стресса просто начинал курить в микрофон. На звонках с менеджером терялся и молчал. Коммуникация — 2 из 10.

Мы начали прокачивать именно soft-навыки: уверенность, структура, подача. И всё изменилось. Его взяли туда, куда он даже не рассчитывал. Зарплата — вдвое выше, чем он ожидал.

🔥 Почему это важно:
— Лучшие предложения получают не самые умные, а самые понятные.
— Ты можешь быть крутым технарём, но если не можешь объяснить, что ты сделал — тебя не услышат.
— Любая карьера в IT (тимлид, архитектор, разработчик) требует общения.
— Даже если ты интроверт, ты должен уметь донести суть — спокойно, уверенно, по делу.

💡 Что прокачивать:
— Навык общения: говори чётко, спокойно и по делу.
— Эмпатия: умей слушать, понимать контекст и работать в команде.
— Инициативность: старайся предлагать улучшения, а не просто "пилить таски".
— Умение принимать критику и задавать уточняющие вопросы.

📌 Вывод:
Hard skills делают тебя хорошим специалистом. Soft skills — делают тебя ценным сотрудником и человеком с которым хотят работать.

А вместе они делают тебя незаменимым.

🧠 Почему тебя не зовут на техническое собеседование?

Многие уверены: если ты знаешь React, Typescript и умеешь верстать — тебя должны звать. Но в реальности собесы проходят совсем не те, кто «знает библиотеки и фреймворки».

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

💬 Что происходит на самом деле:
— Резюме написано в стиле «HTML, CSS, JS. Участвовал в проектах. Разрабатывал.».
— Тестовое — копипаст или сделано за вечер «на отвали».
— На отклики никто не отвечает — ты не понимаешь, что не так.
— Никакой стратегии. Просто отклики в никуда.

📖 История из практики:
Один из моих учеников жаловался: «прохожу курсы, делаю проекты, а меня игнорят». Мы начали с разбора его резюме.

Там не было ни одного конкретного достижения. Просто: «делал компоненты», «работал с API». Без цифр, без результата, без акцентов. Рекрутеры такое не читают — они пролистывают.

Потом посмотрели тестовое — оно было. Но без описания, без деплоя, без README. А задача — типовая из курса.

После доработки этих двух вещей он получил 3 приглашения на тех-собес за неделю. Причём в компании, где до этого ему не отвечали.

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

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

💡 Что нужно прокачать:
— Писать коротко и конкретно: не «делал», а «реализовал X → получил Y».
— Готовить тестовое так, чтобы его можно было продать.
— Говорить уверенно: объяснять свои решения и видеть боль бизнеса.

📌 Вывод:
Знания — это важно. Но оформление и коммуникация — это то, что открывает тебе дверь на собеседование.
Если ты хочешь на тех-собес — сначала стань кандидатом, с которым хочется поговорить.

💬 Готов разобрать твоё резюме, тестовое или подход — пиши.

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

👨‍💻 Как я завалил 3 собеса подряд — и почему это пошло мне на пользу?

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

💬 Что происходило:
— Я путался в базовых вопросах, хотя знал их.
— На задачах тупил от стресса.
— На вопросы типа «в чём твоя сильная сторона?» говорил что-то про «умение учиться».

Итог — отказ, отказ, отказ.

📖 Разбор одного собеса:
Меня спросили: «Почему вы выбрали именно Redux, а не Context API для глобального состояния?»

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

🔥 Что я понял:
— Знать и объяснить — вообще разные вещи.
— Если ты теряешься под давлением — ты теряешь и шансы.
— Уверенность — это не врождённое, это тренируемое.

💡 Что помогло:
Я записал все вопросы, которые встречал. И научился не просто отвечать, а объяснять.

Я рефлексировал после каждого пройденного мною интервью.

Прошёл мок-собес со знакомым техлидом, который разнёс меня, но дал фидбэк.

Прокачал структуру мышления, начав отвечать как архитектор, а не как «ученик с курсов».

Подготовился по уже собранной базе вопросов.

Через 2 недели получил оффер с окладом выше, чем ожидал.

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

Делись в комментах, на чём ты сыпался чаще всего? Задача? Формулировки? Рассказ про свой опыт?

Обсудим и разберём это в следующих постах.

🗣 Ты бы взял джуна с «накрученным» опытом?

🎯 Ситуация следующая. Ты тимлид. К тебе приходит кандидат.
У него хорошее резюме, коммерческий опыт, команда, процессы, стек — всё как надо.

На собесе — держится уверенно, отвечает по делу, код пишет чисто, архитектурно мыслит. Глаз радуется.
Но потом выясняется, что опыта в компаниях не было.
Все проекты — pet’ы, опыт в резюме — накручен, GitHub — фейковый профиль под «команду», он — самоучка, который очень хотел пробиться.

💬 Вопрос: что ты с ним сделаешь?
— Откажешь, потому что «обманул»?
— Или возьмёшь, потому что «умеет делать дело»?

📖 История из практики:
У меня был менти, который несколько месяцев безуспешно рассылал резюме.
Его игнорировали, потому что «нет коммерческого опыта».
Мы сделали с ним фиктивную «команду», проект под неё, документацию, выстроили легенду, расписали в стиле продуктовой разработки. Через 3 недели он вышел на оффер с з/п 130к. На тех-собесе — все были довольны.

Тимлид потом сказал: «Мне плевать, где он это выучил. Он умеет. Остальное — детали».

🔥 Вот что важно:
— Сегодня многие проходят через накрутку. Не от хорошей жизни.
— Кто-то палится, а кто-то наоборот получает крутые офферы.
— Но главное не в том, «накрутил» ты или нет, а то, что ты реально умеешь делать.

💬 Делись своим мнением в комментариях:
— Сталкивался(ась) ли ты с таким?
— Как считаешь, это нормально или зашквар?
— Ты бы взял джуна с «накрученным» опытом, если он реально шарит?

📌 Завтра продолжим тему найма: «Стоит ли делать тестовое на 10 часов, если тебе даже не отвечают?»

Будет жёстко, но по делу, подпишись, чтобы не пропустить.

💬 Стоит ли делать тестовое на 10 часов, если тебе даже не отвечают?

Ты получаешь дефолтное сообщение — «Для начала пройдите тестовое, это обязательный этап».

И тут у тебя внутри включается:
— «А стоит ли вообще?».
— «А вдруг зря убью полдня?».
— «А если они даже не посмотрят?».

📖 История из моей практики:
Когда-то, за примерно 20 откликов я получил 8 предложений сделать тестовое задание без уточнения временных рамок, без оплаты, без гарантий, без всего вообще, каждое из которых я бы оценил не меньше, чем на 5 часов. Поначалу я вообще не собирался их делать, но после решил провести эксперимент. Я выполнил 6 тестовых заданий, отправил репозитории с решением ответным сообщением.
Итог:
— 2 ответили через полторы-две недели «не подошли».
— 3 компании не дали никакого фидбэка вообще.
— 1 просто исчезла.

Я вложил 30+ часов своей жизни и получил ровно ноль результата.

🎯 Что важно понимать:
— Тестовые задания бывают на грани и даже за гранью адекватности.
— Никто не платит тебе за N часов потраченного времени (в 95% случаев).
— Если ты не ценишь свой ресурс — компания тоже не будет.

💡 Как работать с тестовыми:
Заранее уточняй, оплачивается ли тестовое задание (такая практика существует и она действительно рабочая).

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

Пробуй договориться, например: «у меня плотный график, могу выделить 3 часа — показать подход, ок?».

Делай демо, описывай решения, покажи мышление, даже если код не идеален.

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

📌 Вывод:
Ты не обязан делать каждое тестовое, лишь бы понравиться компании/нанимающим.
Ты обязан фильтровать, задавать вопросы и ставить себя на равных — хорошие компании это уважают.

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

💬 Напиши, сколько часов у тебя максимум уходило на тестовое.

Были ли случаи, когда ты пожалел, что вообще сел за него?

📎 Завтра — разбор фидбэка от рекрутеров, о котором обычно молчат.

Обсудим, как это работает в реальности.

📊 Типичный фидбэк от рекрутеров, о котором тебе не скажут.

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

Максимум, что получаешь на выходе, это «Спасибо за участие, вы нам не подходите».

Ты сидишь и гадаешь:
— Я плохо ответил?
— Я показался неуверенным?
— Или всё было нормально, но «не зашёл»?

На самом деле — у рекрутеров есть ответ. Просто тебе его не дают.

📖 Что на самом деле пишут в комментариях к кандидатам (из реальных кейсов):
— «Не особо понравились ответы по софтам, делал акцент на заработной плате».
— «Код норм, но не очень понимает базу, еще и по вилке ожидания слишком высокие».
— «Не умеет аргументировать, отвечает шаблонно, не чувствуется уверенности».
— «Потенциал есть, но маловато опыта, пусть ещё поработает».

А теперь представь, что таких кандидатов — сотни в день. И HR физически не может (и не хочет) каждому это объяснять.

💬 Почему они молчат?
Нет времени — ты не один, им проще не вступать в полемику.

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

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

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

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

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

📖 Вот очередная история из практики:
Один из моих менти тоже получал отказ 4 раза подряд с одной и той же формулировкой: «хороший кандидат, но решили продолжить с другим».
Когда мы начали копать я понял, что он просто не умел озвучивать свои решения.
На всех интервью он молча писал код и ждал, что за него всё скажет результат.
После работы над подачей его позвали сразу в две компании в течение следующей недели.
Отсутствие фидбэка или базовое «Мы решили продолжить с другим кандидатом» — это буквально самый первый сигнал о том, что вы что-то делаете не так.

📌 Вывод:
Если тебе не дают фидбэк — это не значит, что его нет, он есть, просто он у них, а не у тебя.
Твоя задача научиться его добывать и работать с ним хладнокровно.
Не нужно переживать о том, что какой-то тимлид в какой-то компании посчитал, что ты какой-то не такой разработчик или оценил тебя на уровень ниже, чем ты сам ожидал — эта оценка зачастую распространяется только на эту компанию и поменяется на следующем же собеседовании.
Я на своем опыте получал друг за другом две обратные связи в разные компании — «Не дотягиваешь до Middle, не назвал принципы SOLID» и «Прекрасно справился со всеми секциями, мы оценили тебя как Senior и готовы сделать тебе предложение о работе» и это уже должно говорить тебе о многом.

💬 Напиши, получал ли ты когда-нибудь честный фидбэк? Что было в нём самого полезного или самого неприятного?

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

🧠 Как понять, что ты готов к собесам (и не тратить месяцы впустую)?

Одна из главных ошибок начинающих — слишком долго ждать «готовности».
Сначала курсы, потом ещё курсы, потом pet-проекты, потом ещё парочка для уверенности, а потом и выгорание.

Ты не идёшь на собес, потому что думаешь: «Я ещё не дотягиваю. Надо чуть-чуть подучить и доработать портфолио. А что будет, если я не пройду?»

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

📌 Признаки, которые буквально кричат о том, что ты уже готов идти на рынок:
— У тебя есть базовые знания HTML/CSS/JS + фреймворк/библиотека.
— Ты можешь собрать SPA-приложение.
— Ты понимаешь, что такое state, props, lifecycles, async и понимаешь компонентный подход.
— У тебя есть хотя бы 1 pet-проект, который ты можешь объяснить.
— Ты хотя бы раз открыл чужой код и попробовал его понять.
— Ты можешь ответить на вопрос «что ты делал сам, а не по видео?».

У меня был менти, который ждал около 2 месяцев. Всё подтягивал навыки, боялся, что будет «не готов», что ему откажут и на этом его жизнь закончится.
Когда мы всё же начали откликаться, он попал на собес на третий день.
Да, волновался. Да, не на все вопросы ответил. Но уже через 3 недели получил свой первый оффер — просто потому, что вышел на рынок, пока остальные «готовились» дальше.

🔥 Почему важно не ждать:
— «Готовность» к собеседованиям это не точка, а процесс.
— Чем раньше начнёшь — тем быстрее поймёшь, где твои слабые места.
— Рынок не ждёт. Пока ты сидишь за изучением очередной технологии, которая «нужна для работы/собеседований и без нее никак», кто-то уже собеседуется и забирает твое место.
— Пробные собесы это тоже обучение и часто гораздо более эффективное.

📎 Вывод:
Если ты читаешь этот пост и узнаёшь себя в 4+ пунктах выше — иди на собесы. Сейчас. А не «когда доучу ещё Redux, TS и еще пару технологий для работы».

💬 Как просить фидбэк, чтобы тебе действительно ответили?

Ты прошёл собес, а через пару дней получаешь сообщение «Благодарим за участие. К сожалению, вы нам не подходите.».

Ты конечно же хочешь узнать:
— Что пошло не так?
— Почему отказали?
— Где ты ошибся?

Но если просто написать «А можете дать фидбэк?», то в 90% случаев ты получишь тишину.

📌 Почему не отвечают:
— HR боятся токсичных кандидатов.
— У них нет времени на персональные разборы, да и в целом цель у них другая.
— Формально фидбэк не обязателен.
— Ты пишешь слишком общие фразы, и они не знают, как на это реагировать.

💡 Что с этим делать?
Просить точечно, коротко и уважительно. Вот примеры фраз, которые реально работают:
✅ Вариант 1 (универсальный): «Спасибо за возможность пройти собеседование. Если возможно, подскажите какие 1–2 момента я мог бы улучшить в будущем? Очень помогло бы в дальнейшей работе над собой.».
✅ Вариант 2 (HR + тех. интервью): «Спасибо за собеседование. Буду признателен, если сможете обозначить, какие именно моменты показались вам слабее, софт-скиллы, аргументация или техническая часть?».
✅ Вариант 3 (после нескольких этапов): «Благодарю за обратную связь. Чтобы не повторять ошибок в следующих интервью, подскажите, пожалуйста, в чём именно не дотянул? Любая конкретика будет очень полезна.».

📖 Что это даёт:
— Ты показываешь, что готов к росту.
— У тебя появляется вектор и он не «угадайка», а конкретный.
— Иногда HR пересылает это техлиду — и ты получаешь реальный фидбэк, который редко кому дают.

📎 Вывод:
📢 Тот, кто умеет спокойно и точно просить обратную связь растёт в 2 раза быстрее. Именно фидбэк отделяет стагнацию от прогресса.

📍 Завтра покажу изнутри, как проходит менторство, и чем оно отличается от просто «помощи по вопросам».

🧲 Чем менторство отличается от просто «советов по вопросам».

Многие думают, что ментор — это типа «задал вопрос — получил ответ». Как Stack Overflow в Telegram. Но на деле — менторство это не ответы. Это движение.

📌 Что реально происходит на менторстве:
— Мы разбираем, где ты сейчас и где реально хочешь быть.
— Выкидываем 70% всего лишнего из обучения.
— Ставим фокус на то, что даёт результат, а не «чувство занятости».
— Я говорю, где ты косячишь, ибо никто тебе этого не говорит.
— Двигаемся по шагам от хаоса — к офферу.

📖 Пример из практики:
Ко мне пришёл парень с запросом: «Хочу пройти собес, но не понимаю, чего мне не хватает. Я уже всё учил.».

На разборе выяснилось:
— Он не умеет структурировать ответы.
— На собесе ведет себя максимально вяло и отстраненно.
— Не проявляет инициативы.
— Его резюме не даёт понять, кто он вообще такой.

После 2 недель плотной работы он получил:
— Новое резюме, которое работает.
— Структуру ответов, чтобы звучать уверенно.
— Понимание, как думать как middle, а не ученик с курсов.

В итоге начал получать свои долгожданные приглашения на собеседования и шанс проявить себя.

💡 В чём сила менторства:
— Ты не в одиночку.
— Ты не просто учишь — ты двигаешься по конкретной траектории.
— У тебя всегда есть фидбэк, план и поддержка.
— Ты не прокрастинируешь под видом «саморазвития».

📎 Вывод:
Ментор — не гугл с лицом.
Это человек, который тащит тебя в нужную точку, даже когда ты сам сомневаешься.

💬 Если хочешь понять, подойдёт ли тебе менторство — просто напиши. Я честно скажу, поможет тебе это или пока рано.

📍 В следующем посте разберём спорную тему — нужны ли pet-проекты джунам, или это переоценено?

🤔 Pet-проекты — маст-хэв для джуна или переоценённый ритуал?

Когда ты заходишь в любой IT-чат для начинающих тебе сразу говорят «Делай pet-проекты! Без них никуда!», «Компаниям нужен опыт!», «Пиши свою CRM, таск-трекер, Netflix-клон...».

Но правда в том, что pet-проект сам по себе не решает ничего.

📌 Что видят рекрутеры в 90% pet-проектов:
— Туду-лист с тремя тасками.
— Приложение с фейковым API, где всё — просто UI.
— Бесконечный UI-kit без сценариев.
— Клон YouTube с 10 компонентами и без единой бизнес-задачи.

Ты думаешь, что это — опыт, а они видят это как «Ещё один новичок, который повторил курс с YouTube».

📖 Когда pet-проект работает:
— Когда он про задачу, а не про кнопки.
— Когда ты объясняешь, что и зачем сделал.
— Когда видно, как ты принимал решения.
— Когда есть реальный README, структура, логика, архитектура.

📉 Пример провала:
У кандидата 4 pet-проекта в резюме.
На вопрос «А зачем ты делал этот таск-трекер?» он отвечает «Просто хотел попробовать Tailwind + Zustand.».

⚠️ Это не показывает продуктового мышления. Это показывает «я игрался со стеком».

📈 Пример успеха:
У другого кандидата — 1 pet-проект.
Приложение для планирования бюджета, сделанное для реальных пользователей, его друзей.
Всё описано — от проблем до решений, от роутов до бизнес-логики.
И он смог рассказать «Вот где были проблемы. Вот какие решения я принял. Вот что бы я изменил сейчас.».

И выбор был бы в пользу второго кандидата. Не потому что «проект», а потому что мышление.

📎 Вывод:
Pet-проект — не галочка в резюме, это зеркало твоего подхода, логики и зрелости.
Хочешь делать — делай. Но делай не для резюме, а как будто это реальный продукт.

💬 Был ли у тебя pet, которым ты реально гордишься? Или который, наоборот, стыдно показывать?
🔥 — да, я делаю реально крутые и полезные pet'ы.
👍 — они похожи на pet'ы первого кандидата.

📍 В следующем посте разберем, чем отличается код джуна, мидла и синьора на простом примере.

📌 Чем отличается код джуна, мидла и синьора — и почему это считывается за 30 секунд.

Ты написал компонент, всё работает, ничего не падает, но тебе говорят «Пока рано. Код — как у джуна».

Ты не понимаешь в чём вообще проблема, если всё работает?
А проблема — в мышлении, а не в синтаксисе.

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

📖 Представь:
Ты написал компонент, который показывает кнопку, если пользователь админ.
Логика простая:

userRole === 'admin'

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

🧠 Джун пишет так, чтобы «не падало».
⚙️ Мидл так, чтобы было понятно и гибко.
🧱 Синьор так, чтобы это можно было развивать без боли.

Когда ты джун, у тебя одна цель — чтобы работало.
Ты не думаешь о читабельности, разделении логики, архитектуре.
Ты вешаешь useEffect, лепишь условия прямо в JSX, повторяешь код, потому что «ну надо же как-то решить задачу».
Это нормально, но это и есть то, что отличает тебя от следующего уровня.

Когда ты мидл, ты уже понимаешь:
— Тут лучше вынести в хук.
— Здесь нужна нормальная типизация.
— Это можно переиспользовать.
— В этот блок кто-то ещё залезет после тебя.
Ты не просто решаешь задачу — ты думаешь об экосистеме вокруг неё.

А синьор?

Он вообще мыслит слоями:
— Где должна лежать логика?
— Как изолировать изменения?
— Как сделать так, чтобы дизайнер, бэкендер и другой фронт могли с этим работать?
— Что нужно, чтобы фича масштабировалась, если завтра придут новые требования?

📎 Вывод:
💬 Код — это не просто способ «показать, что ты умеешь писать». Это отражение твоего мышления.

Твоя задача — писать так, чтобы тебе самому не было стыдно смотреть на этот файл через 2 месяца.

💬 У тебя был момент, когда ты открыл свой старый код и просто закрыл?
🔥 — конечно был, порой я чувствовал себя не очень от своего же кода, хоть и написал его неделю назад.
👍 — да у меня идеальный код, такого не бывает.

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

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

Не все готовы к менторству. Это не магическая таблетка, не кнопка «получить оффер» и точно не «ответь на пару вопросов и всё решится».

Менторство — это когда ты вкладываешься, слушаешь, меняешься.
Именно поэтому некоторым оно реально не нужно — пока.

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

Это не про уровень, это про позицию.
Ты ждёшь, что тебя вытащат, а менторство — это не спасение, это совместная работа.

📌 А вот когда ты готов:
— У тебя есть цель, но нет чёткого плана.
— Ты устал бегать по кругу и хочешь систему, а не разрозненные советы.
— Готов слушать и пробовать, даже если страшно.
— Хочешь фидбэк, потому что понимаешь его ценность.
— Готов делать шаги, даже если пока не уверен.
— Ценишь своё время и хочешь не просто «плыть по течению», а вырваться вперёд.

📖 Случай из практики:
Ко мне пришёл парень, который делал всё правильно. Pet-проекты, курсы, отклики — всё по гайдам, но он не рос, потому что не видел, что делает не так.
Сказал «Мне нужен человек, который скажет, что во мне видит рекрутер и как это починить». Это яркий пример человека, который был готов к менторству.

Мы работали 3 недели. За это время:
— Он переписал резюме.
— Изменил подачу на собесах.
— Уверенно звучал на звонках.
— Стал получать новые предложения о работе.

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

📎 Вывод:
Менторство — не для тех, кто «ничего не умеет», а для тех, кто хочет расти быстрее и без блужданий.

💬 Готов написать, подходит ли тебе менторство сейчас или пока рано. Просто напиши.

🧠 Где искать вакансии, чтобы тебя не игнорили?

Ты тратишь часы на отклики, рассылаешь резюме, но в ответ либо тишина, либо вежливое «Спасибо, но мы выбрали другого кандидата».

И ты начинаешь думать «Наверное, я слабый. Недостаточно опыта».

На самом деле — ты просто ищешь не там и не так.

📉 Что делают почти все:
— Фильтруют по слову «Junior/Middle/Senior».
— Откликаются на всё подряд без разбора.
— Используют одно и то же резюме и сопроводительное.
— Думают, что главное это количество откликов.

Результат — выгорание, разочарование и 0 офферов.

📌 Где вакансии реально работают:
✅ Telegram-каналы (меньше конкуренции, быстрее отклик):
— @it_match_frontend.
— @rabota_razrabotchikd.
— @frontend_offer.
— и ещё куча региональных/нишевых — по ключу «вакансии + frontend»

✅ Хочешь через GitHub — ищи open source, в которых ищут контрибьюторов.
Многие стартапы так тестят будущих сотрудников.

✅ Discord/Slack коммьюнити.

✅ VC.ru / Tproger / Хабр Карьера.
Компании часто постят напрямую, минуя hh.

✅ LinkedIn (если ты готов работать на английском).
Но не просто размещай профиль — ищи рекрутеров и пиши напрямую.

✅ hirify.me, @g_jobbot.

✅ Отклики напрямую через сайты компаний, а не через сторонние сервисы.

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

✅ И в конце концов HeadHunter, как самый популярный агрегатор вакансий в России.

📖 Что реально работает у моих учеников:
Таргетинг, а не спам. 15 откликов => 3 собеса => 1 оффер.
Всё потому, что каждый отклик был адаптирован под вакансию.

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

Время отклика — критично:
— Если вакансия висит 2 недели — ты уже 148-й в очереди.
— Если реагируешь в течение 1 дня — шансы выше в 3–5 раз.

📌 Алгоритм работы с откликами:
Утром — 15 минут на свежие вакансии и посты в hh / tg / LinkedIn / Хабр Карьера.

Отклик только если:
— Подходишь по стеку.
— Есть что сказать в сопроводительном.

Пишешь в личку (если можно) + делаешь отклик.
Фиксируешь всё в таблицу (да, ты ведёшь учёт, как нормальный менеджер). Тебе всегда должна быть интересна твоя конверсия, чтобы ты мог проводить эксперименты и понимать, что ты делаешь не так.

📎 Вывод:
Дело не в том, что ты не подходишь, а в том, что ты играешь в рынок, в котором все кричат, но никто не слышит.

Хочешь результата — перестань стрелять в воздух, попробуй работать прицельно, расширь свои возможности.

📍 Далее пост о том, как ты сам создаёшь себе потолок, даже когда знаешь всё по технологии.

💭 Внутренний потолок — ты знаешь всё, но не идёшь вперёд. Почему?

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

Это не про «уровень», это про барьер внутри.

📌 Что это может быть:
— Синдром самозванца, якобы «Я ничего не знаю, я просто удачно нагуглил».
— Перфекционизм, такой как «Надо доучить ещё Redux, GraphQL, Docker и вот тогда-то».
— Страх отказа, а-ля «А вдруг я опозорюсь? Лучше не лезть пока не уверен».
— Сравнение с другими, как одно из самых тяжелых — «Он уже в бигтехе, а я никак не сдвинусь с места».

Кажется, что ты «ещё не готов», но правда в том, что ты просто боишься не соответствовать выдуманному образу себя.

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

Когда он начал действовать оказалось:
— Его звали на собесы.
— Он проходил.
— Он умел — просто не верил.

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

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

📌 Как убрать внутренний потолок:
— Перестань ждать идеального момента, его не будет.
— Ходи на собесы как на тренировки.
— Записывай свои ответы и смотри, как звучишь.
— Не сравнивай, ведь у каждого путь свой.
— Говори с менторами, с реальными людьми, а не только с курсами и документацией.

📎 Вывод:
Самое сильное ограничение — в голове. Пробить потолок — это не про технологии, это про состояние «Я не идеален, но я двигаюсь и этого уже достаточно».

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

🧩 Почему продуктовый подход важнее, чем просто «уметь писать код»?

Ты можешь знать React, TypeScript, Webpack и 15 хуков.
Писать чистый, читаемый, даже масштабируемый код.
Но всё равно тебя не повышают, не зовут в сильные команды, не слушают на созвонах.

Почему?

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

📌 В чём суть продуктового подхода?
— Ты не просто кодишь, ты думаешь, зачем.
— Ты умеешь задать вопрос, если не понимаешь задачу.
— Ты знаешь, кто будет пользоваться фичей и что для него важно.
— Ты готов предложить решение, а не просто «выполнить задание».

📖 Пример:
Фронтендеру дали таску «Добавить лоадер при загрузке страницы».

🧑‍💻 Первый разработчик:
«Ок, влеплю спиннер. Всё, победа».

🧑‍🎯 Второй:
«Куда добавить? А если пользователь уже авторизован? А если интернет медленный? Может, skeleton будет быстрее восприниматься? А если мы подгружаем кусками, зачем грузить всё сразу? А что скажет дизайнер?».

Итог следующий, один просто поставил крутилку, а второй улучшил UX, ускорил загрузку, снизил метрику отказов.

🧠 Продуктовый разработчик:
— Не делает «как в задаче».
— Делает лучше, чем в задаче.

📌 Что прокачивать, чтобы двигаться в эту сторону:
— Задавай вопросы «Что мы решаем? Для кого? Зачем?».
— Общайся с дизайнером и продуктом, не бойся предлагать.
— Не бойся выйти за рамки тикета, если можешь сделать лучше.
— Учись смотреть на метрики — откаты, отказы, поведение пользователей.
— Понимай, как твой код влияет на деньги и начинай видеть ценность.

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

📍 Следующий пост будет на тему «Если вы не берёте меня на работу — значит, вам не повезло». Разберем, почему это не высокомерие, а полезное состояние.