O excesso de engenharia é um sinal de alerta? [fechadas]

Portanto, apresentamos um exercício direto de codificação para novos candidatos com alguns requisitos bem definidos. Ocasionalmente, recebemos soluções que realmente não resolvem o problema em questão, mas são projetadas demais para solucionar um problema percebido - geralmente fora dos limites do exercício.

Agora, minha pergunta é: isso é um sinal de alerta?

EDIT: Muita discussão é baseada no teste que está sendo falho - o que é um ponto justo. Como descrevi em um comentário, a premissa básica do teste é mostrar como você pode ler os dados do arquivo de uma maneira sensata (e você ficaria surpreso com a variedade de abordagens que vemos) e como combinar as itens antes de calcular a latência entre as atualizações. Agora, para que isso funcione, certas suposições precisam ser feitas sobre os dados, e procuramos essas suposições, e também declaramos explicitamente que queremos ver a abordagem adotada (incluindo a abordagem OO etc.) Tudo isso em duas horas prazo.

IMHO, quando eu estava entrevistando, foi o exercício mais completo que me deparei.

O cenário específico sobre o qual estou pensando é onde um candidato, em vez de ler o arquivo, aceitou a entrada "rede" em um aplicativo multiencadeado, o que claramente não está no escopo.

O problema é que o teste está inclinado. Você está pedindo a alguém que demonstre sua capacidade de escrever software complexo de nível corporativo usando um exercício simples que leva apenas alguns minutos. Outros entrevistadores de outras empresas reclamam que os candidatos não demonstram habilidade suficiente no design orientado a objetos com esses exercícios; portanto, as pessoas tendem a compensar demais. Isso não significa necessariamente que seu candidato é incapaz de usar código mais simples quando a situação o justificar.

Se você quiser saber se esse é o caso do seu candidato, peça-o para refazê-lo, fornecendo algumas orientações específicas. Diga: "Vejo que você estava apresentando suas habilidades de design orientado a objetos, mas parece um exagero para um problema tão simples. Você pode reescrevê-lo usando apenas duas pequenas funções?"

Eu diria que este é um sinal de alerta claro, mas não necessariamente desqualificante para um candidato.

Existem dois problemas separados que os candidatos parecem estar tendo:

1. Perder o objetivo do exercício - Isso é bastante alarmante. Toda a habilidade de programação do mundo não criará um bom resultado se alguém não conseguir lançar o problema que está resolvendo adequadamente. Descobri que os engenheiros mais produtivos são os que conseguem identificar o verdadeiro problema a ser resolvido, mesmo que não seja exatamente o problema proposto. Ter a capacidade de pensar criticamente sobre a pergunta que está sendo feita e talvez reformulá-la para algo mais simples de resolver é uma habilidade crítica. Perder o ponto em que o problema está sendo claramente indicado deve ser uma grande bandeira vermelha.
2. Overengineering the solution - Esse é um problema secundário e geralmente é o resultado do primeiro problema. Existem algumas patologias diferentes que podem ter esse resultado. Primeiro, não entender adequadamente o problema ou lançá-lo de maneira muito ampla pode resultar em uma solução muito complexa. Isso está claramente relacionado ao primeiro ponto acima. Segundo, tentando "se exibir" pensando em cenários futuros que podem não ser realmente relevantes. Isso pode ser problemático porque indica que o candidato não entendeu o valor da simplicidade nas soluções e adiando a complexidade até que seja realmente necessário. Isso é algo que pode ser corrigido com uma boa orientação, mas é um cuidado ao trazer alguém para a organização.

Eu sugeriria acompanhar o candidato sobre sua resposta durante o curso do processo. Em vez de simplesmente olhar para o resultado, tente determinar o que os levou ao resultado e, com alguma orientação, como eles responderiam e mudariam sua resposta. Provavelmente, isso será mais revelador sobre suas capacidades do que apenas sua resposta direta ao problema. Os "porquês" de sua abordagem podem lhe dar uma idéia de se eles simplesmente não estão entendendo ou se o entendimento deles foi um pouco errado na maneira como eles escolheram responder. Esse tipo de acompanhamento também revelará mais sobre sua abordagem geral para a solução de problemas.

Além disso, reexamine o problema em si e veja se talvez não esteja claro e talvez leve as pessoas a seguirem o caminho errado ao formularem suas respostas.

Não, não durante uma entrevista de emprego. Muitos entrevistadores fazem coisas como subespecificar intencionalmente os requisitos e esperam que o entrevistado faça mais perguntas, ou preste atenção às questões do mundo real não mencionadas explicitamente.

Aqui estão algumas coisas, de cabeça para baixo, que seus requisitos provavelmente não mencionaram:

• Padrões de codificação

• Comentários

• Manipulação de exceção

• Nomes descritivos de variáveis, classes, métodos

• Após o uso idiomático do idioma

• Design orientado a objetos adequado

• Atenção para possíveis problemas de simultaneidade

• Gravando casos de teste para o código

Você prestou atenção a uma dessas coisas sem declarar explicitamente? Como o candidato saberia com quem você se importa e com quem não?

Uma entrevista é um ambiente altamente artificial. O entrevistador geralmente tenta "enganar" o candidato um pouco para dificultar o entrevistado dizer o que ele quer ouvir, e o entrevistador está tentando adivinhar o que o entrevistador realmente deseja.

Geralmente, cometer um erro nesse palpite é bem diferente de cometer um erro nas decisões de design do mundo real. Se você quiser saber se alguém cria demais as coisas, provavelmente precisará falar sobre design, em vez de observar um exercício de codificação muito artificial.

IMHO a resposta é claramente sim , é um sinal de alerta, se

• o exercício de codificação teve uma tarefa clara
• possui requisitos bem definidos (e também bem escritos),
• os candidatos tiveram a chance de fazer perguntas para garantir que resolvessem o problema correto.
• você quer pessoas inteligentes e que realizem tarefas em sua equipe, não astronautas de arquitetura .

Um sinal de alerta não tão grande quanto não resolver o problema em questão . O fato de ele ter falhado no teste e não ter fornecido a solução correta é um sinal de alerta. Não é necessariamente um cenário proibido, porque depende de como e por que ele não forneceu a solução correta.

Muitas vezes a pergunta é uma porcaria completa e simplesmente sem resposta. Não finja que os entrevistadores nunca cometem erros. Ainda é um fracasso de sua parte descobrir por que a pergunta é uma porcaria. Se você está contratando um engenheiro que deve ajudar a fazer requisitos, isso é um problema. Se você está contratando um programador, não espera que ele faça isso.

Presumindo que o exercício de codificação não esteja terrivelmente bagunçado, parece que a maneira como ele falhou foi interpretar mal o problema e partir para o mato tentando resolver um problema que não estava lá. Sim, isso é um sinal de aviso.

Talvez.

Não resolver o problema é, obviamente, um sinal de alerta claro de que algo está errado. O que deu errado? Ou eles entenderam mal o problema ou fizeram uma solução ruim. Uma má solução para algo simples é um sinal claro de que o candidato é pobre.

Se eles entenderam mal o problema, dê uma longa olhada em seus requisitos. Mesmo as coisas que parecem claras para você podem não estar claras para outras pessoas que não estão familiarizadas com um domínio ou que têm uma formação diferente (localidade, idade, educação). Se o candidato estivesse lá na sala com você ou se oferecesse a oportunidade de fazer perguntas e ainda falhasse, consideraria isso um fracasso da parte deles. Se os requisitos fossem ultrapassados, eu provavelmente daria a eles o benefício da dúvida (e pensaria em consertar o processo de entrevista).

Se a solução estava correta, fica menos clara. Pessoalmente, acho que várias pessoas levam YAGNI longe demais. Se você pode resolver um problema específico e criar uma solução geral sem aumentar a complexidade ou prejudicar a capacidade de manutenção, por que não fazer a solução geral? (Pense em reverter uma string versus reverter qualquer coleção) Esse tipo de "excesso de engenharia" é claramente bom na minha opinião.

Tudo o resto é esse meio termo cinza. A solução aborda eixos de mudança prováveis? A solução adiciona complexidade ou prejudica a manutenção? Adicionando um pouco de complexidade para resolver problemas futuros que quase garantem uma vitória. Prejudicar a capacidade de manutenção para explicar algo totalmente improvável não é.

Ser um bom engenheiro de software significa encontrar o equilíbrio certo aqui. Ser um bom entrevistador significa obter o julgamento / inferências corretos sobre como e por que o candidato escolheu esse equilíbrio, geralmente usando outras partes da entrevista para avaliar.

Talvez, mas considere o seguinte:

• As entrevistas são difíceis: as pessoas estão estressadas. Isso deve ser fatorado fortemente em qualquer problema que você dê a alguém

• Comprimento do requisito: Quanto tempo e para a frente são os requisitos? Você os fez extra prolixo para ter certeza de incluir tudo. Como resultado, eles podem ser claros para você, mas os requisitos talvez sejam superdimensionados! Fiz uma entrevista de emprego uma vez por uma hora, com cerca de 3 páginas de texto, para um problema relativamente simples. Às vezes, todo esse texto pode ser difícil de ler e interpretar em uma entrevista e também pode ser mal interpretado.

• Às vezes, menos é mais: eu preferiria ter alguns pontos, frases e / ou exemplos mostrando os principais requisitos e, em seguida, uma discussão com alguém para fazer perguntas e, se necessário, estender a mão ao longo do caminho. Acho que o que estou tentando dizer é que você deve primeiro verificar se seus requisitos de teste não são excessivamente complicados para um problema simples.

• Habilidade de comunicação: você deve testar a capacidade de comunicação dos candidatos e fazer perguntas inteligentes sobre o problema primeiro e depois de saber que eles demonstraram que entendem o problema, você pode defini-los em sua implementação.

• Conclusão: se você não verificou se o problema foi entendido, você realmente não sabe o que fazer com a engenharia excedente. Como outros disseram, poderia ser uma coisa boa ou ruim, mas se você não verificou o entendimento ou se comunicou com o candidato sobre o problema antecipadamente, é mais difícil conhecer sua compreensão geral do problema e o que fazer.

Muito disso pode ser atribuído à maneira como você formula a pergunta e como coloca toda a entrevista em perspectiva.

É como: "Vamos ver como você é criativo. O que é 2 + 2?" Quatro? Tudo o que você pode encontrar é a resposta mais simples, óbvia e precisa? Os desenvolvedores jovens / iniciantes que estão tão ansiosos para impressionar durante uma entrevista farão a pergunta: "Queremos testar suas habilidades de codificação ou ver como você é um bom programador". significa "fazer algo muito sofisticado". Todos gostamos de pensar que o melhor é simples, exceto quando isso dificulta as coisas.

Existem maneiras de ver se alguém está propenso a sempre fazer coisas demais. Dê um exemplo de código de algo que era muito complexo e peça uma solução mais simples. Quando alguém fornece uma solução que você acha que não funcionará, essa é uma ótima oportunidade para ver como ela reage às críticas. Pessoalmente, eu gostaria de ver alguém aberto a novas idéias e reconhecer uma solução melhor do que alguém que cometerá os mesmos erros repetidamente.

E, na realidade, nem sempre temos a oportunidade de alterar nosso código quando ele não funciona? Você pode projetar ou projetar inicialmente. Depois de reconhecer a solução simples, não deve ser mais fácil de implementar?

Depende, mas geralmente não.

O design em geral é uma habilidade aprendida com a experiência. A descrição de Aaronaught dessa progressão vinculada por Marjan é geralmente boa.

A comunicação de qualquer forma também depende muito do contexto. O que pode parecer perfeitamente claro para significar uma coisa em um contexto, pode significar tão claramente outra coisa em um contexto diferente. Saber quais perguntas fazer também é algo que vem com a experiência.

O processo de pensamento deles e o modo como eles raciocinam sobre suas decisões são muito mais importantes que sua solução. Sem revisar sua solução e suas decisões com eles, você não pode avaliar completamente o contexto em que foi desenvolvido.

Dada a progressão acima, um candidato com a solução com excesso de engenharia pode muito mais longe do que o candidato com a solução simples.

Além disso: para qual posição de nível você está contratando? O excesso de engenharia de um candidato de nível intermediário ou de entrada é menos um problema do que o excesso de engenharia de um candidato de nível sênior.

Se o programador não resolveu o problema, todo o código extra é a tentativa do codificador de ofuscar a não resposta. É a mesma técnica usada em um teste de redação por um aluno que não sabe muito sobre o assunto. Ele ou ela vai divagar sobre uma questão convincente, mas não relacionada, na esperança de que sua ignorância seja mascarada pela contagem de palavras.

Se o programador resolveu o problema, mas adicionou muito mais código, considere o histórico do programador, pois algumas áreas da programação exigem tolerâncias maiores que outras.

Por exemplo, o código que executa o piloto automático em um jato comercial de passageiros tem muito menos tolerância a falhas do que um jogo Android grátis. Um desenvolvedor acostumado a programar dispositivos incorporados que são difíceis de alcançar e quase impossíveis de atualizar tenderão a codificar mais what-if, então um desenvolvedor que pode enviar 15 atualizações por dia.