Привет! Меня зовут Артур Домбровский, и я наставник и соавтор курса «Java-разработчик» в Яндекс Практикуме. Зарабатываю на жизнь программированием уже более 7 лет, из которых больше трёх провёл в Amazon. Сейчас я — старший программист/тимлид в финтех-компании Wise. Последние пару лет плотно вовлечён в процесс найма, собеседую и джунов, и принципал-инженеров.

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

Какие пет-проекты делать, чтобы было легче найти работу?

Тема этой статьи родилась из вопроса, заданного на вебинаре одним из студентов. Я посоветовал не тратить на это время, хотя интернет забит рекомендациями и примерами портфолио.

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

Как правило, начинающий разработчик не обладает достаточными навыками, чтобы создать такой проект полностью самостоятельно. Скорее всего, это будет воплощение созданного кем-то учебного проекта или туториала. Даже при наличии оригинальной идеи большая часть технических решений будет выбрана по принципу «так было написано».

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

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

Альтернатива пет-проектам

Мне, как интервьюеру, гораздо интереснее кандидаты с записью в резюме о контрибуции в open-source-проекты. Open source даёт кандидату весомые преимущества в глазах нанимающего менеджера:

Идеальное замещение реального опыта работы. Open source даже лучше реального опыта, потому что то, что делал кандидат, доступно для просмотра, а не скрыто в приватных репозиториях и под кипами NDA. Тот факт, что за этот код не заплатили, меня мало волнует.
Вне зависимости от размера вклада (а это может быть лишь пара строчек) сам процесс — именно то, чем будет заниматься новый разработчик в своей будущей команде. Нужно взять большой и сложный проект, разобраться в нём, внести изменения, протестировать, получить одобрение команды. Отсутствует только шаг релиза, но вряд ли свеженанятого начинающего разработчика допустят релизить код в продакшен без присмотра.

Требует большей глубины навыков. И эти навыки будут ближе к коммерческой разработке: взаимодействие с инфраструктурой, запуск проекта, тестирование, создание пулл-реквеста, отработка замечаний. Как правило, внесение изменений требует обоснования, которое невозможно без глубокого понимания механизмов работы проекта и вовлечённых технологий. Это один в один то, чем занимаются разработчики в реальных проектах.

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

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

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

Во время лайвкодинга я не увижу, как код будет протестирован и как он был бы написан в спокойном состоянии. А ведь мы никогда не работаем под дулом пистолета, а сидим в спокойных, уютных офисах. У нас есть время и чашка кофе, и мы можем создать хорошее решение. Интервью — это стресс. Если у меня есть возможность посмотреть, что кандидат делает, когда спокоен, это идеально. Если нет — простите, но я принимаю решение из полученной во время интервью информации. Я приложу максимум усилий, чтобы сделать интервью комфортным, но не всё в моих силах.

Обязательно включайте в резюме проекты с открытым исходным кодом. Это реальный опыт работы, просто за него не заплатили. С моей точки зрения, open source будет смотреться на порядок весомее, чем портфолио из очередных CRUD-сервисов.

Как выбирать проекты для контрибьюшена

Чтобы выбрать проекты, в которых можно поучаствовать, зайдите на GitHub в раздел Explore.



В Explore зайдите в раздел Trending Repositories и выберите в нём язык коммуникации и язык программирования, на котором написан проект, например Java.



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



Дальше найдите репозиторий, который вам по душе, и зайдите в раздел Issues — это все открытые задачи на проекте. Выбирайте issue с максимально подробным описанием — идеально, если описаны шаги, необходимые, чтобы воспроизвести проблему.

Вот пример такого issue:


Также можно подписываться на топики по интересующим вас темам, инструкцию можно найти тут.

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

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

В open-source-проектах джуну важно показать максимальную самостоятельность. Пройдя весь этот путь, он покажет, что знает, что такое Git, умеет создать pull request и достаточно знает про Java, чтобы запустить проект и внести в него какие-то значимые изменения. А если он чего-то не знал, то самостоятельно нашёл решение. Это максимум, который я могу требовать от джуна.

К кому обращаться за помощью, если пишешь для open source

В open source довольно доброжелательное комьюнити. Если вы правильно задаёте вопросы, вам всегда помогут. Навык задавать вопросы — тоже важен для IT, но обладают им далеко не все. Половина моих студентов после четырёх месяцев объяснений всё ещё периодически загружает не текст исключения и описание проблемы, а сообщение: «Помогите, что делать?»

Правильно сформулированный вопрос в IT состоит из таких пунктов:

1. Описание состояния, которое вы пытаетесь достичь, например: «Пытаюсь библиотеку валидации ABC:1.2.3 заставить работать с фреймворком FooBar:3.2.1».
2. Перечисление, что вы для этого делали, — пошагово.
3. Описание, куда смотрели, что читали и пробовали.
4. В идеальном случае достаточное количество информации, чтобы проблему можно было воспроизвести.
5. Вопрос, какие шаги нужно предпринять дальше, чтобы приблизиться к решению.

Это и будет идеально заданный предметный вопрос. Если вопрос более абстрактного характера, то такой алгоритм тоже подходит, например: «Я смотрю на технологию A и технологию B. Мне кажется, что технология A имеет такие преимущества и недостатки, а технология B — такие, что я упускаю?»

Вопросы, заданные в таком формате, демонстрируют уважение к отвечающим:

• Избавляют от необходимости уточнять. Вы можете что-то упустить, но должны по крайней мере прилагать усилия, чтобы у отвечающего была полная информация. Человек может быть в другой временной зоне или ответить через неделю. Если ему надо переспрашивать, это увеличивает turnaround time до неприличия.
• Свидетельствуют о том, что вы не просто наткнулись на проблему и тут же подняли лапки. Вы копали по разным направлениям, у вас есть прогресс, и вам как минимум не нужно советовать то, что уже испробовано. Вы действительно потратили своё время и действительно в тупике.

Open source делает вас самостоятельной боевой единицей

С моей точки зрения (только с моей, не с позиции Amazon или Wise), джун — это самостоятельный разработчик, которому можно отдать на откуп компонент с довольно чётко прописанным ТЗ. А дальше, при минимальной помощи и поддержке от других членов команды, он должен довести работу до конца. Это человек, которому я могу сказать, в каком месте у нас баг, при каких условиях он появляется, и попросить решить. Джун сделает пусть не идеальное, но самостоятельное решение. Если не сделает, то это не джун, а человек, который ещё только учится.

Перейти из стадии «просто учится» в джуны можно как раз с помощью open source. Такие проекты — это доказательство, что человек стал самостоятельным. Следующей ступенью эволюции будет мидл — специалист, которому можно поручить дизайн компонента, работающего на уровне всего проекта. А следующая ступенька — уже синьор. Он видит много сервисов и может работать над их взаимодействием, над всей системой. Это довольно условные разграничения, но самостоятельность нужна в любом случае.

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

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

Выводы

• С точки зрения работодателя, наём — это риск. Дорогой риск. Поэтому в найме false positive лучше, чем false negative. Лучше не взять потенциально хорошего программиста, чем нанять плохого.
• Джунов сложнее собеседовать и страшнее нанимать, потому что они стоят в найме не намного дешевле синьоров, пользы от них на порядок меньше и получает её компания гораздо позже. То есть какое-то время бизнес просто тратит деньги в пустоту.
• Понять про джунов на собеседовании тоже можно гораздо меньше — у них слишком мало опыта. Зачастую они не могут рассказать, что делали, какие ошибки допустили и чему научились. А это важно, чтобы оценить кандидата.
• Open source, на мой взгляд, идеальный вариант сэкономить ресурсы компании и заявить о себе. Этот вариант подойдёт и рекрутерам, и HR-специалистам — у них есть строчка, в которой указывается, какие проекты человек делал. И это идеально для меня как для нанимающего инженера. Ведь я могу посмотреть и реально увидеть код кандидата.
• Собеседование — это стресс, а работаем мы в спокойном состоянии. Мне интереснее посмотреть, как будет выглядеть код, написанный дома для реального проекта, чем на нервный лайвкодинг.
• Open source — это опыт, о котором можно заявить в CV и который даёт вам действительно полезные навыки коммерческой разработки. А пет-проекты показывают, в каких инструментах заинтересован человек, какие базовые действия он освоил в процессе учёбы.