Всем привет, меня зовут Денис. В рабочее время я тимлид одной из команд отдела цифровизации в Росатоме, а в личное — фуллстек‑разработчик, у которого есть хобби: выигрывать соревнования по программированию. Участвую и один, и с командами. Например, мы взяли Гран‑При VK Hack 2018, финал первого Цифрового Прорыва, второе место на Вездекод 2020, несколько этапов VK Fresh Code, серию Премий Алисы и хакатон от Яндекса, выиграли хакатон Volvo, удостоились высокой отметки от жюри на Junction 2019 и многое другое разных масштабов.

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

И так для систематической победы в конкурсах и хакатонах по программированию нужно всего лишь…

1. Знать о том, какие конкурсы вообще проводятся

Банально звучит, но в первую очередь нужно знать о бойцовском клубе соревновании. Полезно отслеживать различные каналы и новостные ленты по теме. Важным источником являются ещё и платформы для разработчиков, там то и дело запускают соревнования с призами.

Несколько примеров:

• Russian Hackers — сообщество хакатон-энтузиастов. В канале раз в несколько дней стабильно новость об очередном хаке с возможностью зарегистрироваться. Кстати, в 2019 году именно Russian Hackers организовали Хакатон на Полярном Круге — в Салехарде. Мы там не выиграли, но это один из лучших хаков за всю мою жизнь, впечатлений очень много было. Кому интересно, вот статья о том, как всё проходило.

• All Cups — агрегатор IT-соревнований, куда был перенесён, в частности, Russian AI Cup, который аудитории Хабра наверняка хорошо известен. Личного опыта у меня нет, но, как я понимаю, в основном там небольшие онлайн-раунды на разные темы.

• VK Mini Apps — платформа миниприложений от ВКонтакте, на которой систематически запускают активности с призами для разработчиков: хакатоны, онлайн-конкурсы, контесты и так далее. Я участвовал в нескольких форматах. По личному ощущению (и в сравнении с многими другими) организация таких мероприятий у VK высочайшая, особенно в офлайне: всегда интересные локации, классные задания, понятные и адекватные критерии судейства. Вот история про хакатон 2018 года.

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

• Премия Алисы от Яндекса — долгоиграющий конкурс для разработчиков навыков к Алисе, результаты подводят раз в квартал уже несколько лет. Периодически менялись условия и награда.

• До недавнего времени хорошим источником была площадка Салют от Сбера. Но сейчас у неё дела не очень, и большинство активностей на площадке свернули. Впрочем, может быть ещё оживёт.

• Конкурсы от Телеграма*. Довольно регулярные задания с денежными призами. Тут часто бывает работа не только для программистов, но и, например, для дизайнеров.

• Ну и, я думаю, большинство знает Yandex Cup**, можно его не представлять.

2. Не лениться участвовать

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

Однако, как мне кажется, большинство недооценивает свои шансы на выигрыш и/или переоценивает порог вхождения. Нередко я выигрывал в конкурсе не из-за того, что обладал какими-то сверхнавыками, а просто из-за сравнительно небольшого числа претендентов.

Приведу два любопытных примера:

1. В конкурсе от площадки Салют в 2020 году была номинация “Наибольшее число приложений” (прошедших модерацию). Награждали три первых места. Велась сильная борьба за первые два, и в комьюнити многие сразу отказались участвовать, не желая вступать в гонку. В итоге третье место досталось человеку случайно, он просто выпустил пару приложений без какого-либо желания вписываться в конкурс и делал это пассивно. По итогам оказалось, что для попадания на третье место достаточно было посидеть два-три вечера, а призовая сумма при этом составляла порядка 500к рублей.

2. Когда начинался “Код Петербурга” в 2022-м, мы со знакомыми обсуждали этот конкурс в чате, и один товарищ прямо там сформулировал идею для приложения. Я тогда сразу сказал, что идея огонь, но он в итоге участвовать не стал. По результатам награждали 10 призовых мест, и многие решения явно уступали той идее моего знакомого. Я абсолютно уверен, что, прими он участие, в десятку точно попал бы, и скорее всего получил бы призовые порядка 600-800 тысяч рублей.

Если мотивации в виде приза мало, то вот ещё рецепт: подгонять под конкурс какие-то существующие личные наработки. Большинство программистов, так или иначе, занимается собственными проектами помимо работы: коммитят в опенсорс, изучают новые технологии, пишут статьи.

Например, на текущий момент у меня несколько статей на Хабре по алгоритмам, и наработки, описанные в них, были использованы в конкурсах (во всех случаях успешно), хотя ничто из этого не создавалось изначально специально под какое-нибудь соревнование.

3. Понимать критерии оценки

Лично я глобально разделил бы все айтишные состязания на три типа:

“Творчество”

Тебе дают общую задачу, описывают проблему, которую ты должен решить. Ты выбираешь практически любые инструменты для её решения, делаешь, затем презентуешь результат. Результат, как правило, оценивают члены жюри, реже голосование пользователей или комьюнити. Помимо просто хорошо сделанного решения тут нередко имеет значение ещё и качество презентации. Мой любимый тип состязаний. Таковы большинство хакатонов, например.

“Жизнеспособность”

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

“Техзадание”

Тебе дают подробные инструкции, что именно нужно сделать, зачастую ещё и предоставляют готовые макеты, если речь идёт о создании приложения с интерфейсом. Такими конкурсами компании пользуются, чтобы дёшево получить большой объём конкретной программистской работы над конкретными бизнес-задачами компании. Например, почти все конкурсы Telegram принадлежат к этой категории. Лично я считаю эту категорию скучной, но многим знакомым айтишникам, наоборот, нравится, потому что не нужно самому ничего придумывать.

Бывают смешанные критерии: допустим, жюри составляет шорт-лист, который потом сортируется по метриками или голосованию. Или, скажем, есть и чёткие инструкции и оценка метрик — спортивное программирование. В любом случае, участвуя в конкурсе, вы должны точно понимать, как работа будет оцениваться.

4. Выбрать главную цель

Здесь я пойду в обратном порядке по увеличению сложности.

Каждая мелочь

В контестах с типом “Техзадание” работы участников почти одинаковые. Отличаются они буквально в мелочах. Оценивать могут всё, даже какие-то вещи, о которых вы не подумали: например, размер сборки в байтах. Так что здесь сложно, но одновременно просто: вам нужно вложить максимум усилий в максимально близкую к идеалу реализацию.

Программисты любят такие вещи, потому что они интуитивно ощущаются справедливыми — субъективный вкус жюри почти не влияет на распределение мест. Но и разрыв совсем небольшой: первое место с призом в $10000 от второго с призом в $5000 может отделять лишняя миллисекунда в скорости загрузки начального экрана.

Пример из жизни. Лет 10 назад я выиграл один небольшой конкурс, потому что вместо Flex-компонентов (да, конкурс был на Flash) нарисовал свои, которые весили в несколько раз меньше. Визуально было то же самое, что у соперников, а по размеру сборки я их обошёл.

Любой ценой

У “Жизнеспособности” плюс в том, что чаще всего способ достижения метрик не слишком важен. Но в этом же и минус. Нередко конкурс превращается не в соревнование по программированию, а в соревнование по хитрости и “взлому” системы. Мне рассказывали историю про хакатон по ML, где работы участников загоняли в функцию оценки, которая выдавала численную результативность, и победил человек, который просто аккуратно подобрал нужные коэффициенты в экселе. Ещё подобное бывает при прохождении роботами полос препятствий: можно не программировать способность реагировать на датчики, а просто захардкодить последовательность шагов в стиле “ехать прямо в течение 810 мс, затем направо на 32 градуса, затем ещё прямо в течение 1235 мс”.

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

Пример из жизни. У Яндекс Диалогов есть динамический чарт, где представлены топ-100 самых популярных навыков в Алисе. Разработчики этих навыков регулярно получают от Яндекса денежные выплаты просто за счёт нахождения их продуктов в топе. Поскольку Алисой активно пользуются дети, то вполне неплохой трафик идёт в навыки-повторюшки (Алиса просто возвращает тебе твою же фразу; помните, наверное, как игрушечный хомяк-повторюшка). Понятно, что никакой работы по написанию такого навыка не нужно, обычно это едва ли 5-10 строчек кода. Тем не менее, вы можете увидеть в этом топе: Хомяк повторюшка, Хрюшка повторюшка, Детская повторюшка, Пукающая повторюшка, Громкая повторюшка, Картавая повторюшка, Мужская повторюшка, Зайка повторюшка… Обилие однообразного хлама даже в абсолютном топе по всей платформе указывает на синтетический абьюз системы. Не то, чтоб такого не было в других областях, но как участнику конкурсов лично мне подобное совершенно не интересно, даже если это сулит какие-то деньги.

Индивидуальный подход

Категория “Творчество” требует от вас понимания того, что за люди будут в жюри. И на общем уровне, и на уровне мелочей. Например, если вы знаете, что в жюри все пользуются айфонами, то будет разумно отшлифовать интерфейс приложения или сайта именно под айфоны, использовать знакомый визуал и iOS-подобные анимации.

Но, в целом, ответьте сами себе на вопросы: Что это за люди? Какой у них опыт работы с технологиями? Что они могут ценить выше, а что ниже? По какой причине им нужен конкурс, что они хотели бы от решений? Те же Russian Hackers в одной из своих лекций дали простой, но дельный совет: “Подойдите к любому организатору, и напрямую спросите, что нужно сделать, чтобы выиграть”.

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

Пример из жизни. В Салехарде мы делали голосовой навык и не учли тот факт, что люди чаще всего с навыками знакомы плохо, и для них это выглядит, как обычный чат-бот, просто с озвучкой. Мы сделали супер хитрый NLP-модуль, который обрабатывал кучу вариантов голосовых команд на естественном языке. Как вы думаете, что сделал первый же член жюри, запустивший наше решение? Он забил на голос и стал нажимать на экране кнопки… об обработке которых мы совершенно не подумали. За двое суток хакатона ни один из нас не удосужился попробовать нажать в навыке кнопку вместо того, чтобы вводить команду голосом. Мы к тому моменту работали с голосовыми решениями уже не первый год и просто отвыкли от того, как обычные люди извне реагируют на таких ботов первый раз. Да, как в анекдоте “Тестировщик заходит в бар”. Так и проиграли.

5. Обладать нужными умениями

Понятное дело, что вы не выиграете конкурс программистов, если не умеете программировать. Ладно, может и выиграете, но тогда это очень плохой конкурс, и так бывает крайне редко. В остальном: вам нужно уметь делать то, в чём вы соревнуетесь. И уметь делать это хорошо.

Подбор команды

Если соревнование командное, то важно и распределение ролей в команде, и готовность работать совместно. Думаю, по правильному подбору и организации команды на хакатон можно написать отдельную статью (чаще всего я капитан, так что есть приличный опыт в этом). Но главные тезисы такие:

• Равноправие и демократия не работают. Должен быть капитан, который ведёт команду, и на период конкурса все соглашаются его слушаться (что не исключает, конечно, возможность спорить, предлагать другие идеи и так далее).

• Каждый член команды должен обладать навыками, благодаря которым у него всегда будет работа на период конкурса. Не должно быть ситуации, при которой в команде два программиста сидят долбят код 48 часов и один продуктолог, который последние 2 часа составляет презентацию, а до этого особо ничего не делает.

• Вы должны точно знать, что задача принципиально решаема вашими силами.

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

Софтскиллы

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

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

Пример из жизни. На AtomSkills — это наш внутренний Росатомовский чемпионат по всем профессиям, в том числе по программированию — мы заметили в задании неточность и убедили жюри в том, что наше решение в этой части можно трактовать, как частично выполненное, хотя изначально нам собирались не зачесть этот пункт, и мы потеряли бы много баллов. Кстати, этот чемпионат проводится по методике WorldSkills, и он неожиданно интересный. Предложить поучаствовать людям извне я не могу, зато вы можете почитать и посмотреть немного внутренней кухни.

Хардскиллы

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

Обратное тоже верно: если задание решаемо несколькими путями, выбирайте тот инструментарий, которым владеете. Можно командой одних бэкендеров сделать бота там, где другие команды соорудят веб-сервис (если подобное позволяет регламент, но чаще всего позволяет).

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

Заключение

Я вам описал кучу плюсов и историй успеха, но, как вы понимаете, не бывает добра без худа. Участие в конкурсах может лишать вас огромного количества свободных вечеров и выходных. Поражения бывают очень обидными: например, один раз комиссия отказалась вообще нормально смотреть наш проект, потому что мы сделали игру, а жюри ожидали не игру (в условиях, конечно же, никаких ограничений не было). Иногда по выбору организаторов ты понимаешь, что формулировка задания вообще не имеет никакого отношения к тому, что они на самом деле хотели. Иногда ты понимаешь, что выиграла команда, которая ничего не сделала, однако удачно показала презентацию. Или, например, команда соединила два чужих опенсорсных проекта.

Однако же, всё равно это очень интересно и, при определённой сноровке, приносит немалый дополнительный доход. Не говоря уже об обучении новым навыкам и поддержании старых в тонусе.

Сноски

UPD. Первоначально у статьи был заголовок: "Почему я выигрываю конкурсы по программированию, а вы — нет". Аудитория в основном посчитала его кликбейтным (отсюда и основное количество минусов), хотя, помимо отсылки на известную в интернетах мемную конструкцию ("...а вы — нет") я просто старался таким способом выразить свою досаду от того, что разработчики часто относятся к конкурсам очень пассивно, не используя возможности, которые у них на самом деле есть. Что ж, по видимому, искусство заголовка — не моя сильная сторона. Если вы дочитали досюда, надеюсь, в тексте встретилось что-то новое, полезное или интересное для вас.