100 первых дней Джуна: как не облажаться

Проявлять интерес

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

Быть честным

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

Быть самостоятельным

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

Не оправдываться

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

Достигать результата

Важно понимать, что написать код — это не решить задачу. Чего от вас ждут в результате? Что нужно, чтобы задачу приняли?

Записывать всё в блокнот

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

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

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

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

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

Если с тайм-менеджментом не ладится, присмотритесь к Getting Things Done (GTD) — методологии «доведения дел до завершения» американского писателя Дэвида Аллена. По ней вам нужно отвлечься от условного списка дел и сосредоточиться на выполнении. Сами задачи должны быть четко определены и сформулированы заранее — это поможет не только вам, но и старшим коллегам при оценке вашей работы.

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

Что ещё стоит делать, так это стремиться к самостоятельности, стараться искать информацию самому и, если совсем нет понимания, как делать какую-то конкретную работу, идти к ментору со своей задачей.

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