Recentemente, tive uma discussão com um colega programador. Ele estava entrevistando para uma nova posição e foi feita a seguinte pergunta:

Dê uma sequência de números começando em X e terminando em Y, mas com um elemento faltando, para que N seja YX-1, encontre o elemento ausente em O (N) ou melhor.

Agora, a resposta é irrelevante aqui (mas interessante). Isso iniciou uma discussão sobre se essa era uma boa pergunta a ser feita durante uma entrevista.

Um lado: os algoritmos são uma parte herdada da programação e a capacidade dos candidatos de responder a essa pergunta suporta que esse candidato seja um bom programador e seja capaz de resolver problemas maiores e possa lidar com a maioria das tarefas de programação que são fáceis de entender e responder.

Outro lado: escrever algoritmos do zero raramente é usado na programação moderna e, portanto, é irrelevante na questão maior de saber se a pessoa será um bom programador. Uma pessoa poderia responder com êxito a essa pergunta e ainda não conseguir executar tarefas de programação mais comuns.

Seus pensamentos? Boa pergunta para entrevista ou não?

Concordo em fazer uma pergunta sobre algoritmo, mas discordo em insistir em um nível específico de qualidade de grande O.

Fazer esse tipo de pergunta é interessante para ver como a pessoa aborda o problema e quais armadilhas consideram em sua tentativa, mas, a menos que esteja escrevendo algo insanamente incorreto ou ineficiente, os detalhes reais do que eles escrevem não são tão reveladores quanto o fato de que eles supere as etapas de solução / projeto de problemas de maneira coerente.

Faço uma pergunta semelhante, mas as pessoas com quem tive mais sorte depois da contratação são as que deram respostas erradas, mas tiveram a idéia correta em sua abordagem.

Eu discordaria da idéia de que a capacidade de escrever algoritmos é irrelevante na questão maior de saber se a pessoa será um bom programador. Mesmo que ele nunca precise usá-lo (o que é duvidoso), ele ainda mostra se ele tem a flexibilidade mental necessária para encontrar uma solução lógica para um problema mais complicado do que um simples conjunto de requisitos já escritos e definidos em detalhes pelo cliente.

Definitivamente, não gostaria de contratar alguém que não saiba pensar e analisar. É isso que faz a diferença entre um macaco de código e um programador de computador.

Devo admitir aqui que sou um daqueles que gosta de fazer perguntas sobre algoritmos em entrevistas, mas devo enfatizar que a resposta real à pergunta é absolutamente irrelevante. Não me importo nem um pouco se o entrevistado souber a resposta ou não. Em vez disso, para mim, esta pergunta visa aspectos diferentes, como os seguintes - em ordem de importância:

Exigências

Tais perguntas são deliberadamente subespecificadas. No seu exemplo, não há mais detalhes sobre a sequência. Se você tem um entrevistado que pergunta se esses números são realmente classificados, é um bom sinal. Ele tem a mentalidade correta para pedir aos clientes mais detalhes, que ajudarão a chegar a uma solução melhor em menos tempo. O candidato também pode brincar com a idéia de usar o espaço O (n) para armazenar uma matriz de N números, mas ele não deve fazer isso sem perguntar mais detalhes sobre X e Y. Digamos que X e Y estejam entre 1 e 1000 , então com certeza, vá em frente e inicie uma solução baseada em matriz. Mas se eu lhe disser que o intervalo é de 1 e 1 bilhão, então o problema se torna totalmente diferente. Deixe-me enfatizar novamente, que não me importo com a solução.

Técnicas padrão

Não quero contratar um programador que nem saiba o que significa O (n). É uma necessidade absoluta saber se você teve alguma educação decente nessa área. Mas também é importante não apenas saber o que isso significa, mas realmente aplicar esse conhecimento. No seu exemplo, quero que um candidato perceba que ele não tem permissão para classificar os dados (sem fazer mais perguntas visando a opção de uma classificação de bucket ou outras abordagens de classificação O (n)) devido à classificação necessária O (n log n) em geral.

Da mesma forma, outras perguntas sobre algoritmos têm como alvo técnicas padrão, como travessia em árvore ou gráfico ou recursão. Um candidato pode usar uma dessas técnicas, o que não causa uma boa impressão. Nesses casos, no entanto, eu gosto de ir mais fundo para descobrir se o candidato tem alguma experiência em CS. Obviamente, depende de qual é a posição de destino, mas geralmente um desenvolvedor que não conhece as complexidades do tempo de execução, nem as estruturas de dados típicas e seus percursos, não ajudará.

Mentalidade de solução de problemas

Depois de fazer a pergunta, você monitora o candidato de perto. Como ele reage? Você obtém os melhores resultados aqui de candidatos que não têm absolutamente nenhuma pista sobre como resolver o problema primeiro . A esse respeito, a pergunta verifica o que pode acontecer se uma situação semelhante ocorrer mais tarde no local de trabalho. Você pode encontrar esse problema durante o seu desenvolvimento e é bom saber como o candidato lida com esses problemas, mesmo que ele não consiga resolver tudo sozinho.

Exemplo: você não deseja que seu candidato entre no modo silencioso pela próxima meia hora! Verifique se ele consegue formular perguntas inteligentes (consulte Requisitos), verifique se ele começa a pensar fora da caixa quando perceber que não pode fazê-lo. Mesmo uma contra-pergunta "divertida" como uma "Posso usar a opção de telefone por colega de trabalho?" é um bom sinal.

Como responder

Em geral, as melhores respostas que você pode dar para esse tipo de pergunta são contra-perguntas! Dizer uma resposta imediatamente falha basicamente a coisa toda e, na verdade, não é uma boa resposta, porque todas essas perguntas sugerem trocas, o que sua resposta implica, sem que você tenha as informações necessárias ainda para fazer isso de maneira inteligente. troca. Obviamente, a qualidade das contra-perguntas varia entre os candidatos.

Como uma observação geral sobre as perguntas da entrevista: Contra-perguntas raramente são uma coisa ruim. Em uma de minhas próprias entrevistas, perguntaram-me, por exemplo, algo como o seguinte: "Se você tivesse que implementar o X, escolheria C ++ ou Java para isso, e por quê?" - Simplesmente respondi com "Estou limitado a esses dois?". Adivinhe você mesmo, que tipo de reação você recebe de um entrevistador por uma contra-pergunta - e quão fácil é realmente mostrar ao entrevistador do que você é capaz.

A menos que você esteja fazendo perguntas sobre algoritmos / fórmulas que o candidato precisa conhecer para o trabalho (dinâmica dos fluidos, por exemplo, se a posição exigir isso), não vejo o valor deles. O candidato provavelmente já está preocupado com o modo como está vestido, com o que está falando, etc ... se eles podem responder uma pergunta de matemática no local não prova nada além de como eles poderiam se sair em um programa de TV.

Quando entrevisto, nem faço perguntas de 'programação' por si só. Eu tenho o candidato descrevendo seus projetos anteriores, como seu código alcançou objetivos, quais são suas abordagens, etc. A partir disso, posso dizer rapidamente se o candidato sabe o que está fazendo ou se é um poser.

Concordo que os programadores devem conhecer muito bem os algoritmos, mesmo com novas estruturas sofisticadas, mas não estou totalmente convencido sobre um quebra-cabeças em uma entrevista. Minha maior preocupação seria que, em um ambiente real, você escreva algoritmos sob condições muito diferentes; ou seja, não sob pressão com alguém observando você a cada toque, com pelo menos alguns minutos para refletir em silêncio. Para aqueles que defendem esse método de avaliação, quanto tempo você geralmente dá à pessoa para resolvê-lo? Acredito que o código não é tanto o de encontrar uma solução em um terror febril de três minutos, então me convença de que essa é realmente uma boa maneira de ver como alguém lidará com uma tarefa cotidiana.

O problema com essa pergunta específica é que é quase uma questão complicada. Com um insight específico, você encontrará facilmente O (n), caso contrário, lutará para ficar melhor que O (n log n). Quase se reduz a "Você já viu esse antes?"

Não tenho certeza se existem boas perguntas algorítmicas. Se você perguntasse a alguém com base na teoria dos grafos, por exemplo, isso dependeria de como o entrevistado estivesse familiarizado com a teoria dos grafos - e, se você o contratar, ele ou ela poderá acelerar a teoria dos grafos rapidamente. Novamente, voltamos a "Você já foi exposto a isso antes?"

Em uma entrevista regular, não há tempo para resolver sérios problemas, e eu abordo as coisas de maneira diferente quando posso me sentar, usar a Wikipedia e, geralmente, levo algum tempo para entender as coisas. Provavelmente não há tempo para o entrevistador discutir cuidadosamente o que o entrevistado sabe em detalhes e escolher uma pergunta algorítmica adequada.

Eu tenho várias perguntas semelhantes a algoritmos que eu uso regularmente, algumas das quais são muito difíceis. Eu os uso para ver como eles atacam mentalmente um problema e para ver se eles criam certos conceitos. (Já vi muitos candidatos a desenvolvedores que simplesmente não entendem ponteiros.)

Você quer uma pergunta que lhe dê informações sobre o candidato. Uma pergunta sobre algoritmo pode dar uma boa resposta ou não. E não estou me referindo a eles serem capazes de responder ou não. Se eles resolverem o problema e você entender e seguir o raciocínio deles, esse é um bom indicador. Se eles ficarem lá, sem resposta real, nem parecerem por onde começar, isso é um indicador ruim (talvez). O problema seria que algumas pessoas congelam e pode ser difícil diferenciar o congelamento de não ter habilidades para resolver problemas.

As pessoas reclamam de perguntar praticamente qualquer coisa nas entrevistas, por vários motivos. O requerente pode congelar, o requerente pode ter acabado de pesquisar essa pergunta, o requerente pode não conhecer aquela parte específica de trivialidade / tecnologia / qualquer coisa. Tudo isso é verdade, mas uma entrevista ainda precisa acontecer, e muitos de nós nessa profissão odeiam isso. Nós odiamos a idéia de alguém sentando em nosso julgamento. Imediatamente invocamos razões pelas quais podemos ser julgados injustamente ou como o teste pode ser falso ou falso. Resumindo, isso não importa.

O que você realmente deseja é um entrevistador com a capacidade de determinar habilidades que podem ou não ser apresentadas durante a entrevista. Perguntas são apenas as ferramentas. Para mim, todos os martelos parecem iguais. Mas para alguém habilidoso o suficiente com eles, tenho certeza de que há diferença.

Gosto de perguntas sobre algoritmos, porque é o que fazemos. Eu gosto de restrições, porque é o que usamos. Big-O é especialmente relevante na minha indústria.

Não gosto de exigir que as respostas para esse tipo de pergunta sejam "escreva o código no quadro". O entrevistado deve ser capaz de falar de maneira inteligente sobre a abordagem da solução e participar de uma discussão contínua, à medida que os entrevistadores alteram os requisitos enquanto a discussão está em andamento.

A pergunta original é feita, diz o entrevistado, "comece do começo e marque no final, procurando o 'buraco'". O entrevistador diz que é muito lento, porque N é gigantesco. O entrevistado começa a discutir a pesquisa binária. O entrevistador diz que, de repente, os dados não são mais classificados. O entrevistado diz "classificar e pesquisar". "Agora está muito lento". Etc etc.