Por que as entrevistas de engenharia da SW são desproporcionalmente difíceis (vs. entrevistas de pesquisa)? [fechadas]

Primeiro, algumas informações sobre mim. Eu tenho um doutorado em CS e tive trabalhos tanto como engenheiro de software quanto como cientista de pesquisa e desenvolvimento, ambos em empresas muito grandes que você conhece muito bem. Recentemente, mudei de emprego e entrevistei os dois tipos de cargo (como fiz no passado).

Minha observação: as entrevistas de emprego de engenheiro de SW são muito, muito mais difíceis do que as entrevistas de pesquisador de CS, mas o trabalho de pesquisador é mais bem remunerado, mais competitivo, mais gratificante, mais interessante e tem uma vantagem maior.

Aqui está um ciclo de entrevista típico para o pesquisador:

• Entrevista por telefone para ver se minha pesquisa está alinhada com a pesquisa do laboratório
• Pessoalmente: faça uma apresentação sobre minha pesquisa recente por uma hora (o que representa um trabalho de talvez 9 meses) e responda a perguntas da platéia
• Entrevistas individuais com cerca de 5 pesquisadores, nas quais eles me fazem perguntas razoáveis ​​sobre meu trabalho / publicações / patentes, incluindo: perguntas técnicas, onde meu trabalho se encaixa em trabalhos relacionados e como posso estender meu trabalho para novas áreas

Aqui está um loop de entrevista típico para o engenheiro de software:

• Entrevista por telefone, onde são feitas perguntas sobre algoritmos e talvez fazer alguma codificação. Bastante padrão.
• Entrevistas presenciais no quadro branco, onde eles analisam o F *** em minúcias esotéricas em C ++ (por exemplo, como funciona uma chamada de função virtual polimórfica), algoritmos (fazem o algoritmo de caminho mais curto de todos os pares funcionar para vértices 1B) , design do sistema (projetar um balanceador de carga de banco de dados) etc. Isso ocorre por seis ou sete entrevistas. Ridículo.

Por que alguém estaria disposto a suportar isso? Qual o sentido de perguntar sobre trivialidades em C ++ ou escrever código para provar a si mesmo? Por que não tornar a entrevista SE mais parecida com a entrevista do pesquisador, onde você fala sobre o que fez?

Como são as entrevistas técnicas de trabalho para outros campos, como física, química, engenharia civil, engenharia mecânica?

É relativamente fácil estabelecer se você é tecnicamente competente o suficiente para fazer a pesquisa - você tem publicações que os gerentes de contratação podem ler e essas publicações provavelmente sugerem outras pessoas com quem podem conversar para verificar você.

A engenharia de software, por outro lado, é uma disciplina tão cheia de desperdícios de espaço incompetentes que é preciso fazer muita diligência para garantir que o cara que você está contratando possa de fato escrever o código que planeja contratá-lo para escrever.

Sair em um membro aqui.

Como pesquisador com doutorado, você já provou para várias organizações reconhecidas seu valor e qualidades mínimas como pesquisador. Você defendeu com sucesso uma tese na frente de um conselho de seus colegas e convenceu pelo menos uma publicação revisada por pares a publicar seu trabalho.

O desenvolvimento de software, por outro lado, não possui padrões de qualificação. As pessoas costumam inflar sua base de conhecimento. Como resultado, as entrevistas de desenvolvimento de software precisam fazer todo o trabalho que a defesa de PhD e a revisão por pares fazem na academia. Eles fazem você provar que realmente sabe do que está falando.

Considere isso por um momento.

Se eu tentasse me candidatar a este trabalho de pesquisador em CS, não veria meu currículo / currículo. Eu não chegaria a uma entrevista em primeiro lugar. Recebia uma carta padronizada de "sem diploma avançado" dizendo que eu nem estava qualificado para examinar meu currículo.

Minhas perguntas são: "Por que é tão difícil conseguir um doutorado?" E "Por que eu preciso de um PhD para ser pesquisador de CS?" "Por que tantas barreiras e obstáculos?"

Por que alguém estaria disposto a suportar isso?

Qual é o sentido de fazer todo esse trabalho do curso e imprimir pesquisas em periódicos e conferências? Por que não posso simplesmente fazer a pesquisa e receber mais do que pago pela engenharia?

Por que contar com escolas de pós-graduação e publicações para estabelecer credenciais? Por que não tornar a entrevista de pesquisa mais parecida com as entrevistas de SE, onde tudo depende do que você pode se lembrar agora durante a entrevista?

Bem, eu tenho uma teoria. A pesquisa normalmente é paga por doações, portanto a oferta de dinheiro é alta. Eles têm um balde de dinheiro para gastar e só precisam encontrar alguém para gastá-lo. Independentemente de você realizar algo nessa posição ou não, a empresa / instituição não registra uma perda líquida porque, de qualquer maneira, era apenas uma despesa contabilizada. Há pouco risco em contratar a pessoa errada. O pior cenário é que eles jogam fora tudo o que você fez.

Por outro lado, o sucesso ou fracasso dos produtos existentes repousa sobre os ombros dos desenvolvedores do dia-a-dia. Especialmente se você estiver no desenvolvimento de produtos, é um centro de lucro para a empresa. Desenvolvedores bons ou ruins têm um enorme impacto que está muito além do custo de seu salário. Um desenvolvedor ruim realmente causa danos. Eles podem atrasar uma equipe, lançar um produto etc. As consequências de contratar um engenheiro de SW ruim são muito maiores.

Nossa empresa também "faz muitas perguntas difíceis" e eu explicarei o porquê. Nós nos importamos se você realmente sabe como uma chamada de função virtual é feita, mas não porque é tão criticamente necessária para o trabalho que você fará.

Em vez disso, nos importamos porque precisamos saber com que rapidez você pode aprender coisas fundamentais. Você reivindica X anos de experiência? Ok, faremos perguntas difíceis para descobrir se você tem um conhecimento sólido.

Você não sabe como é feita uma chamada de função virtual, mas sabe tudo sobre criação de perfil e otimização? Ótimo, provavelmente o contratamos - você adquiriu conhecimento sólido em um campo e, com certeza, adquiriu conhecimento sólido em outro.

Você afirma X anos de experiência "desenvolvendo, depurando e corrigindo código C ++" e não pode explicar em palavras simples como um ponteiro aponta para um objeto? Desculpe, não podemos contratar você - se você não pode fazer isso, como explicará problemas mais difíceis quando precisarmos tomar decisões técnicas complexas?

Resposta curta: existem muitas pessoas no mercado que afirmam conhecer programação, mas não podem programar.

Observação: Estou surpreso que ninguém postou um link para o ensaio do FizzBuzz .

Vou seguir um caminho diferente e dizer que o problema pode não ser tanto que as entrevistas de engenharia de software sejam inerentemente mais difíceis, mas que setores diferentes estejam procurando coisas diferentes que sejam mostradas em seu estilo de entrevista.

Eu entrevistei em uma ampla gama de setores (por exemplo, empresa iniciante, pequena empresa, grande empresa, departamento interno de TI, empresa de software, organização de pesquisa) e todos eles têm uma maneira diferente de entrevistar que, geralmente, tende a siga o seguinte padrão:

• As empresas iniciantes tendem a se preocupar em saber que você pode começar a escrever código agora e lidar com um ambiente de ritmo acelerado. Como tal, eles tendem a se preocupar com o quanto você sabe de antemão, pois aparentemente eles não querem que você gaste muito tempo procurando o que eles consideram ser o conhecimento "central". Admitir que você não sabe que algo pode não ser uma coisa tão boa nesse ambiente, se é algo que eles esperam que você saiba.
• As pequenas empresas tendem a procurar as mesmas coisas que as start-ups em relação ao quanto você sabe, mas não estão tão preocupadas com o quão bem você lida com ambientes de ritmo acelerado (depende do trabalho) e mais com que tipo de habilidades sociais você trazer e quão bem você vai se encaixar na sagacidade da empresa.
• As grandes empresas e os departamentos internos de TI parecem estar mais preocupados em garantir que você tenha um determinado padrão de conhecimento técnico, mas não estão tão preocupados se não souberem tudo o que está pensando, pois antecipam que haverá algum tempo envolvido em treiná-lo sobre o que a empresa espera. Portanto, este é um ambiente em que admitir que você não sabe algo, mas está disposto a aprender e estudar pode ser visto como um benefício.
• No ambiente de pesquisa (isto é, suporte ao desenvolvimento de software para cientistas na minha experiência), eles tendem a se preocupar se você pode escrever software, mas mais ainda se você estiver disposto a fazer o que é necessário para garantir que você possa aprender o que eles estão fazendo. eles não precisam segurar sua mão enquanto você tenta resolver um problema. Como também é um ambiente de pesquisa, eles também parecem interessados ​​em saber como você está interessado em aprender coisas novas.

Agora, deixei de mencionar as empresas de software (ou seja, Google, Microsoft), pois elas tendem a fazer suas próprias coisas e, dependendo da maturidade da empresa e de qual grupo você está entrevistando, elas estão procurando coisas diferentes.

No final do dia, porém, e como na maioria das coisas na vida, tudo depende. Pessoalmente, descobri que algumas empresas se concentram muito no "conhecimento do livro", que pode custar a capacidade de realmente resolver os problemas de nível superior, enquanto outras empresas parecem estar muito preocupadas com a forma como você lida com os problemas de nível superior. (ou seja, você pode projetar um esquema para x ) e operar com a premissa de que eles estão dispostos a investir de três a seis meses para que você se mantenha totalmente atualizado antes que seja totalmente produtivo.

Sou desenvolvedor de software (c / c ++) com mais de 20 anos em campo. O tipo de entrevista que costumamos ver agora (quebra-cabeças, implementação de estruturas de dados, algoritmos de busca etc. no quadro branco) não costumava ocorrer muito, exceto para os recém-formados. Se uma pessoa trabalhava para uma empresa respeitável por um período de tempo razoável, isso era considerado prova de sua capacidade de escrever código. Agora tornou-se muito escolar e não sei porquê. Realmente, as coisas típicas que eles pedem para codificar PODEM ser memorizadas, de modo que fazê-lo no quadro branco realmente não prova nada. Em um projeto de trabalho, você usaria a Internet para pesquisar alguma coisa e não estaria escrevendo btrees ou listas vinculadas do zero.

Eu acho que é outra moda de gerenciamento - assim como o scrum - com este provavelmente sendo iniciado pelo google, amazon e microsoft. Todos os outros copiaram exatamente como fizeram com o posto de Jack Welch e puxão ... lembra da GE?

Se você é um gerente de contratação que está lendo meus comentários, o que você DEVE estar perguntando aos candidatos é como eles resolveriam certos problemas. Em vez de pedir que codifiquem uma tabela de hash, dê a eles um problema envolvendo uma tabela de hash e pergunte como eles a resolveriam.

Também concordo com o desenvolvedor acima deste post, que disse: "dê a eles um problema do mundo real que a empresa teve que resolver"!

"mas eu tenderia a bombardear as perguntas de OOP / Herança. Por quê? Como uma vez que o suporte a modelos foi adicionado, usei C ++ quase exclusivamente para Programação Genérica".

Eu também concordo com o acima exposto. Quando você trabalha para uma empresa, escreve o código DA SUA maneira. Às vezes, ainda luto para lembrar da chamada C ++ por sintaxe de referência, porque o arquiteto sênior da empresa em que trabalhei 15 anos preferiu usar ponteiros, não referências. Ele era um velho programador C, você vê. Então é isso que todos nós usamos.

Novamente, as entrevistas técnicas são arbitrárias e caprichosas.

Há uma grande diferença entre grelhar uma pessoa nas minúcias e ver se ela conhece o seu CS. Como eu disse acima, tenho mais de uma década de experiência com C ++, mas eu tenderia a bombardear as questões de OOP / Herança. Por quê? Como o suporte a modelos foi adicionado, usei C ++ quase exclusivamente para programação genérica. .

Eu entrevistei várias empresas BigHouseHoldNameTech na área de Bay e Seattle, e uma das melhores entrevistas envolveu perguntas reais com as quais eles tiveram que lidar no trabalho, envolvendo estruturas e algoritmos de dados [ou seja: você tem 300 bilhões de pontos de dados consistindo em XYZ. Como você armazena e pesquisa com eficiência?]

Isso mostra como um candidato pode intervir e ajudar a resolver os problemas reais que você está enfrentando. O pior foi também com outra empresa da BigHouseHoldNameTech, mas eles fizeram horas de perguntas incrivelmente misteriosas que você realmente deveria procurar em um manual [ ou seja, descreve as principais diferenças entre o PCB no Windows e o Linux - e isso não era ' t para uma posição no nível do kernel ]

Os fundos de hedge são bizarros com a intenção de torturar ... esperam 8 horas resolvendo problemas do tipo mochila em um quadro branco.