Наш рынок растет и развивается. Компании, помимо традиционных кадровых процедур, ищут новые пути поиска лучших специалистов. В свою очередь, разработчики, которые креативны по своей природе, готовы презентовать и проявить себя не только в рабочих задачах. Участие в хакатоне - своего рода испытание на прочность, тест собственной скорости ума.
Рад поделиться своим опытом участия в мероприятии в качестве капитана команды "чай СБЕРгамотом".
О событии
В октябре в Сбере прошел очередной хакатон “Лучший по профессии”.
Кратко о формате мероприятия:
На выбор нам предложили 38 задач из разных областей. Основные из них:
приложения для сотрудников (различные внутренние порталы), инструменты улучшения производственных процессов;
сервисы экосистемы;
забота о здоровье;
безопасность и противостояние кибер-угрозам.
К каждой задаче был описан ожидаемый стэк решения. Можно было объединиться в команды количеством от 3 до 5 человек. Первый этап конкурса представляет из себя 24-часовой хакатон, в рамках которого нужно разработать прототип решения на отведенную тему.
Каждое решение жюри оценивали по показателям:
работоспособность прототипа;
оценка UX;
качество решения;
техническая оценка кода;
масштабируемость.
На втором этапе все участники хакатона случайным образом распределяются по командам и участвуют в бизнес-игре, тема которой является единой для всех.
Опыт глазами участника
Расскажу о том, что получилось, а что нет. В состав команды вошли 3 Java-разработчика и 2 JS-разработчика. Мы выбрали задачу под названием “Медицинская карта сотрудника”.
24-часовой марафон кодинга
Трудности начались в первые же минуты хакатона. Мы оказались настолько самоуверены, что не обсудили до марафона скелет проекта и его функциональность - на это было потрачено драгоценное время хакатона. Вот и урок №1 на будущее - если заранее известны задача и стэк, то стоит подготовить хотя бы какой-то фундамент.
Недолго подумав, решили, что медицинская карта - это понятие обширное, и за 24 часа работающий прототип всей карты реализовать будет сложно. Пришли к выводу, что нужно сфокусироваться на каком-то одном блоке функциональности.
Вспомнили, что для посещения офиса зачастую требуются разные реквизиты в зависимости от действующих правил, поэтому выбрали актуальную тему борьбы с распространением COVID-19.
Решили запилить следующие функции в прототипе:
запись на тестирование (ПЦР), запись на вакцинацию
отслеживание текущего статуса действия ПЦР и вакцинации
отслеживание текущего статуса действия пропуска
Справедливости ради отмечу, что бОльшая часть описанного выше - уже реализована в одном из внутренних приложений для сотрудников Сбера. Нас это ничуть не смутило - решили, что наличие киллер-фичи принесет невиданные ранее для банка бизнес-ценности. Этой фичей стала возможность регулярной записи на ПЦР-тестирование.
Зачастую коллеги по цеху забывают записаться на очередной тест и узнают о том, что попасть в офис нельзя только у турникетов. Продолжать с таким непоправимым уроном культуре Sbergile невозможно и наша команда взялась за исправление ситуации.
Урок №2 - оглядываясь на этот шаг сейчас, понимаю, что стоило пригласить кого-то в команду с предпринимательской жилкой (пусть даже потеряв в хард-скилл-вооруженности). Если бы решение было более инновационным, то это явно принесло бы нам больше баллов в итоговом зачете.
После обсуждения функций спроектировали API прямо в ходе звонка с командой. Все поняли друг друга быстро и принялись за дело. И фронтовики и бэкэндеры распределили задачи между собой в разрезе функций, а не слоев кода - и, кажется, что это было первым верным решением.
В середине ночи боевой дух команды ушел на боковую и мы решили последовать его примеру. К этому моменту сквозной интеграции нашего веб-приложения с серверной частью еще не было и фронт работал на заглушках. За 2 часа до презентации мы и наш боевой дух принялись исправлять ситуацию. Наконец, победили в неравном бою с конфигурацией nginx (задача деплоя приложения оказалась сложнее, чем на первый взгляд), потратив на это час времени. Вуаля - и фронт ожил! Но продолжил радостно показывать данные из заглушек. Пришлось решать и проблему с конфигурацией CORS. Покончив и с ней, выявили несколько несостыковок в ожидаемых моделях данных. Время презентации уже как раз наступило, поэтому фиксить нужно было здесь и сейчас.
Вот и урок №3 - начать тестировать интеграцию и выявлять потенциальные проблемы стоило сразу. Как правило, вопросы, которые возникают несложные, но требуют внимательного гугления и последующей конфигурации. Параллельно ребята из фронт-команды работали над презентацией для нашего решения. Само видео получилось замечательным, но времени на подготовку к выступлению не осталось. Поэтому разделили роли и импровизировали при рассказе.
Финальный (банальный) урок по части кодинга: нужно не забывать про важность всех составляющих участия в хакатоне. Мы слишком увлеклись непосредственно технической реализацией, забыв о том, что техническая оценка - всего лишь один из аспектов. Не смотря на все препятствия - выступили хорошо. В оценках получили 9 из 10 возможных баллов в каждом из показателей.
Бизнес-игра
Кодингом все не ограничилось. Организаторы дали нам понять, что красноглазить - хорошо, но проблема глобального потепления сама себя не решит. Ну и софт-скиллы сами себя не оценят. Слаженные коллективы команд перемешали случайным образом и предложили решить проблему глобального потепления. В ходе решения задачи можно было обратиться за помощью к представителям науки, правительства и бизнеса.
Независимые консультанты наблюдали за нашим поведением в ходе игры и оценивали по следующим критериям:
управление результатом, ответственность;
управление собой;
клиентоцентричность.
Эта часть хакатона вызвала довольно много бурления резонанса среди участников. В чате мероприятия звучали такие мнения:
“Конкурс на лучшую команду должен проводиться в рамках собранной команды.”
“Софт скиллы для разработчиков безусловно важны, но в данной игре проверяются софтскиллы не разработчиков, а каких-то обобщенных абстрактных сотрудников Сбера, больше похожих на менеджеров. Разработчик работает в своей команде, которая очень важна и где все дополняют друг друга, он решает задачи в рамках своих рабочих компетенций, он часто мало общается с бизнесом, заказчиками и иже с ними, ибо это не его задачи.”
Лично мне кажется, что проверять наличие софт-скиллов важно и нужно, тут я согласен с организаторами. Но формат, при котором слаженные коллективы разбивают - кажется действительно спорным, ведь само мероприятие - командное. Сама задача оказалась интересной и заставила задуматься о последствиях простых ежедневных активностей. Были мнения, что оценивать нас по решению задачи из новой и неизвестной предметной области - это неправильно. Согласиться с таким тезисом не могу - сам формат хакатона, как по мне, предполагает быстрое погружение в незнакомые кейсы.
Итоги
Мы заняли 6 место в командном зачете и получили крутые памятные призы. Результатом команда довольна. Обидно, что могли выступить лучше, если бы не забили на фазу подготовки. Во многом не хватило организованности - тут вижу свое упущение (как капитана команды).
С другой стороны понимаю, что разработка - дело творческое. Среди нас много людей с рывковым типом производительности. Научиться понимать себя, разобраться с тем, как оставаться эффективным с таким складом ума - тема для отдельного разговора
А пока интересно Ваше мнение по поводу бизнес-игры:
Как вы думаете, нужно ли проверять наличие софт-скиллов у разработчика? Каким образом это можно оценить и нужно ли это делать в рамках хакатонов?
