Портфолио в GitHub, което работодателите четат – как да го подредите

Портфолио в GitHub, което работодателите четат, е подреден профил с кратко представяне и до шест закачени проекта, всеки с ясно README (GitHub Docs). Броят на хранилищата не решава нищо. Важно е дали човек отвън бързо разбира какво сте направили и как да го пусне.

Какво поглежда работодателят в портфолио в GitHub

Линкът от CV води първо до профилната страница. Там GitHub показва профилното README и закачените хранилища или gist-ове (GitHub Docs). Ако и двете места са празни, посетителят вижда само списък без обяснения и сам трябва да гадае кое е важно.

Самите разработчици учат главно от писан текст. В проучването на Stack Overflow за 2025 г. 67,8% посочват техническата документация като източник за учене през последната година, пред онлайн форумите и общностите с 58,7% и видеата с 50% (Stack Overflow). Изводът ни е прост: да обясните проекта си в README е работно умение, а не украса.

Отделен сигнал е историята на промените. Хранилище, качено с един-единствен комит, не показва как сте стигнали до резултата. Десетки малки, ясно описани стъпки го показват.

Как се прави профилно README в GitHub

Профилното README е обикновено хранилище със специално име. Името му трябва да е точно вашето потребителско име, хранилището трябва да е публично, файлът README.md трябва да е в корена и не бива да е празен (GitHub Docs). Създава се от New repository, като изберете Public и включите опцията Add README.

Файлът изчезва от профила, ако го изтриете или изпразните, ако направите хранилището частно или ако името му и потребителското име престанат да съвпадат (GitHub Docs). При по-стари хранилища със съвпадащо име, създадени преди юли 2020 г., трябва ръчно да натиснете Share to profile.

Съдържанието да е кратко. Едно изречение за това към каква роля се насочвате и кои технологии реално ползвате, а след него връзки към два-три проекта. Ако още избирате посока, пътната карта за първата година помага да решите какво да покажете. Значки, броячи и анимации отвличат вниманието от кода.

Кои проекти да закачите на профила

GitHub позволява да закачите до шест елемента, като хранилищата и gist-овете се броят заедно (GitHub Docs). Шест е горната граница, а не задължителен брой. Три-четири завършени проекта казват повече от шест недовършени.

Най-силен е проект, който решава истинска задача от началото до края, например малко уеб приложение с база данни, публикувано онлайн. За хората, които се насочват към front-end, уеб приложенията с JavaScript са естествен първи проект. Упражнение от курс закачете само ако сте го доразвили и сте описали какво точно сте добавили.

Какво да пише в README на всеки проект

Добрият README отговаря на въпросите на човек, който вижда проекта за първи път. Започнете с едно изречение какво прави приложението и линк към работеща версия или снимка на екрана.

След това сложете командите за инсталиране и стартиране, проверени на чиста машина. Добавете използваните технологии и кратък раздел с известните ограничения и какво бихте подобрили. Този последен раздел често липсва, а именно той показва, че оценявате работата си трезво.

Комитите показват как работите

Ръководството Pro Git препоръчва първият ред на съобщението за комит да е до около 50 знака и сбито да описва промяната (Git (git-scm.com), книгата Pro Git). След него се оставя празен ред, а по-подробното обяснение, ако има такова, се пренася на около 72 знака. Пише се в повелително наклонение, тоест „Fix bug“, а не „Fixed bug“.

Преди всеки комит командата git diff --check намира излишните интервали и ги изброява (Git (git-scm.com), книгата Pro Git). Изглежда дреболия, но при преглед на код diff-ът се чете ред по ред.

AI инструментите вече са масов начин за учене: 44% от участниците в проучването на Stack Overflow са ги ползвали за това през последната година (Stack Overflow). Затова готовият код сам по себе си доказва по-малко от преди. Малки, смислено описани комити и обяснените решения в README показват, че разбирате какво сте написали.

Контролен списък преди да изпратите линка

Най-честата грешка е линк в CV към хранилище, което по-късно е станало частно. Тогава работодателят вижда страница за грешка вместо проекта. Внимавайте и за пароли и API ключове, качени заедно с кода. Изнесете ги във файл, който Git игнорира, и сменете всеки ключ, който вече е бил публикуван.

Колко тежи практиката на пазара в ЕС

Работещите ИКТ специалисти в ЕС през 2025 г. са над 10 милиона, или 5,0% от всички заети, при 3,5% през 2015 г. (Евростат). За десет години броят им е нараснал с 59,4%, докато общата заетост е нараснала с 9,8%.

Висше образование имат 68,8% от ИКТ специалистите в ЕС, които са посочили образованието си (Евростат). По наше изчисление по данни на Евростат около 31% от тях нямат висше. За хората, които сменят професията си без диплома по информатика, проектите в GitHub са от малкото неща, които работодателят може да провери сам.

България има най-високия дял в ЕС на ИКТ специалисти сред заетите в сектор „Информация и комуникации“, 76,3% през 2025 г. (Евростат). По наше закръгляне това са около трима от всеки четирима работещи в сектора. Други данни за местния пазар събрахме в материала за кариерата в IT индустрията.