Trilhas preguiçosas
Ao pedir aos engenheiros de software para fazer uma tarefa específica, como escrever um algoritmo de geração fatorial (muito comum) ou classificar uma lista unida ou duplamente vinculada que seja fácil de lembrar, você não terá nenhuma ideia sobre as habilidades do candidato, exceto a capacidade de estudar. Você também pode pedir o código ASCII do caractere 'A'.
Soluções detalhadas para muitos problemas são fáceis de encontrar em uma variedade de materiais de referência, geralmente em livros, que descrevem soluções algorítmicas e específicas para todos os problemas comuns em uma entrevista de programação.
Trabalhei para uma empresa e lá conversei em detalhes com um colega sobre como foi a entrevista com um grande fundo de hedge. Ele memorizou cuidadosamente todas as perguntas técnicas do livro amplamente disponível de perguntas e respostas da entrevista, que o funcionário na época transmitiu como a fonte de todas as perguntas da entrevista.
Felizmente, meu colega é um engenheiro experiente, mas concordou em passar por esse exercício descaradamente monótono e mundano para permanecer no trabalho. Ele não precisava fazer isso - a entrevista não era apenas uma perda de seu precioso tempo, ela não fazia nada para a empresa contratante determinar sua capacidade. Um colega saiu depois de um ano, cansado do baixo nível técnico em termos de contratações e gestão ineficaz ...
Memória
Os mesmos argumentos funcionam quando você escreve um algoritmo em um idioma específico. Em um projeto real, nenhum engenheiro de software escreveria uma seção de código sem algum tipo de ferramenta de verificação de sintaxe (por exemplo, preenchimento de código integrado no editor), sem referência a algum tipo de documentação técnica ou simplesmente sem copiar a solução finalizada, onde está possivelmente. Não adianta reinventar a roda.
Aposto que a maior parte do código que roda em sistemas mundiais hoje se originou como uma resposta ao Stack Overflow.
Apesar de toda a sua praticidade, trabalhar com a sintaxe de uma linguagem de programação específica começa com familiaridade e aplicação. A pessoa que está entrevistando você pode pensar que testar seu conhecimento das nuances de um idioma específico está testando sua compreensão do idioma. Por exemplo, posso afirmar categoricamente que, embora tenha escrito em C por quase 30 anos, sempre sinto falta da sintaxe.
Na verdade, à medida que minha carreira se desenvolveu e fui me familiarizando com as linguagens de interesse, fiquei constantemente confuso sobre as nuances da sintaxe, digamos, C, C ++ e Objective-C. Não porque eu seja um péssimo engenheiro de software (embora alguns possam discordar ...), mas porque apenas o conhecimento que você pode manter em sua cabeça e relembrar imediatamente a qualquer momento está armazenado em sua memória.
Um bom engenheiro geralmente não sabe imediatamente a resposta a uma pergunta específica, mas ele definitivamente sabe onde procurá-la. Talvez você queira perguntar onde é o melhor lugar para encontrar informações sobre as perguntas da entrevista?
Tarefas comuns
Algo que já mencionei: esta é uma máxima - não reinvente a roda. Por exemplo, se você estiver trabalhando em C e precisar de uma rotina de porta serial, não a escreva do zero, a menos que a situação exija. Talvez você precise de um analisador JSON, um requisito muito comum - a menos que você esteja escrevendo código em uma placa embutida com um recurso limitado, para um satélite em órbita geoestacionária ou em Malbolg ; então, talvez você deva apenas pegar o que já escreveu da biblioteca. Provavelmente, o código foi usado por um longo tempo, foi totalmente testado e possui documentação detalhada (e correta). É confiável.
É improvável que na engenharia de software moderna haja uma tarefa comum que ainda não tenha sido automatizada na biblioteca ou cujo algoritmo seja difícil de encontrar.
Se você é como eu, e acima de tudo você trabalha por amor ao assunto, então você irá buscar ativamente posições onde você implementa o que você já escreveu antes: em busca de estranhos, novos mundos, nova vida, novas civilizações ...
Na verdade, o conceito de engenheiros de software em um futuro distante foi mais de uma vez comparado a arqueólogos de código, em que os engenheiros basicamente reutilizam o código existente e passam relativamente pouco tempo desenvolvendo e programando novos e novos algoritmos.
Discussão. Discussão. Discussão
Apoio a descoberta de que a pessoa que você está contratando conhece o negócio dela. Mas os métodos acima são completamente inúteis em minha opinião. Não quero ofender ninguém, digo como é.
Por exemplo, simplesmente falar sobre paradigmas de programação na moderna engenharia de software, se uma linguagem seria uma boa escolha para uma implementação específica ou se uma metodologia de engenharia de software específica (Agile, estou olhando para você) é um tópico muito mais útil e relevante para discussão.
Conduza uma discussão para destacar áreas de terreno comum, veja como o candidato entende novos problemas e, possivelmente, novas formas alternativas de resolver os antigos. Como os candidatos veem o desenvolvimento das coisas, como começariam a resolver algo. Fique aberto, fique longe de detalhes e trivialidades.
A chave aqui é a discussão. Fico constantemente surpreso com o fato de que muitas das empresas consideradas "voltadas para o futuro" e "líderes em seu campo" ainda recorrem a métodos de contratação desatualizados, monótonos e completamente previsíveis, porque dificilmente apreciam a veia técnica real.
Costuma-se dizer que um candidato a emprego deve entrevistar uma empresa da mesma forma que uma empresa o entrevista. Eu sou totalmente a favor.
Entrevistar alguém com uma lista de perguntas técnicas precisas é sempre uma bandeira vermelha, especialmente quando as pessoas não querem arrastar uma discussão sobre um determinado assunto. Isso geralmente mostra que o entrevistado pode não entender totalmente o que está perguntando e qualquer resposta que não corresponda exatamente ao que está escrito no roteiro será considerada incorreta.
Vamos resumir
Algumas empresas mudaram para métodos de contratação melhores, outras - bem, eles estão aquém. É aqui que exorto vocês, colegas programadores, a não se envolverem com empresas que contratam da maneira antiga e insistem em testes e exercícios de programação. Especialmente para longos!
Já ouvi histórias de empresas que pedem que os projetos sejam concluídos no prazo de um candidato, geralmente levando dias.
Outros têm “testes de aptidão” genéricos para idiomas específicos, testes de múltipla escolha, em que, em um tempo limitado, uma pitada de névoa em sua cabeça significa que você falhou na entrevista!
Se você é um iniciante, pode não estar em posição de pular uma entrevista, e eu o entendo totalmente, mas vejo isso como uma experiência de aprendizado. Vá em frente, ganhe experiência, aprenda o máximo possível e se o trabalho o decepcionar, siga em frente. Seguindo em frente, você ganhará mais confiança, conhecimento e experiência. Afinal, a empresa se beneficia de você, então você deve se beneficiar igualmente da empresa.
Se você, como eu, é mais velho e experiente, deixe a empresa contratante falar com você. Temos muita experiência, temos visto e feito muito, as qualificações estão bem visíveis no currículo e no currículo. E estou indignado por estar sendo guiado pelo canal de recrutamento geral e minha capacidade testada várias vezes.
Se você acha que é um empregador digno e não consegue descobrir por que candidatos aparentemente excelentes saem e vão embora, dê uma olhada em como você contrata pessoas.
<>
Outras profissões e cursos
</>