Мы уже рассказывали историю Марка, разработчика, который перешел в IT из другой сферы и за два года прошел путь от джуна до тимлида frontend-команды.
Сегодня своим опытом делится Вова — лид DevOps-направления в CosySoft. В 2023 году он вырос до лидера команды, и в последние 2 года качал скиллы без непосредственного технического наставника, на собственном ресурсе. На карьерном пути Вова наступил на множество граблей, и теперь готов поделиться советами, которые помогут вам не совершать тех же ошибок.
Оценивайте себя объективно
Не преувеличивайте свой опыт на собеседовании и, тем более, не проходите технические интервью с другом напротив, открытым поисковиком или ChatGPT. Поверьте, HR’ы видят, когда вы приукрашиваете, пытаетесь врать или добавляете себе в резюме немного коммерческого опыта, которого не было. Имейте в виду, что даже свои решения в успешно выполненном тестовом тоже придется защищать.
- Заходить в IT, потому что в рекламе сказали «это модно и много платят» — решение, которое с большой вероятностью приведет вас к выгоранию 🚫
- Заходить в IT ради развития и интересных задач — решение, которое приведет к высокому грейду и хорошей зарплате ✅
И на собеседовании, и в работе важно показать не только свои знания, но и как вы рассуждаете. Ответ «Я не знаю» — тоже ответ. Если вы не знаете точного ответа, это не значит, что вы не сможете придумать решение. Начните рассуждать логически: «Я не знаю, но думаю что …».
Для девопса знание теории имеет большое значение. Отсутствие понимания базовых вещей, например, названий сущностей Kubernetes, может сильно затруднить работу. Ведь девопсу важно уметь быстро и аргументированно доносить информацию до разработчиков, аналитиков и продакт-менеджеров.
Задавайте вопросы
Невозможно знать все о новом проекте, только начав с ним работать. Нет такого разработчика, который открывает дверь с ноги и сразу садится писать код. Не знать все технологии — это нормально.
Если вы не понимаете, как хорошо сделать свою работу, задавайте вопросы, не бойтесь показаться некомпетентным.
Правило двух часов
Ставьте таймер: если примерно за 2 часа нет прогресса в работе, значит нужно спросить совета. Это то время, за которое можно попробовать разные подходы и собрать какое-то количество решений.
Даже если менторство декларировано в корпоративной культуре компании, это не всегда работает идеально. Тимлид может не находится на расстоянии руки или всегда быть онлайн. Он может быть занят, банально завален встречами. В этом случае пишите в мессенджер и продолжайте искать решение. Сигнализируйте проблему — он будет в курсе, и даже если не сможет помочь сразу, то обозначит сроки.
Если тимлида нет рядом, задайте свой вопрос кому-то со смежными компетенциями. Возможно, они не смогут помочь именно по вашему направлению, но определенно смогут дать полезные советы. Например, если вы DevOps, то тимлиды frontend- и backend-направлений наверняка смогут вам помочь. Кроме того, в небольших компаниях роли и экспертиза часто размыта. В этом случае эффективно просто подойти к кому-то, кто рядом, и спросить: «Это похоже на то, что я ищу?».
Не бойтесь спорить
Ваши идеи ценны, не стоит их стесняться. То, что вы на старте карьеры не значит, что ваши идеи и мысли плохие. Используйте суперсилу новичка под названием «Свежий взгляд». Она позволяет увидеть устоявшиеся процессы с нового угла и найти ошибки в проекте, которые остальные просто не замечали.
Джун в команде — это всегда свежие мысли, свежие взгляды. Они потребляют много свежей, актуальной информации и больше следят за новостями.
Хорошим тоном будет начать критику существующего решения, например, так:
«Не считаешь ли ты, что правильнее сделать так, потому что …?»
Используйте опыт сообщества
Один из лучших способов принимать правильные решения при разработке — следить за лучшими практиками сообщества. Это могут быть различные IT-ресурсы, телеграм-каналы, форумы, мероприятия, встречи, специализированная литература.
Пробуйте разные инструменты, читайте документацию и составляйте свое мнение. Это поможет в дальнейшем поиске нужно решения.
От осведомленности DevOps'a о том или ином инструменте и выбора правильного решения зависит качество и скорость работы смежных команд. Выбор недостаточно производительных и удобных инструментов в последствии может повлиять на развитие продукта.
Хорошим источником знаний для построения инфраструктуры будет сайт фонда CNCF [Cloud Native Landscape]. Интерактивная карта поможет разобраться во всем многообразии продуктов и подобрать инструменты для разных типов задач.
Оптимизируйте процессы
Научитесь управлять своим временем. Ищите пути автоматизации и сокращения трудозатрат. Лучше один раз потратить 1 час времени на настройку своей IDE, чем потом тратить 10 раз по полчаса.
- Шорткаты лучше, чем двигать мышкой.
- Темплейты лучше, чем писать каждый раз много кода.
- Выносить части кода в отдельные функции и переиспользовать его, лучше чем писать каждый раз заново.
Вы получаете +1000 опыта
Просто прочитать чужую историю — недостаточно, начните использовать эти советы уже сейчас. Они помогут приступить к новой работе более подготовленным, чем обычный новичок. А если вы уже в команде, то с помощью этих рекомендаций вы сможете лучше понимать ожидания коллег и ускорить профессиональный рост.
И не забывайте, выходные и отпуск — для отдыха 🤘
