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

Quando eu estava em uma posição similar, eu diria ao entrevistado: "Finja que sou o Google. Se você precisar procurar algo, apenas diga".

Por outro lado, eu não ia dizer 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 nervosos. Simplesmente não dar uma resposta era inaceitável.

Você tem duas abordagens que funcionam tanto para a solução de problemas quanto para questões 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, uma vez que você 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 apoio não importa muito; A única coisa que importa é que quanto mais ajuda você fornecer para a pessoa, menos você tem que valorizar seu sucesso.

Exemplo:

‒ Can you tell me how do you create read only properties in C#, i.e. properties with a value which can be initialized only within a constructor and cannot be changed later?
‒ Of course. I just use the keyword readonly.
‒ Are you sure? Can you explain me the difference between a property and a field?
‒ Hm. A property is... you see... get and set...
‒ Ok. So a field is a variable declared inside a class or a struct and valid within the class/struct scope, while a property is like a field, but also provides a mechanism to read, write or compute a value. Now what about readonly? Is it used with properties?
‒ I believe that it's used only for fields...
‒ Right. So what about the properties?
‒ They cannot be read only.
‒ Are you sure? What about the properties which have only getters?
‒ They are read only.
‒ Does it mean that their value will always remain the same?
‒ Yes.
‒ No, not really. The fact that you have a property with a getter doesn't mean that its value doesn't change during the lifespan of the instance of the class. If the getter refers to a field which is incremented each time you access the property, the returned value will continuously increase.
‒ Right.
‒ So? Do you have an idea of a way you can implement a property with a value which never changes?
‒ No.
‒ Well, you can use a readonly backing field. Do you know what is a backing field?
[...]

Dar a resposta é uma boa ideia em todos os casos. Houve vários casos em que o entrevistado comentou a minha resposta de uma forma interessante, mostrando que, mesmo que ele fosse incapaz de responder à pergunta em primeiro lugar, ele ainda sabe coisas relacionadas.

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

Também pode mostrar outras coisas que a pessoa não conhece. Tome 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 ela 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 com isso. Se você acabar respondendo a pergunta por si mesmo, é um mau sinal e esperamos que o entrevistado seja capaz de responder aos outros.

Eu sempre gosto de ajudar os entrevistados se eles estão presos em algo simples (como o nome de um determinado padrão, se eles obviamente sabem o que é), e deixar que eles encobrem coisas como os detalhes de estabelecer uma conexão com o banco de dados. Se eles estão tentando projetar algo, no entanto, eu não falo muito porque eu não quero guiá-los ou jogá-los fora se eles estiverem pensando em algo diferente de onde eu estou achando que estão indo.

Eu me lembro de uma questão específica de solução de problemas de um entrevistador que tinha um resultado muito específico em mente, mas ele não conseguiu me comunicar a questão claramente. Isso descreve a situação que muitos entrevistados enfrentam. Às vezes, o olhar vazio não é porque a pessoa não é um bom solucionador de problemas, mas porque a pessoa que faz a pergunta não está sendo clara no que está perguntando. Nesse caso, a abordagem de seu colega de dizer e não fazer nada apenas prova que o candidato não pensa como seu colega ou não está na 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 (a maioria de nós, pelo menos) não trabalha no vácuo, e que as entrevistas são estressantes o suficiente sem limites artificiais, eu estaria inclinado a oferecer tanta ajuda quanto um entrevistado pede ou precisa. / p>

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

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

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

Para "engenheiros de linha", usei a técnica para programar testes em que você fornece ao candidato um computador e um problema e algumas horas, depois você volta. Nessa situação, perguntamos ao solicitante com antecedência quais sistemas operacionais e ferramentas eles preferiam (também uma parte interessante da experiência de um programador). Quando eles terminaram, como 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 eu espero de um engenheiro experiente no primeiro dia.

É importante ressaltar que toda a equipe de entrevistas havia feito 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 ideia de diferentes abordagens.

Esta segunda técnica nos encontrou alguns dos melhores programadores "não cantados" (péssimo currículo, péssimas habilidades de entrevista) que já encontrei.

Eu prefiro começar entrevistas com uma questão simples de confiança para que o candidato se sinta confortável com o processo. Quando isso funciona, ainda permite que você obtenha o máximo de informações possíveis 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 hints durante a entrevista oral ajuda a ver como o candidato entende o (s) tópico (s). No entanto, deve haver no hints nos testes padrão solicitados por cada candidato.

Basicamente, existem two main things que você pode querer saber sobre possíveis candidatos:

a) Características pessoais - ele se encaixa bem na 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 potencial candidato em uma conversa. Também é importante certificar-se de que o candidato é comfortable during the interview para obter o máximo entendimento de suas habilidades atuais (tanto soft quanto de tecnologia), bem como seu potencial para realizar o trabalho.

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

Parte do que deve ser olhado é habilidades de comunicação. Se o candidato não estiver claro sobre a questão, ele deve fazer perguntas para esclarecer. Isso é bom, na minha opinião. Com muita frequência, decisões ruins são tomadas porque certas suposições são feitas ao ler as especificações ou, neste caso, processar uma pergunta da entrevista. O candidato pode responder com base nessas suposições e perder totalmente o ponto pretendido. A questão pode ser falha ou pode ser o candidato. Em ambos os casos, permitir o esclarecimento via comunicação demonstra uma habilidade valiosa, que os empregadores devem procurar.

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

Pessoalmente, eu valorizo a capacidade prática / pragmática em relação a trivialidades acadêmicas / esotéricas. Estou muito mais interessada em um candidato que possa entrar, trabalhar e contribuir efetivamente de alguma maneira valiosa para qualquer projeto (s) para o qual eles estão sendo contratados para trabalhar do que para saber o quão boa é sua memória para a minúcia.

Então, eu treinarei um pouco se o candidato estiver preso a algo esotérico, ou uma nuance raramente usada, ou um caso extremo que pode ser relevante em uma entrevista inventada, mas raramente é relevante na vida real. . Especialmente qualquer coisa que eles pudessem obter com alguns minutos no Google ou com uma referência útil, ou "definir e esquecer" digitar coisas.

No entanto, eu não vou treiná-los no mundo real, comum, mainstream, fundamental, trabalho por dia coisas. Estas são as coisas que eu quero que sejam inatas para elas.

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

Por que posso querer 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 quão bem eles poderiam lidar com o estresse foi um fator crítico em nossas avaliações, então fizemos algumas perguntas extremamente difíceis que ninguém poderia responder sem algum estresse.

Quando estou tentando descobrir seu conhecimento técnico, 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ê tem que perguntar a todos as mesmas perguntas para ser justo, eu acredito que isso é justo, desde que várias condições sejam atendidas. Primeiro, todos recebem a mesma pergunta básica. Em segundo lugar, você não deve fazer perguntas de acompanhamento para ajudar apenas uma pessoa. Se você deixou os outros se debaterem sem ajuda, você precisa deixar todos os solhadores sem ajuda. Em segundo lugar, você deve comparar o desempenho dos candidatos na questão, não apenas em termos de sua resposta final, mas em termos de quão difícil foi arrastá-la para fora deles. Este processo ainda trata todos de forma justa.

Depende do tipo de programador que você deseja. Um introvertido que pode escrever 20 grandes linhas de código no papel ficará bem em seu chefe. Um desenvolvedor de software que pode 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 irá se sair muito bem. Eu adoro esses tipos de entrevistas como candidatas - elas me dizem muito sobre como o chefe trata sua equipe e qual é a cultura de trabalho. Em um caso como este, quando deixei a entrevista, eu disse: "Obrigado - Vamos nos salvar um pouco, se você não me ligar, eu não vou ligar para você". Quando perguntado por que, eu indiquei que não queria trabalhar para uma empresa que me preparou para falhar.

Sua abordagem provavelmente obterá melhores seleções para o desenvolvimento de software. Sua abordagem dos chefes funcionaria bem para os coletores de lixo e para os caras que seguram os pirulitos Stop / Go nos trabalhos na estrada.

O desenvolvimento de software é um esforço de equipe, não um jogo solo / mental / não interativo. Quantos projetos falham porque o software faz o que foi pedido, não o que foi desejado.

Eu estava recentemente em uma situação semelhante. A direção que recebi do meu gerente e do RH foi que precisávamos ser completamente justos com todos os seis entrevistados, então eu 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 com 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 entrevistas após a rodada técnica sobre personalidade e traços comportamentais, se eles conseguiram passar pelo primeiro turno.

Parte do que você quer de um funcionário é alguém que pode interagir com o restante 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 buscar ajuda e que ele tenha autoconhecimento e habilidade social para fazer isso. Este último conjunto de soleiras definirá melhor a empresa a longo prazo do que qualquer Du-jour específico em linguagem de computador.

Do jeito que eu vejo, uma entrevista é uma sessão experimental de coworking, não um teste . Eu estou principalmente tentando responder a pergunta "como é a sensação de trabalhar com essa pessoa?" Às vezes até finjo ter esquecido a resposta da pergunta, para fazer o exercício parecer mais colaborativo.

Você já trabalhou com alguém que você não poderia não entrar na mesma página sempre que você falou sobre um problema? Ou alguém que fez muitas perguntas em vez de entrar e resolver problemas? Em uma entrevista, estou principalmente certificando-me de que a pessoa com quem estou falando não seja uma dessas pessoas. Há um strong elemento de química aí.

No processo, eu também aprenderei coisas como: "ela escreve código limpo", "ela está familiarizada com os conceitos necessários", e "ela pode inteligentemente sugerir um problema para chegar a insights?" O candidato ainda será o único a "dirigir" e escrever código. Mas ao longo do caminho espero que ela esteja mais relaxada e eu vou ver uma versão dela mais próxima do que eu realmente veria no dia a dia como um colega de trabalho.