Qual é o objetivo dessas perguntas detalhadas da entrevista técnica para o desenvolvedor sênior? [fechadas]

Eu tive uma entrevista de promoção interna para ganhar um título de programador de nível superior, algo como Senior plus. E eu fui entrevistado por cerca de 7 pessoas usando tecnologia diferente, e as pessoas que usam a mesma tecnologia comigo (.Net) tendem a fazer perguntas muito técnicas detalhadas que podem ser facilmente encontradas no Google, como o JIT, como o GC funciona , diferença entre Lista e Matriz, classe abstrata e interface, delegado e evento, até qual é o nome da classe quando você processa Carregar arquivo, etc. E eu tenho apenas uma pergunta sobre uma das minhas idéias de design no meu projeto e apenas discussão simples. Mas para a maioria das outras opções de design, elas parecem não estar interessadas.

Ainda não recebi o resultado e já seria tarde desta semana, mas aqui está a minha preocupação:

Pessoalmente, acho que quando jogo como programador sênior, resolvo principalmente problemas, e só preciso saber que existe alguma maneira de fazer isso acontecer, mas talvez não me lembre de tudo, e é por isso que temos essas referências detalhadas documentação como o MSDN.

Eu me sinto bem se você descobriu que não tenho muitas experiências nessa área, como Junior a Intermediário, mas quando tende a entrevistar um cara de nível superior, você não deve se concentrar mais para ver como esse pensamento lógico é e como é bom ele / ela está resolvendo problemas? Todo mundo pensa se você conhece todos os detalhes técnicos de pequenos pontos, então você é um Senior +. E, verificando os livros de perguntas das entrevistas, descobri que existem mais tipos de perguntas.

Se eu passar cinco dias examinando o livro de perguntas da entrevista, posso facilmente fazer esses caras se sentirem impressionados, mas isso realmente significa alguma coisa? Esse tipo de entrevista pode facilmente deixar aqueles caras bons em lembrar que as coisas ganham salários mais altos, mesmo que não tenham idéia de como resolver o problema da dificuldade.

Então, por que isso está acontecendo no mundo, é que apenas causa habilidades de resolução de problemas, é difícil medir as habilidades de design? Eu sirvo esta empresa há anos e só tive poucas entrevistas com outras empresas, então eu me pergunto se todas as empresas estão fazendo a mesma coisa?

Ou isso é realmente apenas o meu próprio problema, que eu deveria me esforçar mais para lembrar de tudo no MSDN em minha mente para poder trabalhar mesmo sem ele e com a Internet?

EDITAR

Para melhor explicar minha situação em relação à preocupação de Frank com as tarefas do trabalho. Desculpe, mas o meu mal não esclareceu esses antecedentes.

Na verdade, não haverá mudanças específicas nas tarefas do trabalho. Pessoalmente, acho que o que fiz já joguei como sênior, como revisão de código, membros mentores, revisar o documento da BA e dar opiniões técnicas, projetar arquitetura de novos projetos; esse é apenas o meu título permaneceu sem sénior e pedi que um refletisse o recibo de vencimento e levasse a essa entrevista. Essa é uma empresa da Saas, para que as pessoas permaneçam em um projeto enquanto esse produto ainda estiver vivo, o que leva a que elas precisem que as pessoas sejam capazes de projetar mais recursos novos com base no produto atual, corrigindo dificuldades técnicas em servidores ativos, design / revisão de código / mentoria members E um título de nível superior baseado na técnica seria Architect e não temos nenhum trabalho semelhante ao Technical Expert. E eu concordo que, se você quiser desempenhar a função de especialista técnico, deve saber mais detalhes sobre a tecnologia usada. Desculpe, mas o meu mal não esclareceu esses antecedentes.

Como engenheiro sênior e pessoa que contrata engenheiros, parece que o processo de entrevista perdeu toda uma faixa de informações conceituais.

Desejo que meus engenheiros seniores sejam capazes de visualizar um resultado final, escolher a tecnologia certa, projetar o banco de dados e processos corretos e delegar os detalhes a outros engenheiros quando necessário. O Google está sempre do lado deles, então eu me concentro na capacidade deles de fornecer resultados, em vez do tamanho de um cartão SD que eles conectam ao ouvido. (ri muito).

Espero que funcione bem.

Não está totalmente certo o que as tarefas de um Senior + no seu caso envolveriam. Lembre-se sempre de que é muito mais importante saber quais são as tarefas do seu trabalho e não como é chamada a sua posição. Embora ter um Sênior na frente do seu cargo possa ter um impacto no seu resultado financeiro, ele não diz nada sobre o que você realmente faz no seu trabalho. No entanto, existem dois tipos diferentes de "desenvolvedores" de nível sênior.

Arquiteto de Sistemas

Se você foi entrevistado para essa posição, de fato algo está errado. Concordo com o gahooa que essa entrevista deve se concentrar no pensamento geral do candidato, que parece ter faltado no seu.

Há, no entanto, também o tipo de perspectiva maligna sobre isso: no trabalho cotidiano, você sempre ficará impressionado com esses pequenos detalhes e será sua a responsabilidade acompanhar o cenário geral, apesar de todos esses pequenos distúrbios. Se você quiser testar se um candidato é capaz de não se perder nos pequenos detalhes, uma maneira pode ser apenas tentar afundá-lo nesses detalhes. Se você não lembrou a eles que a posição da arquitetura prevista é sobre o cenário geral - você pode ter acabado de falhar nesse teste. Embora eu duvide disso, como esse tipo de entrevista certamente não é do lado amigável das coisas.

Técnico especializado

Nesse caso, talvez você não consiga influenciar muito a arquitetura geral do sistema e a direção da empresa. Em vez disso, você se concentrará no nível do design. Observe que todas as perguntas que você deu como exemplos se encaixam perfeitamente nessa categoria. De um desenvolvedor sênior responsável pelos projetos de SW, espero que ele saiba coisas como JIT, GC, estruturas de dados, etc., dentro e fora - sem precisar procurar nada além dos detalhes mais complexos. Se você deve criar um design de software, ainda não sabe a diferença entre uma matriz e uma lista, está na posição errada.

Ao ler sua pergunta, suspeito que seu cargo (atual e proposto) se concentre no design de software. Nesse caso, convém repensar o que realmente deve saber / lembrar e o que não deve. Dado que você trabalha com essas coisas dia a dia, deve haver pouca necessidade de procurar algo para responder perguntas elementares como essas.

Em uma nota lateral: um ex-professor meu tinha o hábito interessante de fazer perguntas sobre disciplinas elementares em exames orais em cursos avançados. Embora esses assuntos nunca tenham sido explicitamente abordados no curso avançado, um aluno deveria conhecê-los desde o ensino fundamental. Nas entrevistas (de qualquer tipo), eu também aderi a esse comportamento, porque, nos últimos anos, tenho testemunhado repetidamente como estudantes / candidatos a algo "avançado" têm uma falta grave em relação aos fundamentos. Dado esse raciocínio, eu não tenho escrúpulos em pedir a um candidato para uma posição sênior o que é um padrão de ouvinte ou quais são os prós / contras de manter os ouvintes em uma matriz versus lista versus conjunto.

Sinto muito, mas não acho que o tipo de perguntas que você fez seja trivial e que deva ser pesquisado no Google quando necessário. Isso pode ser verdade para o nome da classe quando você processa o upload de arquivo, mas:

• o que é JIT: Essa é uma preocupação tecnológica fundamental. Um programador sênior deve definitivamente saber o que isso significa, pelo menos, alto nível. Por exemplo, isso afeta o desempenho de diferentes VMs e tempos de execução; portanto, deve ser pelo menos considerado ao avaliar uma nova tecnologia.
• como o GC funciona: semelhante ao acima. Os algoritmos para GC são bastante simples, e é preciso pelo menos estar familiarizado com GC geracional versus marca e varredura, versus contagem de referência e as várias compensações
• diferença entre List e Array: esta é uma pergunta básica que eu esperaria que um programador júnior soubesse
• classe abstrata e interface: o mesmo que acima. Eu não entendo como é esperado arquitetar um sistema complexo sem conhecer pelo menos interfaces
• delegar e evento: novamente, para projetar um sistema robusto e flexível, a delegação de eventos é um dos padrões básicos.

Parece-me que eles fizeram um bom trabalho ao fazer perguntas conceituais relevantes para um programador sênior sem se perder em trivialidades.