Карьера в IT: как расти без лишнего шума и не потеряться
Мы изучили два материала — один длинный разговор с опытным разработчиком и тимлидом, другой — честный монолог фронтенд-разработчика о пути от нуля до работы в крупном банке. Суммарно около 75 минут контента, и при всей разнице форматов оба источника сходятся в одном: карьерный рост в IT — это не про правильный стек и не про громкое имя в резюме. Это про фокус, фундамент и умение задавать неудобные вопросы.
Статья будет полезна тем, кто уже работает разработчиком и думает о росте, и тем, кто только входит в профессию. Конкретных советов здесь больше, чем мотивации. Главный вывод одним предложением: если вы хотите расти быстро — сузьтесь, а не расширяйтесь.
Как не попасть не туда: два вопроса, которые меняют всё
Один из самых болезненных сценариев в IT — когда приходишь в компанию с ожиданием интересных задач, а попадаешь на конвейер багфиксов. Это не гипотетическая ситуация. В одном из разборов описан конкретный кейс: разработчик устраивается в известную компанию, на собеседовании обещают системную разработку на C++, а в реальности команда занята правками перед редкими релизами. Итог — уход через месяц.
Проблема не в том, что компания «плохая». Проблема в том, что никто не задал правильных вопросов на этапе найма.
Есть два вопроса, которые стоит задавать на каждом собеседовании — не вместо технических, а после них:
- «Что сложного и интересного ваша команда делала за последние год-два?»
- «Что планируете делать сложного и интересного в ближайший год?»
Если интервьюер мнётся, говорит общими словами или вообще не может ответить — это сигнал. Не приговор, но повод серьёзно задуматься. Команда, которая решает нетривиальные задачи, всегда может рассказать об этом конкретно.
Громкое имя в резюме повышает конверсию откликов. Но реальные навыки вырастают только на сложных задачах — и именно они определяют, пройдёте ли вы следующее собеседование.
Это не значит, что нужно игнорировать крупные компании. Это значит, что нужно проверять, что именно там делает ваша будущая команда — а не что делает компания в целом.
Фундамент или фреймворк: что реально защищает от устаревания
Один из самых распространённых страхов разработчика — «я учу не то» или «то, что я знаю, скоро устареет». Этот страх подпитывается постоянным потоком новых инструментов, библиотек и подходов.
Короткий ответ: фреймворки устаревают. Основы — нет.
Архитектура компьютера, алгоритмы, структуры данных, сетевые протоколы, принципы работы операционных систем — эти знания актуальны десятилетиями. Они переносятся между стеками без потерь. Разработчик, который понимает, как работает память, почему регулярное выражение может съесть CPU на высоконагруженном сервисе (реальный пример с трафиком 11 ГБ/сек), или чем отличается репликация от шардирования — такой разработчик адаптируется к любому новому инструменту быстро.
Разработчик, который знает только синтаксис последнего фреймворка — нет.
Что конкретно входит в «базу», о которой стоит думать:
- Алгоритмы и структуры данных (хотя бы на уровне понимания сложности)
- Принципы работы сетей (TCP/IP, HTTP, DNS — не на уровне энциклопедии, но на уровне понимания)
- Базы данных: реляционные и нереляционные, транзакции, индексы
- Операционные системы: процессы, потоки, память
- Паттерны проектирования — не все, но основные
Это не значит, что нужно читать учебники вместо работы. Но если у вас есть 2-3 часа в неделю на самообразование — лучше потратить их на «Высоконагруженные приложения» Клеппмана или курс по алгоритмам, чем на очередной туториал по новому фреймворку.
System Design: почему большинство готовится неправильно
System Design — это отдельная боль. Особенно для тех, кто целится на позицию senior или выше. Разберём по пунктам, где люди теряют время.
Ошибка первая: учить всё подряд
На собеседовании по System Design не нужно знать всё. Нужно знать 20% базы, которые закрывают 80% вопросов. Эта база выглядит так:
- Кэширование — когда и зачем, Redis, инвалидация кэша
- Балансировка нагрузки — L4 vs L7, round robin, sticky sessions
- Проксирование — прямой и обратный прокси
- Репликация — master-slave, eventual consistency
- Шардирование — горизонтальное разбиение данных
- Микросервисы — плюсы, минусы, когда это оверкилл
- Очереди сообщений — Kafka, RabbitMQ, зачем нужны
- Основные паттерны — CQRS, Event Sourcing, Saga
Это не исчерпывающий список, но это то, с чего нужно начать. Не с Kubernetes internals и не с алгоритмов консенсуса.
Ошибка вторая: путать работу с собеседованием
На работе System Design — итеративный процесс. Вы обсуждаете с командой, рисуете диаграммы, возвращаетесь, правите, снова обсуждаете. Это может занять недели.
На собеседовании у вас час. И задача — не найти идеальное решение, а показать структуру мышления: как вы задаёте уточняющие вопросы, как расставляете приоритеты, как обосновываете компромиссы.
Это разные навыки. И если вы хорошо проектируете на работе, это не значит, что вы хорошо пройдёте собеседование по System Design. Навык нужно тренировать отдельно.
Как тренироваться
Раз в неделю берёте задачу — «спроектируйте YouTube», «спроектируйте мессенджер», «спроектируйте систему уведомлений». Ставите таймер на час. Рисуете архитектуру на бумаге или в Excalidraw. Записываете рассуждения вслух или текстом.
Потом можно скинуть результат в ChatGPT и попросить указать слабые места. Это не заменит живого ревью, но как инструмент самопроверки — работает.
После 8-10 таких сессий паттерны начнут повторяться, и вы перестанете теряться на реальном интервью.
ИИ в разработке: эволюция, а не революция
Тема неизбежная. Разберём без паники и без эйфории.
ИИ-инструменты в разработке — это новая версия поисковика. Не замена разработчику, а эволюция инструмента. Поисковик в своё время заменил книги как основной способ найти информацию. ИИ сейчас делает то же самое с поисковиком.
Что это значит на практике:
Где ИИ реально помогает: - Генерация шаблонного кода — быстро и без ошибок - Перевод реализации алгоритма с одного языка на другой (например, с Python на Go) — экономит время на рутине - Объяснение незнакомого кода - Генерация тестов - Первый драфт документации
Где ИИ опасен без экспертизы: - Генерация кода с неявными проблемами безопасности - Игнорирование специфики проекта (например, выброс исключения там, где это недопустимо по архитектуре) - Производительность — ИИ не знает, что ваш сервис обрабатывает 11 ГБ/сек трафика, и может предложить «тяжёлое» решение
Конкретный пример из разборов: ИИ генерирует несколько вариантов функции поиска элемента. Один из вариантов выбрасывает исключение. В большинстве проектов это нормально. Но если в вашем проекте исключения в этом месте недопустимы по архитектурным причинам — ИИ об этом не знает. Он сгенерирует «правильный» с точки зрения общей практики код, который сломает вашу систему.
Вывод простой: ИИ — это умный ассистент, а не замена понимания. Чем глубже ваша экспертиза, тем эффективнее вы используете ИИ. Чем меньше вы понимаете — тем выше риск, что вы не заметите проблему в сгенерированном коде.
Базовые принципы — архитектура, алгоритмы, паттерны — ИИ не переписывает. Он работает поверх них. Поэтому программы обучения System Design и алгоритмам не требуют переработки из-за появления ChatGPT.
Путь с нуля до первой работы: что реально работает
Перейдём к другому масштабу. Не senior-уровень, а вход в профессию.
Мы изучили историю фронтенд-разработчика, которая прошла путь от первого знакомства с HTML до работы в крупном банке за 2,5 года. Без платных курсов на старте, без ментора, без готовой дорожной карты.
Несколько наблюдений, которые показались нам важными.
Метод «повторяй, пока не сможешь сам»
Основной метод обучения — YouTube плюс повторение за видео. Звучит банально, но суть не в самом YouTube. Суть в критерии остановки: не «посмотрел и понял», а «могу сделать это сам без постоянного гугления».
Это принципиальная разница. Большинство новичков смотрят видео, кивают, идут дальше — и через неделю не могут воспроизвести то, что «поняли». Реальное освоение — это когда вы закрываете видео и делаете то же самое самостоятельно.
Первый проект — не шедевр, а рабочий артефакт
Первый полноценный проект — сайт о погоде с открытым API. «Кривой, косой», по словам автора, но рабочий. И он работает до сих пор.
Это важная установка. Первый проект не должен быть красивым. Он должен решать реальную задачу и работать. Именно это показывает работодателю, что вы можете довести что-то до конца.
Хакатоны как ускоритель
Около шести хакатонов за период обучения. Один из них — с Web3 и криптокошельками, где нужно было за одну ночь разобраться с незнакомой библиотекой и подключить её к проекту.
Хакатон — это стресс-тест. Он прокачивает способность быстро разбираться в незнакомом коде, работать в команде под давлением и доводить что-то до демо за ограниченное время. Это ровно те навыки, которые нужны на реальной работе.
Аутсорс как школа собеседований
Интересный паттерн: аутсорс-компания была заинтересована в том, чтобы «продавать» своих разработчиков клиентам. Поэтому она активно обучала сотрудников проходить собеседования и составлять резюме.
Результат — огромное количество реальных интервью, глубокое погружение в теорию JavaScript (промисы, замыкания, Event Loop, асинхронность, оптимизация), конспект по всем темам, которые могут спросить.
Это нетипичный взгляд на аутсорс. Обычно его критикуют за рутину и отсутствие роста. Но как этап подготовки к переходу в продуктовую компанию — может работать очень эффективно.
Адаптация резюме — не опция, а обязанность
При трудоустройстве в банк резюме было переработано: опыт из стартапа и аутсорса объединён в один проект, акцент сделан на релевантных задачах — оптимизация, работа с большими данными. Весь остальной опыт — убран или минимизирован.
Это не обман. Это фокус. Рекрутер смотрит резюме за 30 секунд. Если он не видит релевантного опыта сразу — он идёт дальше.
Практический раздел: что делать прямо сейчас
Разберём по пунктам — в зависимости от вашей ситуации.
Если вы джуниор или только входите в профессию
- Освойте основы до уровня «могу без гугления» — HTML/CSS, потом JavaScript. Не переходите к следующему этапу, пока не можете сделать простую задачу самостоятельно.
- Сделайте первый проект с реальным API — погода, курсы валют, новости. Что угодно, что работает и решает задачу.
- Выберите один фреймворк — React, Vue или Angular. Не все три. Один. Учите его до уверенного уровня.
- Участвуйте в хакатонах — хотя бы в одном. Это даст больше опыта за 48 часов, чем месяц туториалов.
- Не игнорируйте теорию — промисы, замыкания, Event Loop в JavaScript — это не академическая абстракция, это то, что спрашивают на каждом втором собеседовании.
- Адаптируйте резюме под каждую вакансию — не пишите обо всём подряд. Выделяйте то, что релевантно конкретной позиции.
Если вы middle и думаете о росте
- Проверьте своего текущего работодателя — задайте себе два вопроса из начала статьи. Если ответы вас не устраивают — начинайте смотреть рынок.
- Инвестируйте 2-3 часа в неделю в фундамент — алгоритмы, архитектура, сети. Не в новый фреймворк.
- Начните тренировать System Design — раз в неделю, один час, одна задача. Таймер обязателен.
- Проявите инициативу на текущем месте — найдите задачу, которую никто не хочет брать, и возьмите её. Это открывает возможности быстрее, чем любой курс.
- Используйте ИИ осознанно — как ассистента, не как оракула. Всегда проверяйте сгенерированный код на соответствие требованиям вашего проекта.
Если вы готовитесь к собеседованию прямо сейчас
- Закройте базу System Design (список выше)
- Составьте конспект по теории вашего стека — не читайте, а пишите своими словами
- Пройдите 5-10 mock-интервью — с напарником, на платформах или с ИИ как первым ревьюером
- Подготовьте список вопросов к работодателю — не забудьте два ключевых
- Адаптируйте резюме под конкретную вакансию перед каждым откликом
Что мы заметили: где подходы сходятся, а где расходятся
Изучив оба материала, мы выделили несколько точек пересечения и несколько мест, где взгляды различаются.
Сходятся оба источника:
- Фундамент важнее актуального стека. Оба материала, при всей разнице уровня аудитории, говорят об одном: понимание того, как работает система «под капотом», даёт долгосрочное преимущество.
- Практика без теории — ловушка. Можно научиться делать кнопки работающими, не понимая Event Loop. Но рано или поздно это догонит — либо на собеседовании, либо на продакшне.
- Фокус быстрее распыления. Оба источника, независимо друг от друга, приходят к выводу: концентрация на одном направлении на 2-3 месяца даёт результат быстрее, чем параллельное развитие по нескольким.
Где подходы различаются:
Более опытный взгляд (подход А) делает акцент на системном мышлении и глубине: лучше понять одну технологию до уровня «под капотом», чем знать пять поверхностно. Образовательная философия здесь — «раскапывать абстракции».
Более практичный взгляд (подход Б) — история входа в профессию — показывает, что на старте важнее скорость: сделать что-то рабочее, получить первый опыт, потом углубляться. Теория догоняет практику, а не предшествует ей.
Оба подхода работают — просто на разных этапах карьеры. На старте важно сделать что-то работающее и получить первый опыт. На этапе роста — углубляться и строить системное понимание. Ошибка — применять подход Б на этапе, когда нужен подход А, и наоборот.
Ещё одно расхождение — отношение к аутсорсу. Подход А рассматривает его скорее как ограничивающую среду. Подход Б — как эффективную школу для подготовки к переходу в продуктовую компанию. Истина, как обычно, зависит от конкретной компании и конкретного человека.
Рост — это не про знания, это про действия
Оба материала, при всей разнице форматов и аудитории, сходятся в одном наблюдении: карьерные прорывы происходят не от изучения правильного фреймворка и не от работы в правильной компании. Они происходят от действий — часто некомфортных и неочевидных.
Взять задачу, которую никто не хочет. Предложить улучшение процесса. Записаться на хакатон, не зная технологии. Задать неудобный вопрос на собеседовании. Уйти из компании, когда доход от собственного проекта превысил зарплату.
Закон Питера гласит, что люди поднимаются до уровня своей некомпетентности. В IT это работает немного иначе: вы часто становитесь senior раньше, чем полностью готовы. Это нормально. Нагрузка растёт постепенно, и вы разбираетесь по ходу дела. Главное — не отказываться от возможности из страха не справиться.
Начните с одного действия из чек-листа выше. Не с самого лёгкого — с самого нужного.