Hard-Skills: Da prova técnica à entrevista para vaga de Desenvolvedor

Desde 2013 corrijo provas e entrevisto candidatos à cargos de desenvolvimento e engenharia de software. Como entrevistador, sempre o foco é encontrar talentos, principalmente pessoas melhores que nós mesmos, o que sempre nos fará crescer como pessoas e time.

Várias são as peculiaridades e capacidades dos candidatos, e quando falamos de hard-skills há sempre o que acreditamos ser o cenário desejável e, claro, o cenário ideal. O que diversas vezes ficam evidentes são casos de candidatos com síndrome do impostor ou, embora em casos raros, porém com muito pesar, efeito Dunning–Kruger.

Você conhece de verdade seus limites?

Quais são suas capacidades e suas fraquezas?

Que tal uma análise SWOT?

"Nosce te ipsum"

A Prova Técnica

Aplicar uma prova técnica é um procedimento padrão no momento de tentar buscar e reconhecer ótimos técnicos com as skills para fazer o business prosperar. Assim como sou entrevistador e avaliador, também já fui, sou e sempre serei avaliado.

Afinal, o que realmente importa na prova técnica?

Embora cada empresa e time tenha seu modo de avaliar, conversando com outros avaliadores parece haver um bom-senso e costume acerca do procedimento.

As dicas a seguir não estão detalhadas ou aprofundadas, afinal são tópicos colossais. Considere mais como um guia e sugestão, não como via de regra.

Documentação

O primeiro aspecto que é avaliado é o nível de detalhe (relevante, claro) da documentação do projeto entregue, geralmente realizada no arquivo README.md, quando utilizado Git.

A documentação tem que conter de forma sintetizada:

• Explicação do Arquétipo: porque esta foi a arquitetura proposta? Porque um banco NoSQL, ou utilização de um data stream para resolver tal problema?

• Diagramas: este auxiliam a explicação do arquétipo e, particularmente, gosto do C4Model para tal. Gosto da utilização dos diagramas de containers, components e deployment;

• Restrições: Quais são? Até onde você deseja ir e o que não pretende atender?

• Como executar o aplicação;

Quer saber um pouco mais sobre documentação de software ágil? Veja aqui vão algumas dicas.

Dependências para o Projeto

Ao baixar o fonte do seu projeto está tudo pronto para o correto funcionamento? Ou o avaliador precisa rodar scripts e provisionar recursos como MongoDB ou Elastic Search manualmente? Utilize a estratégia de containers Docker com Docker Compose, por exemplo. Isto demonstra preocupação não só com o código-fonte produzido, mas com o ecossistema de dependências, além de demonstrar uma cultura voltada para o DevOps.

Dependendo do nível e objetivo da prova poderia também se abordada uma estratégia Infrastructure as Code.

Lógica e Algoritmo

Diversos testes tentam filtrar pessoas com boa lógica e capacidade de resolução de problemas com algoritmos que vão desde cenários envolvendo sequência de Fibonacci e números primos até casos de implementação de algoritmos de busca, ordenação e grafos.

Se atente as as técnicas de algoritmo utilizadas. Por exemplo, em um algoritmo de busca solicitado, foi implementado com técnica brute force ou divide and conquer? Foi utilizada a técnica recursion ao invés de loops complexos?

Qual a complexidade e performance (Big O Notation)?

Interpretação do Negócio

Nas provas sempre há uma espécie de caso de uso ou especificação de requisitos que o candidato deve seguir. Transformar requisitos (linguagem natural) em código-fonte é algo peculiar e inerente à nossa profissão. Crie um código domain centric, e sintetize o unit test para cobertura dos cenários.

Teste

Como citado no tópico anterior, vá para uma abordagem de unit tests, e conheça os impactos e limites de tal abordagem. Documente a decisão por exemplo citando a pirâmide de testes.

Quando o assunto é Teste de Software prefiro uma abordagem ATDD (Acceptance Test-Driven Development). Como certamente não serão providos os critérios de aceite, crie você mesmo. Isto também demonstra tamanha senioridade com relação à absorção dos requisitos de negócio.

Cobertura de Testes

Em adição ao tópico anterior, avalie a cobertura de testes do código entregue, e busque o percentual mais alto possível, sempre focando em cobrir o maior número de cenários de negócio, pois entrega mais valor do que simplesmente cobrir linhas de código.

O Código

Ah, o código!!! O tão esperado e minuciosamente analisado. Há diversas técnicas que podem ajudá-lo a entregar um bom código. A qualidade já está bem garantida, pelo menos no aspecto funcional, se estiver com uma ótima cobertura de testes. Este tópico em si é homérico e extenso. Vou citar algumas técnicas aqui, contudo acredito que conhecimento e experiência agregados com code reviews de pessoas do times e colegas de profissão ajudam demais nessa evolução.

Utilize técnicas Clean Code, seja simplista (KISS: Keep it Simple, Stupid), apenas crie o que faz sentido evitando big design upfront (YAGNI: You Ain't Gonna Need It). Siga e tenha uma ótima noção de orientação a objetos (SOLID) e conhecimento de design patterns (GoF: Gang of Four Patterns).

A Entrevista

Este é o momento que gostamos de sua prova, possuímos dúvidas e queremos saber mais sobre você. Queremos saber sua história, seus anseios, por quais perrengues passou e como se saiu. Não queremos saber só do que deu certo, queremos saber decisões que também foram catastróficas para o negócio, arquitetura ou até para o time.

Neste momento queremos saber o que você acredita que seja o caminho ideal, queremos saber o que você aconselha ou abomina. Esqueça como é no seu trabalho atual, ou em um anterior. Isto realmente não importa. Precisamos de sua experiência, e na entrevista você precisa transpirar informação, principalmente o que acredita ser o melhor caminho.

Comportamento

No momento da entrevista com certeza há a análise comportamental, todavia não é nosso objetivo aqui. Estamos falando de tech! Porém, só pra dar aquela "palhinha", fica a pergunta: Não é contagiante quando encontra alguém que fala entusiasmo sobre algo que ama? Acima de tudo, seja verdadeiro, porém demonstre sua paixão pelo que faz. Afinal, se não está tão apaixonado assim, talvez deveria buscar fazer o que realmente ama ;)

Termos Técnicos

Na entrevista é imprescindível conhecer os conceitos inerentes a tecnologia em questão, e certamente é um atalho conhecer o termo correto. Conhecer os termos (e até as buzz words) do mundo de desenvolvimento ajuda e garante que entrevistado e entrevistador estão falando a mesma língua e, principalmente, demonstra que o entrevistado está bem conectado e sempre busca conhecimento.

Por exemplo, temos muitos utilizados são (não importa se inglês ou português) Test Driven Design, Domain Driven Design, Unit Testing, ORM, Load Testing, Microservice, Monolith, Transação Distribuída, dentre outros.

Conhecimento

O conhecimento requerido é sempre exposto na vaga publicada. Fique atento ao que é imprescindível, pois é fator decisivo. Se candidatar sem conhecer o necessário é perder seu tempo e o tempo dos entrevistadores.

Se já conhece o necessário, avance para o que é marcado como "desejável" ou "diferencial".

Lembre-se: Na entrevista fale a verdade! Se não conhece sobre um assunto ou tecnologia, apenas diga a verdade.

Esteja preparado, busque conhecimento em blogs, vídeos e livros, assim sempre estará preparado.

Faltou alguma dica? Quer ajudar a dar mais informação pra galera? Mande suas sugestões e dicas ;)