Como lidar com uma entrevista com 'código incorreto'? [fechadas]

Uma entrevista com 'código incorreto' é aquela em que o entrevistado recebe um trecho de 'código incorreto' e é solicitado a corrigi-lo ou apontar coisas que estão erradas. Tenho problemas com essas entrevistas porque levo algum tempo para ler o código, descobrir o que está fazendo e apontar as falhas. Em uma situação em que há pressão de tempo, tenho tendência a congelar e vejo que o código 'deve' funcionar, mesmo quando não funciona.

Qual é uma boa maneira de lidar com esse tipo de entrevista e, de maneira mais geral, quais são algumas boas técnicas para ler e entender códigos rapidamente ?

Entrevistas com código incorreto (se forem feitas corretamente) devem mostrar o código com o seguinte:

• Uma técnica de linguagem ruim (não usando a usinginstrução em C # quando necessário ou usando um em ArrayListvez de a List<T>)
• Uma má decisão de design (por que diabos estamos passando strings por toda parte, ou usando tanto parâmetros refe out?)
• Erros de sintaxe (isso nem deve ser compilado!)
• Erros em tempo de execução (como um estouro de pilha causado por uma propriedade que se refere a si mesma em c #)

Há uma lista de verificação mental pela qual você deve passar, atingindo cada um dos pontos acima. Se você não pode olhar o código e fazer isso, esse é um ponto de melhoria. Qualquer que seja o idioma em que você afirme ser "proficiente", você poderá analisar um bloco de código e apontar esses quatro tipos de erros.

Eu escrevi recentemente sobre um pedaço de código que exibia todos esses problemas ; isso deve ajudá-lo a passar pelo mesmo processo mental.

Ayende vai mais fundo com sua série Salários do Pecado .

Não tente entendê-lo rapidamente. O objetivo aqui não é ver se você consegue entender o código como um guru, mas sim como você pensa.

A chave da IMO é simplesmente pensar em voz alta. Portanto, mesmo que você congele - apenas diga: "Estou estressado aqui, mas deixe-me passar por isso lentamente em voz alta".

Supondo que você tenha a habilidade de pensar em voz alta, você o atrasará o suficiente para acertar sua mente. Se as entrevistas forem esclarecidas o suficiente, elas verão sua situação e o ajudarão até você pensar claramente. Eles não querem tentar enganá-lo a parecer estúpido - apenas uma técnica poderosa para ver como você pensa.

As probabilidades são de que a 'pressão do tempo' que você sente é totalmente auto-imposta. Isso tem mais a ver com seus próprios sentimentos de insegurança e com a preocupação com o quão bem você mede.

O melhor conselho que qualquer pessoa pode dar é: Relaxe. Não se apresse, observe o código e apenas fale sobre o que vê como o vê. Sinta-se livre para falar sobre as partes boas e as ruins; isso ajudará a reduzir seu nervosismo e preocupações internas de que muito tempo está passando.

Além disso, passar por diferentes 'passes' pode facilitar um pouco a localização de detalhes específicos. Faça um teste procurando chaves ou erros de digitação incompatíveis. Faça outro passe procurando linhas ofuscadas. Tome outro procurando por pretzels semânticos. Concentrar-se em um tipo de "coisa errada" pode facilitar a identificação desses detalhes e (novamente) reduzir sua voz interior questionando se você está fazendo isso rápido / suficientemente bem.

Acima de tudo, fale sobre o que você está fazendo e pensando - isso ajudará você e o entrevistador.

Eu nunca estive nesse tipo de entrevista, mas quando estou tentando trabalhar em um pedaço complicado de código que posso suspeitar ser ruim, às vezes falo em voz baixa comigo mesma. Acho que vocalizar às vezes ajuda a resolver problemas. Também em uma entrevista, você pode tentar traçar as etapas da execução como um diagrama ou algo com um lápis e papel. Isso costumava funcionar para mim na escola, ainda às vezes no trabalho. YMMV, é claro ...

Eu acho que um bom lugar para começar (se você não vê nada óbvio) seria "depurando". A menos que você veja possíveis problemas logo de cara, um bom lugar para começar é fazer uma pequena lista de valores de teste. Bons valores são um valor de 'caminho feliz' (normal), um valor 'zero' ou 'vazio', valores nulos, um valor muito pequeno (uma cadeia de 1 caractere, o int 1, etc.), muito grande ou muito longo valor e valores 'estranhos' específicos ao tipo (por exemplo, caracteres Unicode para seqüências de caracteres, números negativos para entradas, etc.). Não faria mal mencionar aqui que normalmente você escreveria testes de unidade usando esses valores para testar o código e apenas executaria aqueles para verificar a função.

Comece caminhando com seus valores de caminho feliz. Para uma função de adição, você pode começar com 3 ou 4. Examine cada linha quanto a erros de digitação e lógicos, rastreando os valores das variáveis ​​locais à medida que avança. Felizmente, você encontra alguns erros. Quando você terminar o caminho feliz, sentirá melhor o código e esperançosamente se sentirá um pouco menos sobrecarregado - diga algo como: "Agora que sinto melhor o que esse código está fazendo, estou voltando atrás e dando uma olhada nisso ", faça exatamente isso - procurando coisas que se destacam para você como coisas que você teria feito de maneira diferente (decisões ruins de design, variáveis ​​mal nomeadas, investigar possíveis erros etc.).

Se isso não o levar a lugar algum, ou se você sentir que não tem mais o que dizer, retorne à sua lista de valores de teste e passe por ela novamente com uma nova que você acha que provavelmente causará problemas.

Isso vai pelo menos fazer você ir.

Como Stephen Bailey disse, pensar em voz alta é uma excelente técnica nessa situação, pois permite que seus entrevistadores vejam seu processo de pensamento. Explique o que você está tentando descobrir. A outra coisa que você pode fazer é informar aos entrevistadores que você lerá o código corretamente antes de fornecer um diagnóstico sobre a maldade no código. Estive em ambos os lados da mesa e sei que pode ser frustrante para ambos os lados nessas situações.

Se você sentir menos pressão fazendo isso como um teste escrito, retire seu caderno e comece a fazer anotações. Peguei um caderno e comecei a esboçar anotações como parte do meu processo de pensamento em uma entrevista. Ter um caderno e uma caneta faz você parecer organizado mesmo. Você pode anotar alguns itens de itens a serem procurados, sintaxe, erros lógicos, incompatibilidades de tipo de dados, valores de variáveis ​​locais (a lista pode variar dependendo do tipo de código que você obteve, minha lista para uma parte complexa do SQL seria seja diferente de alguém que tenha um código que não era centralizado em dados) durante o processo, etc. Depois de escrever alguns deles, comece a procurá-los. Dessa forma, mesmo que você não encontre todos os problemas antes que o entrevistador queira seguir em frente, ele poderá ver uma lista das coisas que você estava verificando. Se você criar uma lista de verificação de antemão das coisas que deseja procurar, ficará mais confiante ao iniciar o processo, sabendo quais as coisas que planeja examinar. Geralmente, essas perguntas são mais sobre como você encontraria os erros do que realmente encontrar todos eles.

Estou um pouco atrasado para essa parte, mas uma técnica que você poderia usar seria escrever testes de unidade para o código em questão. Então você pode se concentrar menos no que está sutilmente errado com o código e mais nos resultados esperados que está procurando. Prefiro contratar alguém que possa escrever bons testes do que alguém que possa identificar imediatamente o que está errado com um pedaço de código.

Pode haver dois problemas:

Pode ser uma "entrevista de estresse" http://en.wikipedia.org/wiki/Job_interview#Stress . O entrevistador está tentando ver como você lida com o estresse, já que o ambiente de trabalho é tal.

OU

Você pode estar se estressando. Nesse caso, você terá que gerenciar esse estresse, por exemplo, introspectar e ver como você pode permanecer calmo.