Em uma entrevista, é melhor codificar uma solução de força bruta para uma pergunta difícil, ou passar a entrevista examinando a questão com cuidado? [fechadas]

14

Por vezes, as perguntas da entrevista são difíceis, quer o entrevistador pretenda que elas sejam ou não. Pode ser uma escolha entre usar o tempo limitado da entrevista para codificar uma solução feia, ineficiente e de força bruta, ou passar o tempo compreendendo cada aspecto do problema com o entrevistador.

Por exemplo, o Problema 91 no Projeto Euler pode ser solucionado por uma solução de força bruta não tão difícil de calcular todos os possíveis triângulo, escrevendo um teste isRightTriangle (), e popping todos os triângulos que passam o teste em um conjunto. Mas os dois pares de coordenadas X / Y fazem disso uma solução O (x ^ 4) com um valor constante alto. Um amigo e eu acabamos de chegar a uma solução que é muito mais elegante e eficiente, mas nós dois passamos 3 horas nele e desenhamos dezenas de diagramas, testamos várias fórmulas, examinamos várias abordagens, etc.

Nem toda questão da entrevista é justa. Além disso, o que é fácil para uma pessoa pode ser difícil para outra. Se alguém se esforça com uma pergunta, você ficaria mais impressionado com uma solução feia de força bruta que funciona? Ou excelente compreensão do problema e estradas para uma solução elegante, mas sem solução codificada? Existe uma regra como depois de 20 minutos você deve começar a codificar não importa o quê?

    
por GlenPeterson 16.03.2013 / 22:32
fonte

8 respostas

9
Em primeiro lugar, uma pergunta que leva dois desenvolvedores experientes três horas para otimizar elegantemente é uma má escolha para uma pergunta da entrevista. Se você perguntar, não espere respostas perfeitas.

Por outro lado, às vezes você aprende mais sobre alguém quando faz com que ele atinja seus limites. É por isso que muitos cursos universitários aumentam a dificuldade e, em seguida, avaliam a curva. Se todos pontuarem 100% em cada exame, você está deixando muito potencial para aprender.

Meu candidato ideal provavelmente faria primeiro o cálculo de complexidade, digamos, "Oh, são apenas 6 milhões de iterações, que não demoram muito", e então escreva rapidamente a solução de força bruta. Em seguida, eles discutiam as abordagens que poderiam adotar para otimizá-lo, sem necessariamente implementá-los, a menos que o entrevistador os solicitasse.

Em parte, isso ocorre porque muitos dos problemas de tipo euler do projeto que surgem no mundo real são problemas únicos que você precisa resolver uma vez e depois esquecem disso. Eu quero saber que alguém que eu contratar será capaz de reconhecer um algoritmo de força bruta que leva 2 minutos para escrever e 10 minutos para rodar é mais eficiente que um algoritmo que leva 3 horas para escrever e 10 segundos para rodar, se você só precisa para executá-lo uma vez.

    
por 17.03.2013 / 00:50
fonte
14

Como gerente de contratação, se eu estou pedindo para você resolver um problema com o código bem na minha frente, eu não estou fazendo tanto para ver o código em si (embora seja importante), mas sim para verificar o código como e por que você fez o que fez. Uma dessas coisas que você pode fazer é não código, e em vez disso me interrogar sobre os aspectos do problema em si, 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 todos fazem isso, nem é o que todo mundo quer ver (e de fato eu raramente peço para as pessoas codificarem em um ambiente de entrevista, mas eu coloco problemas na mesa e nós falamos sobre eles e às vezes emerge pseudocódigo , que é tão bom para mim ).

Você está certo de que nem todas as perguntas da entrevista são justas, e o que é fácil para alguém é difícil para outra, nesse cenário e com essas restrições, e é por isso que as entrevistas que entendem normalmente não estão procurando pelo código solução (embora, mais uma vez, que desempenha um papel importante), mas sim a solução processo .

"Existe uma regra como depois de 20 minutos você deve simplesmente começar a codificar não importa o quê?" Eu responderia isso dizendo que dentro de um tempo muito curto de pensar sobre o problema, você deveria pelo menos, estar fazendo algo - fazendo mais perguntas, esboçando um framework para uma solução, ou dizendo que você simplesmente não pode fazer isso / não sabe por onde começar.

Se eu colocar um problema difícil na sua frente e a solução que você forneceu - dadas restrições de tempo e o que você tem - for força bruta e feia, eu então lhe faria uma série de perguntas sobre o motivo o caso, e o que mudaria isso para algo mais elegante: mais informação? mais tempo? um ambiente diferente? Ser autoconsciente e em contato com o porquê do que você fez, e o que você não fez, e ser capaz de explicá-lo racionalmente, é um grande estrela de ouro no meu livro, mas esses são os tipos de desenvolvedores que eu procuro. Então, "excelente compreensão do problema e direcionamento para uma solução elegante" funcionaria para mim também, mas nem todos.

    
por 16.03.2013 / 23:20
fonte
4

Eu gostaria de ambos, mas eles podem exibir um "código que simplesmente funciona" em uma solução e possivelmente discutir possíveis soluções para melhoria em um ou outro problema.

Se você pedir a alguém para escrever código e eles só quiserem falar sobre possíveis soluções com código zero, isso seria uma preocupação.

Como você disse, alguém pode lutar com o problema em particular por qualquer motivo, mas você precisa aprender como resolvê-lo. Eles podem ter sorte e já ouviram falar de uma solução para um problema semelhante. Acontece.

Assista a alguém escrever código suficiente e discuti-lo, e você pode descobrir se ele está certo para o trabalho.

    
por 16.03.2013 / 22:50
fonte
3

Is there a rule like after 20 minutes you should just start coding no matter what?

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 ele perguntar como um problema de codificação, ele também verá um código. Converse com eles através do seu processo de pensamento ...

Well, the obvious approach here is brute force. If I had a way to recognize a right triangle given the three vertices, I could run through all the combinations of two points and the origin looking for right triangles. That shouldn't be hard -- I can write a function that uses the Pythagorean Theorem to identify right triangles. To make that easier, I'll also write a function that determines the distance between two points using the distance formula...

Escrever essas funções deve levar cerca de três minutos. Agora, apenas alguns minutos depois, você já demonstrou que se lembra da geometria básica e que realmente sabe como escrever código. Também lhe dá algo para falar:

So, we could obviously put the isRightTriangle(p1, p2, p3) function in the middle of four for loops and iterate over all the possible choices for each of the two variable points. Let's see... the problem asks for the number of right triangles including the origin on a 50x50 grid, so using the brute force method makes us check 50 possibilities for each coordinate of each point. That's 50^4 checks... I'm sure we can do better, but the code is obvious, so let me write that down...

Agora você escreve uma função que usa loops for aninhados e a função isRightTriangle() que você acabou de escrever. Você resolveu o problema, mas também deixou o entrevistador ver aonde está indo. Se o objetivo deles era apenas ver que você pode escrever código, eles podem pedir para você parar. Mais provavelmente, eles estão felizes em conversar com alguém que sabe o que estão fazendo e eles vão querer ver até onde você leva isso. Então você continua ...

It occurred to me while I was writing that that we can take advantage of symmetry. We can reflect any given right triangle around the 45° line, so if we choose to check one of the points only on one side of that line, we can just count any right triangles we find twice... once for the triangle and once for its reflection. That cuts the number of checks by half. Also, looking at it now, we're taking a square root to find the distance between two points, but then we just square that again in isRightTriangle()...

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 nada parecido com o acima - apenas ter confiança para pensar em voz alta contará muito. Não se preocupe se você cometer um erro - apenas diga "hmmm, eu acho que saí dos trilhos aqui - deixe-me voltar um passo ..."

    
por 17.03.2013 / 07:15
fonte
3

Como gerente, se eu pedir para você codificar como um teste, estou mais interessado em:

  • Se você pode escrever código
  • Seu estilo de codificação
  • O algoritmo selecionado
  • A tentativa indica que você entendeu o problema
  • Se eu realmente gosto de uma tecnologia específica, você demonstrou que mais ou menos sabe disso.

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:

  • Você escolheu composição ou herança para resolver esse problema? Por quê?
  • Para esse valor, por que você escolheu usar um enum versus uma string versus um int (ou qualquer permutação aplicável)
  • Você usou propriedades, campos ou métodos get / set para esse valor? Por quê?
  • Como você lidou com o estado em suas aulas?
  • Você entende como a herança, as interfaces e os lambdas funcionam?
  • Você entende as convenções de parâmetro da linguagem (o que é por ref vs por valor?)
  • Você sabe escrever testes de unidade?

Aqui está o que eu realmente não me interessa:

  • Que ele compila (assumindo que eu acabei de lhe fornecer o bloco de notas e não o compilador)
  • Que você sabia por memória a ordem desses dois parâmetros nessa função
  • Que você pode recitar uma string de conexão do SQL Server ou Oracle de cor
  • Que você pode codificar perfeitamente enquanto eu estou em pé sobre o seu ombro assistindo a cada erro.

Com toda a honestidade, eu nunca fui muito fã de testes de codificação - exceto como uma ferramenta para analisar o estilo.

    
por 17.03.2013 / 01:32
fonte
1

Nesse caso, incursões para uma solução elegante é melhor do que uma solução pior, mas completa. Ambos os casos são bons embora. É absolutamente bom ter escrito pusdocode demonstrando que você entende o problema e como você pretende resolvê-lo, mesmo que você não tenha tempo para realmente codificar o programa.

    
por 16.03.2013 / 22:46
fonte
1

Acho que você está fazendo uma pergunta para a qual realmente não há resposta, muito menos uma resposta "certa". A razão pela qual digo isso é que depende inteiramente do que a pessoa que faz a pergunta avalia.

É possível que o entrevistador seja um pragmático incondicional, realmente querendo que você consiga algo funcionando rapidamente e depois otimize como uma atividade de menor prioridade, se você tiver tempo restante. É igualmente possível que o entrevistador esteja fazendo sua melhor impressão das práticas de contratação do Google e não esteja interessado em nada, a não ser no algoritmo mais sexy e elegante, e leva isso como um sinal de fraqueza que você já colocou as palavras "brute" e " força "dentro de 5 palavras um do outro. Também é possível que o entrevistador pesquise "perguntas da entrevista" e encontre esse problema na Internet 5 minutos antes de você entrar e não ter ideia do que ele quer.

Em todos os casos, sua melhor aposta é pedir esclarecimentos, se você não puder deduzir com base nas informações de contexto o que o entrevistador deseja. Você está certo de que nem todas as perguntas da entrevista são justas e, na verdade, nem todas são boas perguntas ou mesmo perguntas que fazem sentido. Uma entrevista é uma atividade inerentemente reducionista, muito parecida com "speed dating", em que você está passando uma hora ou duas com alguém e os dois estão tentando adivinhar, com base nessa hora, se você trabalhará bem juntos pela próxima vez. 5 anos ou não. Examinado a partir dessa perspectiva, espero que seja mais claro por que digo que realmente não há resposta para sua pergunta sobre uma "regra".

Alguém está fazendo uma pergunta que acha que lhe dará uma visão sobre sua competência e se encaixará com a equipe. Você precisa olhar para a equipe deles, o que sabe sobre eles, a personalidade do entrevistador e dezenas de outros fatores, além de adivinhar quais respostas, abordagens e processos eles provavelmente valorizariam. Pessoalmente, eu diria que você deve abordá-lo da maneira que acha que é a melhor ideia. Se eles não concordarem com você, pode não ter sido um bom ajuste de qualquer maneira - mais fácil de descobrir isso mais cedo do que tarde.

    
por 17.03.2013 / 20:54
fonte
0

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á-la.

    
por 16.03.2013 / 22:50
fonte