Quanta ajuda devo dar durante as entrevistas técnicas? [fechadas]

Me pedem para realizar ou participar de muitas entrevistas técnicas. Fazemos perguntas lógicas e simples problemas de programação que o entrevistado deve resolver no papel. (Prefiro que eles tenham acesso a um teclado, mas isso é um problema para outra hora.) Às vezes, sinto que as pessoas sabem como abordar um problema, mas estão atoladas pelo nervosismo ou por adivinhar a questão ( eles não pretendem ser perguntas complicadas).

Eu nunca ouvi meu chefe dar qualquer ajuda ou dicas. Ele apenas agradece ao entrevistado pela resposta (não importa quão boa ou ruim seja) e passa para a próxima pergunta ou problema. Mas eu sei algo sobre a toca do coelho que a derrota e os nervos podem levar você para baixo, e como isso desativa sua mente, e não posso deixar de pensar se fornecer uma pequena ajuda de vez em quando nos ajudaria a acabar com programadores mais capazes. de mais entrevistas falhadas.

Devo fornecer dicas e assistência para os entrevistados confusos (e, em caso afirmativo, até onde devo ir enquanto continuo sendo justo com os candidatos mais preparados)?

Quando eu estava em uma posição semelhante, eu dizia ao entrevistado: "Finja que sou o Google. Se você precisar procurar algo, basta dizer".

Em uma pergunta, os entrevistados precisavam descobrir o volume de um cilindro, então não me importei se alguém dissesse: "Eu precisaria procurar no Google a fórmula para o volume de um cilindro". Eu estava interessado em saber se eles sabiam como atacar o problema, não se tivessem memorizado fórmulas. Para o trabalho, eles tinham que ter uma compreensão decente de como traduzir o mundo real em software, por isso era um conceito importante.

Por outro lado, eu não diria a eles que eles precisavam dessa fórmula.

Você está certo de que os nervos podem ser um problema, mas ainda espero que as pessoas possam expressar seu processo de pensamento, mesmo que estejam nervosas. Simplesmente não dar uma resposta era inaceitável.

Você tem duas abordagens que funcionam tanto para solucionar problemas quanto para perguntas técnicas curtas:

1. O primeiro é usado pelo seu chefe: não forneça nenhuma ajuda para testar como a pessoa se comporta em um contexto estressante. É uma abordagem perfeitamente válida e pode dar algumas dicas sobre a pessoa. Afinal, depois de contratar essa pessoa, ela não poderá receber ajuda constante de todos os seus colegas.

2. O segundo é fornecer dicas e suporte. O nível de suporte não importa muito; a única coisa que importa é que quanto mais ajuda você oferece à pessoa, menos precisa valorizar o sucesso dela.

Pessoalmente, acredito que você deve dedicar tempo suficiente para garantir que a pessoa não consiga resolver um problema sozinho e fazer com que sinta que não pode resolvê-lo sem ajuda. Mas então, você pode fornecer ajuda progressiva até dizer à pessoa a resposta em si.

Exemplo:

- Você pode me dizer como criar propriedades somente leitura em C #, ou seja, propriedades com um valor que pode ser inicializado apenas dentro de um construtor e não pode ser alterado posteriormente?
- Claro. Eu apenas uso a palavra-chave readonly.
- Você tem certeza? Você pode me explicar a diferença entre uma propriedade e um campo?
- Hum. Uma propriedade é ... você vê ... obtém e define ...
- Ok. Portanto, um campo é uma variável declarada dentro de uma classe ou uma estrutura e válida dentro do escopo de classe / estrutura, enquanto uma propriedade é como um campo, mas também fornece um mecanismo para ler, gravar ou calcular um valor. E agora readonly? É usado com propriedades?
- Eu acredito que é usado apenas para campos ...
- Certo. E as propriedades?
- Eles não podem ser somente leitura.
- Você tem certeza? E as propriedades que possuem apenas getters?
- Eles são somente leitura.
- Isso significa que seu valor sempre permanecerá o mesmo?
- Sim.
- Não, na verdade não. O fato de você ter uma propriedade com um getter não significa que seu valor não seja alterado durante a vida útil da instância da classe. Se o getter se referir a um campo que é incrementado toda vez que você acessar a propriedade, o valor retornado aumentará continuamente.
- Direito.
- Assim? Você tem uma idéia de como implementar uma propriedade com um valor que nunca muda?
- Não.
- Bem, você pode usar um campo de suporte somente leitura. Você sabe o que é um campo de apoio?
[...]

Dar a resposta é uma boa ideia em todos os casos. Houve vários casos em que o entrevistado comentou minha resposta de uma maneira interessante, mostrando que, mesmo que ele não pudesse responder à pergunta em primeiro lugar, ele ainda sabia coisas relacionadas.

Além disso, apenas fazendo uma pergunta sem ajuda adicional, você não está tendo muitas informações sobre a pessoa, além do fato de ela saber ou não a resposta . Fornecer ajuda progressiva pode permitir que você veja como a pessoa está pensando em um problema.

Também pode mostrar outras coisas que a pessoa não sabe. Tomemos o exemplo acima: se eu parasse na primeira resposta, não saberia que a pessoa não pode explicar a diferença entre um campo e uma propriedade ou que não sabe o que é um campo de apoio.

Se a pessoa responder imediatamente, tudo bem. Se ela precisar de alguma ajuda, não há nada de errado nisso. Se você mesmo responder à pergunta, é um mau sinal e espero que o entrevistado seja capaz de responder aos outros.

Eu sempre gosto de ajudar os entrevistados se eles estão presos a alguma coisa simples (como o nome de um padrão específico, se eles obviamente sabem o que é), e deixá-los passar por cima de coisas como os detalhes do estabelecimento de uma conexão com o banco de dados. Se eles estão tentando projetar algo, não digo muito porque não quero guiá-los ou jogá-los fora, se eles estão pensando em algo diferente do que eu acho que eles estão indo.

Lembro-me de ter sido perguntado a um entrevistador sobre um problema em particular, que tinha um resultado muito específico em mente, mas ele não foi capaz de me comunicar claramente a pergunta. Isso descreve a situação em que muitos entrevistados se deparam. Às vezes, o olhar vazio não é porque a pessoa não é uma boa solucionadora de problemas, mas porque a pessoa que está fazendo a pergunta não está sendo clara no que está fazendo. Nesse caso, a abordagem do seu colega de dizer e não fazer nada apenas prova que o candidato não se parece com o seu colega ou não está dentro da cabeça do seu colega. Acho que fornecer esclarecimentos sobre a questão em palavras diferentes pode fornecer melhores resultados para todos os envolvidos.

Dado que os programadores (pelo menos a maioria de nós) não trabalham no vácuo e que as entrevistas são estressantes o suficiente sem limites artificiais, eu estaria inclinado a oferecer a ajuda que um entrevistado pedir ou precisar.

Mas leve tudo isso em consideração ao fazer um julgamento final sobre o nível de competência real de um candidato.

Alguém que está procurando uma posição sênior, mas precisa de muita ajuda, tocaria um alarme.

Para os "idosos", ofereço perguntas curtas e abertas e presto mais atenção às perguntas que eles fazem do que à resposta. Encontro pessoas sêniores que ouvem, se comunicam, usam a escuta ativa, esclarecem e fornecem soluções do tipo que eu gosto.

Para "engenheiros de linha", usei a técnica para programar testes em que você fornece a um candidato um computador e um problema e algumas horas e depois volta. Nessa situação, perguntamos antecipadamente ao candidato quais sistemas operacionais e ferramentas eles preferiam (também uma parte interessante da experiência de um programador). Quando eles terminaram, como um grupo, pedimos que apresentassem a solução e por que ela era melhor do que outras soluções - uma revisão de código. Todas as habilidades que espero de um engenheiro experiente no primeiro dia.

É importante ressaltar que toda a equipe de entrevistas levou uma tarde para fazer o mesmo teste, então sabíamos que o teste era justo. Passamos uma hora examinando a abordagem de cada pessoa como faríamos com um entrevistado, o que nos deu uma sensação de abordagens diferentes.

Essa segunda técnica encontrou alguns dos melhores programadores "desconhecidos" (péssimo currículo, péssimas habilidades de entrevista) que eu já encontrei.

Prefiro iniciar entrevistas com uma pergunta fácil de criar confiança para deixar o candidato confortável com o processo. Quando isso funciona, ele ainda permite que você colha o máximo de informações possível de perguntas posteriores sem dar vantagem aos candidatos que entendem a linguagem corporal melhor do que o material relacionado ao trabalho.

Às vezes, fornecer minor hintsdurante a entrevista oral ajuda a ver até que ponto o candidato entende o (s) tópico (s). No entanto, deve haver no hintstestes padrão que cada candidato é solicitado a fazer.

Basicamente, two main thingsvocê pode querer saber sobre um candidato em potencial:

a) Características pessoais - ele se encaixa bem em sua empresa ou equipe

b) Habilidades técnicas - ele tem boa formação técnica e interesse em aprender coisas novas

Para aprender sobre esses pontos mencionados, você deve envolver o candidato em potencial em uma conversa. Também é importante garantir que o candidato comfortable during the interviewtenha o máximo conhecimento de suas habilidades atuais (soft e tech), bem como de seu potencial para realizar o trabalho.

Além disso, as habilidades de comunicação do candidato em potencial são tão importantes quanto suas habilidades técnicas e competência para resolver os problemas.

Parte do que deve ser observado é a capacidade de comunicação. Se o candidato não tiver certeza sobre a pergunta, ele deve fazer perguntas para esclarecer. Isso é uma coisa boa, na minha opinião. Muitas vezes, são tomadas más decisões porque certas suposições são feitas ao ler as especificações ou, nesse caso, ao processar uma pergunta da entrevista. O candidato pode responder com base nessas suposições e perder totalmente o ponto pretendido. A pergunta pode ter falhas ou pode ser o candidato. Em ambos os casos, permitir esclarecimentos via comunicação demonstra uma habilidade valiosa, que os empregadores devem procurar.

Eu acho que isso se resume à sua personalidade como entrevistador, e o que você acha importante e, portanto, está realmente classificando o candidato.

Pessoalmente, valorizo ​​a capacidade prática / pragmática em vez de trivialidades acadêmicas / esotéricas. Estou muito mais interessado em um candidato que possa entrar, trabalhar e contribuir efetivamente de alguma maneira valiosa para qualquer projeto que esteja sendo contratado para trabalhar, do que eu para saber quão boa é a memória deles por minúcias.

Então, treinarei um pouco se o candidato estiver preso em algo esotérico, ou em uma nuance raramente usada, ou em um caso delicado que possa ser relevante em uma pergunta de entrevista inventada, mas que raramente seja relevante na vida real. Especialmente tudo o que eles poderiam obter com alguns minutos no Google ou com uma referência prática da mesa ou o tipo "defina e esqueça".

No entanto, não vou treiná-los no mundo real, comum, convencional, fundamental, no trabalho diário. Essas são as coisas que quero que sejam inatas para eles.

Eu acho que isso depende da situação da entrevista e das perguntas. Eu usei as duas técnicas.

Por que eu gostaria de não fazer perguntas de acompanhamento? Quando estou tentando descobrir a resposta da pessoa ao estresse. Eu entrevistei pessoas para alguns trabalhos que estavam em ambientes altamente estressantes e o quão bem eles conseguiam lidar com o estresse era um fator crítico em nossas avaliações. Por isso, fizemos algumas perguntas extremamente difíceis que ninguém poderia responder sem estresse.

Quando estou tentando descobrir seus conhecimentos técnicos, faço perguntas de acompanhamento que podem conter dicas sobre o que estou procurando. Ao contrário do pensamento do gerente que disse que você deve fazer a todos as mesmas perguntas para ser justo, acredito que isso seja justo desde que várias condições sejam atendidas. Primeiro, todos recebem a mesma pergunta básica. Segundo, você não deve fazer perguntas de acompanhamento para ajudar apenas uma pessoa. Se você deixou os outros tropeçarem sem ajuda, você precisa deixar todos tropeçarem sem ajuda. Segundo, você deve comparar o desempenho dos candidatos na questão, não apenas em termos de resposta final, mas em termos de quão difícil foi arrastá-lo para fora deles. Esse processo ainda trata a todos de maneira justa.

Depende do tipo de programador que você deseja. Um introvertido que pode escrever ótimas 20 linhas de código no papel ficará bem para seu chefe. Um desenvolvedor de software que possa trabalhar em milhões de bases de código de linha dentro de uma equipe para produzir um bom software com eficiência, provavelmente não se sairá muito bem. Adoro esse tipo de entrevista como candidato - eles me dizem muito sobre como o chefe trata sua equipe e qual é a cultura do trabalho. Em um caso como esse, ao sair da entrevista, eu disse: "Obrigado - vamos economizar um pouco de tempo, se não me ligar, não vou ligar para você". Quando perguntado por quê, apontei que não queria trabalhar para uma empresa que me preparou para o fracasso.

É provável que sua abordagem obtenha melhores seleções para o desenvolvimento de software. A abordagem dos seus chefes funcionaria bem para coletores de lixo e para os caras que detêm os pirulitos Stop / Go em obras nas estradas.

O desenvolvimento de software é um esforço de equipe, não um jogo solo / de leitura da mente / não interativo. Quantos projetos falham porque o software faz o que foi solicitado, não o que era desejado.

Eu estava recentemente em uma situação semelhante. A direção que recebi do meu gerente e de RH foi que precisávamos ser completamente justos com todos os 6 entrevistados, então tive que fazer o mesmo conjunto de perguntas técnicas com o mínimo de ajuda para ver como cada entrevistado se comporta. Às vezes, quando eles sabiam a resposta, mas ficavam presos a um termo técnico ou algo assim, eu os ajudava indiretamente com algumas perguntas que os guiavam para esse termo. Houve uma segunda rodada de entrevista após a rodada técnica sobre traços de personalidade e comportamento, se eles conseguissem passar pela primeira rodada.

Parte do que você deseja em um funcionário é alguém que possa interagir com o resto da equipe. Você precisa de alguém com a habilidade necessária, é verdade. Mas você também precisa de alguém que saiba quando precisa procurar ajuda e que ele tenha autoconhecimento e habilidade social para fazer isso. Esse último conjunto de peitoris estabelecerá a empresa melhor a longo prazo do que qualquer linguagem Du-jour em particular.

Do meu ponto de vista, uma entrevista é uma sessão experimental de coworking, não um teste . Estou principalmente tentando responder à pergunta "como é trabalhar com essa pessoa?" Às vezes, até finjo que esqueci a resposta da pergunta, para tornar o exercício mais colaborativo.

Você já trabalhou com alguém com quem simplesmente não conseguia entrar na mesma página sempre que falava sobre um problema? Ou alguém que fez muitas perguntas em vez de entrar e resolver problemas? Em uma entrevista, estou me certificando principalmente de que a pessoa com quem estou conversando não seja uma delas. Há um forte elemento de química lá.

No processo, é claro que também aprenderei coisas como "ela escreve código limpo", "ela está familiarizada com os conceitos necessários" e "ela pode habilmente cutucar um problema para obter insights?" O candidato ainda será o "dirigindo" e escrevendo o código. Mas ao longo do caminho, espero que ela fique mais relaxada e eu verei uma versão dela mais próxima do que eu veria no dia a dia como colega de trabalho.