As entrevistas técnicas tendem a ser subjetivas? [fechadas]

Com base na minha experiência em entrevistas técnicas, descobri que a maioria tende a ser subjetiva porque o entrevistador já tem sua própria resposta. Embora a resposta do candidato esteja correta, porque o entrevistador não estava preparado para essa resposta, o candidato não consegue o emprego.

Em uma entrevista recentemente, eu disse algo sobre o uso de um algoritmo de árvore AVL para resolver um problema específico que foi solicitado. O entrevistador respondeu: "O que é uma árvore AVL?". Outro exemplo é sobre sintaxe; Eu encontrei isso principalmente em entrevistas que exigem código Ruby, porque existem muitas maneiras de implementar uma solução para um determinado problema. Os problemas mais comuns são os projetos orientados a objetos.

Nesta situação, não há como o entrevistado ter sucesso. Alguém mais se sentiu assim também ou sou apenas eu? Se não sou apenas eu, como podemos melhorar as entrevistas técnicas?

Eu acho que seus próprios pontos cegos estão levando você a uma suposição inválida sobre o motivo de você não conseguir o emprego.

É possível responder tudo corretamente em uma entrevista de emprego e não conseguir o emprego, porque você está competindo com outras pessoas que também podem ter acertado tudo. Quando você tem apenas um emprego e três pessoas acha que podem fazer o trabalho, ainda pode contratar apenas um. É um mercado difícil por aí e muitas pessoas experientes estão procurando. Você nunca sabe o quão bem sua concorrência se saiu nas entrevistas deles.

Sim, as entrevistas são subjetivas, estão procurando pessoas que não apenas tenham habilidades técnicas, mas que se encaixem no grupo existente. Apenas continue tentando, se você for capaz, encontrará o lugar certo e eles o contratarão.

Qualquer entrevistador que demitiu um candidato simplesmente porque não forneceu a resposta esperada é um entrevistador ruim. Se uma empresa encoraja isso e sinto essa sensação em uma entrevista, isso é uma bandeira vermelha séria sobre a equipe e a empresa que estão me entrevistando.

Se um entrevistado me fornecesse uma resposta em que não pensava, esperaria que ele fosse capaz de explicar qual é a solução usada e as vantagens / desvantagens dela. Como você disse, muitas vezes existem várias soluções, desde a escolha de um algoritmo até as estruturas sintáticas usadas, e quase sempre há trocas envolvidas. Eu até pesquisava o entrevistado em busca de soluções alternativas para ver se elas conseguem encontrar outras pessoas, especialmente se for uma solução óbvia, e pedir as vantagens / desvantagens de cada uma.

Independentemente de como você conduz a entrevista, ela será subjetiva. Todo entrevistador, como pessoa, terá preconceitos. Como entrevistado, você pode simplesmente fazer o melhor que puder, ser completo (mas não excessivamente detalhado) ao responder a perguntas e explicar suas respostas e como chegou lá. Isso levará um longo caminho.

Um que eu descobri recentemente é quando eu disse algo sobre o uso de um algoritmo de árvore AVL para resolver um problema específico que foi solicitado. O entrevistador me perguntou de volta: "O que é uma árvore AVL?".

Como entrevistador, eu também pediria isso, mesmo que soubesse tudo sobre as árvores AVL (não sei), para descobrir o quanto o candidato sabe. Fingir a ignorância pode ser um truque para ver se o candidato pode explicar bem. Mas, obviamente, se você criar uma estrutura de algoritmo / dados que resolva o problema, que eu não conheço e que possa explicar corretamente, eu o contrataria. Caso contrário, tenha vergonha de mim. Não contratar pessoas porque são mais inteligentes do que você não é uma boa estratégia de contratação.

Mas de um modo geral: sim, as entrevistas técnicas são sempre subjetivas. E eles têm que ser. Se você vai passar mais de 8 horas todos os dias com uma pessoa, não seria razoável escolher alguém que consiga deixá-lo louco em uma entrevista de 60 minutos.

Perguntas triviais são antipadrões para entrevistas. Se você se encontra preso em uma entrevista, tente encaminhá-los de volta ao que você conhece. Concentre-se em seu currículo. Se isso não funcionar ... bem, considere procurar em outro lugar.

Os entrevistadores devem fazer perguntas abertas relacionadas ao seu currículo. Embora seja possível ter uma noção das habilidades de comunicação de uma pessoa, é difícil avaliar as habilidades de desenvolvimento de uma pessoa simplesmente fazendo perguntas. É em parte por isso que tantas pessoas (incluindo Joel no software) recomendam, não é necessário que os entrevistados escrevam código (e pulem por vários outros argumentos).

O fato é que o desenvolvimento de software ainda tem como principal objetivo solucionar um conjunto desconhecido de problemas em um período desconhecido. Não há um conjunto de testes que comprove, ok esse cara pode construir "uma ponte". Estamos melhorando em transformar a criação de software em um processo de engenharia mais definido, mas ainda não estamos lá.

As entrevistas técnicas "reais" que tive foram todas como: "Aqui está o problema, use essas tecnologias, você tem 3 horas". Depois disso, fizemos uma revisão de código e conversamos sobre por que fiz o que fiz. Dessa forma, ele viu o que eu já sei e onde me falta conhecimento.

Depois conversamos um pouco sobre tecnologias e meus objetivos em geral, e foi isso. As entrevistas são, na minha opinião, projetadas para ter uma ideia do candidato. Você não pode testar tudo. Demora muito tempo para conhecer alguém muito bem, para que, novamente, na minha opinião, você deva se concentrar nas coisas que são importantes para o seu projeto e ver como as pessoas lidam com esses problemas. O resto vem com a experiência ao longo do tempo

Receio que a parte subjetiva não possa ser removida, apenas diminua. Freqüentemente, tenho entrevistas técnicas, nas quais o entrevistador "polui" a entrevista com suas próprias idéias subjetivas.

Um exemplo simples, como você mencionou, é que o entrevistador deseja uma resposta muito próxima da sua própria resposta. Outro exemplo é quando um entrevistador está mais interessado em investigar que sabe mais do que o candidato. E outra simples, é quando o entrevistador deseja que o candidato conheça o local específico do menu para uma operação de um IDE de programação (Visual Studio, Eclipse, NetBeans).

Eu já participei de várias dessas, e é muito frustrante.

E, é claro, também existe a questão da discriminação oculta, na qual o entrevistador não deseja que o candidato seja pobre, de gênero, de idéias políticas, de raça, de escola, o que você quiser. E está procurando qualquer desculpa para rejeitar o candidato.

A parte mais estranha é que, formado em ciências da computação, conheço um pouco de psicologia (estudava essa profissão) e, às vezes, detecta muita "interferência" subjetiva. Ou, quando o entrevistador vai ao escritório ao lado e diz explicitamente a seus colegas de trabalho, ele / ela não quer contratar um candidato, por uma razão subjetiva.

Algo importante, a considerar, é que muitas universidades ou empresas ensinam as pessoas de TI / técnicas a fazer entrevistas de emprego, e esse ensino inclui os fatores técnicos e humanos, e não apenas técnicos.

Aqui está como eu faço:

• Primeiro, peço ao candidato que resolva um problema realista. Geralmente, este é um problema que posso resolver facilmente; geralmente em muito menos do que o tempo previsto.

• Uma vez que o candidato é feito; Eu me torno estudante . Eu tenho o candidato falando e aponte a solução deles e me mostre como eles resolveram isso. Faço perguntas sobre as idéias deles, e se eles sabem de soluções alternativas e por que escolheram essa solução em vez disso.

Aqui está o que estou procurando.

• Só porque eu sei que uma boa solução para o problema não significa que estou procurando essa solução. Qualquer solução válida dentro das restrições iniciais é aceitável. Estou interessado em como eles planejaram sua solução, como eles usaram as ferramentas fornecidas. Estou interessado em quais deficiências eles são capazes de identificar em suas próprias soluções.

• Também estou interessado em saber como eles escutam e se comunicam. Eles conseguiram entender e implementar todos os requisitos iniciais? Quão bem eles explicaram o modo como sua solução funciona?

No final de tudo isso, depois de ter uma boa idéia do que o candidato está realmente trazendo para a abertura, posso oferecer alguns dos pontos da minha própria solução, onde acho que minhas escolhas seriam melhores.

Se o candidato disser algo como "Essa é uma boa ideia, eu gostaria de ter pensado nisso" ou "Ah, eu não sabia sobre essa técnica" ou mesmo "Eu pensei nisso, mas usei isso" uma razão sensata como "eu entendo melhor esse método" ou "eu pensei que você estava procurando esse tipo de solução", todos eles contam fortemente a favor do candidato.

Se o candidato escolher diferente de mim, isso pode significar que estou errado. Ou, se eu estiver certo, e o candidato estiver aberto o suficiente para discutir as diferenças nas soluções, é um bom sinal de que o candidato pode ser cutucado com bastante facilidade para fazer melhores escolhas.

Eis como sei que um candidato é uma má escolha:

• o candidato tenta buscar uma solução esperada do entrevistador.
• a solução fornecida não resolve o problema declarado ou, de alguma forma, viola algumas das restrições declaradas de uma maneira que o candidato não pode explicar.
• o candidato argumenta com as restrições para tentar alterar o problema que ele espera resolver (lembre-se de que esse é um problema para o qual tenho uma solução que pode ser implementada em muito menos tempo do que o indicado).
• o candidato fica "preso" e passa grande parte do tempo alocado sem fazer nada. Idealmente, um candidato atacaria o problema de outro ângulo ou procuraria o entrevistador para saber o que deveria fazer quando não pudesse prosseguir.
• o candidato não sabe "por que" ele usou uma técnica, mesmo que não conheça alternativas. Respostas como "Não conheço outra ferramenta que faça isso" ou "Não sei como essa ferramenta funciona, mas funciona" estão bem, mas "porque eu sabia" são questionáveis.

Você acha que, como entrevistado, sua aceitação de um emprego não é subjetiva, até certo ponto? O recrutamento é um processo bidirecional.

Como entrevistador, se eu e meus colegas "clicamos" em um candidato, eles têm uma boa chance de concorrer ao cargo, assumindo que outros fatores, como um exercício de codificação doméstica e problemas no quadro branco, vão bem. Clicando é estar no meu comprimento de onda, ter uma conversa proveitosa, compartilhar valores comuns sobre o processo de desenvolvimento. Quão objetivo isso pode ser?

Na questão da árvore AVL, eu estaria interessado no candidato explicar como ele funciona e fornecer informações sobre propriedades e uso. Para fazer melhor do que a explicação na Wikipedia. Lembre-se de que seu público pode ser alguém em um ambiente corporativo corporativo em que a última referência a O (log n) em uma discussão técnica foi basicamente ... nunca.

Como entrevistador, quero dar a um candidato todas as oportunidades para brilhar. Eu imagino que isso se aplicaria a qualquer organização em que você gostaria de trabalhar.

Um bom entrevistador não fará uma pergunta em que espera uma resposta específica, a menos que a pergunta seja trivialmente simples, onde há apenas uma resposta correta. Um bom entrevistador verá como você aborda um problema, como você o pensa e como chega à sua resposta - se a sua resposta for válida, eles não devem mantê-la contra você, porque você não fez as coisas da maneira que elas o fariam. .

Parece que você acabou de ser submetido a péssimos entrevistadores, mais preocupados em mostrar sua "superioridade" ao candidato do que em avaliar habilidades técnicas.

Uma habilidade muito importante quando você trabalha em equipe é ser capaz de justificar sua própria solução e avaliar de maneira justa a de outra pessoa. Você precisa aprender com seus colegas e ensiná-los.

Se você deseja usar uma árvore AVL para resolver um problema, e os outros membros da sua equipe se lembram deles vagamente da faculdade e não pensaram nisso desde então, é melhor que você possa explicar suas vantagens para eles. Se alguém apresentar uma solução que você não entende, é melhor você querer fazer perguntas até entender. Se alguém apresentar uma solução claramente inferior, é melhor você articular o porquê. Se alguém apresentar uma solução superior, é melhor você reconhecer isso e deixar seu ego de lado.

Essas são as habilidades que procuro quando faço uma pergunta técnica em uma entrevista. Se eles vieram com a resposta "correta" da cabeça é irrelevante. Isso é importante apenas na escola.