Всем привет! Меня зовут Артём Харченков, и я руководитель подразделения разработки программных продуктов в компании Crosstech Solutions Group. Сегодня я расскажу, как успешно пройти свой первый испытательный срок, что нужно делать обязательно и чего лучше не делать.
Для начала – кратко обо мне, чтобы было понятно, почему мне стоит доверять в таком вопросе.
/слайд обо мне/
Образование у меня ИБ-шное, в ИТ я работаю с 2012 года. За свою карьеру занимался внедрением, был разработчиком, инженером, главным техническим специалистом в группе разработчиков и даже делал проекты практически в одиночку :) В «Кросстех Солюшнс Групп» руковожу разработкой чуть более трех лет. Здесь мы создаем системы для обеспечения безопасности данных, сейчас импортозамещаем зарубежные продукты, ушедшие с российского рынка. К слову, активно нанимаем сотрудников: еще в прошлом году в компании было 50 человек, а в этом году стало уже больше 200.
В моем управлении четыре департамента: разработка, тестирование, системная аналитика и devops, суммарно нас на текущий момент уже 29 человек. За свою карьеру я сам прошел несколько испытательных сроков, а самое главное – повидал много работников, которые его проходили.
Советы из этой статьи актуальны для любой IT-шной профессии, но так как в моём управлении больше всего программистов, часть рекомендаций будет с уклоном в сторону разработки.
А что такого в первом испытательном сроке и зачем все эти советы?
Я бы сказал, что первый испытательный срок – это особенный и ни с чем не сравнимый опыт, во многом определяющий не только ваш дальнейший трек в компании, но и первое впечатление от работы в IT в целом. Вспоминая свой собственный первый испытательный срок (ой, как давно это было!), могу сказать, что интуитивно я придерживался только части рекомендаций, которые будут описаны дальше. Я, например, ничего не уточнил про план своего испытательного срока, не узнал кто будет меня оценивать и как, не спрашивал своего ментора, как я справляюсь, потому что просто не знал, что так можно. Зато я переживал за результат так сильно, что даже заболев через две недели после трудоустройства, через пару дней как только смог встать – побежал работать. В моём случае испытательный срок прошел успешно, но если бы я прочитал такую статью перед тем как устраиваться на первую работу, моя жизнь точно была бы легче:)
Есть советы, которые могут показаться очевидными. Но это только на первый взгляд, а на практике мало кто об этом задумывается. Например, если спросить новичка: «Как думаешь, стоит ли получать обратную связь о своих успехах хотя бы раз в пару недель?», то с высокой долей вероятности, тот ответит «Конечно!», а на деле такую инициативу джуны сами практически не предлагают. Такую ошибку совершал и я сам. Но перейдём к собственно рекомендациям.
Что важно помнить
1. Не только компания присматривается к вам, но и вы к ней
Конец испытательного срока – это временная отсечка, когда сотрудник и компания понимают, готовы ли они работать друг с другом или нет. Обычно он составляет три месяца, но иногда бывает и меньше, и больше. Если вам некомфортно, то вы всегда сможете завершить испытательный срок раньше. Это нормально, такое случается. Испытательный срок для этого и нужен, чтобы сотрудник и компания присмотрелись друг к другу и поняли, подходят ли они друг другу. Каждый раз, принимая нового сотрудника, ваша компания тоже проходит испытательный срок :)
2. Сосредоточьтесь на чём-то одном (в данном случае – на новой работе)
Эти 1-3 месяца в вашей жизни будут несколько сложнее, чем обычные. Именно то, как пройдет ваш первый испытательный срок, ляжет в основу вашего будущего отношения к работе, а может, даже и к выбранной сфере в целом. Поэтому в этот период лучше не начинать новых проектов. Например, не стоит совмещать начало работы и переезд в новую квартиру, или ремонт – иначе будете страдать и вы, и ваша продуктивность.
У меня есть знакомые, которые любят всё и сразу. Их логика примерно следующая: «С понедельника я выхожу на новую работу, записываюсь на курсы английского по выходным, а ещё начну ходить в спортзал». На практике получается, что энергии на такой режим хватает максимум на две недели, после чего у человека начинает сильно проседать одна сфера за другой, в том числе и работа.
3. Опыт чуть важнее соцпакета
Помню, была такая серия в ситкоме «Универ. Новая общага», где Майкл после защиты кандидатской при устройстве на первую работу высокомерно отказывает всем компаниям со словами «Как у вас нет отдельного кабинета? Перезвоните как появится!», «Зарплата 30 тысяч? Это смешно. Вообще-то я кандидат исторических наук!». Надо ли говорить, что потом ситуация изменилась и затем ему отказывали уже сами компании. По итогу Майклу пришлось устроиться хоть на какую-то первую работу, чтобы получить первый практический опыт.
Хоть мы и не историки, а IT-шники, в начале карьерного пути нам также необходимо получить опыт. Поэтому если ваша компания не дает абонемента в фитнес-зал, уроки английского языка или чего-то ещё – не страшно. Когда вы профессионально подрастете и вас захочет видеть у себя уже много компаний, вы сможете выбирать себе работу, ориентируясь в том числе на соцпакет.
4. На первом месте работы лучше поработать подольше
Если вы – начинающий специалист, для которого эта работа – первая, то я крайне рекомендую проработать на ней минимум полгода-год, чтобы получить тот самый первый опыт, с которым вас потом «с руками оторвут» на рынке.
Ещё на четвертом курсе универа многие из нас пошли работать. Часть группы поработали два месяца и ушли, а часть работали до самого выпуска, освоив до базового уровня какой-то из языков программирования. Старт карьеры был наиболее успешным у тех, кто уже успел набраться опыта и к защите диплома набил руку.
Уходить с первого места работы по вашей инициативе следует только в 2-ух случаях:
- До вас всем нет вообще никакого дела, вам не выдают задачи, а если и выдают, то они максимально механические и простые. Например, копипастить что-то из одного класса в другой или добавлять новые поля на веб-формочки. Никакого развития на таких задачах не происходит, и вы просто просиживаете здесь штаны.
- Вы попали в максимально токсичный коллектив, где руководитель – самодур, а все коллеги – неуравновешенные. За каждую ошибку в коде на вас орут и бьют клюшкой для гольфа.
Конечно, я немного утрировал, но если ваша ситуация близка к этим двум, то вам действительно стоит поискать что-то ещё. Для будущих работодателей ваше решение уйти будет выглядеть адекватным. Во всех остальных случаях я очень рекомендую постараться проявить себя на текущем месте.
5. Половина успеха – в ответственном отношении к работе
Если вы осознанно подходите к работе, выкладываетесь на все сто и вас волнует, как пройдет испытательный срок, то у меня для вас хорошая новость: вы достигли 50% успеха! По моему опыту, половина сотрудников испытательный срок не проходит из-за наплевательского отношения. Помню случай, когда новый тестировщик устроился на работу и больше ни разу на ней не появился. Как потом выяснилось, он был заядлым игроком в онлайн-игры и на следующий день его клан позвал в «рейд на лича», куда он с удовольствием вместо работы и пошёл, видимо, тестировать новую броню:) Видел я и разработчиков, кто игнорировал пожелания и распоряжения своего тимлида и упорно делал всё по-своему без какой-либо аргументации. Ему в Merge Request’e пишут, что здесь необходимо использовать существующую функцию utils.checkItem(newItem) и писать названия в lowerCamelCase, а он продолжает изобретать собственную библиотеку, где названия методов пишутся Inthisstyle и все методы public. Все эти случаи, конечно, печально заканчивались.
Впрочем, одной ответственности недостаточно. Еще нужно быть достаточного уровня квалификации для выбранной позиции и компании. У меня в департаменте был сотрудник Семён (настоящее имя заменено), который не прошел испытательный срок, хотя сам по себе был приятным человеком, старался, сидел до вечера в попытках решить поставленные ему задачи. Но из-за изначально низкого уровня его пришлось уволить по окончании испытательного срока, так как он пришёл на должность мидла, а по факту не потянул даже на джуна. Мы так до конца и не поняли, как он прошёл собеседование, потому что все кто его проводил, сошлись во мнении, что на вопросы он отвечал очень даже хорошо. Но когда он взял практические задачи, то все были в шоке: человек нормально не умел создавать новые сущности и пользоваться отладчиком кода в IDE. Отличный пример теоретиков на собеседовании :) Хорошо, что он сам понимал, что не тянет свою позицию, и ушел спокойно и без конфликтов.
6. Ответственность компании – найм и рабочая нагрузка
Пример про Семёна из предыдущего раздела – это типичная ошибка найма. Чаще всего такие случаи единичны.
Если вы делали всё, что вас просили, старались и выкладывались, а по итогу не прошли испытательный срок — знайте, что это ошибка найма, а не ваша. Для компании ваш найм стоит довольно дорого: она несёт затраты на поиск, подбор, инвестиции в ваше обучение, зарплату тех, кто вас обучает и курирует. Поэтому компания не будет просто так, из-за своего самодурства, избавляться от вас. Она сделает это только в случае, если вы не подошли по каким-то объективным причинам. Но даже если вас по итогу уволят, просто продолжайте искать работу дальше. Не стоит сильно расстраиваться из-за этого (да-да, знаю, легко сказать!).
7. Но ваша работа и карьера – ваша ответственность
То, что ответственность за найм лежит на компании – это не значит, что вы должны расслабиться и пустить всё на самотёк. Вы должны сделать всё возможное, что зависит от вас. А от вас зависит очень многое. Пишите свой код настолько хорошо, насколько только можете и продемонстрируйте, что в вас поверили не зря!
Какие есть компании и с какой стоит начать свою карьеру
Компании бывают крупные, средние и маленькие. Разберем их преимущества и недостатки с точки зрения работы начинающего специалиста.
Плюсы и минусы работы в крупной компании:
Плюсы и минусы работы в маленькой компании:
Средние же компании могут объединять плюсы и минусы маленьких и больших. Кстати, наш «Кросстех Солюшнс Групп» можно как раз отнести к категории средних.
В одних компаниях вашим руководителем и ментором могут быть два разных человека, в других компаниях это будет один человек. Под ментором я имею в виду того, кто погружает вас в проект, оценивает ваши успехи и по итогу принимает решение о вашей дальнейшей судьбе, либо же передаёт заключение о вас руководителю. У нас также нет к этому единого подхода: иногда нового человека менторит его непосредственный руководитель, иногда – старший программист.
Так в какую компанию лучше идти начинающему специалисту? Ответ: без разницы. В какую возьмут😊 Для старта любой вариант хорош. Если вы получите первый опыт в маленькой компании, то, в дальнейшем будет классно поработать и в крупной, чтобы понять и увидеть разницу в подходах. И наоборот, после крупной компании для более цельной картины мира хорошо было бы поработать и в маленькой. Сам я начинал с большой компании, затем поработал в очень маленькой, а две крайние в моём списке – средних размеров.
Итак, вас взяли. 7 рабочих лайфхаков для прохождения испытательного срока
Советы, приведенные ниже, актуальны для компаний любого размера, и помогут вам не растеряться в первые месяцы на новом месте и зарекомендовать себя как проактивного сотрудника.
Спросите про план испытательного срока
Некоторые компании практикуют план испытательного срока с целями и задачами, а некоторые – нет. Поэтому не стоит спрашивать слишком настойчиво предоставить вам этот самый план. Можно спросить примерно так: «У меня есть какой-то формализованный план с задачами, целями на испытательный срок и оценками их достижения? Или же мои результаты будут оцениваться менторами и руководителями экспертно, исходя из моей эффективности и общего впечатления обо мне как о работнике?». Такой вариант не принижает ни одного подхода, вы показываете, что уважаете как наличие такого плана, так и его отсутствие и считаете и то и другое нормальным.
Используйте кофе-брейки с пользой
На них вы можете больше узнать о проекте. Если вы – разработчик, в перерывах вы можете общаться с другими разработчиками, тестировщиками или аналитиками из вашей команды. Спросите у них, как будет тестироваться ваша текущая фича, чтобы вам лучше понимать, чему уделить больше внимания. Спросите у руководителя проекта, кто ваш заказчик, как давно проект разрабатывается, на какой он сейчас находится стадии. Любая информация о проекте будет полезна, помните, что погружение в проект – это одна из основных целей испытательного срока.
Показывайте своё желание расти и развиваться
При виде неизвестного фреймворка не нужно говорить фразами «это я не знаю», «это не умею», даже если это действительно так. Вас взяли на работу не просто так, работодатель поверил в вас и в ваши силы, увидел потенциал и способности к обучению. Вы всегда можете заменить такие фразы на более позитивные: «С этим не работал, но слышал про эту штуку, думаю почитаю и разберусь» или «Про такое не слышал, но очень интересно изучить эту технологию», «Класс, так много нового узнаю и изучу». Тем самым вы показываете, что в вас есть запал и желание развиваться, а это очень важно для джунов. В IT очень ценятся люди, которые готовы разбираться с неизвестными технологиями и занимают активную позицию. В идеале в каждой задаче даже старшего программиста от 30 до 50% потенциальной работы – новая и неизвестная зона.
Почаще подводите промежуточные итоги
Желательно договориться заранее о промежуточных точках контроля и фидбеке о вас: это можно делать 1 раз в 2 недели или 1 раз в месяц. Понимать обратную связь необходимо, чтобы в случае чего успеть исправиться. Если вы придёте с неудовлетворительным результатами в конце – может быть уже слишком поздно, а если узнаете о проблемах через месяц, то ещё успеете что-то изменить в своей работе. Это подход как в гибкой методологии разработки Agile: чтобы достичь целей, которые устраивают заказчика, необходимо проводить демонстрацию результатов каждый спринт. В нашем случае в роли заказчика компания, а вы – исполнитель. Здесь идея такая же. Это работает.
Перед выполнением задачи убедитесь, что понимаете результат
Этот совет мне дал мой первый руководитель на моей первой работе, я его использую по сей день. Коля, если ты это читаешь, спасибо тебе :) Есть лайфхак: в конце предложите ментору кратко пересказать, как вы поняли задачу и что должно получиться в итоге. Это займёт пару минут, но повысит вас в глазах руководителя, вы дадите ему понять, что ответственно подходите к делу и удостоверяетесь, что всё поняли правильно. Не бойтесь задавать уточняющие вопросы, если в результате пересказа выяснилось, что вы что-то поняли неверно.
Некоторые люди стесняются задавать вопросы. У меня в команде была девушка-аналитик, которая при получении задачи всегда кивала и говорила, что ей всё понятно. По итогу в результате её работы получалось совсем не то, что требовалось. Затем мы ввели с ней практику пересказа задачи своими словами. Да, для постановки задачи стало требоваться больше времени, но зато результат получался намного ближе к тому, что было нужно, что в свою очередь, сильно экономило время.
Фиксируйте результаты встреч
Записывайте резюме ваших с ментором договоренностей, будь то организационные моменты или технические детали по задаче. Старайтесь не надеяться на свою память, в первое время новой информации будет очень много и всё в голове удержать не получится.
Поверьте, очень сильно раздражает, когда один и тот же вопрос задаётся по нескольку раз: например, вам недавно рассказали, как взаимодействуют сервисы А и Б, а вы приходите с этим вопросом повторно. Это происходит из-за того, что в моменте вам показалось, что вы это запомните, но потом все улетучилось. Можно спросить разрешения на запись онлайн-встречи или диктофонной записи очной встречи с ментором. Объясните, что это нужно для того, чтобы вы потом в спокойной обстановке переслушали ваш диалог и лучше поняли какие-то моменты и детали объяснений/обсуждений. В 99% случаев возражений против записи не будет. В нашей компании мы практикуем в том числе записи групповых встреч и обсуждений, чтобы никакие детали не были утеряны.
Уделяйте время на изучение технологий, которые используются на проекте
Договоритесь с ментором, какую часть времени вы будете посвящать изучению тех технологий, по которым у вас недостаточно знаний. Так как вас брали на начинающую позицию, все понимают, что вам есть что подтягивать, и все 100% времени посвящать закрытию задач неэффективно. Проговорите, что 20-50% рабочего времени (в зависимости от ситуации) вы будете заниматься изучением технологий проекта и обсудите, в каком именно порядке это стоит делать. Например, вы пришли на проект, где используется брокер сообщений, а вы раньше с ним не работали. Будет намного эффективнее, если вы посвятите какую-то часть времени реализации небольшого пет-проекта с брокером, поймёте хотя бы основные принципы его работы, а уже потом приступите к реализации боевых задач в проекте, которые с ним связаны.
Что точно не надо делать на испытательном сроке
Далее перечислим несколько вещей, могут быть негативно восприняты эйчарами и руководством. Их просто стоит иметь в виду – на самом деле, в конкретной ситуации вам будет виднее, как поступать, но эти рекомендации помогут сориентироваться быстрее.
Сидеть и ждать следующей задачи
Иногда случается так, что в потоке рабочих задач про вас могут забыть, это нормальная история. Не стоит обижаться на это или стараться «пересидеть тихо», ожидая внимания ментора. Закончили задачу – спросите, что можно ещё поделать. Будьте проактивны – руководство это оценит!
Воспринимать критику как личное оскорбление
Помните, что критика работы – не критика конкретно вас как человека. Некоторые члены команды могут высказываться на код-ревью довольно жёстко, но скорее всего вас об этом предупредят или вы скоро поймёте это сами. Часто проблема в том, что в тексте не всегда видна эмоция, с которой человек пишет тот или иной комментарий. Сообщение «Вот тут надо переписать функцию так-то» в голове у человека может звучать по-разному.
Помню, как один программист по имени Леонид был очень недоволен комментариями к его Merge Request’ам. Ему казалось, что каждый из комментариев нацелен на унижение и оскорбление его личного достоинства, что выражалось в едких ответах и исправлением ошибок нехотя. Когда команда HR собирала обратную связь по Леониду, коллеги отметили, что он резко реагирует на комментарии к его коду. Проблему решил прямой и открытый разговор – претензий как к человеку к нему не было, а исправления были нацелены на общий результат. Но проговорить это было важно. В результате Леонид стал проще относиться к критике, а код стал писать лучше. Мораль истории следующая – обратная связь от коллег полезна, и не стоит принимать ее близко к сердцу.
Часто дергать ментора
Старших разработчиков сильно выбивают из состояния потока постоянные вопросы от их подопечных. Представьте, сидишь такой, решаешь архитектурную задачу межгалактического уровня, в голове уже построен алгоритм размером с адронный коллайдер, а тут тебе в рабочий чат прилетает вопрос «Игнат, а подскажи пожалуйста, вот функция Arrays.sort() тут вызывается, она что делает?». Нет ничего хуже, чем задать подобный вопрос в таком контексте.
Поверьте, у ментора много дел и он очень занят текущими проблемами проекта. Если у вас возникла проблема, сначала постарайтесь решить её самостоятельно: погуглить, задать вопрос в ChatGPT. Только перепробовав какие-то варианты самостоятельно, идите к ментору с вопросом.
Ещё лучше, если у вас накопится список из 3-5 вопросов, которые вы за одну встречу на 20-30 минут сможете задать ментору. Перед тем как задать вопросы, обязательно сформулируйте их и укажите варианты, которые вы уже пробовали для самостоятельного решения. Это поможет провести синк с ментором эффективно и покажет вас как самостоятельного сотрудника, на которого можно положиться.
Бонусный лайфхак для первого рабочего дня
Им, как и всеми остальными, можно воспользоваться, а можно и нет. Но я оставлю этот совет как рекомендацию, которая поможет настроиться на нужный лад и быстрее адаптироваться. В общем – в первый рабочий день не убегайте с работы сразу после оформления и получения техники, даже если вы будете работать удалённо. Лучше осмотритесь: прогуляйтесь по офису, почитайте регламент работы вашего отдела, установите нужный для работы софт. По возможности познакомьтесь с кем-нибудь, кто пришел выпить кофе на кухне (конечно, речь не о том, чтобы вовлечь человека в часовую беседу о себе, а о небольшом смолл-толке). К слову, руководителю подобное поведение тоже понравится – лично я обращаю внимание на такие мелочи и знаю, что так делают многие мои коллеги-руководители.
