Como entrevistar Engenheiros de Software

Esse artigo foi traduzido do Blog Triplebyte, em parceria com o Co-fundador da startup, Ammon Bartram.

Artigo original: https://triplebyte.com/blog/how-to-interview-engineers

Nós da Triplebyte fazemos muitas entrevistas com engenheiros de software. Nos últimos anos, entrevistei mais de 900 deles. Se foi um bom uso do meu tempo, podemos discutir depois (às vezes eu acordo suando frio de noite duvidando disso). De qualquer forma, nosso objetivo é melhorar a forma com que engenheiros são contratados. Para isso, estamos fazendo entrevistas que ignoram completamente a história dos candidatos (não sabemos se eles são formados, nem onde, ou até se já trabalharam em algum lugar). Olhamos apenas para suas habilidades de programação, e não credenciais e currículos. Quando um engenheiro é aprovado no nosso processo, ele vai direto para as entrevistas finais das empresas com quem trabalhamos (como Apple, Facebook, Dropbox e Stripe). E por isso conseguimos fechar o loop e ver como eles foram nessas entrevistas, o que nos permite avaliar como ninguém nossos métodos de seleção.

Neste post, vou apresentar o que aprendemos até agora com esses dados. A conclusão é que a forma com que as empresas entrevistam engenheiros está quebrada. E isso é fácil de falar (vários posts por aí falam isso). A parte difícil é entender o que fazer para melhorar isso. Meu objetivo com esse post é atacar esse desafio, e dar conselhos específicos para gestores e CTOs. Selecionar bons candidatos é muito difícil, mas acho que vários dos problemas podem ser resolvidos a partir de um processo cuidadoso.

O status quo

A maioria dos processos de seleção tem duas grandes etapas:

Triagem de candidatos
Entrevista finais

O objetivo da triagem é filtrar para fora do processo candidatos que não sejam boas escolhas o quanto antes para assim economizar tempo da equipe. Esse processo geralmente envolve algum tipo de recrutador ou RH avaliando currículos (em uns 10 segundos), seguido de uma rápida entrevista por telefone. Aproximadamente 18% das empresas com quem trabalhamos ainda aplica algum tipo de desafio de programação que o candidato pode fazer de casa. E é nessa etapa que a maioria dos candidatos é rejeitada. Nas empresas com que trabalhamos, mais de 50% dos candidatos caem fora na triagem de currículos, e outros 30% nas entrevistas iniciais e desafios de código. E a triagem é também onde o processo pode ser mais capciosos: recrutadores geralmente estão atolados de trabalho e precisam tomar decisões rápidas. É aí que as credenciais e os padrões e preconceitos se instalam.

As entrevistas finais geralmente são sessões de 45 minutos a 1 hora, cada uma com um entrevistador diferente. As sessões tratam geralmente de assuntos técnicos (com uma ou duas exceções tratando de fit cultural ou aspectos comportamentais). A decisão de contratar ou não contratar é tomada quando o candidato deixa o escritório, e dela participam o gestor contratante e todos que participaram das entrevistas. Essencialmente um candidato precisa de algum grande "patrocinador" a favor e ninguém muito contra para receber uma oferta.

Mas além do formato em comum, as entrevistas variam bastante. Das empresas com que trabalhamos:

39% usa quadros brancos e marcadores nas entrevistas (a entrevista de whiteboarding)
52% deixam que o candidato use seu próprio computador no processo
55% deixam que os entrevistadores escolham quais perguntas querem fazer (nos outros 45%, são usados bancos de perguntas padrão da empresa)
40% exigem a avaliação de habilidades e conhecimentos acadêmicos de ciência da computação para que possam fazer uma oferta
15% acham que conhecimentos acadêmicos de ciência da computação são na verdade indesejáveis, e acham que um candidato que fala muito do tema será improdutivo
80% usam qualquer linguagem de programação nas entrevistas, enquanto 20% exigem que seja usada alguma linguagem específica da empresa
5% avalia detalhes de sintaxe da linguagem durante as entrevistas

Nas empresas com quem trabalhamos, 22% dos candidatos que passam pelas entrevistas finais recebe uma oferta (e candidatos provenientes da Triplebyte recebem ofertas em 53% dos casos). Em torno de 65% das ofertas são aceitas, ou seja, resultam em uma contratação. Após 1 ano, as empresas estão felizes e contentes com aproximadamente 30% das contratações feitas, e demitem em torno de 5%.

Falsos negativos e falsos positivos

Então, o que tem de errado com o status quo? As taxas de demissão não parecem estar fora de controle. Para entender o problema, precisamos entender que há duas formas de um processo seletivo dar errado: o processo pode resultar em um engenheiro ruim sendo contratado e depois demitido (um falso positivo) ou o processo pode recusar um engenheiro que teria sido um bom colaborador (um falso negativo). Más contratações são muito ruins. Sugam a energia do time e são extremamente visíveis e caras (em termos de salários, tempo de gestão e moral dos times). Candidatos que teriam sido bons mas não receberam uma oferta, por outro lado, não são tão visíveis. E por causa desta assimetria, as empresas possuem processos altamente orientados para a rejeição de candidatos.

Para manter o barulho dos falsos positivos baixo, as empresas erram muito para o lado da rejeição. O resultado é processos seletivos que deixam passar excelentes engenheiros, que dão mais importância às credenciais do que às habilidades reais, e que parecem subjetivos a ponto de deixar aflitos todos os participantes. Aqui vale uma provocação: se todo mundo que trabalha na sua empresa tivesse que passar de novo pelo processo seletivo para seu trabalho atual, quantos seriam "aprovados"? É uma pergunta assustadora. A resposta, provavelmente, é que com certeza passariam menos de 100%. Muito menos. Candidatos são prejudicados quando são rejeitados por empresas em que poderiam fazer uma excelente contribuição, e as empresas são prejudicadas quando não conseguem achar os talentos de que precisam.

Que fique claro: não estou dizendo que as empresas devam ser menos exigentes em seus processos seletivos. Rejeitar maus candidatos é justamente o ponto. Não estou nem falando que as empresas estão erradas ao temer os falsos positivos mais do que os falsos negativos. Contratações mal feitas são muito caras. Meu argumento é que um processo seletivo falho combinado a um viés para a rejeição resultam em uma taxa de falsos negativos alta demais. E a solução, para nós, está em melhorar o processo seletivo.

Formas concretas de melhorar o processo seletivo de engenheiros

Decida quais habilidades você está procurando

Não há um só conjunto de habilidades que define um bom programador. Há um mar de conjuntos. Nenhum engenheiro pode ser forte em todas as áreas de habilidades. De fato, nós da Triplebyte já vimos candidatos excelentes terem habilidades completamente diferentes. Então o primeiro passo para um processo seletivo excelente é decidir quais habilidades realmente importam para a vaga. Eu recomendo que você se pergunte o seguinte (e fazemos essas perguntas quando começamos a trabalhar com uma nova empresa):

Você precisa de programadores rápidos e iterativos, ou cuidadosos e rigorosos?
Você quer alguém mais motivado por resolver problemas técnicos difíceis ou construir um produto?
Você precisa de habilidades em alguma tecnologia específica, ou um programador esperto/inteligente pode aprendê-la no trabalho?
Conhecimentos acadêmicos/de ciência da computação são importantes ou irrelevantes?
Entender concorrência/o modelo de memória C/HTTP é importante?

Não há certo e errado. Trabalhamos com grandes empresas que responderam de maneiras opostas a estas perguntas. A chave é tomar uma decisão consciente, baseada nas suas necessidades. O anti-padrão a evitar é escolher suas perguntas e critérios de entrevistas de maneira aleatória, ou deixar que cada entrevistador escolha o que quiser. Quando isso acontece, você pode acabar com uma equipe muito pouco diversa em termos de habilidades, e que tenha as habilidades erradas para suas necessidades. E os engenheiros com as habilidades corretas podem acabar sendo reprovados.

Avalie o candidato sob condições reais de trabalho

Engenheiros de software são contratados para resolver problemas grandes e complexos durante semanas e meses. Mas entrevistadores não têm semanas ou meses para avaliar seus candidatos. Cada entrevistador tem em torno de uma hora. Por isso acabam avaliando a capacidade do candidato de resolver problemas simples rapidamente e sob pressão. E essa é uma habilidade bem diferente do que você precisa. Eles podem até ser correlacionados. Mas a correlação não é boa o suficiente.

Então minimizar o gap entre essas realidades é muito importante.

Isso se consegue fazendo com que o processo seja o mais parecido possível com a realidade que o candidato encontrará quando começar a trabalhar na empresa. Por exemplo, se você procura alguém de back-end, pedir ao candidato que construa uma simples API e depois que adicione features é muito provavelmente mais efetivo do que pedir ao candidato que resolva um problema de cadeias de palavras/BFS. Se você está buscando habilidade com algoritmos, perguntar ao candidato que aplique algoritmos a problemas (como por exemplo, construir um simples índice de busca, talvez baseado em um BST e um hashmap) é muito provavelmente mais efetivo do que pedir que determine e um ponto está contido em um polígono côncavo. E solucionar um bug é muito provavelmente melhor do que fazer algum exercício no quadro branco.

Dito isso, há um argumento a favor de entrevistas em quadro branco: como entrevistador, eu não ligo a mínima se a engenheira memorizou o módulo itertools do Python. Eu ligo se ela consegue raciocinar como usar loops para resolver um problema. E ao deixar que a candidata trabalhe no quadro branco, eu a livro de ter que acertar a sintaxe da linguagem na virgula, e a deixo focar na lógica de programação. Mas de maneira geral acho que esse argumento cai por terra. É mais fácil deixar que a candidata trabalhe no seu computador e deixar claro para ela que a sintaxe exata não será avaliada, ou ainda deixar que ela consulte o Google (prova com consulta).

Há um importante ponto para lembrarmos quando falamos em tornar o processo seletivo o mais próximo possível do ambiente de trabalho: é importante que os desafios sejam livres de quaisquer dependências externas fora do controle do candidato. Por exemplo, pedir à candidata que escreva um simples scrapper em Ruby pode parecer um bom desafio do mundo real. No entanto, se ela precisar instalar o Nokogiri (uma biblioteca de Ruby) e ela acabar perdendo 30 minutos batendo cabeça com a instalação, a entrevista vira um inferno. Tempo não só foi jogado no lixo como o nível de stress da candidata foi para o céu.

Faça perguntas compostas que não possam ser "roubadas"

Outra boa regra a seguir é não usar perguntas que possam ser "roubadas", ou seja, para que haja alguma informação "mágica" que torne sua resolução óbvia e que possa ser achada no Love Mondays ou em algum fórum de discussão. Isso obviamente elimina da conta desafios de lógica tipo Google (o mais famoso é o da saída do liquidificador) ou quaisquer perguntas que dependam de um insight específico. E vamos além: o ideal é usar perguntas/desafios que sejam compostos por múltiplas partes que se constróem umas nas outras. Um teste é se perguntar se os desafios que você está usando permitem que você ajude o candidato caso ele precise e ainda assim possa sair da entrevista com uma boa impressão dele. Em uma pergunta ruim, sua ajuda significará que ele falhou. Em uma pergunta boa, mesmo você ajudando em uma etapa da pergunta, o candidato ainda tem que acertar as outras para ir bem.

Isso não é só importante por que os candidatos vão acabar descobrindo as respostas na internet. Mas sim porque perguntas compostas são melhores para avaliar as habilidades dos candidatos. Bons candidatos podem ficar nervosos e "travar" (engenheiros tendem a ser mais introvertidos e tímidos). Ajudá-los a se recuperar é importante. Problemas compostos suavizam o processo, e dão ao candidato a oportunidade de verem seus esforços dando resultados. Esforços aplicados a uma parte ajudam na próxima. E essa é uma dinâmica muito importante no mundo real.

Exemplos: pedir a um candidato que implemente um joguinho Connect Four no terminal (em uma série de passos) é provavelmente uma pergunta melhor do que pedir a ele que gire uma matriz (um passo único). E implementar a clusterização de médias-k é provavelmente melhor do que pedir que determine qual o maior retângulo que cabe dentro de um histograma.

Evite perguntas difíceis

Se um candidato resolve uma pergunta muito difícil bem, isso diz muito sobre suas habilidades. Porém, devido à dificuldade da pergunta, a maioria dos candidatos não será capaz de resolver bem a questão. A quantidade de informação dos candidatos ganha com uma pergunta é, portanto, muito impactada pela dificuldade da mesma. O nível de dificuldade ideal é bem menor do que a maioria dos entrevistadores acredita.

Esse efeito é amplificado pelo fato de que há dois fatores sendo considerados durante uma entrevista: se o candidato responde "corretamente" a pergunta e qual foi seu processo/esforço para chegar a aquela resposta. Na Tryplebyte, examinamos dados de ambos (avaliando se a resposta foi correta e qual o esforço foi necessário para atingi-la, e depois medindo qual das notas prevê com mais acurácia o sucesso dentro da empresa).

O que descobrimos foi um tradeoff. Quando as perguntas são mais difíceis, o que carrega mais peso é se a resposta do candidato foi correta. Mas quando as perguntas são mais fáceis, o processo e esforço do candidato na resolução do problema que melhor preveem seu sucesso na empresa. Considerando ambos os fatores, se tem um resultado melhor quando as questões tem um nível de dificuldade menor.
A regra que seguimos agora é de que entrevistadores devem ser capazes de resolver o problema apresentado em ¼ do tempo que esperam que os candidatos dediquem à tarefa. Então, se estou desenvolvendo um problema para ser resolvido em 1h pela candidato, espero que meus colegas de trabalho consigam resolver a mesma questão em 15 minutos, sem aviso prévio. Em conjunto com a prática de apresentar problemas que aparecem no dia a dia real do trabalho, isso significa que a pergunta ideal em entrevistas é bastante direta e relativamente fácil.

Quero deixar claro que não estou defendendo que mais candidatos passem dessa etapa. Estou defendendo que as perguntas em si sejam mais fáceis, mas que também se leve em conta qual o nível de esforço que o candidato teve para chegar à solução. Estou defendendo perguntas fáceis e julgamento duro. Dessa forma, a nota do candidato tem maior relação com o seu futuro desempenho na empresa. E há o benefício adicional de ser menos estressante para a maioria dos candidatos.

Por exemplo, pedir a um candidato que crie uma interface de command line simples com comandos para armazenar e reaver pares de chaves e valores é provavelmente melhor do que pedir que implemente um parser para expressões aritméticas. E uma pergunta envolvendo estruturas de dados comuns (listas, matrizes e árvores) é provavelmente melhor do que uma pergunta sobre skiplists, treaps e outras estruturas obscuras.

Faça as mesmas perguntas para todos os candidatos

O objetivo de entrevistas é comparar candidatos, separando aqueles que podem contribuir muito para a empresa e aqueles que não tem o potencial de fazer o mesmo (e no caso de uma posição específica, encontrar a pessoa que se encaixa mais com a função). Portanto, não há nenhuma justificativa para fazer perguntas diferentes para candidatos diferentes. Se você avalia candidatos para a mesma posição de formas diferentes, você está introduzindo ruído nos dados.

Eu acho que escolher perguntas de forma ad-hoc continua sendo comum porque é o que entrevistadores preferem. Engenheiros em empresas de tecnologia tipicamente não gostam de entrevistar candidatos. É algo que eles fazem esporadicamente, e que os tira de seu foco principal.
Para padronizar as perguntas feitas para cada candidato, os entrevistadores teriam que dedicar mais tempo para aprender as perguntas e discutir escalas de avaliação e como a questão é apresentada. E eles teriam que fazer isso toda vez que a pergunta mudasse. Além disso, perguntar sempre a mesma coisa da mesma forma é um pouco mais tedioso.

Infelizmente, a única solução aqui é que os entrevistadores se esforcem para manter as entrevistas consistentes. A consistência é essencial para conduzir boas entrevistas, e isso significa fazer as mesmas perguntas, da mesma forma, para todos os candidatos. Simplesmente não há outra alternativa.

Considere rodar variações da entrevista em paralelo

Em conflito com meu ponto anterior, considere usar várias versões completamente diferentes da sua entrevista. O primeiro passo para criar uma entrevista é pensar quais habilidades são importantes a serem avaliadas. No entanto, algumas das respostas podem ser paradoxais! É bastante comum, por exemplo, querer um engenheiro que trabalhe muito bem com conceitos mais abstratos de matemática mas que também seja produtivos e iterativos (às vezes até para as mesmas funções).
Nesse caso, considere oferecer variações da entrevista. O ponto principal é ter escala o suficiente que você possa padronizar todas as variações do processo e ter observações suficientes para que cada variação seja minimamente relevante do ponto de vista estatístico. Fazemos isso aqui na Triplebyte. O que aprendemos é que você pode simplesmente perguntar para cada candidato que tipo de entrevista ele prefere.

Não seja enviesado por credenciais

Credenciais não são insignificantes. Engenheiros que se formaram no MIT ou em Stanford, ou que trabalharam no Google e na Apple realmente são melhores, na média, do que engenheiros que não tiveram as mesmas experiências. O problema é que a grande maioria dos engenheiros (eu incluso) não fez nenhuma dessas coisas. Portanto, se uma empresa coloca um peso excessivo nesses fatores, ela vai descartar a maioria dos candidatos, incluindo aqueles plenamente qualificados (falsos negativos).

Dar algum peso para credenciais durante a triagem não é totalmente irracional. Nós não fazemos isso na Triplebyte (toda nossa avaliação de candidatos é feita 100% sem a influência do seu histórico), mas não vemos problema em usar as credenciais com moderação. Deixar que as credenciais influenciem as decisões na fase de entrevistas finais, no entanto, não faz nenhum sentido. E nós temos dados que mostram que isso acontece. Para um dado nível de performance no nosso processo livre de histórico, candidatos com uma graduação de universidades prestigiadas tem uma aprovação 30% maior do que candidatos sem uma graduação "de marca". Se os entrevistadores sabem que o candidato veio do MIT, estão mais dispostos a perdoar dificuldades na entrevista.

Isso é um ruído, e deve ser evitado. A maneira mais óbvia é retirar o histórico acadêmico e profissional dos currículos antes de entregá-los aos entrevistadores. Claro que alguns candidatos podem mencionar sua universidade ou empresa, mas tentamos fazer com que todas as nossas entrevistas sejam feitas sem conhecimento prévio do histórico dos candidatos, e achamos que isso funciona muito bem.

Evite o "trote"

Uma das piores formas em que uma entrevista pode falhar é se tornar um "trote". Quando funcionam assim, as entrevistas não servem apenas para avaliar as habilidades dos candidatos, pois viram um ritual através do qual o grupo admite um novo membro. Como um rito de passagem. E aí a entrevista tende a se tornar um calvário, estressante e horrível, justificado pelo fato de "todos já terem passado por isso um dia".
O horror desse tipo de entrevista pode ser agravado quando um candidato está indo mal. Como um entrevistador, pode ser frustrante ver um candidato bater contra um muro no processo de resolução do problema, quando a resposta parece tão óbvia! Você pode perder a paciência e ficar frustrado. Isso, é claro, só aumenta o stress do candidato numa espiral descendente. E isso é algo que você deve evitar a qualquer custo.

Um truque que usamos quando o candidato está indo muito mal é ir de uma postura de avaliador, onde o objetivo é julgar o candidato, para uma postura de professor, onde o objetivo é fazer o candidato entender o problema. Mentalmente, essa mudança de postura pode ajudar muito. Quando seu objetivo é ensinar, não há motivo para ocultar informações ou ser qualquer coisa que não amigável.

Tome decisões baseadas em habilidades "máximas" demonstradas, e não "mínimas"

Até agora, a gente só falou sobre perguntas e entrevistas, mas ainda não falamos nada sobre as decisões finais de contratar ou não contratar um candidato. Nosso conselho aqui é simples: tentar basear sua decisão na melhor habilidade que você tenha observado no candidato durante o processo, e não na média ou na pior.

Achamos que a maioria das empresas já faz isso intuitivamente. Geralmente, todos os entrevistadores de um dado candidato se reúnem em uma sala de reuniões quando o candidato vai embora e discutem seu desempenho. Tendem a ser contratados aqueles candidatos que têm pelo menos um grande defensor (alguém muito convicto de que o candidato deve ser contratado) e nenhum grande detrator (alguém muito convicto de que o candidato não deve ser contratado). E na nossa experiência, geralmente esse grande defensor foi alguém que observou o candidato realmente arrebentando em um dado pedaço das entrevistas, enquanto os grandes detratores são aqueles que viram o candidato falhando miseravelmente em algum pedaço das entrevistas.

E aqui a coisa fica difícil: há tantos sabores diferentes de bons engenheiros que nenhum consegue ser bom em tudo. E isso significa que com a pergunta certa (ou será errada?) qualquer engenheiro pode ser posto em uma situação onde soa estúpido. Então candidatos tendem a receber ofertas quando algum entrevistador pergunta justamente algo em que ele é bom, e quando ninguém pergunta justamente algo em que ele é péssimo. E o desafio é justamente esse: um bom engenheiro que tenha arrebentado em uma entrevista focada em redes (seu ponto forte) pode falhar miseravelmente em uma próxima entrevista em que redes não tenham sido um tópico.

Por isso, achamos que o ideal é que as empresas deem mais valor para as áreas onde o candidato tenha realmente deixado uma excelente impressão, e menos valor para as áreas onde ele tenha eventualmente falhado. Busque razões fortes para aprovar o candidato, e não razões para reprová-lo. Não quero ser dogmático nisso - claro que pode haver áreas de conhecimento/expertise que são importantes para todos os engenheiros de uma empresa. Mas mantenha o que eu disse em mente e você não poderá errar muito.

Por que então realizar entrevistas?

Uma pergunta final que devemos tentar responder é por que então realizar entrevistas? Por que não evitá-las completamente?

Períodos probatórios e projetos

Tenho certeza que alguns dos nossos leitores estão se perguntando "por que focar tanto em algo que não está funcionando? É só dar desafios para o candidato levar para casa… ou ainda contratar para um período de experiência...". Até por que, muitas empresas muito bem-sucedidas usam períodos de experiência (quando o candidato trabalha na empresa em período probatório por algumas semanas), e até nem fazem entrevistas em favor deste método de seleção. Isso faz todo o sentido. Trabalhar lado a lado com um engenheiro de software por alguns dias é uma forma sensacional de selecionar bons candidatos, e muito melhor do que uma entrevista de uma hora. No entanto, esses testes têm dois grandes problemas:

Eles são muito caros: nenhuma empresa pode gastar uma semana com cada candidato que aplica para seu processo seletivo. Para triar candidatos, a empresa precisa de algum outro método menos caro, e
Períodos de testes, assim como grandes projetos a serem feitos em casa, são muito caros para o candidato. Mesmo quando são remunerados, nem todos os candidatos têm o tempo necessário para fazê-los direito. E mesmo quando podem, alguns simplesmente não querem. Se um programador já tem um emprego ele estará automaticamente menos disposto a investir seu tempo em um projeto teste incerto. Vemos isso claramente com os candidatos da Triplebyte. Vários dos melhores candidatos (com ofertas em mãos) simplesmente não aceitam projetos ou períodos probatórios

O resultado é que períodos de teste são uma boa opção para selecionar alguns candidatos, mas não todos. Então se você tem a escala e os recursos necessários para ter dois caminhos paralelos de seleção, use o método para alguns candidatos (talvez funcione melhor com candidatos mais juniores e menos concorridos). Mas entrevistas bem estruturadas serão necessárias com as estrelas que não têm tempo nem paciência para este tipo de processo seletivo.

Questionar experiências passadas

Outra forma de evitar testes técnicos e projetos, a experiência nos diz, é entrevistar o candidato com foco nas suas experiências passadas. A lógica é a seguinte: para entender como o candidato vai desempenhar no futuro, entenda bem como ele desempenhou no passado em situações comparáveis.

Testamos também essa tese na Triplebyte, sem bons resultados. Nessas entrevistas acabaram indo bem aqueles candidatos que se comunicam bem (ou seja, que conseguem vender seu peixe), e não aqueles que tinham habilidades técnicas mais sólidas. É muito comum se deparar com candidatos que falam muito bem e que acabam exagerando um pouco suas conquistas, por exemplo tomando para si méritos de seus colegas e times. E também é muito comum encontrar excelentes engenheiros que não são grandes comunicadores e/ou subestimam suas contribuições. É claro, dado tempo e esforço suficientes, um bom entrevistador consegue neutralizar esses efeitos. No entanto, sob as limitações de uma entrevista normal (principalmente o tempo reduzido de duração), o ruído é muito significativo e atrapalha a seleção. Por isso, nossa recomendação é usar este tipo de pergunta apenas para quebrar o gelo com o candidato, mas focar a energia nas questões técnicas.

Conclusão

Quero terminar este post em um tom mais positivo. Por mais que haja muita coisa quebrada no processo de seleção e entrevistas de engenheiros, também há coisas que funcionam bem, obrigado.

Por mais que sejam imperfeitas, as entrevistas técnicas de programadores ainda estão entre os processos mais meritocráticos que conhecemos. Em outras profissões, como docência e advocacia, são medidos apenas aspectos como a capacidade de comunicação e as credenciais dos candidatos. No nosso meio, no entanto, vamos além e testamos as suas habilidades. Pontos para todos nós.

E aperfeiçoar esse processo é extremamente difícil. Julgar os méritos de um candidato em algumas horas é algo dificílimo, quiçá destinado ao fracasso. Mas isso não significa que devemos simplesmente desistir. Nosso produto na Triplebyte é exatamente nosso processo seletivo, e não vamos desistir. Vamos experimentar, iterar, e você vai saber a cada nova conclusão a que chegarmos.

Além disso, vemos que consistentemente nossos candidatos ainda preferem entrevistas a outros tipos de avaliação, como testes técnicos, lições de casa e períodos de experiência. Por isso achamos que as entrevistas estão aqui, por bem ou por mal, para ficar. Para parafrasear Churchill, “entrevistas são a pior maneira de se selecionar programadores, excluindo todas as outras maneiras que já testamos de tempos em tempos”.