Избавляемся от страха перед первым трудоустройством

Кадр из к/ф «Гарри Поттер и узник Азкабана»

Проблема этого мира в том, что воспитанные люди полны сомнений, а идиоты полны уверенности

Чарльз Буковски

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

Вопросы были примерно такие:

• Каждый год из ВУЗов выпускается множество студентов и они все идут искать работу. Это ведь очень много людей. Наверняка возьмут лучших, а мне места не достанется.
• Что если я накосячу и меня сразу уволят?
• Что если в процессе работы они поймут что я тупой и выгонят?

Этот студент не был первым человеком, которому я отвечал на подобные вопросы. Они возникают у многих, и обычно приходится рассказывать без подготовки. В этот раз я решил записать свой монолог в блокнот. Думал, что получится пара абзацев, а набралось на целую статью.

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

Статья писалась от разработчика для разработчиков. Однако если вы планируете заниматься тестированием, администрированием или чем-нибудь другим в IT, то часть советов вам тоже пригодятся.

Вообще не наймут

Когда представляешь себе, что ежегодно множество университетов выпускают сотни студентов, то становится неуютно. Как конкурировать с такой огромной толпой?

К сожалению далеко не все выпускники имеют достаточную техническую подготовку. Попробуйте спросить какого нибудь знакомого студента из универа: как люди в его группе получают допуск к экзаменам по дисциплинам вроде «базы данных» или «основы алгоритмизации и программирования»? В группе из 30 человек в лучшем случае найдется 3-5 «продвинутых» ребят, которые все реально сделали сами. Остальные просто списывают у них, зубрят ответы на вопросы и сдают.

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

Cреди сотен выпускников, лишь пара десятков представляют интерес для работодателей

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

Безумие — это точное повторение одного и того же действия. Раз за разом, в надежде на изменение

Альберт Эйнштейн

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

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

Тупой — уволят

Когда принимают на работу человека без опыта, к нему есть соответствующие ожидания.

От новичка на работе ожидают:

• Знания общей технической базы
• Изучения особенностей предметной области компании
• Освоения используемых инструментов и практик

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

Еще бывают технические вводные курсы, но их полезность сомнительна. Если дело дошло до трудоустройства, значит наниматели убедились что вы имеете какой-то достаточный уровень знаний. Лучше всего такие курсы просто пройти добросовестно, как небольшую формальность. Может быть в них действительно будет что-нибудь полезное.

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

Задачи по освоению инструментария будут «сложными» и искусственными. Скорее всего это будет упрощенный вариант основной системы. В подобных задачах используется тот же стек технологий и те же термины из предметной области, что и во всем проекте. При этом результат выполнения не будет отдаваться конечному пользователю. Это может демотивировать, но этому настроению лучше сопротивляться. Искусственную задачу нужно делать добросовестно, как будто от нее зависит судьба проекта.

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

Другой вариант задачи на освоение инструментария это «запустить проект на локальной машине/тестовой среде». Иногда этот процесс описан в инструкции. Но они, как правило, старые и местами неактуальные. Можно принести реальную пользу проекту, если написать новую инструкцию с уточнениями по возникшим проблемам. Наверняка в ВУЗе приходилось писать РГР для отчёта по каким-нибудь дисциплинам. Тут почти то же самое. В документе должны быть отражены действия, которые нужно выполнить для запуска.

Обычно действия для запуска продукта на тестовой среде примерно такие:

• клонировать репозиторий, переключиться на какую-то ветку или тэг
• оформить какой-нибудь конфигурационный файл
• подготовить структуру базы данных
• наполнить ее тестовыми данными
• выполнить сборку или компиляцию проекта,
• запустить набор консольных скриптов в определенной последовательности

В процессе запуска системы локально неизбежно будут возникать непредвиденные проблемы.

Найденные решения проблем нужно дописывать в инструкцию по развертыванию. Тогда в следующий раз при следовании инструкции, эти проблемы уже не будут возникать. При заполнении конфигурационных файлов и вызове скриптов, нужно обращать внимание, какое значение где используется, и с чем оно должно совпадать. Например если проект собирается с помощью CI-системы и потом запускается скриптом, то важно понять куда писать имя ветки или номер коммита. Бывает так, что скрипт подразумевает передачу IP-адреса или DNS имени базы данных, её логина и пароля. В этом случае нужно знать какой именно адрес использовать для тестового окружения, какие логины там есть и какие пароли для них нужно указать.

Некоторые задачи могут казаться простыми для опытных разработчиков и вызывать затруднения у стажёров. Это нормальное явление.

Разработчикам ежедневно приходится решать технические проблемы. Опытные сотрудники множество проблем уже решали раньше, а новичкам ещё только предстоит с ними справиться. Наилучшей тактикой будет запись всех встреченных ошибок в документ «решение проблем с ${название задачи}». Для каждой проблемы нужно сформулировать гипотезу о причине, найти в Интернете варианты решения и по очереди их попробовать. Результат каждой попытки также нужно фиксировать.

Оформление ваших изысканий в виде документа позволит:

• выгрузить из головы мелкие детали. Например параметры конфигурации, DNS/IP-адреса, консольные команды и SQL запросы.
• вспомнить «что же я вчера делал» когда задача растягивается на несколько дней
• не блуждать по кругу. Вы всегда сможете прочитать что делали раньше и понять, что вернулись к исходной проблеме
• внятно ответить на вопрос: «что ты сделал за сегодня?» даже если готового решения ещё нет.

Вам нужно уметь рассказывать статус своих задач коллегам

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

Если вы не отслеживаете встреченные и решенные проблемы, то описание ваших успехов будет выглядеть как: «Я попытался сделать задачу, но у меня не получается. Пока что ищу решение». Из такого рассказа не ясно, делал стажёр что-нибудь или просто сидел хабр читал. Нужна ли ему помощь? Изменилась ли ситуация со вчерашнего дня?

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

Если задача хоть как-то может быть измерена, то в статусе должны звучать цифры. Например для задачи «написать юнит тесты для модуля» можно сказать «планирую сделать 20 тестов, сейчас написал 10».

Чем больше подробностей вы сообщите, тем лучше ваши коллеги будут понимать что вы делали. Это сформирует у коллег положительное отношение к вам и позволит им понять, нужна вам помощь или нет.

Не стесняйтесь обращаться за помощью

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

Лучше всего начать с вопроса: «сталкивался ли кто-нибудь с проблемой раньше?» с кратким описанием проблемы. Желательно приложить кусок сообщения об ошибке или скриншот. Это сообщение первый раз лучше направить в какой-нибудь общий чат по работе. Так вы не отрываете от работы тех, кто действительно занят. Свободные коллеги при этом увидят ваше сообщение и смогут помочь.

Если после сообщения в общем чате никто не помог, попробуйте поймать опытного коллегу во время перерыва: обеда, похода за чаем/кофе, партии в теннис или перекура. Если такого не получилось, то сообщите о своих затруднениях на летучке или стендапе.

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

«Важные» задачи новичков, которые нужны конечному пользователю, будут скучные и маленькие. Например «добавить дополнительную колонку в отчет» или «поправить опечатку в печатной форме» или «реализовать метод модели для загрузки атрибутов клиента из СУБД». Цель таких задач в том, чтобы новичок ознакомился с предметной областью и встроился в ежедневную работу.

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

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

Как только вы найдете общий язык с коллегами, они начнут видеть в вас не новичка-стажера, а равного себе специалиста.

Есть особенные задачи, например «написать юнит-тесты на модуль». На ней вряд ли можно надолго застрять с поиском решений. При этом она достаточно серьезная и даётся не только для обучения стажёра. Написанные тесты увеличивают стабильность проекта путем уменьшения багов в приложении и уменьшения времени на тестирование людьми. В идеальном мире юнит-тесты пишутся сразу по ходу разработки, но реальность как всегда иная. Бывает что разработчик модуля полностью удерживает его в голове и не видит необходимости их писать. «Все очевидно, что тут тестировать?» Иногда модули пишутся в авральном режиме и на юнит-тесты не остаётся времени. Так что в реальном мире юнит-тестов может не быть. Поэтому задачу по написанию юнит-тестов поручают новичку. Так стажер сможет быстрее освоиться в проекте, а проект сможет сэкономить время более высокооплачиваемых специалистов.

Бывает, что стажерам и новичкам поручают роль полноценных тестировщиков. Обычно перед этим нужно развернуть продукт локально и почитать требования. В качестве результата от нового сотрудника ждут:

• вопросы вроде «если сделать вот так, то получится вот так. В требованиях этого нет. Как должно быть?»
• задачи в баг-трекере «в требованиях написано вот так, а по факту иначе».

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

Накосячишь — уволят

В нормальной организации, если вдруг случится такое, что неопытный сотрудник получит к доступ к чему-нибудь критичному и что-нибудь испортит, то виноват будет тот, кто допустил такое. Потому что у новичка по-умолчанию нет доступа к критичной инфраструктуре. При адекватном руководстве, спускать всех собак на неопытного стажёра не будут.

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

Главное — учиться на ошибках и больше их не повторять.

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

Инциденты лучше не допускать

Даже если вас лично не уволят за косяк, такое происшествие доставит нежелательных проблем вашей команде и проекту в целом. Поэтому будьте особенно аккуратны с операциями удаления или создания таблиц в базе данных, файлов, инстансов сервисов и документов в базе знаний по проекту. Если встречаете адрес нового подключения, уточните хотя бы у двух разных людей, что там можно делать. Проверяйте свои права на окружениях не методом проб и ошибок, а соответствующими командами. Например права на удаление файлов с помощью команды `ls`, права на работу с таблицами в mysql с помощью команды `SHOW GRANTS FOR ‘user’@’host’;` и тому подобное. Практически в любом инструменте у вас будет подобная возможность.

При редактировании файлов, на всякий случай сохраняйте себе копию оригинала.

Между стажером и конечным потребителем выстраивают несколько барьеров.

Если бы вы могли сразу отдать свой продукт потребителю, вы бы смогли не устраиваться на работу, а пуститься в «свободное плавание». Но пока у вас нет такой возможности (а заодно и ответственности), вам нужно пройти несколько стадий контроля на проекте.
Первая из них — проверка наставником. Он оценивает решение новичка с технической точки зрения. Если наставник не был назначен, то нужно его найти. Для этого нужно выбрать кого-нибудь из старожилов проекта и на перерыве попросить его посмотреть решение: правильно ли решена задача? Если начнет смотреть и отвечать, значит наставник найден. Если проигнорирует — значит стоит спросить ещё кого-нибудь.

Следующая стадия — Quality Assurance. По-русски — тестировщики. По советски — нормоконтроль и ОТК. Они должны убедиться, что результат работы стажёра соответствует поставленной для него задаче. Они редко будут вчитываться в код. Чаще всего тестировщики будут проверять собранный проект, который разработчик сохраняет в системе контроля версий.

Третья стадия — релиз менеджер. Отдельного человека для этой задачи может не быть, но роль все равно кто-то исполняет. Он проверяет, что тестировщики подтвердили что проект можно выпускать. После этого, он выполняет действия по доставке продукта конечным пользователям.
В мелких организациях эти барьеры по различным причинам могут отсутствовать. Однако в них не поставят новичку задачу на изменение чего-то важного. Потому что этот риск никому не нужен.

Нужно сперва ввязаться в бой, а там видно будет.
Наполеон Бонапарт

Надеюсь, что статья поможет вам перебороть свою неуверенность и отправить своё первое резюме. Разумеется, вы предварительно должны подготовиться. Но не нужно чрезмерно затягивать. Вы скорее всего и так уже несколько лет проучились в ВУЗе или колледже. Куда уж дальше тянуть? В конце концов, лучше один раз услышать «нет» от специалиста и провести работу над ошибками, чем каждый день говорить «нет» самому себе и остановиться в профессиональном росте.

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

Желаю терпения и настойчивости.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Какими были ваши первые задачи на первой работе в IT?

• Сложными

• Важными

• Срочными

• Ни одно из вышеперечисленного

Проголосовали 75 пользователей. Воздержались 20 пользователей.

Что примерно приходилось делать поначалу на первой работе?

• Устанавливать продукт локально

• Тестировать существующий продукт

• Выполнять учебное, ненастоящее задание

• Заниматься экспериментальным, настоящим проектом для клиента

Проголосовали 63 пользователя. Воздержались 25 пользователей.

Сколько студентов в вашей группе во время обучения могли самостоятельно выполнить задания по техническим предметам?

• 1 из 10

• 1 из 5

• Каждый второй

• Все, за редким исключением

Проголосовали 70 пользователей. Воздержались 19 пользователей.

Источник: habr.com