Как се печели хакатон: отбор, идея, работещо демо и две минути пред журито

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

Тук описваме как изглежда хакатонът от другата страна на масата: по наръчника за организатори на Major League Hacking (MLH), една от най-големите мрежи от студентски хакатони, и по това, което журито реално успява да види.

Как журито вижда вашия проект

Наръчникът на MLH препоръчва журиране „като на научен панаир“: всеки отбор стои на своята маса, а журиращите обикаля, гледат демо на живо и задават въпроси. Сметката, по която организаторите планират времето, е 4 минути на проект: 2 минути за представяне и демо, 1 минута за въпроси и оценяване и 1 минута, докато журиращият стигне до следващата маса. В инструкциите към самите журиращи стоят дори 3 минути на отбор.

Всеки проект трябва да бъде видян от поне трима журиращи. Вместо точки по десет критерия наръчникът препоръчва всеки журиращ да посочи своите три най-добри проекта, които получават 3, 2 и 1 точка. Ако има финал на сцената, на отбор се дават около 7 минути: 3–5 минути за представяне и време за смяна.

Изводът е прост: имате около две минути, за да покажете проблема, решението и че то работи. Всичко, което не се побира в тях, журито просто няма да види.

Преди събитието

• Прочетете правилата и темите. Кои категории има, какво точно се предава и до кога, може ли да се използва готов код и библиотеки.
• Подгответе инструментите, не проекта. Инсталирайте езиците и средите, проверете профилите си в Git и в облачните услуги, които ще ползвате. Готов код от преди събитието обикновено е забранен (повече в последната част).
• Съберете отбор с различни умения. Добрият отбор има човек, който пише back-end, човек за интерфейса, човек, който мисли за потребителя и разказва историята. Ако отивате сам, повечето хакатони имат време за събиране на отбори в началото.

Първите часове: идея, която се побира във времето

Най-честата грешка е твърде голямата идея. Изберете един проблем и една основна функция, която може да работи до края. Добър тест е да кажете идеята в едно изречение: „Приложение, което показва на студента свободните зали в момента“. Ако не можете, идеята е още размита.

Разпределете времето назад от крайния срок. Последните часове са за демото, видеото и описанието, не за нови функции. Решете още в началото кое ще пропуснете, ако не стигне времето: вход с парола, красив дизайн, мобилна версия. Журито прощава липсващи екстри, но не и демо, което не тръгва.

Демото печели

Проектът се предава в платформа за подаване на проекти. В шаблона на MLH полетата са: име, описание на проекта, връзка към кода или работеща версия, използвани технологии, категориите, за които кандидатствате, членовете на отбора и задължително описание дали и как сте ползвали инструменти с генеративен изкуствен интелект. Попълнете ги грижливо: това е първото, което журито чете, и остава видимо след събитието.

Наръчникът препоръчва и 2-минутно видео, което е демо на проекта, а не презентация. При журиране на живо то не е задължително, но помага при крайното обсъждане и после стои в портфолиото ви.

Как да построите двете минути:

1. Проблемът с едно изречение и за кого е.
2. Демо на живо: един истински сценарий от начало до край, с подготвени данни.
3. Какво е технически интересно: едно изречение, не списък с технологии.
4. Какво следва: какво бихте добавили с още време.

Репетирайте поне два пъти. Пазете резервен вариант: запис на екрана, ако интернетът в залата падне.

Честна игра: кодът се пише на място

Организаторите проверяват печелившите проекти. Сред сигналите, които наръчникът на MLH изброява, са: хранилище, започнато преди събитието; един голям commit в самото начало; промени след крайния срок; проект, споменаващ друго събитие; член на отбора, който не е допринесъл; много сходни проекти от други хакатони в профилите на участниците. Нито един сигнал сам по себе си не е повод за дисквалификация. Наръчникът изрично казва, че един commit в края не е причина за отстраняване, защото някои участници тепърва учат Git, но журито ще помоли отбора да обясни кой какво е направил.

Затова правете чести commit-и с ясни съобщения от първия час и бъдете готови всеки от отбора да обясни своята част. Ако ползвате готови библиотеки или инструменти с изкуствен интелект, кажете го открито.

Какво печелите, дори без награда

Хакатонът е едно от най-бързите места да покажете, че можете да работите в екип под срок. Готовият проект с описание и видео е отличен елемент от портфолиото без опит, а кодът в GitHub се вижда от работодателите (вижте как да подредите портфолиото си в GitHub). На много хакатони има ментори от компании, а това е и среща с бъдещи колеги. Ако тепърва избирате посока, ръководството за кариера в IT за начинаещи ще ви помогне да прецените къде да се упражнявате.