Em mais de uma década trabalhando na área de TI, eu fiz minha cota de entrevistas, para empresas muito pequenas, empresas médias, empresas grandes e absurdamente grandes. Tanto nacionalmente quanto internacionalmente.

Mas foi quando estive do outro lado, como entrevistador (algumas dezenas de vezes depois), que eu notei como tudo era diferente...

Eu acho que chegou a hora de eu escrever sobre como tanto nós como devs quanto recrutadores estamos entendendo as coisas de forma diferente. Esse artigo vai ser bastante informal, com muitas opiniões minhas, e eu adoraria ouvir um pouco sobre o que você também tem a dizer!

Me chama lá no meu Twitter e me conta o que você acha e quais as suas opiniões sobre esse assunto!

Entrevistas técnicas

Desde que eu comecei a trabalhar, eu sempre tive muito medo de entrevistas, especialmente as técnicas (eu, na verdade, sempre gostei de entrevistas comportamentais), inicialmente eu tinha muito mais, hoje em dia se tornou algo muito mais simples, – especialmente com um mercado mais acelerado onde, como dev, a média de tempo que ficamos em um emprego é de um a dois anos – primeiro eu sempre achei que as pessoas iam me julgar e se eu, por algum motivo, não passasse na entrevista, isso invalidaria todo o trabalho que eu já fiz na vida até aquele momento. Eu era uma fraude!

Mas não é bem assim...

Com o tempo eu fui percebendo que entrevistas técnicas não eram só "um freela não remunerado", ou então "alguém muito sacana que está querendo que você falhe". Claro, entrevistas ruins são assim, mas as boas entrevistas vão muito além do código.

Tipos de entrevistas

Vamos começar diferenciando as etapas destas entrevistas e os tipos que elas podem aparecer para você, mas antes eu quero pincelar um tipo de entrevista interessante. O teste lógico.

Eu vou usar exemplos do que vi aqui (na Suécia) como sendo mais comum, mas isso pode variar de lugar pra lugar

Teste lógico e "entrevista inicial"

Eu nem chamo isso de entrevista por isso que estou colocando antes de tudo, mas é muito comum termos um teste de lógica básica, algo como:

"qual é a próxima figura dada essas três figuras"

O objetivo deste teste, pelo que eu sempre notei, era cortar pessoas que não teriam nenhuma chance nas próximas etapas que iriam requerer muito conhecimento lógico, imagina que é uma nota de corte, só isso.

Esse tipo de teste tanto não é uma entrevista técnica que ele geralmente acontece antes de qualquer entrevista, geralmente depois de uma entrevista inicial, que é uma chamada entre você e a pessoa que está gerenciando o processo (recruiter) só pra garantir que você é uma pessoa de verdade e atende os requisitos mínimos da vaga.

Testes de proficiência

Esse tipo de teste é o que a maioria da galera está acostumada. Um teste que é entregue pela empresa para que você resolva. Ele pode ter tipos diferentes, e pode acontecer de diversas formas, vamos falar de alguns que eu já passei:

1. Take-home assignment: É o teste enviado pela empresa através de um e-mail, zip ou qualquer coisa que você possa ler com calma, resolver e devolver. Esses são geralmente exercícios mais longos, com mais etapas, mas com um tempo muito maior para fazer e também não tem a pressão de estar sendo observado
2. Pair programming: Pode ser feito em pessoa ou em chamada, é a mesma coisa do exercício pra casa, só que você faz ao vivo, com alguém falando contigo. Idealmente não é para você se sentir pressionado, mas mesmo que a pessoa não esteja diretamente te julgando, ainda sim é um ambiente bem estressante. Esses exercícios geralmente começam com uma pergunta simples, que vai escalando aos poucos.
3. Revisão de código: É um meio a meio entre os dois anteriores, e pessoalmente o meu preferido, quando você tem uma etapa onde faz um exercício técnico, devolve, mas recebe feedbacks ao vivo e revisa o código com as pessoas mais técnicas do outro lado, isso tira um pouco da pressão, mas muitas vezes ambas acontecem com um tempo muito longo entre uma e outra e isso pode atrapalhar a resolução.
4. Entrevista de arquitetura : Uma entrevista focada em criar uma arquitetura para uma determinada solução, o objetivo aqui não é codar a solução, mas explicar como ela funcionaria e como você arquitetaria todo o projeto. Pelo menos aqui, as duas são feitas no mesmo processo para uma vaga.
5. Algorítmos: Esse tipo de entrevista é aquele onde você recebe um link para uma plataforma tipo o Codility, HackerRank, etc. É um exercício cujo foco é apenas na resolução técnica de um problema teórico, por exemplo: "Achar o menor número de uma lista".

Inclusive, fiz uma thread no Twitter com uma pesquisa sobre qual é o que a galera mais gosta e, sem dúvida, o mais votado foi o exercício para casa:

E isso tem um motivo muito simples.

Entrevistas nunca são sobre código

Existem bons testes e maus testes. Os bons testes são complexos o suficiente para serem desafiadores, mas simples o suficiente para não serem impossíveis. E a parte mais importante: O código não importa.

O que importa nesse tipo de teste é o caminho da resolução do problema, claro que existem nuances de como alguém escreve um código, como a pessoa documenta esse código, como a performance é avaliada, mas você percebe que a pergunta não é sobre o código em si, mas como você pensa sobre o código?

Desafios que eu considero ruins são exatamente os desafios de algorítmos, eles são totalmente sobre o código, você raramente vai ter que resolver um problema desses na vida real, muito menos sobre pressão com algum tempo específico. Transformar uma entrevista em um teste de paciência e estresse é algo que não traz muito valor e, muitas vezes, a razão da falha é justamente por causa disso

Mas isso é uma forma de avaliar como você se comporta sob estresse

A não ser que o seu trabalho seja estar em constante estresse com deadlines absurdamente curtas para o que você precisa fazer, eu diria que talvez essa não seja uma boa empresa para estar...

Além disso, o foco direto no código, e somente no código, não deixa você analisar outras características do desenvolvimento, como comunicação, trabalho em equipe, resolução de problemas...

O código é uma das ferramentas, por exemplo, você precisa saber usar um rolo de pintura se você for um pintor, mas você não precisa saber todos os detalhes sobre todos os rolos de pintura existentes.

As boas entrevistas

Eu, particularmente, gosto de uma sequência de entrevistas que focam não só na parte técnica, muitas vezes a parte técnica nem é a parte mais importante (pelo menos não é para mim quando eu sou o entrevistador), simplesmente pelo fato de que você vai passar substancialmente mais tempo interagindo com o time e com outras pessoas do que codando, de fato.

Isso não significa que a parte técnica pode ser completamente ignorada, pelo contrário, ela é parte integrante do todo que compõe o trabalho, uma entrevista técnica muito ruim vai minar o sucesso da vaga, com certeza. Mas uma entrevista não técnica muito boa pode ser o diferencial entre ser aceito ou não, mesmo que outras partes não tenham sido tão boas.

Para mim, o processo ideal é:

1. Começar com uma entrevista inicial, que não é técnica, e foca apenas em conhecer a pessoa que está aplicando. Essa entrevista geralmente é feita com a pessoa que conhece da vaga, provavelmente a área de contratação. O objetivo aqui não é avaliar tecnicamente ninguém, mas entender o momento e o background da pessoa para ver se ela vai ter uma boa integração, deve ser curta, no máximo 20 ou 30 minutos.
2. Depois passamos por uma entrevista comportamental, chamada de behavioural interview , que é uma entrevista focada na parte não técnica da coisa. Ela dura 1h e geralmente as perguntas são relacionadas às coisas do passado, como a pessoa trabalhou com alguma coisa, como ela resolveu um determinado problema, quais foram as principais lições que ela tirou disso. Essa pra mim é a principal entrevista, se a pessoa não conseguir mostrar que ela é uma pessoa que vai se dar bem com o time ou que não tem a mesma ideia da empresa, ela é instantaneamente rejeitada, enquanto você pode não ir tão bem em uma entrevista técnica e ainda passar, mais uma vez: nunca foi sobre o código
3. o terceiro passo seria a entrevista técnica em si, focada em um desafio específico, vamos ver mais sobre no próximo parágrafo
4. No final podemos ou não ter uma entrevista de arquitetura, isso depende muito da vaga, eu não acredito que elas contribuem tanto dependendo do nível esperado.

Agora quais são os testes técnicos que eu acho que valem a pena serem aplicados

Os bons testes técnicos

Para mim um bom teste técnico é aquele que consegue replicar bem o ambiente de trabalho e, ao mesmo tempo, mostrar como é o processo de pensamento da pessoa, que é o mais importante.

Eu prefiro não aplicar testes de algoritmos pelos motivos que falei antes, não acho que eles sejam justos. Eles não mostram como alguém resolve um problema, mas sim que alguém consegue resolver aquele problema.

Além disso eu não gosto de testes surpresa onde você não sabe de nada previamente. isso não é real, você nunca vai entrar em uma empresa onde o produto que você precisa desenvolver simplesmente vai aparecer pronto pra você do nada, mas vai existir todo um processo de conhecimento daquele projeto.

Para mim os melhores testes são aqueles que são enviados para a pessoa e ela tem um determinado tempo (de dias e não horas) para finalizar, usando todos os recursos que ela puder. O teste é então enviado de volta e aí a entrevista técnica em si é sobre a revisão e perguntas sobre aquele código.

Eu acho esse um processo muito mais válido porque você está avaliando um código que foi feito pela pessoa, sobre um desafio imposto pela empresa. Muitas vezes a base do teste vem pronta e você precisa cumprir com alguns requisitos, adicionar outros e etc.

Outro tipo de teste que eu acho interessante é enviar uma aplicação pronta para a pessoa analisar geralmente um dia antes, no dia seguinte a entrevista seria uma série de perguntas para adicionar novas funcionalidades àquela aplicação. Eu acredito que essa é a forma de chegar mais perto do que seria um dia a dia na empresa, porque 99% do tempo nós não vamos criar nada, mas manter o que existe é adicionar coisas novas, além do que esse tipo de aproximação permite que a gente também veja o processo de pensamento de uma pessoa. Que é a parte mais importante.

E não importa se a pessoa finalizar ou não o teste, ou parte de um teste, o importante é saber se ela conseguiria ou não finalizar, ou se a forma de pensar é comunicar dela estaria correta. Lembre-se não é sobre o código.

Conclusão

Esse post foi uma forma de trazer um pouco do que eu aprendi depois de centenas de entrevistas tanto como candidato quanto como entrevistador e ter visto um pouco mais de como tudo isso funciona do ponto de vista técnico como dev.

A minha ideia é expandir mais nesse tópico com vídeos lá no meu canal e falar mais sobre cada parte do processo, mas criar vídeos é um processo complexo e eu queria ter certeza de que existe gente interessada no assunto.

Então, se você achar essa ideia interessante, me chama lá no twitter e me fala o que você achou mais interessante e o que eu posso focar mais nesse tópico! Vou adorar saber o seu feedback!