Do ano passado (2016) até Janeiro desse ano, em meio a desventuras pessoais e aventuras profissionais passei por alguns processos de contratação. Em geral, experiências ruins como a maioria dos processos pra contratação de desenvolvedores de software são.
Arrisco dizer: qualquer um que já tenha participado de pelo menos dois processos em grandes empresas conhece o teor estúpido da maior parte deles. A vergonha alheia geralmente já começa no job description, e nos piores casos, vai até o fim do processo.
A ideia aqui é refletir sobre algumas coisitas curiosas tão presentes em recrutamentos na área de software, na visão de um desenvolvedor que já acompanhou algumas dezenas de processos desse tipo e participou de outros. Então vamos lá.
Brinquedos, cores e sabores
Descrições de vagas extremamente infantilizadas é bad smell. É cada vez mais comum encontrarmos job descriptions que destacam o quanto você seria privilegiado com a oportunidade de fazer parte do time de pessoas felizes que adoram Star Wars, vestem chapéu do Mário e jogam video game na empresa!
Máquina de café, ping pong, no dress code (nossa), são coisas superficiais e naturalmente surgem como consequência de um bom ambiente de trabalho. Nenhuma dessas coisas implica na existência de ambiente agradável pra se trabalhar.
Então por que empresas destacam essas coisas muito mais do que os benefícios que me interessam realmente (plano de carreira, por exemplo)?
Simples: distrações para encontrar mão de obra barata. E funciona. Conheço umas 5 pessoas que trabalham em empresas e startups cheias de diversão e happy hour (uhul), mas vivem insatisfeitas com o plano de carreira extremamente mal definido, falta de perspectiva em relação a novos desafios e nunca sequer ouviram falar sobre aumentos salariais ou mudança de cargo.
Essa infantilização é intencional e venenosa. Essas mesmas pessoas que conheço começam a pensar: “Poxa, eu trabalho as vezes em home office, trabalho de bermuda no escritório e bebendo cerveja. Talvez eu esteja sendo ingrato.” Não. Você não está sendo ingrato. Se você pensa dessa forma, a tática funcionou com você.
Obviamente isso não é uma regra. Existem sim empresas que além de oferecer toda essa estrutura bacanuda e os brinquedos divertidos, se preocupam com o crescimento profissional e a realização real dos seus colaboradores. Essas empresas geralmente tem dinheiro (diferente de muita startup com job description colorido por aí), e elas não precisam exibir seu “excelente ambiente de trabalho” de forma artificial pra chamar sua atenção.
Coincidência ou não, as melhores propostas de trabalho que já recebi (ou vi pessoas recebendo) vieram de empresas que de forma direta, falaram sobre salário, benefícios, políticas de hora extra e plano de carreira. Se não te falam sobre essas coisas, desconfie. Fuja da cilada da fábrica de doces.
Enigmas e labirintos. Pra que?!
Depois de conversar com alguém por telefone/skype, a primeira etapa da maioria dos processos é um teste de lógica. Acho até justo. Como recrutador, não quero conversar com um sujeito que não consegue resolver problemas triviais de lógica, certo? Mais ou menos.
O que era pra ser um teste de lógica, vira algo como um exame psicotécnico pra não habilitados (tipo daqueles pra tirar carteira mesmo). Ao invés de receber uma prova que desafie sua capacidade de raciocínio lógico e resolução de problemas, as vezes você recebe um labirinto, um jogo da memória ou até uma especie de hieroglifo. Coisas do tipo “qual será a próxima figura?” onde existem outras três fotos completamente abstratas e sem sentido. Ou “qual será a próxima cor?” onde existem um quadrado vermelho, verde e um azul…
Sei menos que nada sobre psicologia, mas acho que não precisa saber pra se irritar com testes desse tipo. Como desenvolvedor, estou sendo contratado pra resolver problemas usando software, tecnologia e técnicas que de alguma forma envolvem atividades relacionadas ao processo de desenvolvimento de software.
Por que não testam minhas capacidades nesse contexto então?
De duas uma: simplesmente não sabem fazer isso ou acham caro demais. Acredito mais na primeira opção. Já vi avaliações extremamente eficientes no que diz respeito à avaliação lógica e nenhuma delas envolvia questões confusas de múltipla escolha (falo disso daqui a pouco).
Não acho justo que pessoas se sintam burras por tirar notas horríveis em testes assim. Enquanto empresas não tiverem pessoas intelectualmente capazes de testar competências lógicas com um teste decente, um diálogo ou qualquer coisa que faça sentido, vamos continuar sofrendo com essa bobagem. É importante saber que existem sim maneiras diferentes de se testar esse tipo de capacidade, então, paciência… Esteja pronto pra chutar a maioria das questões nesse caso, e relax.
Binary search, bubble sort e árvores
Na hora de avaliar conhecimentos técnicos de forma pouco mais aprofundada, fazem de tudo. Apesar de alguns aspectos serem comuns a todo tipo de processo, a forma de avaliação varia de acordo com nível de senioridade e com o tipo de tecnologia.
Seja júnior ou sênior, quem nunca viu testes que pedem implementação de coisas do tipo “crie uma estrutura de árvore binária bem como seus métodos de inserção, remoção e pesquisa”? Esperam de coração que você saiba implementar esse tipo de coisa do zero, literalmente from scratch.
Depois de ter visto tanta coisa desse tipo, comecei a me questionar: “Será que realmente devo me esforçar pra saber esse tipo de implementação específica?”, sem resposta fui pro Hacker Hank começar a resolver tudo quanto é desafio de lógica e estrutura de dados. Estou quase no final do “30 days of code” (uma série de desafios que o Hacker Rank propõem para exercitar esse tipo de coisa) e depois de ter implementado alguns métodos de ordenação (quick sort, insertion sort e bubble sort), e alguns métodos de pesquisa (sequencial e binária) na raça, posso dizer que nada mudou na minha vida como desenvolvedor.
Conhecer de cabeça a implementação de um algoritmo que balanceia uma árvore binária não faz de você um programador melhor. É essencial que você saiba o que são as estruturas de dados, conhecer diferenças entre elas, quando não se recomenda utilizar uma ou outra, e por aí vai. Mas o pleno conhecimento de alguns métodos lógicos específicos exigem um certo esforço repetitivo, e isso na minha opinião não tem valor algum.
Participei de um processo uma vez onde o recrutador me fez uma série de perguntas sobre diferenças entre estruturas de dados, modelos relacionais e não relacionais, me pediu pra falar sobre o que se entende sobre padrões de projeto, e no fim me pediu pra resolver um problema de lógica usando uma linguagem de programação que fictícia, chamada i++. O ponto aqui é que esses são aspectos relevantes. Não tive que buscar na memória nada que não fosse (ou pelo menos deveria ser) trivial na vida de todo programador ou programadora.
O perfil generalista do desenvolvedor é mais explorável. Consegue-se extrair muito mais informações sobre o conhecimento de um profissional dessa área partindo de abordagens genéricas para mais específicas. Começar pelo minucioso ou no pior caso, “decoreba”, é anti-produtivo e bastante desmotivador!
Quando descubro que desafios desse tipo vão acontecer em algum processo que estou participando, me preparo antes no Tesdome ou no próprio Hacker Hank pra fazer bonito. Cada vez mais amigos meus dizem fazer isso em casos desse tipo. Repare no quanto se torna ridículo: desenvolvedores se preparam para resolver problemas extremamente específicos em um processo de contratação, parece concurso. Weird!
Vai ser sempre assim?
Contratar um desenvolvedor é sempre complicado e talvez (com sorte) não é demorado. O processo é caro porque precisa ser. Grande parte do aspecto sem sentido e desagradável em processos de contratação, são fruto de economias burras feitas por empresas com medo de investir em um processo decente, e na minha opinião, isso deveria ser feito.
Enquanto se tem um mercado mal educado e imaturo, acreditando em serviços de terceirização de RH e produtos milagrosos que simplesmente “encontram” desenvolvedores de forma rápida e indolor (mágica), sofreremos com processos longos, sem sentido e cheios de inutilidade. Contratantes querem rápido e barato, o fato é que isso não existe sem antes investir em se ter pessoas altamente capacitadas a contratar programadores.
Por fim, a dica é: gaste um tempo consumindo conteúdo informativo, veja como foram experiencias de outros desenvolvedores durante processos em empresas específicas no Love Mondays e no Glassdoor, converse com as pessoas no LinkedIn e desconfie sempre de propostas nebulosas, de empresas perfeitas e ambientes coloridos demais (risos).
Referências e links úteis
Obs.: Não achei conteúdo decente sobre processos de contratação de desenvolvedores. A maioria é conteúdo propagandístico da upworks, geek hunter e outros serviços “milagrosos” de contratação. Se você tem um link maneiro de um livro/post/video, por favor poste nos comentários! :)