Hackathon como forma de contratação

{ September 26th, 2014 }


cmilfont

Autor: cmilfont

Sempre tive a id√©ia de utilizar um Hackathon como modelo de avalia√ß√£o de candidatos que desej√°vamos contratar, apresentei o modelo para a Fortes e realizamos um evento com bastante sucesso em 2012. ¬†Outras equipes da empresa passaram a utilizar a experi√™ncia e se tornou um modelo a ser seguido internamente e j√° com v√°rias edi√ß√Ķes.

Esse ano fizemos o segundo do meu time para avaliar um candidato em Rails justamente para me substituir (foi meu √ļltimo compromisso na empresa, apesar de j√° ter sa√≠do).

 

Vantagens

Contratar alguém é sempre uma loteria, por mais justo que seja o processo. Envolve, além dos aspectos técnicos, saber se o sujeito conseguirá se integrar na equipe aonde vai trabalhar, se não fere princípios e cultura da empresa e aceitação perante a todos os participantes. Não basta ter feeling no candidato, você precisa sempre comprovar que ele realmente merece, ou seja, o próprio avaliador também tem que saber vender a escolha que fez.

IMG_20140830_102439134

No primeiro Hackathon o candidato escolhido era primo de um funcion√°rio da empresa e membro do time aonde iria trabalhar, meu amigo pessoal e j√° tinha trabalhado na pr√≥pria empresa como terceirizado por uma consultoria. Ele venceu a competi√ß√£o com os crit√©rios estabelecidos acompanhado pelo departamento de RH (que participaram no dia do evento como olheiros), foi o suficiente para n√£o pairar nenhuma d√ļvida em sua escolha, apesar do RH ter escolhido outro candidato por quest√Ķes que n√£o estavam definidos nos nossos crit√©rios de avalia√ß√£o e premia√ß√£o (o Hackathon ainda teve um premio em dinheiro para o vencedor).

Formato

A avaliação dos aspectos técnicos é dentro de uma simulação do ambiente de trabalho, já que você provavelmente organizará o evento dentro de sua cultura. A pressão que se espera, o relacionamento que se espera que ele desempenhe e toda a expertise técnica é esmiuçada com mais detalhes do que uma simples prova ou avaliação de currículo.

No primeiro evento fizemos um detalhamento muito rígido de como os candidatos seriam avaliados, inclusive incluímos testes como item obrigatório.

IMG_20140830_125726664

Dessa vez o formato foi mais simples, apenas dois times codificando o mesmo sistema (as mesmas features), com apenas duas rodadas de avaliação, uma primeira aonde declarávamos e apontávamos todos os pontos negativos e de correção e a segunda que seria apenas uma forma de avaliar o evento, trocar feedback e curtir a tarde de diversão.

IMG_20140830_125705090

O formato de inscri√ß√£o no evento era acompanhado do curr√≠culo, link do github e quaisquer informa√ß√Ķes necess√°rias que os candidatos pudessem informar para ajudar na escolha dos participantes.

Os desenvolvedores estavam livres para codificarem como quiserem, avaliamos inclusive como eles se comportariam tendo que assumir posi√ß√Ķes com pessoas que nunca viram antes ou mesmo que conhecessem, nunca trabalharam juntas.

IMG_20140830_143802812

Feedback

O que todos perceberam é que uma simulação de codificação de uma Release real, mas acompanhado por uma equipe experiente que vai corrigindo o processo e os erros, é praticamente uma aula, um curso.

Tivemos o cuidado de apontar sempre quando o time se desviava do objetivo do desafio, praticamente doutrinar sobre o conceito de MVP dentro da realidade da empresa e do mercado. Pudemos perceber que os desenvolvedores se perdem fácil em detalhes que não são importantes em um produto e deixam seu ego passar sobre o valor do negócio.

IMG_20140830_164309781

O que percebemos também é que candidatos com o currículo muito forte ou experiente em relação aos demais  não conseguiu se vender tanto quanto outros candidatos que provavelmente seriam descartados logo de início em um processo convencional de apenas avaliação de currículo ou entrevista.

Daqui pra frente eu espero que o formato seja adotado em larga escala Рe vou trabalhar para isso Рcomo uma forma de contratação, inclusive na empresa que trabalho, a Sagarana.

Posted in eventos, Rails, Ruby ~ 2 Comments

Retrospectiva 2013

{ December 31st, 2013 }


cmilfont

Autor: cmilfont

Trabalho

Em 2013 eu integrei a Fortes Informática de verdade. Li 10+ livros técnicos, apesar de nenhum linguagem nova #shameonme (considero aprender uma linguagem nova apenas quando uso em um projeto real que vai para o ar).


Gravei alguns Screencasts, fiz cerca de 10 turmas em cursos de Javascript tanto em empresas quanto na minha, 8 turmas no Product On Rails e tantos outros em diversas modalidades que ministro. #cansativo

Eventos

Viajei para eventos em S√£o Paulo palestrando no MobileConf em abril.



Em maio construímos o JSConfBR (Eu, Henrique Gogó e Douglas Campos como organizadores, eu como realizador e Douglas Campos como curador e responsável pela família no Brazil).
Palestrei no mês de junho em Quixadá-CE e me surpreendi como uma universidade (ou o conjunto delas) pode transformar uma cidade.


Palestrei no mês de junho em Brasília no Agile Brazil com o Yuri Adams.


Final de junho e inicio de julho eu fui participar do QCON e RubyConf.


Viajei em agosto para palestrar pela primeira vez em Teresina para o evento do Agile Piauí.


Em novembro construímos (eu e Henrique Gogó) o CEJS que entra para o calendário anual.

CEJS 2013
Palestrei novamente na fantástica Uberlandia no TechDays do UaiJUG pelo terceiro ano seguido em novembro.

Esportes

Corri a 12ª Maratona Pão de Açucar de Revezamento com um time da Fortes (2x5km) e prometi me aposentar desse esporte.


Fui graduado a Purple Belt pelo Daniel Campelo (equipe Gigueto-MG) depois de 15 anos do primeiro treino (primeiro treino foi na antiga academia Sazinho Sá da Santos Dumont com o Onix Ferraz em 1997) ao mesmo tempo que quebrei uma costela e em seguida uma tendinite, terminei o ano com 6kg a mais.

Família

Descobrimos que estamos gr√°vidos do nosso segundo filho, o Miguel que nascer√° l√° pra festas juninas e vai integrar a equipe do Christian Milfont.


Terminamos o ano mais felizes e nos amando com a ben√ß√£o de D’us.

Um feliz ano novo a todos.

Posted in retrospectiva ~ No Comments

Designed for Use

Designed for Use

Uma dica bastante interessante que li no excelente Designed for Use: Create Usable Interfaces for Applications and the Web¬†de Lukas Mathis √© Don’t Interrupt (N√£o interrompa) seguida de¬†Instead of Interrupting, Offer Undo (Em vez de interromper, ofere√ßa o desfazer).

Pois bem, o exemplo usado é justamente a implementação do gmail web que não me interrompe quando transfiro um email para a lixeira, mas oferecendo a opção de desfazer caso por algum acidente eu tenha acionado a ação.

Notei a versão android pisando na bola por fazer as duas coisas, oferece a opção de desfazer, mas também me interrompe.  Seguem Screenshots da operação.

Eu adoraria fazer Drag and Drop para a lixeira na a√ß√£o de apertar o email por um tempo e n√£o apenas habilitar o menu de op√ß√Ķes.

Posted in usabilidade ~ 3 Comments