Комментарии 15
это уже общее место
is a commonplace
Ну первая фраза же, честное слово
Плохой термин "пет-проект" - это попытка обесценивания хорошего термина "домашний проект". Промежуточную ступень между ними и пол шага в сторону занимают "фанатские проекты". Последние чаще вырастают во что-нибудь успешное.
Многие домашние переехали в "петы" с ростом популярности GitHub и других публичных площадок. В большинстве случаев - туда им и дорога.
(В этом комментарии нет ненависти или пренебрежения. Просто отделяю мух от котлет через плохое слово "пет". Плохо подходящее для проектов.)
В моей практике был случай, когда гитхаб кандидата в резюме стал минусом.
Ни нормальной работы с коммитами, ни с гитом вообще. Gitignore не настроен и многие проекты либо содержали один коммит, под которым они и были залиты, либо несколько с хреновым описанием.
По кодовой базе. Я не ожидал увидеть супер энтерпрайс кода, но все проекты буквально говорили о том, что их делал человек без опыта работы. Хотя, в резюме он значился как специалист с 1.5 годами опыта.
В общем, если вам нечего показать, лучше не показывать вообще ничего. С ним тогда даже общаться не стали, так как джун с даже с годом опыта не стал бы, условно, пол года назад так писать код.
У меня есть один проект, которым пользуется довольно большое количество людей (с учётом того, что я его вообще не рекламирую). Это шуточный телеграм-бот на определение красавчика дня и, скажем так, не красавчика. Начал я его ещё в бытность тестировщиком, то есть, код писать умел, но писал так, чтоб он лишь бы работал. И он, в общем-то, работает, и работает неплохо. Но показывать его сейчас кому-то стыдно, потому что сейчас я бы так ни за что не написал, а рефакторить не хочется. Помимо самой структуры проекта там и с работой с БД есть проблемы, не самые эффективные запросы, вот думаю хотя бы их поправить, но потом понимаю, что смысла в этом особо нет, потому что проект всё равно выглядит очень непримечательно, и показывать его кому-то я бы не стал, потому что он не отражает мой уровень сейчас.
Вот как раз хотел написать статью о том, как правильно оценивать гитхаб кандидата. И вы все сделали неправильно 😄
Гит - надо смотреть с целью задать вопросы, а не с целью проверить код и ведение гита. В домашних проектах совсем другие цели и задачи и совсем другие пути их решения.
Если проект буду поддерживать я и только я - возможно забью на правильный гитигнор. И в комментах могу писать хоть про огород бабушки, если не планирую их читать никогда.
Если это код, который никогда не планируется читать - то в нём не нужна декомпозиция или внятный стиль.
Если это проект для эксперементов - в нём может быть невероятная чушь вида поднятия всего opengl стека ради простой анимации или парсинга json руками с использованием регулярок.
Но посмотрев на это вы можете на собеседовании спросить почему сделано так, и как бы человек сделал будь это рабочий код - и вот если он скажет, что норм и так-же - это один вывод, а если он распишет минусы своего решения, причины почему так сделано, и как он бы сделал у вас - вы получите ценную информацию и скорее всего в итоге хорошего сотрудника.
Фраза "если человек делает хорошо, то будет делать хорошо везде", которую я слышал от коллег которые тоже оценивают гит кандидата как продуктовый - верна, но трактуется неправильно. Потому что хорошо решенная задача это далеко не всегда хорошо написанный код - зачастую в идеале это вообще код не написанный, или код написанный как угодно но срок, или код работающий только в нужных сценариях, или даже не работающий, но позволивший сделать необходимые выводы.
Главное чтобы карьера не вредила пет-проектам!
Пет-проект показывает, какие технологии и как знает соискатель. Он написал в резюме, что знает mysql, а смотришь - он у себя в проекте в базе файлы хранит, про индексы не слышал, везде LIKE, и так далее. Сразу помечаешь, что надо бы спросить это на собесе. Или другой - 18 лет, только школу закончил, пришел на миддла жава... Сначала было смешно, потом сунулись - а там игра, и какая-то жирная шняга для майнкрафта, и всё чисто-опрятно, почти нет говнокода... В итоге пригласили на собес и он остался у нас. Гитхаб очень помогает в определении реального опыта соискателя.
Так что не надо боятся показывать свои знания и навыки. Да, пустые репы, свалки кода, и прочее надо либо скрывать, либо подписывать, что это мусор "на всякий случай", чтобы его не смотрели.
Короче я понял, статья нужна как правильно оценивать Гиты кандидатов. Потому что ваш подход тоже вызывает сомнения - кандидат который знает sql в совершенстве может хранить в пет проекте файлы в базе и не делать индексы - главный вопрос осознанно он это делает или нет.
Потому что в домашнем проекте - где предельная нагрузка 3.5 папуаса, а данных 10 записей, хранить файлы в базе и забить на индексы - может оказать 0.00000000000000001% влияния производительность, но сэкономить пару часов.
Свалите уже с Хабра наконец, и заберите с собой свои непрошеные карьерные советы и унылые телеграм каналы.
А потом такие разработчики получают отказ с комментарием, что они будут заниматься пет-проектом в рабочее время.
Я не стал бы начинку показывать, что за мода, что все должно быть доступно и бесплатно. Ты вжарил тысячу часов например, а кто-то за полчаса скопировал. Я понимаю, что очень крупным и известным проектам это не грозит, так как после того, как скопировал, нужно ещё команду иметь для доработки. Плюс конкуренты все на виду. Но тут... не очень хочется бесплатно делиться тем, на что ты потратил свое время и знания.
А проекты я бы посоветовал делать и доводить до конца, если они отзываются в вас) но с умом, чтобы действительно не было как в посте описано.
Как pet-проекты могут навредить вашей карьере