Насколько обширным должно быть портфолио GitHub для студента CS без опыта «реального мира», который хочет получить свою первую стажировку?

Я не знаю о стажировках, но ранее сегодня я писал по другому вопросу, что для реальной работы работодатели почти никогда не смотрят личное портфолио потенциального сотрудника на GitHub. Я бы предположил, что стажировки в основном одинаковы, хотя они могут более внимательно изучить ваш GitHub, потому что они не ожидают, что у вас будет надежное резюме; в то время как я бы сказал, что это на 100% бесполезно для реальной работы, я бы сказал, что это может быть только на 80% бесполезно для стажировки.

Что касается того, что на него надеть: просто наденьте что угодно, просто чтобы показать, что у вас там что-то есть. Возможно, вы захотите дать несколько описательных названий или кратких описаний своим проектам, которые особенно не впечатляют, например, school-assignment-calculatorчтобы тот, кто читает это, знал, что не стоит ожидать слишком многого. Тем не менее, не размещайте там слишком беспорядочный код и обязательно продемонстрируйте свою лучшую работу, потому что это то, на что могут смотреть работодатели, и вы хотите показать себя с лучшей стороны.

Что касается того, какие или сколько языков использовать, ответ будет «предлагать то, что удобно». Если вы хотите работать на Java, то нет ничего плохого в том, чтобы использовать только Java-приложения. Если вы хотите продемонстрировать свое портфолио компании, которая работает на Python, то они, вероятно, не будут впечатлены портфолио на Java, и вам может понадобиться продемонстрировать немного Python. Точно так же, если вы хотите продемонстрировать свое портфолио только компаниям, работающим на Java, то тратить кучу времени на изучение и написание Python, вероятно, непродуктивно. Так что это действительно зависит от того, что вы хотите/ожидаете.

По моему опыту младшего программиста, очень ОЧЕНЬ редко мое портфолио на Github проверяют. Чтобы дать вам конкретный ответ о том, сколько проектов у вас должно быть, возможно, больше 5. Имейте там несколько глупых проектов, таких как приложение API погоды, приложение калькулятора и тому подобное. Если кто-то собирался проверить, дайте им что-нибудь посмотреть. Это доказывает, что вы знаете, как работает git.

Поскольку вы выпускник, немного важнее иметь какую-то работу там, но даже в этом случае вы не обязаны. Однажды мне предложили роль React.js. Они спросили меня, есть ли у меня какие-либо реагирующие приложения на моем github, я сказал, что у меня их нет, но меня все равно наняли.

Идея портфолио сильно переоценена. Это то, что вам скажут рекрутеры и гуру в LinkedIn. Что дает вам работу, так это то, насколько хорошо вы представляете себя в своем резюме и на собеседованиях. Пока это хорошо, вы наверняка сможете получить работу, даже не имея Github. Мой приятель даже не знает, как использовать git, но его наняли. Он просто пообещал, что выучит это

Это зависит от того, что ищет конкретный работодатель. Качество вашего общедоступного портфолио GitHub (или его отсутствие) является одним из многих решающих факторов, и я никогда не видел, чтобы это нарушало условия сделки. Если менеджер по найму сомневается, стоит ли вас нанимать, отличное портфолио на GitHub может склонить чашу весов в вашу пользу. Или вы можете столкнуться с менеджером по найму, который не тратит время на просмотр вашего портфолио и вместо этого принимает решение исключительно на основе собеседования.

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

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

• Масштаб проекта должен быть нетривиальным. Игрушечные программы, базовые упражнения и тривиальные вещи здесь не годятся, поскольку не демонстрируют высокого уровня мастерства. Например, простой калькулятор — это то, что люди кодируют во время собеседований. Это не добавляет ничего нового в ваше приложение. Сложный калькулятор, поддерживающий преобразование единиц измерения, алгебру, исчисление или построение графиков, — это совсем другое дело.
• Стек технологий должен быть актуальным. Если вы подаете заявку в магазин Java, проекты на Java лучше. Тем не менее, многие CS не зависят от языка/платформы. Таким образом, даже если у вас есть проекты только на C и C++, и во время собеседования вы хорошо справились с заданием по Java, не будет преувеличением сказать, что ваши навыки C/C++ перейдут на Java. Но это если вас вызовут на собеседование по Java с вашим портфолио по C/C++.
• Домен должен быть актуальным. Если вы претендуете на позицию фронтенда, обязательно потратьте время на графический интерфейс и убедитесь, что вы делаете свою работу хорошо. Но не ожидайте, что проект с большим количеством графического интерфейса сделает для вас много полезного в тяжелом положении бэкэнда. Он не только не может продемонстрировать столько навыков в целевых областях, но и ставит вопрос о том, были бы вы счастливы, работая над бэкендом, если в свободное время вы занимаетесь только фронтенд-проектами и никогда не занимаетесь бэкэндом. Точно так же, если вы заинтересованы в работе в сети, вам подойдет одноранговое приложение, а чисто однопользовательская текстовая приключенческая игра не так хороша.
• Это должно быть четко объяснено. Если люди даже не могут сказать, что представляет собой ваш проект и для чего он предназначен, это не может быть веским доказательством. Это может даже быть воспринято как доказательство того, что с вами будет трудно работать, потому что вы не можете хорошо объяснить свою работу. Поэтому убедитесь, что все ваши readme и документы на месте, ваш код прокомментирован, ваша история git аккуратна и т. д. Но также при запуске проекта убедитесь, что он решает четкую проблему , которую людям будет легко понять.

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ

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

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

GitHub — удобное место для обмена подобными вещами, но, конечно, это не обязательно должно быть на GitHub. «Раньше» приложения иногда состояли из сопроводительного письма, резюме и образца кода на 3 отдельных листах бумаги.

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

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

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

Так что мы делаем, мы поворачиваем его вокруг. Мы не фокусируемся на опыте программирования. Мы фокусируемся на всех остальных вещах. Вещи, которые некоторые люди называют soft skills , но мне не нравится этот термин, поскольку они гораздо важнее, чем умение писать код.

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

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