Parte final da trilogia sobre hackathons. No falei sobre a motivação para participar de tais eventos. Foi dedicada aos erros dos organizadores e seus resultados. A parte final responderá às perguntas que não couberam nas duas primeiras partes.
Conte como você começou a participar de hackathons.
Estudei no mestrado da Universidade de Lappeenranta, enquanto participava de competições de análise de dados. Meu dia típico era assim: acordava às 8, tinha algumas aulas na universidade, depois competições e cursos até a meia-noite (enquanto aguardava a submissão, assistia a palestras ou lia artigos). Esse cronograma rigoroso deu resultados, e eu ganhei a competição de análise de dados MERC-2017 (o que até gerou um ). A vitória aumentou minha confiança, e quando me deparei com informações sobre o hackathon SkinHack 2 em Moscou, decidi visitar meus pais e descobrir o que era — um hackathon.
O hackathon em si foi bastante divertido. Havia duas trilhas de análise de dados com métricas claras e um conjunto de dados, com prêmios de 100 mil rublos. A terceira trilha era de desenvolvimento de aplicativos com um prêmio de 50 mil, e não havia participantes. Em um momento, o organizador disse que uma janela com um botão sem funcionalidade poderia ganhar 50 mil, porque o prêmio não poderia ser não pago. Eu não quis aprender a programar aplicativos (não competo onde posso ser facilmente 'destruído'), mas para mim essa foi uma mensagem clara de que os campos em hackathons não estão saturados.
Naquele momento, eu estava resolvendo as duas trilhas de análise de dados sozinho. Encontrei uma brecha nos dados que permitia obter uma pontuação perfeita, mas a coluna com a brecha não estava nos dados de teste que recebi duas horas antes do final do evento (a propósito, naquele momento eu entendi que a presença da coluna 'target' no treinamento não conta como brecha). Ao mesmo tempo, o leaderboard foi aberto, minha submissão sem a brecha estava em terceiro lugar de cinco, havia uma grande diferença até o primeiro e decidi não perder tempo e fui embora.
Depois de analisar com clareza o que aconteceu, encontrei vários erros (um dos meus hábitos é revisitar mentalmente o que ocorreu, com um caderno e analisar os erros, suas causas e o que poderia ser mudado — um legado agradável de jogar poker semi-profissionalmente). Mas uma coisa ficou clara — há muito valor nos hackathons, e eu simplesmente preciso realizá-lo. Após esse evento, comecei a monitorar eventos e grupos, e o próximo hackathon não demorou a chegar. Depois mais um, e mais um...
Por que você participa de hackathons e não de Kaggle?
No momento, não estou interessado no Kaggle. A partir de um certo nível de habilidades, sem razões específicas para participar, o Kaggle se torna menos útil do que outras atividades. Participei bastante antes, aparentemente consegui "sair".
Por que hackathons e não trabalhar em seu próprio projeto?
Gosto da ideia de fazer algo incrível com minhas próprias mãos em um ritmo desacelerado. O pessoal do ODS organizou para todos que querem dedicar seus finais de semana a seus projetos em um grupo de pessoas com ideias semelhantes. Acredito que em breve irei me juntar a eles.
Como você encontra os eventos?
Minha principal fonte é hackathon.com (mundo) e um grupo no Telegram (Rússia). Além disso, anúncios de eventos aparecem em redes sociais e no LinkedIn. Se nada for encontrado, você pode conferir aqui: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Você elabora um plano de ação antes de participar ou tudo é decidido no improviso? Por exemplo, uma semana antes do hackathon, você planeja: "Vou precisar de tal e tal especialista, preciso procurar"?
Se for um hackathon voltado para produto — sim, me preparo. Algumas semanas antes, eu penso no que farei, avalio quem pode ser útil, monto uma equipe com amigos ou participantes de hackathons anteriores.
É realmente possível hackear um hackathon sozinho? O que fazer se não houver equipe?
Os hackathons de data science são reais (eu sou um exemplo vivo disso), os de produtos — não vi, embora também pense que sim. Infelizmente, às vezes os organizadores impõem um limite no número mínimo de participantes na equipe. Acredito que isso se deve ao fato de que nem todos os “solitários” chegam à final (ou seja, simplesmente desistem ao enfrentar as primeiras dificuldades); participar em equipe ajuda a manter esse impulso. Além disso, após o evento, espera-se que você continue trabalhando no projeto. Com uma equipe, será mais fácil levar o projeto adiante.
No geral, recomendo sempre participar em equipe. Se você não tiver sua própria equipe, os organizadores sempre ajudarão a encontrá-la ou criá-la.
Como você consegue lidar com a fadiga durante um hackathon?
Em um hackathon, temos 2 dias para trabalhar, isso é 48 horas (30-48 horas, vamos considerar 48 para facilitar a conta). Tirando o tempo para dormir (16-20 horas), restam no máximo 30. Desses, realisticamente, cerca de 8 horas vão para trabalho produtivo (em média). Se você organizar bem seu tempo (sono, alimentação, ar fresco, exercícios, momentos de mindfulness, boa comunicação com a equipe e alternância de atividades), pode aumentar suas horas de trabalho profundo para 12-14. Após esse trabalho, você se sentirá exausto, mas será uma exaustão prazerosa. Programar sem dormir e sem pausas, se alimentando de energéticos — é caminho para o fracasso.
Você já tem seus próprios pipelines prontos para hackathons? Como eles surgiram, como estão organizados (os arquivos .py estão em pastas, cada um para sua tarefa, etc.) e como começar a criar os seus?
Eu não uso soluções prontas de hackathons anteriores em novos, mas tenho meu próprio zoológico de modelos e pipelines de competições passadas. Não preciso reescrever trechos padrão do zero (por exemplo, a codificação correta de target ou uma rede simples para identificar a intenção no texto), o que me economiza muito tempo.
Atualmente, isso se parece com isso: para cada competição ou hackathon, há um repositório no GitHub, onde estão armazenados notebooks, scripts e uma breve documentação sobre o que está acontecendo. Além disso, há um repositório separado para várias “gimmicks” prontas (como a codificação correta de target com validação cruzada). Não acho que seja a solução mais elegante, mas, por enquanto, estou satisfeito.
Eu começaria salvando todo o meu código em pastas e escrevendo uma documentação curta (por que, o que, como fiz e o resultado).
É realmente possível preparar um MVP do zero em tão pouco tempo ou todos os participantes chegam com soluções prontas?
Posso falar apenas sobre projetos relacionados a data science — sim, é possível. Para mim, MVP é a combinação de dois fatores:
- Uma ideia viável apresentada como um produto (ou seja, um business canvas elaborado). Sempre deve haver uma compreensão clara do porquê e para quem estamos fazendo o produto. Às vezes, projetos com uma proposta bem fundamentada, mas sem protótipo, ganham prêmios, e isso não é surpreendente. Infelizmente, muitos participantes não conseguem se abstrair da amargura da derrota e atribuem suas falhas à falta de visão dos organizadores, continuando a desenvolver modelos que não se sabe para quem em hackathons futuros.
- Algum indicativo de que você pode fazer esse produto (aplicativo, código, descrição de pipelines).
Às vezes, uma equipe chega ao hackathon com uma solução pronta e tenta "adaptá-la" à tarefa dos organizadores. Essas equipes são desclassificadas na triagem técnica ou só é contabilizada a parte que elas desenvolveram no evento. Eu não vi tais equipes entre os vencedores, mas acho que ainda é vantajoso para elas participar devido ao valor futuro ().
Existem exemplos de projetos desenvolvidos em hackathons que foram levados à produção/startup?
Sim. Tive três casos em que levaram ao produto final. Uma vez eu mesmo, duas vezes — por meio de outras pessoas com base nas minhas ideias e no código que escrevi no hackathon. Também conheço algumas equipes que continuaram a colaboração com a empresa como consultores. Não sei os resultados finais, mas é bem provável que algo tenha sido concluído. Não organizei startups e não sei se alguém fez, embora eu esteja certo de que há exemplos.
Após participar de muitos hackathons, que conselhos você daria a si mesmo se pudesse voltar no tempo?
- A tática é mais importante do que as manobras. Encare cada decisão como um produto pronto. A ideia, o jupyter notebook, o algoritmo não valem nada se não está claro quem pagará por isso.
- Antes de projetar qualquer coisa, pergunte-se não “o quê?”, mas “por quê?” e “como?”. Exemplo: ao projetar uma solução de ML, comece pensando no algoritmo ideal: o que ele recebe como entrada, como suas previsões são utilizadas a seguir?
- Participe da equipe.
O que geralmente servem em hackathons?
Geralmente, em hackathons a comida é ruim: pizzas, energéticos, refrigerantes. Quase sempre a comida é organizada em formato de buffet (ou mesa de distribuição) onde se forma uma enorme fila. À noite, normalmente não há comida, embora tenha havido um caso em uma competição em Paris onde deixaram petiscos à noite — chips, donuts e refrigerante. Posso imaginar o processo mental dos organizadores: “Então, o que os programadores comem? Ah, claro! Chips, donuts — isso deve bastar. Vamos dar isso para eles.” No dia seguinte, perguntei aos organizadores: “Pessoal, não seria possível preparar algo diferente para a noite? Tipo uma sopa, por exemplo?” Depois disso, me olharam como se eu fosse um idiota. É o famoso acolhimento francês.
Em bons hackathons, a comida é encomendada em caixas, com opções de alimentação comum, vegetariana e kosher. Além disso, há uma geladeira com iogurtes e granola — para quem quer petiscar. Chá, café e água — são padrão. Lembro-me do hackathon Hack Moscow 2 — lá nos serviram generosamente borscht e almôndegas com purê no refeitório do escritório 1C.
A qualidade dos hackathons depende, por assim dizer, da área profissional dos organizadores (por exemplo, os melhores hackathons são organizados por consultores)?
Os melhores hackathons foram realizados por organizadores que ou já haviam organizado hackathons antes ou havia participado deles anteriormente. Talvez esse seja o único fator que influencia a qualidade do evento.
Como saber que você não é um novato e é hora de ir a um hackathon?
O melhor momento para participar de um hackathon foi há um ano. O segundo melhor momento é agora. Então, vá em frente, cometa erros, aprenda — isso é normal. Até uma rede neural — a maior invenção da humanidade depois da roda e do boosting de gradiente sobre árvores — não consegue distinguir um gato de um cachorro na primeira época de aprendizado.
Quais são os “sinais vermelhos” que indicam imediatamente que o evento não será bom e que não vale a pena gastar tempo?
- Uma descrição clara do que precisa ser feito (relevante para hackathons de produtos). Se, ao se registrar, uma tarefa clara for definida, é melhor ficar em casa. Na minha memória, não houve um bom hackathon com um briefing. Para comparação: Bom — faça algo relacionado à análise de conversas de áudio. Ruim — faça um aplicativo que seja capaz de separar uma conversa em duas trilhas sonoras separadas para cada pessoa.
- Um prêmio pequeno. Se pedirem para você criar um “Tinder para lojas online com IA” e o prêmio para o primeiro lugar for 500 euros com um tamanho mínimo de equipe de 5 pessoas — talvez não valha a pena perder tempo (sim, este é um hackathon real que ocorreu em Munique).
- Falta de dados (relevante para hackathons de ciência de dados). Os organizadores geralmente fornecem informações básicas sobre o evento e, às vezes, uma amostra do conjunto de dados. Se não forneceram — pergunte, você não vai perder nada. Se em 2-3 dias não estiver claro quais dados serão fornecidos e se realmente serão — isso é um sinal vermelho.
- Novos organizadores. Não hesite em pesquisar informações sobre os organizadores do hackathon. Se eles estão realizando esse tipo de evento pela primeira vez — há uma grande probabilidade de que algo dê errado. Por outro lado, se o organizador e os membros do júri já realizaram hackathons ou participaram ativamente no passado — isso é um sinal verde.
Em um hackathon, me disseram: “Você tinha a melhor solução em termos de pontuação, mas desculpe, aqui avaliamos o trabalho em equipe, e você trabalhou sozinho. Se você tivesse trazido um estudante ou uma garota na equipe…?” Você já encontrou uma injustiça assim? Como lidou com isso?
Sim, já encontrei e não foi uma vez. Eu adoto uma abordagem estoica em relação a tudo o que acontece: fiz tudo o que pude, se não funcionou — que seja.
Por que você faz tudo isso?
Tudo isso é apenas por tédio.
Fonte: habr.com
