Como você entrevista alguém com mais experiência que você? [fechadas]

A empresa em que estou trabalhando procura contratar um desenvolvedor sênior com mais experiência do que eu e eles esperam que eu faça a parte técnica da entrevista. Estou programando apenas alguns anos e não tenho certeza de que tenho o conhecimento necessário para avaliar as habilidades de codificação de alguém que tem maior entendimento / experiência do que eu.

Alguém pode recomendar algumas perguntas técnicas da entrevista para perguntar que são um bom meio de avaliar as habilidades de programação de nível superior, mas ainda assim eu entendo?

Eu diria que já passei do jr. nível de programador, mas nem de longe o mais velho. A maior parte do que fiz foram aplicativos pequenos (Web e desktop), alguns deles bastante complicados, mas todos foram feitos para serem usados ​​por mais de um punhado de usuários. Sinto que tenho um entendimento decente da maioria dos conceitos de programação e sou capaz de aprender / me ensinar praticamente qualquer coisa, no entanto, não tenho experiência. Como meu chefe gosta de me dizer: "Você não sabe o que não sabe".

Em particular, o que gostaríamos que a pessoa com quem contratamos tenha experiência (que eu não tenho) é: desenvolvimento de várias camadas, ambiente multiusuário, desenvolvimento de aplicativos em larga escala, mensagens bidirecionais, sessões compartilhadas, e Multi-threading / BackgroundWorkers.

ATUALIZAR:

Em resposta ao comentário de Thor abaixo, contratamos alguém há alguns meses e acho que está dando certo. Estou aprendendo muito, não apenas sobre codificação, mas também sobre coisas como padrões de design, arquitetura de software, documentação e como outras equipes de programação maiores fazem as coisas. Nem sempre é fácil ter alguém entrando e apontando maneiras melhores de fazer as coisas que você fez, mas se você pode engolir seu orgulho e estar disposto a experimentar coisas novas, pode aprender muito.

O processo de entrevista foi melhor do que eu esperava. Comecei a fazer perguntas sobre coisas com as quais estava familiarizado, depois fiz algumas perguntas sobre algumas coisas com as quais eu estava lutando. Sempre que o entrevistado dissesse algo que eu não entendia, eu pedia que eles me explicassem e depois anotassem para que eu pudesse procurar mais tarde. No geral, eu senti que era capaz de ter uma boa idéia do nível de habilidade, inteligência e como eles trabalhariam.

Você não pode.

Em vez disso, sugiro que você entre na entrevista com uma lista de problemas que você tem hoje e pergunte a ele como ele os resolveria .

Este é um método muito interessante pelos dois motivos a seguir:

1. É consultoria gratuita . Mesmo que você não contrate o sujeito, ele pode sugerir boas soluções para seus problemas .

2. Se ele vem com soluções interessantes , ele resolve problemas . O tipo de cara que você deseja contratar.

Use sua idade como uma vantagem.

Eu entrevistei uma tonelada de pessoas que são mais velhas que eu. I escolher uma tecnologia que não sei muito bem e dizer-lhes que eu ouvi de Tecnologia X, mas nunca utilizamos. Peço ao candidato que me forneça uma visão geral da tecnologia e como eles a usaram em um projeto.

Isso funciona surpreendentemente bem. Primeiro de tudo, se o candidato estiver usando apenas a Tecnologia X como palavra de ordem em seu currículo, a explicação deles será péssima / não fará sentido. Além disso, se eles não puderem dar um bom exemplo concreto de como eles usaram uma tecnologia em seus projetos anteriores, você terá uma grande bandeira vermelha ali.

Eu entrevistei alguém que tinha experiência com java Spring. Eu tinha usado o Spring no meu trabalho anterior, e um dos grandes recursos do Spring é a injeção de dependência. Eu disse ao candidato que entrevistei que tinha ouvido falar sobre o Spring e nunca o havia usado. Ele começou a tagarelar sem parar, mas não podia me dizer onde havia usado o Spring AOP e não podia explicar a Injection de Dependência para mim, mesmo depois que eu perguntei explicitamente depois de ver aquelas coisas mencionadas em seu currículo. Ele apenas me disse que eles eram muito legais, e há muito o que aprender por aí, etc., etc. Acontece que ele não conhecia Jack ... e eu fui o único a descobrir isso porque eu era um membro mais jovem da equipe de desenvolvimento.

Portanto, use sua idade como uma vantagem! Entre, tenha confiança e faça algumas perguntas sobre a tecnologia que você conhece bem.

Lembre-se de que, apenas porque eles têm mais experiência que você, eles podem não ser um desenvolvedor melhor que você. A frase "Um ano de experiência repetida n vezes". surge porque você vê isso acontecer na indústria. Assim, sua primeira tarefa durante a entrevista deve ser estabelecer que eles realmente têm a experiência relevante e podem se apresentar como alguém que sabe o que está fazendo. Da mesma forma, apenas porque alguém teve n anos de experiência no setor, isso não significa que eles tenham uma tonelada de experiência em um determinado idioma, biblioteca ou estrutura, para que ainda possam vir a você de vez em quando fazendo perguntas enquanto estão aprendendo alguma coisa.

Em seguida, lembre-se de que um bom desenvolvedor sênior é alguém com quem você deve se aproximar e perguntar sobre algo com o qual está tendo problemas. Este é um bom momento para fazer a eles algumas perguntas de design que você teve problemas e ver como elas respondem e qual o raciocínio delas nas explicações. Eles viram algo semelhante antes em algum outro lugar, estão fazendo um palpite com base na experiência, leram um artigo on-line ou em um periódico?

Finalmente, outra coisa a considerar é como eles abordam o código de depuração. Em minha própria experiência, descobri que, independentemente do idioma, certas técnicas de depuração tendem a ser aplicadas à universalidade. Dado ao candidato um exemplo de um dos bugs mais esotéricos que você encontrou e faça com que ele o guie através de como eles abordariam o bug. Eles têm alguma idéia do problema que não é imediatamente óbvio?

Em resumo, entrevistar um candidato com uma entrevista impressionante pode ser intimidador, mas há algo que você precisa abordar, independentemente do nível em que eles estarão (ou seja, eles realmente sabem o que estão fazendo) e, uma vez concluído, você pode começar a investigar para ver como estão aplicando sua experiência. Como os candidatos estão aplicando sua experiência de trabalho anterior será o que fará com que um candidato se destaque mais do que outro.

Gosto muito da resposta Use sua idade como vantagem e sugiro algo semelhante:

Use seu nível mais baixo de experiência como uma vantagem

Essa pessoa provavelmente será seu chefe ou mentor; portanto, faça perguntas de uma maneira que permita descobrir se essa pessoa pode realmente te orientar.

Faça perguntas complicadas que poderiam ser muito mais fáceis ou que incluam problemas excessivamente complicados. Se ele / ela é bom, ele / ela não apenas resolverá tentar responder à pergunta / resolver o problema, mas também chegar ao problema real, mostrando as falhas na sua pergunta. Se ele / ela consegue fazer isso de uma maneira educada sem intimidá-lo, ele / ela é um guardião.

O importante é que você tenha certeza de que ele é o tipo certo de desenvolvedor experiente para o que você precisa.

À medida que as pessoas seguem suas carreiras, tendem a seguir direções diferentes em termos do que fazem. Você pode entrevistar pessoas especialistas em administrar grandes equipes de programadores ou trabalhar com código legado complicado e bastante brilhante no que eles fazem sem que eles sejam a pessoa certa para o seu papel. Portanto, tente ter uma idéia do que exatamente você está procurando com antecedência e pense em perguntas que diferenciem exatamente o tipo de desenvolvedor para o seu trabalho de outras pessoas.

Eu tive que fazer isso várias vezes. Eu aprendi a fazê-lo em um processo passo a passo.

1. Comece com as mesmas perguntas que dou aos graduados da faculdade. Fiz isso porque a posição em que eu estava fazendo a entrevista técnica era uma posição de programação em que esperávamos que o desenvolvedor estivesse envolvido no código e queria garantir que os candidatos pudessem programar. Com apenas uma exceção, nenhum dos candidatos conseguiu - eles eram piores do que os graduados da faculdade. Todos eles estavam em cargos gerenciais há muito tempo.
2. Para o candidato que passou no teste básico de competência em codificação, tive algumas perguntas mais gerais sobre "como você lidaria com o cenário X". Se você estiver executando serviços da Web em seu projeto, por exemplo, pense em uma pergunta interessante sobre serviços da Web e pergunte ao candidato como ele iria resolvê-lo. Eu não recomendaria que isso seja algo em que você esteja trabalhando diretamente atualmente, principalmente por causa da questão da propriedade intelectual e dos dados proprietários da empresa. Não dê essas coisas!
3. Passe algum tempo perguntando ao candidato sobre as coisas em seu currículo. Isso é importante. Você pode descobrir quais são suas melhores e piores experiências de equipe, experiências como supervisor e assim por diante. Tente ter uma idéia do estilo de trabalho da pessoa para ver se ela se encaixa em sua equipe.

Meu maior problema ao entrevistar candidatos seniores era que eles frequentemente ficavam muito nervosos ao serem entrevistados por uma pessoa júnior, especialmente aqueles que não conseguiam lidar com meus testes básicos de codificação. Tente não parecer ameaçador em nenhuma das habilidades que mostrar durante a entrevista - concentre-se nelas, mesmo que elas não consigam responder bem às suas perguntas. Tente inclinar a entrevista para perguntas que eles possam responder se falharem no básico.

Em termos do processo real de entrevista, fundamentalmente você os trata da mesma forma que qualquer outra pessoa que você está contratando. Deve haver um processo de contratação semelhante:

1. Seleção, por recomendação de CV ou agência.
2. Teste de aptidão (combinando coisas como FizzBuzz , strdup () / isAlpha (), OOD, etc)
3. Entrevista por telefone (para eliminação rápida, caso não se comuniquem bem)
4. Entrevista presencial
5. Exercício de codificação escrito
6. Conheça alguns dos membros da equipe.
7. Para uma pessoa experiente, o que implica maior risco e custos mais altos, rodadas adicionais de entrevistas são aceitáveis, mas você deve comunicar claramente a elas onde elas estão no processo (ou seja, essa é uma das três rodadas de entrevista).

Existem muitas outras postagens neste site que abordam tópicos gerais de discussão que você deve abordar no processo de entrevista - eis a minha resposta para uma delas .

Em todos os momentos do processo de entrevista, uma pessoa experiente deve demonstrar um excelente entendimento de suas especialidades anunciadas. Você pode sondá-los, com muita profundidade, sobre qualquer tópico abordado durante as discussões. Faça perguntas até os limites do seu nível de experiência / conforto e veja se elas podem continuar sem se preocupar. Se você precisar se aprofundar em algo com o qual não tem muita experiência, faça uma pesquisa na web para obter algumas amostras de perguntas (faça uma seleção delas), leia e entenda as respostas antes da entrevista e, em seguida, pergunte ao candidato qualquer uma dessas perguntas. Não espere que eles saibam todas as respostas, então faça uma seleção de perguntas.

Existem dois tipos de engenheiro experiente que você pode contratar:

1) Experiência relevante na indústria

Essa é a pessoa para quem você pode levar sua lista de problemas atuais e conversar sobre como eles podem abordar esses problemas. Você deve avaliar o nível de entendimento de cada um dos tópicos específicos do domínio em seu setor. Como você está nesse setor, pode dizer uma resposta "burra" de uma resposta "boa" e provavelmente também pode identificar uma resposta "experiente". Ao contrário de outras respostas, eu não esperaria que eles resolvessem seus problemas atuais - o que acontecerá quando você os contratar -, mas você precisará convencê-los de que eles poderiam assim que começarem.

2) Nenhuma experiência relevante na indústria

Portanto, este candidato está possivelmente mudando de setor, mas tem uma boa experiência nas tecnologias / plataformas / habilidades básicas necessárias. Aprofunde-se nesses itens, mas não espere que eles consigam encontrar soluções para problemas específicos de domínio, embora você possa apenas falar sobre eles. Por exemplo, se sua empresa é o Facebook e a pessoa que você está entrevistando gosta muito de PHP e C ++, seria irreal esperar que eles soubessem todas as armadilhas de grandes farms de servidores (a menos que o reivindiquem em seu currículo).

Uma coisa que eu não vi explicitamente apontada é: "Você conhece a tecnologia X muito bem e parece muito interessante. Você poderia me explicar em cinco minutos?"

Como é provável que você consiga manter o código eventualmente saindo da nova pessoa, é crucial que ele seja capaz de explicá-lo a outros programadores de maneira eficiente e bem. Considere-o como habilidades de comunicação.

É necessário um entendimento completo para encontrar qualquer outro desenvolvedor em seu nível de habilidade e comunicar pensamentos e idéias em seu nível.

Se a pessoa não puder se comunicar verbalmente, é provável que ela ou ela escreva apenas o código para o compilador, não para o mantenedor.

Eu concordo com Steven sobre a parte de tutoria. Na verdade, eu diria que você pode fazer perguntas sobre quais são seus pontos de vista sobre orientação e como ele faz isso em diferentes cenários. Em seguida, avalie com base na resposta (você pode obter feedback do seu chefe, se quiser, ou discutir as respostas reais no relatório).

Você também pode fazer perguntas a um colega, pois o candidato provavelmente deve ser capaz de resolver ou, pelo menos, entender seu trabalho.

definitivamente escolha o cérebro dele na entrevista sobre problemas e tecnologias reais que você tem ou pretende usar atualmente

assumindo que ele é um desenvolvedor sênior competente e imaginativo, decida contratar ou não com base em se acha que pode aprender com ele e trabalhar bem com ele

você não está entrevistando seu futuro chefe, está entrevistando seu futuro mentor. Não escolha alguém que saiba todas as respostas, mas não possa ensinar

Tome um monte de problemas que você já resolveu. Descreva a ele o que foi feito para resolver o problema (mantenha-o na terceira pessoa; você não quer colocar seu ego pessoal em risco aqui). Pergunte a ele o que ele teria feito "de forma diferente". Você deve ser capaz de, com base no que ele está sugerindo, descobrir se isso seria melhor ou pior, conceitualmente, do que você fez.

Eu seriamente recomendo que você leia o livro "Smart and Gets Things Done: Guia conciso de Joel Spolsky para encontrar o melhor talento técnico" .

Eu nunca contratei ninguém, mas, às vezes, quando eu era o entrevistado, desejava que alguns idiotas que só conheciam buzzwords e estivessem me entrevistando tivessem a linha de raciocínio exposta naquele livro. O texto é muito fluido e é um prazer ler.

E não, não estou publicando apenas porque este site é do autor do livro. O livro é realmente ótimo e eu o recomendo para qualquer pessoa que esteja em posição de contratar pessoal de TI, especialmente para quem não entende a tecnologia - Hoje em dia é muito comum ter um gerente ou chefe de projeto não técnico.