Às vezes, as perguntas da entrevista são difíceis, se o entrevistador pretende que elas sejam ou não. Pode-se optar por usar o tempo limitado da entrevista para codificar uma solução feia, ineficiente e de força bruta ou gastar o tempo compreendendo todos os aspectos do problema com o entrevistador.
Por exemplo, o Problema 91 no Projeto Euler pode ser resolvido por uma solução de força bruta não tão difícil de calcular todos os triângulos possíveis, escrever um teste isRightTriangle () e exibir todos os triângulos que passam no teste em um conjunto. Mas os dois pares de coordenadas X / Y fazem dessa uma solução O (x ^ 4) com um alto valor constante. Um amigo e eu acabamos de encontrar uma solução muito mais elegante e eficiente, mas nós dois passamos três horas nela e desenhamos dezenas de diagramas, testamos várias fórmulas, examinamos várias abordagens etc.
Nem toda pergunta da entrevista é justa. Além disso, o que é fácil para uma pessoa pode ser difícil para outra. Se alguém luta com uma pergunta, você ficaria mais impressionado com uma solução feia de força bruta que funciona? Ou excelente compreensão de problemas e caminho para uma solução elegante, mas nenhuma solução codificada? Existe uma regra como depois de 20 minutos, você deve começar a codificar, não importa o quê?
fonte
Respostas:
Antes de tudo, uma pergunta que leva dois desenvolvedores experientes três horas para otimizar elegantemente é uma má escolha para uma pergunta de entrevista. Se você perguntar, não deve esperar respostas perfeitas.
Por outro lado, às vezes você aprende mais sobre alguém ao fazê-lo atingir seus limites. É por isso que muitos cursos universitários aumentam a dificuldade e depois avaliam na curva. Se todos obtiverem 100% de pontuação em cada exame, você estará deixando muito aprendizado em potencial.
Meu candidato ideal provavelmente faria primeiro o cálculo da complexidade, diria "Oh, são apenas 6 milhões de iterações, o que não vai demorar muito tempo" e depois escreveria rapidamente a solução de força bruta. Em seguida, discutiam abordagens que poderiam adotar para otimizá-lo, sem necessariamente implementá-las, a menos que o entrevistador pedisse.
Em parte, isso ocorre porque muitos dos problemas do tipo euler do projeto que surgem no mundo real são problemas únicos que você precisa resolver uma vez e depois esquece. Quero saber que alguém contratado poderá reconhecer um algoritmo de força bruta que leva 2 minutos para escrever e 10 minutos para executar é mais eficiente do que um algoritmo que leva 3 horas para escrever e 10 segundos para executar, se você precisar apenas para executá-lo uma vez.
fonte
Como gerente de contratação, se estou lhe pedindo para resolver um problema com o código bem na minha frente, não estou fazendo tanto para ver o código em si (embora seja importante), mas para saber como e por que você fez o que fez. Uma dessas coisas que você pode fazer não é codificar e, em vez disso, me interrogar sobre os aspectos do próprio problema, para resolvê-lo melhor. Isso é significativo para mim e, geralmente, mais significativo do que a solução apresentada no código. No entanto, não é assim que todo mundo faz, nem é o que todo mundo quer ver (e, de fato, raramente peço às pessoas que codifiquem em um ambiente de entrevista, mas coloco problemas na mesa e conversamos através deles e, às vezes, o pseudocódigo surge , o que é tão bom para mim ).
Você está certo que nem todas as perguntas da entrevista são justas, e o que é fácil para alguém é difícil para outra, naquele ambiente e com essas restrições, e é por isso que as entrevistas que entendem que normalmente não estão procurando a solução de código (embora , novamente, isso desempenha um papel importante), mas sim o processo de solução .
"Existe uma regra que, após 20 minutos, você deve começar a codificar, não importa o quê?" Eu responderia isso dizendo que, dentro de um período muito curto de reflexão sobre o problema, você deveria pelo menos estar fazendo algo - fazendo mais perguntas, esboçando uma estrutura para uma solução ou dizendo que simplesmente não pode fazê-lo / não sei por onde começar.
Se eu colocasse um problema difícil na sua frente e a solução que você forneceu - dadas as restrições de tempo e o que você tem - fosse bruta e feia, eu faria uma série de perguntas sobre por que esse era o caso, e o que mudaria para algo mais elegante: mais informações? mais tempo? um ambiente diferente? Ser autoconsciente e estar em contato com o porquê do que você fez e o que não fez e ser capaz de explicá-lo racionalmente é uma grande estrela de ouro no meu livro, mas esses são os tipos de desenvolvedores que eu olhe para. Portanto, "excelente compreensão de problemas e caminhos para uma solução elegante" também funcionariam para mim, mas não para todos.
fonte
Eu gostaria dos dois, mas eles podem exibir um "código que simplesmente funciona" em uma solução e, em seguida, possivelmente discutir possíveis soluções para aprimoramento em um ou outro problema.
Se você pedir a alguém para escrever um código e ele só quiser falar sobre possíveis soluções com código zero, isso seria uma preocupação.
Como você disse, alguém pode ter problemas com o problema específico por qualquer motivo, mas você precisa aprender como eles resolvem o problema. Eles podem ter sorte e já ouviram falar de uma solução para um problema semelhante. Acontece.
Observe alguém escrever código suficiente e discuti-lo, e você pode descobrir se eles são adequados para o trabalho.
fonte
Não, mas se você passar 20 minutos analisando o problema antes de começar a trabalhar, provavelmente já está com problemas. Um empregador que faz uma pergunta como a que você citou está mais interessado em como você aborda um problema, mas, se for perguntado como um problema de codificação, também vai querer ver algum código. Converse com eles através do seu processo de pensamento ...
A escrita dessas funções deve levar cerca de três minutos. Agora, apenas alguns minutos para a pergunta, você já demonstrou que se lembra da geometria básica e que realmente sabe escrever código. Também oferece a você algo para falar:
Então agora você escreve uma função que usa
forloops aninhados e aisRightTriangle()função que você acabou de escrever. Você resolveu o problema, mas também deixou o entrevistador ver para onde está indo. Se o objetivo deles era apenas ver que você pode escrever código, eles podem pedir para você parar. Provavelmente, eles ficam felizes em conversar com alguém que sabe o que estão fazendo e querem ver até onde você leva isso. Então você continua ...E assim por diante. Novamente, eles geralmente não querem ver uma solução perfeita, querem ver como você chega a uma solução. Seu processo de pensamento não precisa ser parecido com o descrito acima - apenas ter a confiança necessária para pensar em voz alta contará muito. Não se preocupe, se você cometer um erro - diga "hmmm, acho que saí dos trilhos aqui - deixe-me voltar um passo ..."
fonte
Como gerente, se eu pedir para você codificar como teste, estou mais interessado em:
O primeiro item pode parecer louco, mas você ficaria surpreso ...
Estilo de codificação - com isso, não quero dizer apenas onde você coloca o aparelho, mas coisas como:
Aqui está o que eu realmente não me importo:
Com toda a honestidade, nunca fui muito fã de testes de codificação - exceto como uma ferramenta para analisar o estilo.
fonte
Nesse caso, o caminho para uma solução elegante é melhor do que uma solução pior, mas completa. Ambos os casos são bons. É absolutamente bom ter escrito um código de pus demonstrando que você entende o problema e como pretende resolvê-lo, mesmo que não tenha tempo para codificar o programa.
fonte
Acho que você está fazendo uma pergunta para a qual não há realmente resposta, muito menos uma resposta "certa". A razão pela qual digo isso é que depende inteiramente do que a pessoa que faz a pergunta valoriza.
É possível que o entrevistador seja um pragmático incondicional que esteja realmente procurando ver que você conseguirá algo funcionando rapidamente e, em seguida, otimizará como uma atividade de menor prioridade se tiver tempo restante. É igualmente possível que o entrevistador esteja fazendo sua melhor impressão sobre as práticas de contratação do Google e não esteja interessado em nada, exceto no algoritmo mais sexy e elegante, e tome isso como um sinal de fraqueza de que você já colocou as palavras "bruto" e " force "dentro de 5 palavras uma da outra. Também é possível que o entrevistador tenha pesquisado no Google "perguntas da entrevista" e encontrado esse problema na internet 5 minutos antes de você entrar e não tenha idéia do que ele quer.
Em todos os casos, sua melhor aposta é provavelmente pedir esclarecimentos, se você não puder inferir, com base em informações de contexto, o que o entrevistador deseja. Você está certo de que nem todas as perguntas da entrevista são justas e, de fato, nem todas são boas ou mesmo perguntas que fazem sentido. Uma entrevista é uma atividade inerentemente reducionista, muito parecida com "namoro rápido", onde você passa uma hora ou duas com alguém e os dois estão tentando adivinhar, com base nessa hora, se trabalharão bem juntos pela próxima vez. 5 anos ou não. Examinado dessa perspectiva, espero que fique mais claro por que digo que realmente não há resposta para sua pergunta sobre uma 'regra'.
Alguém está fazendo uma pergunta que eles acham que lhe dará uma visão da sua competência e se encaixará na equipe deles. Você deve examinar a equipe deles, o que sabe sobre eles, a personalidade do entrevistador e dezenas de outros fatores, e adivinhar quais respostas, abordagem e processo eles provavelmente valorizariam. Pessoalmente, eu diria que você deve abordá-lo da maneira que achar melhor. Se eles não concordarem com você, pode não ter sido bom de qualquer maneira - é mais fácil descobrir isso mais cedo ou mais tarde.
fonte
Os entrevistadores solicitarão que você melhore sua solução de qualquer maneira.
E a abordagem "solução de força bruta primeiro" tem uma vantagem indiscutível: se você não conseguir encontrar uma solução ideal, ainda terá algo concluído para mostrá-las.
fonte