Введение.
Знакомая ситуация? Стажировка перевалила за экватор или уже близится к финалу. Вы вроде бы исправно закрываете таски, фиксите несложные баги, стараетесь не ронять тестовый стенд, но уверенности в завтрашнем дне — ноль. Заветный оффер всё ещё маячит где-то в тумане. При этом вы замечаете, как одного стажёра с радостью забирают в штат, а с другим вежливо прощаются, хотя код они, казалось бы, писали примерно на одном уровне. Почему так происходит?
Давайте начистоту. Бизнес нанимает стажеров не ради их текущих навыков. Прямо сейчас вы не приносите компании прибыли, зато отлично «сжигаете» дорогое время сеньоров и лидов. Вас берут исключительно ради потенциала. Компании нужен человек, из которого можно вырастить крутого, самостоятельного инженера, лояльного к процессам команды. И то, как вы ведете себя в рабочих ситуациях, как общаетесь и как реагируете на трудности, демонстрирует этот потенциал в тысячу раз лучше, чем пара закрытых тикетов в Jira.
За время работы мне довелось поменторить разных ребят: за одних я был готов биться перед руководством, чтобы им выбили ставку, а с другими мы расставались без особых сожалений. Опираясь на этот опыт (и на свои собственные ошибки времен джуниорства), я собрал 5 практических советов. Они помогут вам выстроить работу так, чтобы к концу стажировки тимлид сам пришел к вам с заветным оффером. Погнали.
Совет 1. Держите баланс самостоятельности (или «Правило 30 минут»)
За время работы я насмотрелся на две классические крайности стажеров. Первые превращаются в «чайку»: прилетают каждые пять минут с вопросами вроде «А как гит запушить?» или «Почему у меня кнопочка не центрируется?». Вторые, наоборот, до ужаса боятся показаться глупыми и уходят в глухое подполье. Такой человек может три дня просидеть над пустяковой ошибкой в конфиге, просто чтобы не тревожить старших коллег.
Для бизнеса и то, и другое — красный флаг. В первом случае вы отнимаете слишком много времени у сеньора (а его время стоит дорого), во втором — впустую сжигаете свое, блокируя работу.
Золотая середина — это пресловутое «правило 30 минут». Ваш алгоритм действий при столкновении с затыком должен выглядеть так:
Ищем сами. Идем в Google, на StackOverflow, читаем документацию проекта (да, ту самую внутреннюю вики, которую никто не любит читать) и делаем поиск по истории корпоративного мессенджера.
Пробуем ручками. Пытаемся применить 2–3 найденных варианта решения.
Следим за таймером. Если прошло 30 минут, вы всё перепробовали, а прогресса ноль — стоп. Хватит биться головой в стену, смело идите к ментору. Дальше самостоятельность превращается в неэффективность.
Но тут есть критически важный нюанс — то, как именно вы задаете вопрос.
Навсегда забудьте фразу: «У меня ничего не работает, помоги». От нее у любого лида начинает дергаться глаз.
Вместо этого приходите с готовым контекстом. Правильный запрос выглядит так:
«Слушай, у меня падает вот этот запрос к БД. Я погуглил ошибку, попробовал добавить индексы (вариант А) и переписать джоин (вариант Б) — всё равно сыпется по таймауту. Вот логи. В какую сторону мне вообще копнуть?»
Чувствуете разницу? В первом варианте вы перекладываете свою проблему на чужие плечи и ждете, что за вас всё сделают. Во втором — показываете, что уже проделали аналитическую работу, проявили самостоятельность, и теперь вам нужен просто точечный совет эксперта, чтобы сдвинуться с мертвой точки. Поверьте, именно таких стажеров в командах обожают.
Совет 2. Фидбек — это рабочий инструмент, а не атака на вашу личность
Отлично помню свои первые пулл-реквесты. Ты отправляешь плод своих многодневных трудов, втайне надеешься на похвалу, а в ответ прилетает «простыня» из двадцати комментариев от сеньора. Первая инстинктивная реакция — жуткая обида. Кажется, что до тебя банально докапываются, придираются к мелочам, или, что еще хуже, ты полная бездарность и пора уходить из IT.
Но вот суровая (и на самом деле очень позитивная) правда: правки — это нормально. Идеального кода с первого раза не пишет никто.
Поставьте себя на место ментора. Читать код стажера — то еще удовольствие. Если лид или сеньор тратит свое время на то, чтобы расписать, почему здесь стоит изменить структуру данных или вынести логику в отдельный сервис, он буквально инвестирует в вас. Ему было бы в разы проще и быстрее молча переписать этот кусок самому. Но он оставляет комментарии, потому что хочет сделать из вас крутого специалиста.
Поэтому главное правило на ревью: отключаем эго.
Не нужно спорить с ревьюером просто из желания отстоять свой кусок кода. Аргумент «ну оно же работает!» в коммерческой разработке не прокатывает. Если вам пишут «переделай», и вы искренне не понимаете почему, не вставайте в защитную позу. Задавайте вопросы. Вместо агрессивного «И чем мой вариант хуже?» спросите:
«Слушай, я не совсем понимаю, почему этот паттерн здесь ляжет лучше. Можешь в двух словах объяснить или кинуть ссылку, чтобы я почитал и разобрался?»
И самое важное: мотайте на ус. Нет ничего более удручающего для наставника, чем оставлять одни и те же замечания в каждом новом пулл-реквесте стажера. Если вам один раз объяснили, как в команде принято обрабатывать ошибки или называть переменные — в следующей задаче это уже должно быть учтено. Применяйте полученный фидбек, и ментор увидит главное: вы быстро учитесь, не повторяете старых ошибок и растете над собой. А именно таких ребят и зовут в штат.
Совет 3. Проявляйте адекватную инициативу (и ключевое слово здесь — «адекватную»)
Худшее, что может сделать стажер — включить «режим ждуна». Это позиция школьника или студента: «Я сделал домашку, теперь могу сидеть и смотреть в стену, пока мне не дадут новую». Коммерческая разработка работает иначе. Вы теперь часть механизма, а бизнес обожает проактивных людей, которым «больше всех надо».
Если вы закончили свою задачу раньше срока — отлично! Не ждите завтрашнего стендапа, чтобы об этом торжественно объявить. Напишите ментору: «Я закрыл таску и всё протестировал. Что можно взять еще? Могу я стянуть вот тот небольшой баг из бэклога?». Поверьте, это сразу добавляет вам +100 очков кармы в глазах руководства.
Применяйте «правило бойскаута» — оставляйте проект чуть лучше, чем он был до вас. Заметили опечатку в README? Увидели, что инструкция по развертыванию локального стенда устарела и не работает? Наткнулись на какой-то жутко неудобный ручной процесс? Не проходите мимо. Предложите исправление, а если хватает доступов — просто молча поправьте (создав соответствующий пулл-реквест, конечно). Команда обязательно оценит, что вам не плевать на проект за пределами вашего узкого тикета.
Но здесь есть критически важная оговорка. Инициатива должна быть здоровой.
Не пытайтесь «причинять добро» там, где вас не просят, если это вредит вашим основным задачам. Ничто так не пугает тимлида, как стажер с горящими глазами, который врывается в чат с фразой: «Слушайте, я тут на выходных почитал про новый фреймворк, давайте прямо сейчас перепишем на него весь наш фронтенд!».
Ваша проактивность не должна превращаться в самоуправство. Начните с наведения порядка в мелочах, сфокусируйтесь на своих прямых обязанностях, а инициативу проявляйте дозированно и по делу.
Совет 4. Станьте частью команды (или почему вас нанимают люди, а не компилятор)
Частая картина: приходит новый стажер, надевает огромные наушники с шумоподавлением, забивается в угол опенспейса (или выключает камеру на удаленке) и молча кодит с 10 до 19. Он ни с кем не общается, а на общих созвонах бурчит себе под нос что-то вроде: «Вчера делал таску, сегодня буду делать таску, вопросов нет».
В чем проблема? В том, что такой стажер воспринимается командой как временный гость. А когда через пару месяцев встанет вопрос об оффере и тимлид спросит коллег: «Ну как вам Вася? Оставляем?», в ответ повиснет неловкое молчание. Никто не знает, кто такой Вася и комфортно ли с ним работать в долгую.
Хард-скиллы помогают вам получить стажировку, но именно софт-скиллы конвертируют ее в постоянное место работы. Компании нанимают живых людей, и команда всегда отдаст предпочтение адекватному и приятному в общении джуну, а не заносчивому одиночке (даже если второй чуть быстрее пишет код).
Как перестать быть «человеком-невидимкой»:
Используйте дейли (стендапы) на максимум. Вы не на допросе. Ясно и структурированно докладывайте о статусе: что было сделано (конкретно), чем займетесь сегодня, есть ли блокеры. Показывайте, что вы в контексте общего спринта.
Синхронизируйтесь неформально. Ходите с коллегами на обеды, кофе-брейки или перекуры (даже если просто постоите рядом с чаем). Работаете удаленно? Залетайте во флудилки, кидайте мемы, участвуйте в пятничных онлайн-посиделках или играх. Вам не обязательно становиться душой компании и сыпать шутками, достаточно просто общаться по-человечески.
Вникайте в продукт. Вылезайте из своей IDE. Слушайте, о чем спорят коллеги у кулера или в чатах. Интересуйтесь, зачем нужна фича, которую вы сейчас делаете, и как она повлияет на пользователей. Разработчик, который понимает продуктовую ценность своих задач, сразу переходит в глазах бизнеса на совершенно другой уровень.
Совет 5. Ведите «Дневник стажера» (готовим аргументы для оффера)
Представьте картину: наступает финальная неделя стажировки. Вы сидите на итоговом ревью 1-на-1 с тимлидом и HR. Вам задают закономерный вопрос: «Ну рассказывай, чему ты научился за эти три месяца? Какую пользу принес?». А вы судорожно пытаетесь вспомнить хоть что-то, кроме бесконечных правок на код-ревью, и выдаете невнятное: «Ну-у-у… баги фиксил… докер потрогал немного… тесты писал».
Звучит так себе, правда? За три-шесть месяцев рутина затягивает, и вы сами забываете, какой огромный путь проделали с первого дня. А тимлид тем более не вспомнит каждую вашу мелкую победу. Чтобы получить оффер, вам нужно уметь себя «продавать». И здесь на помощь приходит простой, но убийственно эффективный инструмент.
Заведите себе файл в Notion, Google Docs или даже просто в блокноте на столе. Назовите его «Дневник стажера».
Каждую пятницу, перед тем как закрыть ноут на выходные, выделяйте 10-15 минут и выписывайте:
Какие технологии/инструменты пощупали. (Например: «Разобрался, как работают миграции в базе, научился настраивать CI/CD пайплайн для тестового стенда»).
Какие конкретно задачи закрыли. Не стесняйтесь записывать даже мелочи. («Починил баг с отваливающейся корзиной, ускорил загрузку главной страницы на 10%»).
Инициативу и фидбек. («Предложил обновить документацию по онбордингу, обновил. Получил хороший отзыв от сеньора за рефакторинг старого модуля»).
К концу стажировки этот файл превратится в мощнейший аргумент. На финальном ревью вы не будете мямлить. Вы откроете свои записи и четко проговорите: с чем пришли, как выросли за это время и что конкретно сделали для команды. Факты, метрики, освоенные навыки.
Поверьте, такой структурированный подход убивает наповал. Вы покажете, что умеете рефлексировать, отслеживать собственный прогресс и осознаете свою ценность. А именно такие осознанные джуниоры получают лучшие офферы.
Вместо заключения: стажировка — это растянутое собеседование
Давайте подведем итог. Относитесь к стажировке правильно: это не продолжение университета, где преподаватели обязаны тянуть вас до диплома. В коммерческой разработке стажировка — это просто одно большое, растянутое на несколько месяцев собеседование. И оценивают на нем не только ваш код, но и вашу адекватность.
Никто не ждет, что вы с первого дня начнете писать безупречные решения, с закрытыми глазами настраивать инфраструктуру и в одиночку закрывать сложные эпики. Идеальных джунов в природе не существует. От вас ждут совершенно другого — положительной динамики. Вы можете (и будете) ошибаться, косячить и задавать не самые умные вопросы. Это нормально. Выигрывают те, кто быстро учится на своих ошибках, впитывает фидбек как губка и с каждой неделей становится чуточку самостоятельнее.
Анонсы новых статей, полезные материалы, а так же если в процессе у вас возникнут сложности, обсудить их или задать вопрос по этой статье можно в моём Telegram-сообществе. Смело заходите, если что-то пойдет не так, — постараемся разобраться вместе.