Como as habilidades usadas nas perguntas típicas da entrevista são aplicadas no trabalho real? [fechadas]

Para trabalhos de desenvolvimento de aplicativos SQL e C #, os entrevistadores geralmente fazem perguntas sobre árvore, gráfico e percursos de lista vinculada usando C e ponteiros puros. Nos 3 anos que passei no meu trabalho, nunca tive que realmente

encontre o caminho para o 1º nó à direita de um determinado nó, que é múltiplo do nó especificado

por exemplo

Percebo que essas habilidades podem ser usadas em trabalhos em que você precisa escrever compiladores, drivers e trabalhar no kernel do SO. Além desses, onde mais essas habilidades são usadas?

Leia algumas das respostas de Joel abaixo.

Observe especialmente algo como Schmiel, o pintor. No trabalho, talvez você nunca precise reescrever uma lista vinculada, mas certamente deve saber por baixo de como funciona, para evitar Schmiel.

Basicamente, se você estiver indo ao médico, gostaria que ele estudasse anatomia. Mesmo que ela esteja apenas prescrevendo um anti-histamínico, um médico terá aprendido na faculdade de medicina que certos medicamentos são ruins para pessoas com 'fraturas crônicas diamadabadas no fêmur inferior' ou qualquer outra coisa. Esse tipo de conhecimento profundo de TUDO nessa especialidade pode às vezes fazer a diferença entre vida e morte e, em Tecnologia da Informação, entre vida e morte do produto, ou um emprego.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... gaste pelo menos um semestre se aproximando da máquina ou você nunca poderá criar código eficiente em idiomas de nível superior. ..."

"... você está programando com base em superstições, no que me diz respeito: um médico que não conhece anatomia básica, distribuindo prescrições com base no que o bebê farmacêutico disse que funcionaria".

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Eles não são. Muitas entrevistas são feitas por pessoas que não sabem como procurar desenvolvedores hábeis e não sabem que perguntas devem ou não fazer.

A maioria dos entrevistadores não faz perguntas técnicas e está mais concentrada em coisas sem sentido, mas mensuráveis , como o número de projetos nos quais você participou (mais é melhor para esses entrevistadores) ou o diploma universitário (maior é melhor para eles ) Eles ficam felizes em contratar uma pessoa que perdeu cinco anos na faculdade aprendendo nada e depois passou dez anos fazendo dezenas de sites de comércio eletrônico, mas não contratará uma pessoa que abandonou a faculdade depois de alguns anos e estava trabalhando em alguns grandes projetos tecnicamente desafiadores.

Fazer pelo menos perguntas teóricas é melhor do que não perguntar. Isso tem o benefício de verificar se a pessoa tem conhecimento teórico suficiente e não é um codificador que pode ter alguns anos de experiência em programação, mas realmente não entende o que está acontecendo sob o capô. Os desenvolvedores que normalmente não possuem esse conhecimento teórico ¹ não sabem a diferença entre uma lista, uma lista vinculada, uma pesquisa ou um conjunto de hash, e os usam de forma intercambiável.

Boas perguntas (técnicas), más perguntas

Durante as entrevistas, você pode encontrar perguntas que variam de muito boas a extremamente ruins:

1. (Nocivo) "Qual é o comprimento em linhas do programa de trabalho mais longo que você escreveu nesse idioma?"

   Esta questão está claramente errada. Eu já expliquei o porquê em outra resposta . A empresa onde os entrevistadores fazem essas perguntas tem grandes chances de avaliar a produtividade dos desenvolvedores em LOC / mês. Se eu tiver que dar um conselho: você não precisa desse emprego.

   Este exemplo é diferente de coisas sem sentido, mas mensuráveis , que citei no início da minha resposta. Aqui, o entrevistador também mostra que ele não tem o entendimento mais básico das métricas escolhendo uma que seja bem conhecida por ser prejudicial.

2. (Ruim) "Quem é Dennis Ritchie?"

   Ter pelo menos alguma cultura é realmente muito útil, mas fazer essa pergunta erra o ponto. Se a empresa procurar desenvolvedores talentosos capazes de lidar com projetos de desenvolvimento de software e escrever código, o fato de eles não saberem o nome da pessoa que criou C e Unix não deve importar muito.

3. (Bom) "Quais são os novos recursos do .NET 4.5?"

   Essa pergunta é muito mais interessante que a de Dennis Ritchie. Se o candidato não pode falar sobre novos recursos no .NET 4.5, por que ele se chama desenvolvedor de C #? A falta de tal conhecimento:

   • Mostra que a pessoa pode não estar realmente interessada nem na linguagem de programação nem na comunidade .NET,

   • Indica que a pessoa pode não ter um conhecimento crucial sobre os recursos do C # /. NET que outros desenvolvedores usam, se não diariamente, pelo menos com frequência.

   Veja também a resposta de Jerry Coffin, que contém uma análise mais detalhada desse tipo de pergunta.

4. (Média) "Qual é mais rápido, SSD ou RAM?"

   Isso pode ser útil e mostra se a pessoa tem conhecimento de hardware suficiente, mas ainda assim, um candidato que não pode responder a essa pergunta não deve ser rejeitado.

5. (Média) "Como a pilha e a fila são implementadas?"

   Este é o tipo de perguntas sobre o qual você fala. Eles são teóricos, talvez até teóricos demais, mas saber o que está acontecendo nos bastidores pode ajudar a escrever um código melhor.

   Eu não rejeitaria um candidato que não pode responder a essa pergunta, mas verificarei com mais cuidado se ele realmente conhece o assunto, por exemplo, fazendo uma pergunta relacionada, mas menos teórica:

6. (Bom) "Como você pode andar por uma árvore sem usar recursão?"

   Se o candidato responder a essa pergunta, falando sobre o FILO / FIFO e sobre os benefícios e as desvantagens de usar uma pilha versus uma recursão para o deslocamento em árvore, não importa realmente se ele não conseguiu responder à pergunta anterior.

   Fazer essa pergunta também é uma boa maneira de detectar candidatos que passaram anos cursando o ensino médio, mas não têm experiência de campo.

Como fazer boas perguntas técnicas?

O comentário de kojiro é interessante e merece uma resposta mais longa:

Às vezes, você precisa contratar alguém precisamente porque ele deve saber mais sobre um assunto do que você; portanto, por definição, você está subqualificado para fazer a entrevista. Você não pode obter ajuda confiável mesmo fazendo a entrevista pelo mesmo motivo. O melhor que você pode fazer é tentar fazer perguntas com base em onde seu entendimento se cruza com o domínio do problema e espero que você tenha sorte.

Encontrar boas perguntas pode ser desafiador, especialmente quando você contrata seu primeiro desenvolvedor ou quando você contrata um desenvolvedor que se espera mais qualificado do que todos os desenvolvedores que realmente trabalham na empresa.

Aqui estão três dicas que podem ajudar:

1. Encontre um amigo / colega que você acredite ser qualificado e peça que ele faça as revisões. Isso requer muita confiança, mas pode beneficiar muito sua empresa.

2. Encontre um consultor que acredite ser qualificado e peça que ele o ajude ou faça a parte técnica da entrevista.

3. Digite "perguntas da entrevista" no Google. Funciona muito bem e geralmente explica respostas possíveis. Exemplo:

   • Python : essas dez perguntas parecem muito boas. Eles são talvez um pouco básicos, mas ajudarão a filtrar 95% dos candidatos que você não deseja contratar.

   • SQL de Dave Pinal, excelente como de costume.

   • C # : um pouco básico demais, mas, novamente, eles filtram 95% de candidatos,

   • JavaScript : as perguntas são mais abertas, o que pode não ser bom para perguntas técnicas, se você deseja que a entrevista seja curta e mantenha mais tempo para perguntas não técnicas abertas. A lista ainda ajuda a filtrar facilmente os candidatos que não entendem os conceitos básicos em JavaScript.

   A desvantagem dessa abordagem é que o candidato pode usar a mesma técnica para treinar para a entrevista. Se ele revisou todas as perguntas do primeiro site encontrado no Google, ele pode ter uma boa pontuação, sem ter as habilidades necessárias.

^{Some Existem alguns desenvolvedores que não serão capazes de explicar o que é uma árvore B (exceto que é "alguma estrutura de dados"), mas ainda são capazes de se desenvolver corretamente.}

Da minha experiência em minha empresa, onde fiz muitas entrevistas, há uma boa chance de a pessoa entrevistada não ter idéia de como fazer isso corretamente. Então, eles prepararam um conjunto de perguntas técnicas, calcularam uma pontuação e fizeram disso seu currículo. No entanto, isso tem muitas desvantagens e não deve ser feito pelos seguintes motivos:

• Você pede conhecimento pontual. Se o programador nunca fez algo nessa área, ele ainda pode ser um excelente colega de trabalho, mas simplesmente não conhece essa resposta específica. Por outro lado: se alguém se preparou para a entrevista e encontrou a resposta para essa pergunta específica na rede, você obtém a resposta certa, mas essa pessoa pode não ter idéia do tópico real.

• As pessoas estão nervosas nas entrevistas de emprego. O cérebro tem esse ótimo recurso para desligar muitas áreas de nível superior (como a lógica) se estiver em pânico, o que significa: se você estiver nervoso, poderá não fornecer a qualidade das respostas que faria em uma situação cotidiana. Algumas pessoas podem lidar com uma situação estressante como uma entrevista, muitas não conseguem.

• Com uma resposta única e correta, você testa as habilidades dessas pessoas para encontrar essa resposta específica. Essa é uma das muitas habilidades que um colega de trabalho precisa, mas não a única e única necessária. Portanto, uma ou duas dessas perguntas devem ser suficientes para testar essa área do conhecimento e, em seguida, outras habilidades devem ser consultadas. Uma entrevista que contém apenas perguntas para solucionar problemas testa a mesma habilidade repetidamente.

Quais são as perguntas sobre as boas tarefas de programação?

As famosas perguntas "Você pode escrever um programa curto" têm o enorme problema de que a maioria dos programadores não consegue escrever uma única linha de código sem que o IDE os ajude. Mas isso não é problema nas situações do dia-a-dia, porque o programador sempre tem seu IDE ajudando-o. Então, perguntar coisas como "Encontre o erro", "Escreva 50 linhas de código que funcionem ..." ou até mesmo perguntas simples precisam levar em conta, para que o solicitante não tenha suas ferramentas (IDE, Google) disponíveis.

Por exemplo, posso responder a você basicamente qualquer pergunta em um minuto, se o Google estiver me ajudando, mas sem conexão à Internet, pareço desamparado. Eu chamo isso de memória terceirizada e, em vez de me atrapalhar, me ajuda muito a focar no que é realmente importante - entender a mecânica subjacente - porque todo o resto pode ser procurado. Mas não me pergunte sobre os detalhes de nenhuma API aleatória, porque não os conheço, tenho o Google para isso.

Dito isto, uma boa questão de tarefa de programação não deve se concentrar em conhecer APIs ou em habilidades especiais de codificação, a menos que este seja um requisito absoluto para o trabalho. O conhecimento pode ser adquirido, portanto, é melhor descobrir o quanto essa pessoa é boa em adquirir conhecimento do que perguntar o que ela já sabe.

Uma boa pergunta para uma tarefa de programação deve ser curta, simples, capaz de ser codificada em todas as linguagens com apenas algumas linhas de código e, principalmente, deve informar o máximo possível sobre como a pessoa trabalha e encontra respostas. Exemplo:

"Escreva uma função no idioma de sua escolha que pegue uma matriz de números inteiros e reordene-os de uma maneira que o primeiro inteiro seja depois o último e todos os outros mudem de acordo."

O primeiro que qualquer candidato deve perguntar neste momento é: "Desculpe ... você pode explicar a tarefa?". Porque nenhum programador recebeu uma descrição clara do que fazer. Isso é seguido pela explicação de que o código nas perguntas deve fazer um deslocamento para a esquerda do conteúdo da matriz com o excesso sendo adicionado à direita.

Essa tarefa é tão simples que qualquer pessoa que se formou em qualquer forma de nível de programação deve responder adequadamente. Isso leva em consideração que o programador precisa trabalhar sem suas ferramentas e que ficar nervoso reduz a capacidade de pensar logicamente. No entanto, ele ainda mostra como as pessoas resolvem os problemas da maneira como a pergunta é formulada e da maneira como as pessoas a abordam, simplesmente porque um desvio à esquerda é contra o instinto comum da "esquerda para a direita" e obriga as pessoas a pensar em um segundo.

Há muitas respostas possíveis para essa pergunta, portanto, examinar atentamente a maneira como o código é desenvolvido é a parte importante, não se a solução realmente funcionaria. O candidato testa nulo? Como o estouro é armazenado? É usado um loop ou um conjunto de memórias? Como o candidato verifica a correção do código? Esta pergunta simples mostra uma biografia inteira sobre como essa pessoa trabalha.

Quais são as boas questões de conhecimento geral?

As boas perguntas são fáceis de responder, permitem uma grande quantidade de respostas (chamadas de 'perguntas abertas') e permitem que você aprenda o máximo possível sobre o candidato, no menor tempo possível.

Exemplos:

(Perguntando a um programador de C ++): "Quais outras linguagens além de C ++ você conhece?"

Esta é uma pergunta de nível de entrada, que oferece ao candidato uma chance justa de resgatar neste momento, caso ele não saiba nada sobre o tópico solicitado. Um 'não' neste momento é melhor do que atormentá-lo com várias outras perguntas que ele / ela precisa responder: "Desculpe, não sei nada sobre isso."

Além disso, ele diz em primeiro lugar quais outras linguagens essa pessoa conhece, além disso, você aprende o quanto essa pessoa está interessada em ter uma visão mais ampla do mundo da programação ou se você tem alguém com apenas uma linguagem singular (e, portanto, recursos / técnicas ) Visão.

(Em seguida, digamos que ele conhece Java): Quais são as três principais diferenças entre C ++ e Java em sua opinião? "

Esta é uma pergunta aberta que permite muitas respostas, para que o candidato tenha uma boa chance de encontrar pelo menos três. Solicitar os três primeiros (opinião pessoal) não apenas limita as respostas possíveis, mas também força o solicitante a classificar com base na prioridade. Ainda assim, é (ou deveria ser) fácil de responder.

Essa é uma pergunta simples que testa muito conhecimento profundo sobre diferentes linguagens de programação. Qual é a profundidade do conhecimento desses tópicos? A partir dessas respostas, você pode dizer muito sobre o conhecimento e a compreensão real da mecânica subjacente das linguagens de programação. Quanto essa pessoa gastou com os detalhes sujos ou se é apenas alguém que vincula várias funções da API sem nenhuma pista real do que acontece por baixo delas.

Esse conceito de perguntas básicas, seguido de perguntas simples e aprofundadas, também pode ser usado para a maioria dos outros tópicos. Sempre neste esquema: pergunta de resgate, pergunta de verificação, pergunta detalhada. Outro exemplo (de uma entrevista em Java):

1. "Como você classificaria sua experiência com desenvolvimento multiencadeado?"
2. "Cite o que você acha que são as três principais coisas mais importantes a considerar ao desenvolver um aplicativo multiencadeado".
3. "Indique três classes da API Java que podem ajudá-lo no desenvolvimento desses aplicativos e faça uma breve descrição sobre o que eles são usados."

Essas três perguntas informarão mais do que qualquer pergunta técnica sobre o que o candidato realmente sabe sobre esses tópicos, ao mesmo tempo em que é justo responder considerando o conhecimento pontual e o nível de estresse.

Portanto, da próxima vez que alguém fizer 20 perguntas de codificação em sequência, você saberá que ele ou ela não tem basicamente idéia de como entrevistar alguém adequadamente. ;)

Aviso: isso está escrito como (meio que) um comentário na resposta da @ MainMa, mas 1) é muito longo para caber em um comentário e 2) acho que adiciona uma perspectiva um pouco diferente sobre questões construtivas, por isso é uma resposta real em si .

Em sua resposta, o @MainMa classifica "Quais são os novos recursos do .NET 4.5?" como uma pergunta "boa".

Eu peço desculpa mas não concordo. Como ele disse, eu diria que essa é uma pergunta bastante medíocre na melhor das hipóteses. Uma boa pergunta seria mais como: "Como o código que você escreve hoje difere do código que você escreveu N anos atrás?" (para um valor de N inferior aos anos de experiência listados no currículo, de preferência em torno de 3 a 5).

Como ele disse, a pergunta é sobre memorização. Esse candidato memorizou a lista de recursos completamente? Por direito, quem citar a lista da Microsoft com mais precisão deve ser o vencedor.

Você deve se preocupar com a programação dele. Como isso afetou seu código? Quais desses recursos ele realmente usa ? Mais importante ainda, ele demonstra bom senso sobre quando usar quais novos recursos e quando os mais antigos bastam perfeitamente?

Apenas poder dizer "LINQ" não diz praticamente nada de útil sobre o candidato. Ser capaz de dizer: "O LINQ ajudou a tornar meu código muito mais compacto e legível, porque eu posso expressar os conceitos X, Y e Z de maneira limpa e direta, onde anteriormente eu tinha que pular os seguintes aros flamejantes para fazer essas coisas". (ou algo semelhante) diz muito sobre o candidato, que tipo de código ele escreve, seu julgamento, flexibilidade e assim por diante. Também oferece muito mais oportunidades para perguntas de acompanhamento sobre como essa pessoa pensa em problemas, escreve código, pensa em código e assim por diante. Por fim, você tem uma idéia muito melhor se este é um candidato que realmente tem N anos de experiência ou alguém que tem um ano de experiência, repetido N vezes.

Resumo: ser capaz de citar uma lista de recursos de alguns anos atrás é inútil e fala pouco sobre o candidato que provavelmente será útil. É provável que o progresso do candidato como programador seja de muito mais interesse, por isso é muito melhor perguntar sobre isso mais diretamente.

A realidade é que a maioria das tarefas cotidianas que a maioria dos desenvolvedores realiza em sua vida profissional é trivial; Isso significa que algumas das perguntas que você enfrenta em uma entrevista de emprego podem nunca enfrentá-lo na realidade, mas isso não significa que não há sentido em fazer essas perguntas.

Digamos que exista uma posição aberta em sua empresa e você esteja entrevistando pessoas. Você já tem de 20 a 30 desenvolvedores na fila. Então, como você escolheria o melhor candidato para essa posição? Digamos que a tarefa mais desafiadora que eles tenham realizado nesse trabalho seja abrir um arquivo do sistema de arquivos, ler os dados linha por linha, modificá-lo levemente e modificá-lo e colocá-lo novamente no arquivo original.

Você vai perguntar a eles como você abriria um arquivo? Aposto que você não vê uma grande diferença entre as respostas. Portanto, você precisa encontrar uma solução para distinguir entre os desenvolvedores que sabem apenas abrir um arquivo e os que podem desenvolver um aplicativo em tempo real. Mesmo que você não queira que eles criem esse aplicativo, ainda assim você deseja contratar o melhor candidato.

Como qualquer outra coisa em nossa vida, há alguns pontos em que você percebe que precisa ir e aprender mais. Se você não sabe o que é uma lista vinculada, para mim como programador, isso significa literalmente que você realmente não alcançou esse ponto da sua vida profissional para sentir que precisa ir e aprender algo específico. Por quê? Simplesmente porque você nunca se envolveu em um projeto grande o suficiente para exigir que você aprimore suas habilidades até esse nível. Se você está no nível básico, pode dizer que eu realmente não tenho nenhuma experiência de trabalho para este trabalho específico, mas mesmo assim, se você souber, isso significa que você é motivado o suficiente para se colocar acima da média finalmente.

As habilidades necessárias para realizar essas tarefas raramente são importantes. As habilidades demonstradas na abordagem para responder à pergunta e no diálogo subsequente são o ponto principal.

Quando entrevisto os desenvolvedores, procuro (a) o inteligente (b) realiza as tarefas (c) se encaixam. Existe um nível básico de conhecimento técnico necessário para desempenhar qualquer função, o que tem a ver com a vontade de aprender e adquirir novos conhecimentos. Habilidades. A entrevista é sobre marcar essas caixas.

Minha preferência é ler o código escrito por um candidato. Não gosto de perguntas de entrevistas enlatadas, mas elas fornecem algo para falar na ausência de código. Prefiro perguntar sobre RAII ou COI ou a implementação de IDisposable, em vez de lista e coleções, mas qualquer coisa será útil , desde que seja técnico o suficiente .

O pior medo do entrevistador é contratar alguém que realmente não sabe muito sobre codificação. Você precisa falar sobre algo que não seja a experiência profissional para eliminar as falsificações.

Essas perguntas são para selecionar pessoas que não podem programar. Às vezes, as pessoas que não conseguem programar, mas conhecem muitas curiosidades, se candidatam a empregos de desenvolvimento, e tê-las a escrever algo útil e não trivial consome muito tempo para uma entrevista.

Percebo que essas habilidades podem ser usadas em trabalhos em que você precisa escrever compiladores, drivers e trabalhar no kernel do SO. Além desses, onde mais essas habilidades são usadas?

Que tal escrever mecanismos de pesquisa, servidores da Web, navegadores da Web, processadores de texto, planilhas, editores de imagens, programas de desenho, servidores de banco de dados, bioinformática, programas de negociação, jogos, simuladores de física etc.

Concedo a você que a maioria dos trabalhos de software envolve extrair dados de um banco de dados, colocá-los em uma tela, editá-los, raspá-los e retirá-los em um banco de dados. No entanto, mesmo assim, você pode eventualmente encontrar um aplicativo em que as restrições não podem ser satisfeitas pelos recursos internos de uma plataforma. Nesse ponto, você pode desistir ou acessar sua caixa de ferramentas de algoritmos e estruturas de dados e tentar resolver o problema.

Objetos teóricos são usados ​​por conveniência, porque você sabe o que é uma implementação média de árvore / gráfico / lista e, portanto, sabe como resolver um problema transversal aleatório, mas essas perguntas não são sobre os objetos teóricos.

Eles são capazes de trabalhar com um modelo abstrato, entender um problema abstrato e resolvê-lo com um algoritmo de qualquer tipo. Isso é pura habilidade de desenvolvimento, portanto, com certeza conta. É por isso que essas perguntas fazem sentido, não porque devem ser situações precisas da vida real.