Por que os entrevistadores não pedem ao solicitante que leia algum código? [fechadas]

Eu tive uma dúzia de entrevistas na minha vida (estou prestes a me formar) e me pergunto por que me pediram apenas uma vez para ler e explicar algum código. Aproximadamente, 90% dos trabalhos são principalmente sobre a manutenção de sistemas existentes. A capacidade da OMI de ler o código de outra pessoa é uma habilidade importante.

Por que os entrevistadores não conferem? *

* _{Entre meus amigos, sou o único que foi solicitado a revisar algum código.}

Quando eu estava fazendo perguntas da entrevista, eu fiz no começo, mas lentamente fui eliminando. Os candidatos que poderiam escrever código bem na entrevista puderam ler código bem na entrevista. Os candidatos que não sabiam ler o código também não podiam escrevê-lo. As perguntas envolvidas na leitura do código não diferenciaram realmente nenhum candidato.

Versão curta

Se o trabalho consiste em manter um aplicativo, as habilidades que você precisa testar durante as entrevistas são:

• A capacidade de entender a grande base de código com sua documentação, testes de unidade , etc.

• A capacidade de refatorar o código e trazer alterações sem quebrar tudo.

Pedir às pessoas que leiam o código não ajudará você a avaliar essas habilidades.

Versão longa

Você foi solicitado a escrever código? Se sim, como Sign observou em sua resposta , isso é suficiente. Se generalizarmos um pouco, uma pessoa que escrever código fonte claro e fácil de entender seria capaz de ler o código fonte escrito por outras pessoas.

Se você não foi solicitado a escrever código, então provavelmente foi entrevistado por uma pessoa do departamento de recursos humanos. Essas entrevistas não podem ser muito técnicas e são inúteis, pois não agregam suas habilidades e sua capacidade de funcionar bem, mas sim o número de anos que você passou na faculdade e outras coisas que não têm nada a ver com o trabalho.

Existem mais alguns motivos para não solicitar a leitura do código de um trabalho de manutenção:

1. É difícil fazer de maneira confiável

Concretamente, o que você faria se fosse um entrevistador? Faça seus candidatos lerem algum código. Qual código? Em que língua? Quão bem ou mal escrito? Com ou sem comentários? Com ou sem documentação?

Mais importante, o que isso diz sobre o candidato? Quão bem ele se correlaciona com a própria base de código?

Digamos que você tenha um aplicativo VB.NET herdado para manter. Você sabe que o código fonte é geralmente feio e não testado, e alguns comentários estão desatualizados ou enganosos. Nos últimos três meses, você teve um desenvolvedor muito habilidoso trabalhando na solução; ele refatorou e testou por unidade as partes mais críticas do aplicativo, adicionou comentários onde havia necessidade de comentários e, o mais importante, escreveu documentação detalhada sobre a arquitetura geral, as partes críticas e as armadilhas.

Agora você está contratando um desenvolvedor para manter essa base de código. Durante uma entrevista, você daria um código legado (feio não testado) ou o código que foi refatorado pelo desenvolvedor anterior?

Você daria a documentação? Para ler a documentação, o candidato precisará passar pelo menos algumas horas. Isso torna impossível fazer durante uma entrevista.

2. Ler código curto não é o mesmo que ler código de um projeto familiar

Lembre-se, o trabalho é manter um projeto. É difícil manter uma grande base de código nos primeiros dias ou semanas em que você não está familiarizado com o projeto. É muito mais fácil fazê-lo após alguns meses, quando você tiver escrito toda a documentação e ter uma visão clara da base de código geral.

A coisa mais importante a testar é se a pessoa será eficiente nesses meses . Você não se importa se a pessoa não será capaz de entender nada nos dois primeiros dias.

Ao pedir a uma pessoa que leia um pequeno pedaço de código do zero, você não está testando como essa pessoa seria capaz de lidar com um código familiar e documentado de milhares de LOC .

3. Manter o código fonte não é apenas lê-lo

Quando você está mantendo uma base de código, está modificando -a. Um desenvolvedor que apenas lê código não traz nada de útil para sua empresa.

As habilidades úteis são a capacidade de refatorar o código , adicionar testes de unidade , prever o impacto de uma mudança etc. Você não testa essas habilidades pedindo a uma pessoa que leia o código durante a entrevista.

A leitura é uma suposição baseada no fato de que a capacidade está presente na escrita. Considere o conceito em qualquer idioma. A programação é apenas uma linguagem para se comunicar entre humanos e máquinas. Considere uma comunicação de humano para humano. Se você estivesse contratando alguém para ser intérprete de japonês, não seria lógico que, se eles pudessem escrever um ensaio de 1.000 palavras sobre um tópico específico, eles seriam capazes de lê-lo?

Como programadores, nossa atividade principal é a criação de código e a tradução de idéias abstratas em implementações concretas. Isso geralmente significa escrever. Concordo que a leitura é igualmente crítica, mas na grande maioria dos casos, onde a capacidade de escrita está presente, a capacidade de leitura também está presente. O único caso real em que eu pude ver uma diferença distinta seria em um ambiente em que muitos casos altamente complexos evoluíram ao longo do tempo. Mesmo considerando isso, porém, você não esperaria que alguém fosse capaz de lê-los e entendê-los sem pelo menos algum estudo.

Além disso, ler o código e explicar o que você pensa que não expressa realmente a um entrevistador como você usa suas habilidades de pensamento crítico. Isso mostra um pouco de análise, mas a maioria dos empregadores quer ver se você consegue pensar sem ser colocado em uma caixa. Eles querem saber se você pode entender os conceitos sem o benefício (ou muleta mesmo) do código existente para lhe dizer o que ou como fazer algo.

No passado, eu costumava pensar que a leitura do código deveria ser algo demonstrado nas entrevistas, mas com o tempo percebi que isso é uma perda de tempo para o entrevistador e o entrevistado. Por quê? Porque até codificadores ruins podem ler um trecho de código.

Ser capaz de julgar a capacidade de alguém de ler código só se torna relevante quando você olha para algo complexo ou código que abrange muitas classes e arquivos. Ser capaz de rastrear o código para descobrir o que está fazendo é uma característica desejável, mas simplesmente não há tempo suficiente para alguém apresentar um bom exemplo (não código de produção) nem há tempo em uma entrevista para fazer essa pergunta. .

Portanto, codificadores ruins podem ler código, mas não conseguem escrever bem o código. Pedir para ver exemplos de trabalho de um candidato ou pedir a um candidato que escreva código na entrevista são indicadores muito melhores de sua habilidade. Se eles podem escrever código conciso limpo, é provável que eles possam ler o código foi bom.

Pergunto a todos os candidatos que estou entrevistando uma variação do problema do FizzBuzz . É rápido, simples e normalmente pode escolher codificadores ruins muito mais rápido do que qualquer outra coisa que eu encontrei. Um bom programador irá obtê-lo com muita rapidez e facilidade e fornecerá uma rápida olhada no estilo de codificação e no processo de pensamento.