Как лучше презентовать себя при поиске первой работы? Что писать, чтобы показать, что вы настоящий разработчик? Какие проекты делать начинающему разработчику?
Определитесь с целью
Прежде чем говорить о том, какой проект делать начинающему разработчику, нужно определиться с целью. Тут порекомендую книгу «Цель» Элияху Голдратта.
Цель 1. Развлечение
Если у вас хорошая работа, а программирование вы изучаете просто для фана, то делайте абсолютно любой проект на чем угодно. Хоть на Паскале, хоть на чем-то новомодном. Вот что вам приносит удовольствие — то и пишите. Если вы делаете что-то для фана, обсуждать, какую технологию выбрать — абсолютно бессмысленно.
Цель 2. Максимально быстро найти работу
В этом случае вам нужно показать свои скиллы будущему работодателю, показать, что вы действительно настоящий разработчик. Вот в этом случае нужно задуматься о выборе проекта.
Выбираем стек технологий
Раньше я давал вам чек-лист начинающего разработчика, где рассказывал о том, как определить, какие нужны скиллы, чтобы вас взяли на работу. Я говорил, что нужно прошерстить рынок, найти все вакансии на middle-разработчика, посмотреть все технологии, которые требуются, выписать их и рядом написать, сколько раз эта технология упоминается в вакансиях. Если какая-то технология упоминается много раз, значит ее вы должны записать в резюме. Естественно, просто так в резюме ничего не записываем, все навыки должны иметь подтверждение.
Как подтвердить? Поработав с этой технологией, сделав какой-то проект или закончив курсы по нужному направлению. Таким образом вы получаете список всех технологий, которые должны быть в вашем проекте.
Если в вашей профессии есть две взаимоисключающие технологии, то можете смело брать самую популярную из них. Например, в Java можно использовать либо Hibernate, либо Toplink, но Hibernate гораздо популярнее. Ту, которая менее популярна, можно использовать во втором проекте (если вы ищите работу слишком долго, и чтобы не терять время зря, можно начать еще один проект). Как показывает моя практика, если вы идете на работу, где используется менее популярная технология, то зная более популярную технологию вас также возьмут. Потому что они обычно идентичные и выучить новую вам будет несложно.
Теперь у вас есть стек технологий, которые должны входить в ваш проект. Но проект — это, в первую очередь, идея.
Придумываем идею проекта
Какой же проект писать? Такой, который потенциально может быть кому-то нужен. Это очень важная тема. Кажется, что тут все предельно ясно и понятно, но все же не все это понимают. Делайте именно коммерческое приложение.
Начиная делать пет-проект, чтобы показать, что вы что-то умеете, внезапно может оказаться так, что этот проект реально нужен людям и вы сразу получаете вполне работающий бизнес.
Тут есть одна серьезная ловушка. Большинство новичков ничего не понимают в проджект менеджменте (и это логично). Так вот, в проджект менеджменте говорится, что любой проект нужно начинать с MVP (Minimal Viable Product). MVP — тестовая версия товара/услуги/сервиса с минимальным набором функций (иногда даже одной функцией), которые несут основную ценность для конечного потребителя. Вам не нужно сразу писать полное функциональное приложение, которое умеет все. Нужно минимальное количеству функций, но таких, которые будут полезны людям. Это может быть телеграмм-бот. Но не такой, который просто пишет «Привет» и «До свидания», а который делает что-то полезное.
Тут даже не важно, будет ли этот проект монетизирован. Монетизировать можно абсолютно любую полезную вещь, и нельзя монетизировать вещь, которая никому не нужна. Поэтому в первую очередь думаем о том, чтобы ваш проект был нужен. Про монетизацию пока не думаем. Ну и помним, чтобы функционал был минимальным. Чтобы вы не умерли над этим проектом, чтобы вы могли его сделать в одиночку за пару месяцев. Именно такого размера должен быть проект.
Что это может быть? Ну, например, какой-то трекер задач. Таких приложений очень много, но хороших мало. Вот придумайте такой, который действительно нравится вам. Возможно, найдутся люди, кому ваш трекер тоже понравится больше остальных. Может это будет какая-то очередная домашняя бухгалтерия. Может быть какой-то рекомендательный сервис (по видео, книгам, фильмам — вообще по чему угодно). У меня есть знакомый-рыбак, который писал для себя систему, которая показывала температуру воды во всех водоемах в области. Другие рыбаки тоже оценили. Чем более узконаправленная специфика, тем больше шансов, что приложение действительно окажется кому-то нужно.
Какие проекты делать не стоит?
1. Огромные проекты. Не нужно делать очередную социальную сеть. Возможно, вам кажется, что социальная сеть — это простой проект. Нет! Это чудовищно сложный проект, который требует сотен человеколет работы. Это проект для большой и серьезной компании. И вклад должен быть несколько десятков миллионов долларов. Чат сделать вы можете, но не соцсеть. Но кому нужен чат в 21 веке?
2. Очень маленькие проекты. Например, калькулятор. Хотя калькуляторы бывают разные, если ваш умеет делать какие-то хитрые действия, то может. Но в общем типовой калькулятор не выглядит как проект для портфолио.
Как выбрать проект?
В первую очередь выбираем идею, которая вас драйвит и которая кому-то нужна. Вам, вашему партнеру, вашим друзьям — кому-нибудь. Ну или проект, за который вам заплатят деньги. Даже если заплатят мало — это все равно прекрасный вариант. Во-первых, потому что вы сразу погрузитесь в общение с заказчиком. Во-вторых, такой проект более выигрышно смотрится в портфолио, потому что вы указываете его как коммерческий. В-третьих, вы получите реальный фидбек за эту работу. К тому же заказчик не даст вам спрыгнуть с работы, пока все действительно не будет доделано. Но если нет заказчика — придумывайте нужную идею и делайте.
Как должен выглядеть проект?
Проект должен выглядеть как приложение, которым кто-то пользуется. Это сложно понять, особенно бэкендерам. Если вы не умеете работать с графикой — наймите дизайнера или верстальщика. Вы можете найти таких же начинающих специалистов и делать совместный проект. Идеальный вариант, когда вас в команде двое или трое (бэкендер, фронтэндер и дизайнер). Вы втроем делаете настоящий проект, который отлично выглядит и правильно работает и на фронте, и на бэке. Все трое его указывают в своих резюме. Более того, это можно указать как стратап на троих + добавить навык работы в команде. Но если команда не нашлась — тогда нанимайте дизайнера и верстальщика, ваш проект должен выглядеть хорошо. Ну или разбирайтесь во всех нюансах сами и делайте все сами.
Участие в open-source проектах
Я как технический интервьюер несколько раз встречал людей, которые приходили ко мне на первую работу и рассказывали о своем опыте работы в качестве коммитера в каких-то open-source проектах. И это действительно засчитывается как коммерческий опыт. Включать ли это в резюме в блок коммерческого опыта или в блок проектов — спорный вопрос, я бы все же указал это отдельным пунктом — «участие в open-source проектах».
Но нужно понимать, что участвовать в open-source проектах обычно сложно. Там достаточно жесткие требования к начинающим разработчикам и к вашим коммитам. Пока вы разберетесь, вы можете потерять достаточно много времени. Но если вас драйвит такая идея — берите и делайте.
Всегда ваш Сергей Немчинский.
