A codificação do quadro branco é inadequada durante as entrevistas? [fechadas]

Este é um questionamento um tanto subjetivo, mas eu adoraria ouvir comentários / opiniões de entrevistadores / entrevistados sobre o assunto.

Dividimos nossa entrevista técnica em 4 partes. Escreva Código, Leia e Analise Código, Sessão de Design e Código no quadro branco.

Na última parte, o que pedimos aos entrevistados é escrever um pequeno trecho de código (4-5 linhas) no quadro branco e explicar à medida que eles passam por ele. Deixe-me esclarecer que o objetivo não é capturar as pessoas. Não estamos procurando uma sintaxe perfeita. Inferno, pode até ser pseudo-código. mas o objetivo é dar a eles um problema muito simples e ver se o cérebro deles pode nos comunicar a solução. Por problemas simples, quero dizer "Inverter uma string", "FizzBuzz" etc ...

Observe que sempre solicitamos um idioma explícito primeiro. Somos uma casa .NET C #. dissemos apenas "pseudo-código" em que alguém está apagando / realmente lutando com o código.

Minha pergunta é "É inapropriado / irracional esperar que um programador escreva um trecho de código em um quadro branco durante uma entrevista?"

Na minha opinião, é muito apropriado. Se você deseja que um trabalho desempenhe uma habilidade específica, é inteiramente apropriado que se demonstre essa habilidade na entrevista.

O efeito dessa técnica no processo de recrutamento é muito perceptível. 90% dos candidatos falham nessa tarefa. mas os desenvolvedores recrutados são bons e os desenvolvedores serão respeitados dentro da empresa.

Se, como candidato a esta técnica, relaxe antes de tudo. Trata-se de avaliar você como programador e seus processos de pensamento. Não se trata da sua sintaxe perfeita. Se você cometer um erro de sintaxe, eu posso desempenhar o papel de um compilador e dizer que o código não é compilado em uma determinada linha, além de fornecer uma mensagem de erro e ver como você responde. Da mesma forma, se você adicionar um; em um loop ou em uma instrução if que seria compilada, eu tocaria o depurador e o explicaria em uma única etapa do código. Novamente, não é sobre o erro, é sobre como você lidaria com o erro, e seus processos de pensamento são bons.

Minha pergunta é "É inapropriado / irracional esperar que um programador escreva um trecho de código em um quadro branco durante uma entrevista?"

É muito razoável. Uma alternativa para um quadro branco pode ser um laptop e um beamer, pois os programadores estão mais acostumados a escrever código em um teclado do que em um quadro branco. Apenas verifique se um ambiente de desenvolvimento como Eclipse, VS ou Idle já está em execução com um projeto em branco quando o candidato iniciar, para que ele não precise perder tempo pesquisando nos aplicativos instalados.

Não é inapropriado, mas saiba que nem sempre pode revelar os verdadeiros insights sobre as habilidades de programação ou de resolução de problemas da pessoa que você está entrevistando. E acho que é exatamente isso que você procura.

Em segundo lugar, observe que sempre há o medo do fracasso, constantemente provocando o cérebro da pessoa. "E se eu estragar tudo?", "E se eu cometer um erro bobo". A maior parte do cérebro da pessoa está ocupada, inspecionando constantemente como está saindo - apenas poucos conseguem aguentar os nervos.

Portanto, nesse tipo de situação, até os melhores podem acabar vacilando.

Na última parte , pedimos aos entrevistados que escrevam um pequeno trecho de código (4-5 linhas) no quadro branco e expliquem à medida que eles passam por ele

Isso está ok. Mas, novamente, apenas porque alguém não pode explicar algo corretamente não significa que não o conhece bem. (Explicação é uma arte de falar).

Se eu fosse você, faria isso Pela última parte ...

Contrate-os para um projeto muito pequeno (mas realista). Veja como eles codificam, tomam decisões, assimilam as condições de trabalho e os membros da equipe etc., e depois, com base nisso, tomam a decisão final.

Não é inapropriado, mas lembre-se de que algumas pessoas (e talvez uma parcela maior da multidão de programadores) podem estar muito estressadas em uma entrevista. Acho que a maioria de nós conhece o cara do escritório que é um programador brilhante e uma pessoa muito confiável, mas ele se derreteria em tal situação. Seu desempenho não pôde ser medido em um teste como esse; portanto, não faça disso um teste de aprovação / não aprovação.

Pessoalmente, acho que essa é uma das melhores coisas que você pode fazer. Como você disse que não procura a sintaxe correta ou algo semelhante, a parte mais importante aqui é ver se alguém pode se comunicar ... Eu já vi tantos desenvolvedores bons que só podem trabalhar sozinhos dentro de seu próprio espaço ... Infelizmente isso não é possível em uma grande quantidade de casos, portanto, ter um cara habilidoso que também é capaz de DIZER o que pensa de maneira clara e concisa é um membro mais valioso da equipe do que alguém que pensa: "Eles não vão entender de qualquer forma, eu mesmo faço e demonstro mais tarde ".

Comunicação, comunicação, comunicação é a base de todos os projetos de médio e grande porte (até menores, quando necessário)

Eu acho que não é uma coisa razoável. Tentamos encontrar candidatos que sejam bons na tarefa que queremos que eles façam. Escrever código em um quadro branco não é um deles e não acho que seja um filtro válido encontrar bons candidatos.

• Um bom código não é gravado, é reescrito. Um quadro branco é praticamente imutável, pois é difícil mudar depois que você o escreve. Deve ser o mais fácil possível mudar de idéia assim que entender melhor o problema.
• Estar em uma entrevista é uma situação estressante, pois não é necessário exercer pressão adicional sobre o candidato. Muitas pessoas de computador não têm uma boa caligrafia. Os IDEs modernos fornecem muitas ferramentas com as quais você está acostumado. E poder pesquisar no Google algo no minuto que você precisar também faz parte do estilo de trabalho da maioria dos programadores. Por que tirar todas essas coisas e criar um ambiente artificial, no qual elas nunca terão que trabalhar se você lhes fizer uma oferta?
• Também estamos muito interessados ​​na capacidade de escrever bons testes, talvez até em TDD. Não é possível ver durante a codificação do quadro branco.

A maioria das pistas que você pode obter de uma sessão de codificação do quadro branco também pode sair de uma sessão de emparelhamento - e acredito que o emparelhamento é uma ferramenta muito melhor para ter uma sensação, como um candidato resolve um problema e como ele funciona. Ele pode trazer seu próprio computador e trabalhar em um ambiente com o qual se sinta confortável. E é muito mais fácil aplicar a tarefa que você deseja que eles façam quando ingressarem. Por exemplo, temos uma grande base de códigos herdada, portanto, solicitamos que refatore algum código extraído para o projeto real. E, na verdade, combinamos o máximo possível em nosso trabalho diário, por isso é bem adequado.

Enquanto uma sessão de quadro branco provavelmente ajuda a filtrar candidatos ruins, provavelmente também filtra muitos bons programadores.

Pessoalmente, eu deixaria qualquer entrevistador me pedindo para fazer o FizzBuzz. Não sei quando isso se tornou o novo padrão da indústria, mas é realmente uma perda de tempo. O FizzBuzz é um filtro que pode ser usado antes de uma entrevista, embora pessoalmente eu pense que se eu tivesse que escolher entre N candidatos dos quais bastante código-fonte aberto ou um blog que eu pudesse ver, eu definitivamente preferiria isso como filtro .

Simplificando, acho que em uma entrevista para uma posição de programação (exceto talvez para juniores ou estágios), já deveria ter sido estabelecido / determinado que o entrevistado pode programar.

Mas sim, o quadro branco é perfeito, embora eu ache que você deva ter um conjunto diferente de problemas. Jogue para eles um problema do mundo real e peça para eles desenharem um monte de barganhas UML-ish para explicar sua estratégia geral para resolver esse problema. Dê a eles um computador com Internet, para que eles possam procurar bibliotecas de terceiros que possam ser usadas como caixas-pretas na paisagem de squibbles.
Dentro de alguns minutos, você realmente verá como eles lidam com os problemas. Você pode realmente tornar isso uma coisa muito interessante, escolhendo problemas que você não tem necessariamente uma solução em mente e tentando "resolvê-los" juntos, para ver se eles se comunicam e se podem incorporar informações (por mais que não force demais - algumas pessoas podem congelar se você o fizer). E depois adicione alguns requisitos em tempo real. É como o desenvolvimento de software sem implementação e, o mais importante, sem depuração, portanto, 15 minutos é muito tempo.

Deixe-me responder com outra pergunta:

Escrever código em um quadro branco oferece alguma vantagem real na avaliação da capacidade de programação, em comparação com a digitação e execução do código em um computador?

Eu acho que é absolutamente apropriado pedir a um candidato que escreva código em uma entrevista. No entanto, para mim, poder executar o código é uma parte crítica do ciclo de feedback que compõe a programação. Em um quadro branco, você está amarrando uma mão nas minhas costas e não está tendo uma visão completa de como eu resolvo um problema.

Não, mas na IMO, uma abordagem melhor seria usar o quadro branco para a finalidade pretendida e usar UML / sketches / notes para algum projeto fictício, em vez do antigo "escreva-me uma consulta sql para obter todos os registros" ou "escreva um método que inverte uma string ".

Uma das melhores entrevistas que tive foi passar 20 minutos discutindo com o desenvolvedor principal a arquitetura (não software) da mansão de um cientista louco (completa com esconderijo secreto, raio da morte e canil). Ele conseguiu ver minha abordagem na solução de problemas, e o problema era algo divertido, não algo típico de programação mecânica 101 que foi resolvido pelas linguagens modernas milhares de vezes. Aliás, eu também fiz um código como esse antes, mas me senti muito mais "sob pressão" do que com a parte da arquitetura.

Hoje em dia, muita programação é feita em equipes. Para que as equipes trabalhem, as pessoas precisam ser capazes de se comunicar. Grande parte disso é poder se comunicar na frente de um quadro branco (brainstorming, mentoring, revisões de código, correções propostas etc.)

Eu procuraria saber se o candidato explicou como solucionar a solução de um problema de programação usando o código do quadro branco para ajudar. Se a explicação for boa o suficiente, os outros bons programadores na sala corrigirão mentalmente automaticamente quaisquer erros / erros no quadro.

Para a maioria dos tipos de posições de equipe, não seria razoável NÃO esperar que um candidato seja capaz de explicar e rabiscar sua tentativa de solução.

Não, é bom codificar para uma entrevista, mas você deve permitir o código em qualquer idioma razoável, pois geralmente é mais fácil treinar um competidor de codificador em outro idioma do que obter um codificador mais ou menos no idioma desejado. a um nível concorrente.

Eu diria que é apropriado, mas na maioria dos casos não é uma maneira eficiente de descobrir quem é bom em programação e quem não é. Se você deseja que um trabalho seja feito (= contrate alguém que seja capaz), a entrevista deve se concentrar em medir as habilidades da vida real. Até agora, a melhor entrevista que eu havia trabalhado assim:

• Saudações, bem-vindo pelo RH.
• Poucas palavras sobre mim, sobre a empresa, etc ... e ela explicou o resto da entrevista.
• Ela me deu um laptop com um programa que perdia poucas partes, que havia falhado nos testes de unidade por causa disso. As partes ausentes foram comentadas lá como textos, tratava-se de implementar uma tarefa básica, como criar conexão entre poucas classes e introduzir uma lógica de negócios simples.
• Se tudo corresse bem, os testes de unidade ficariam verdes.
• Dizer adeus e concordar em voltar em alguns dias.
• Naquele dia, o líder se encontrou comigo e perguntou sobre o programa finalizado, o que eu fiz e por quê.
• Este líder também perguntou sobre minhas experiências passadas e algumas outras perguntas.

Então, para resumir: se você está procurando força de trabalho em um código de produção, teste suas habilidades no ambiente real. Se você está curioso sobre o conhecimento teórico deles, é melhor perguntar a eles sobre essas coisas. Se você está despojado do IDE ou está nervoso porque precisa programar no quadro branco na frente de alguém, eu entendo, especialmente nas pessoas de TI às vezes são introvertidas e muitos de nós não conseguem lidar bem com essas situações, por exemplo nossa eficiência parecerá pior do que realmente é.

Eu não acho isso irracional, a menos que o entrevistado tenha uma caligrafia ruim (ou devo dizer) :-). Além da única diferença na sua abordagem, é o uso de um quadro e marcador. Em alguns casos, os entrevistadores fazem isso, mas fornecem um papel e uma caneta. No caso de haver 3-4 pessoas conduzindo a entrevista, eu diria que sua abordagem será muito melhor e adequada.