Vejo muitos anúncios de emprego que exigem pelo menos x anos de experiência. A questão é como você sabe quando um candidato tem os anos de experiência necessários? O que você espera de uma pessoa com x anos de experiência (editar: efetivamente, como você verifica se o currículo não está mentindo sem depender da verificação de habilidades)? O que uma pessoa com x anos de experiência pode fazer com alguém com y anos (com y <x) não pode (editar: supondo que possua habilidades semelhantes)?

Pode haver casos com algum programador apaixonado com anos de experiência que possui vasto conhecimento e trabalhou em vários projetos e outro programador com experiência de x anos (x> y) que trabalhou em poucos projetos e não possui tanta experiência.

Por que não pode ser reduzido a algo assim "se você conhece essa tecnologia e sabe como fazer essas coisas (seja design, comunicação, estimativas etc.), então você é adequado para o nosso trabalho"?

Sei que você não pode contratar um recém-formado com 1 ano de experiência para o cargo de arquiteto corporativo, mas também vejo um problema com o fato de que quase todos os anúncios exigem experiência. IMHO em primeiro lugar a paixão deve ser levada em consideração.

Em primeiro lugar, eu não sabia se a pergunta é adequada para este site, mas como existe uma tag para recrutamento e experiência, acredito que ele tenha um lugar aqui.

Sua pergunta pode ser tratada dividindo-se em duas sub-perguntas.

Por que usar anos de experiência como requisito?

Porque é uma métrica facilmente verificável correlacionada positivamente com a competência de programação . A resposta de Snagulus já detalha os detalhes da correlação, por isso vou focar no "porquê".

A dura verdade é que geralmente há mais de um candidato para uma determinada posição. Além disso, as entrevistas consomem bastante recursos, especialmente se forem realizadas "adequadamente", ou seja, entrevistas técnicas são conduzidas por funcionários tecnicamente competentes (neste caso, programadores).

Portanto, é necessário usar algum critério para analisar inicialmente os currículos recebidos , e de preferência um que possa ser verificado por uma equipe não técnica - em caso de dúvida, o pessoal de RH sempre pode ligar para empregadores anteriores e verificar se sim, John Smith trabalhou para X anos com eles.

Por que não usar a "paixão" como requisito?

Há pelo menos dois problemas com isso:

como medir "paixão"?

KLOCs registrados? Boa sorte ao descobrir que, também em programação (e outras disciplinas), mais profuso não equivale a "melhor".

Projetos de código aberto / hobby concluídos? Não é facilmente controlado pelo RH, e muitos programadores competentes têm razões legítimas para serem inativos a esse respeito - outras obrigações demoradas, longas horas de trabalho com vontade de relaxar, realização profissional simples durante o horário de trabalho etc.

Anos de experiência? Oh espere...

"paixão" é realmente uma boa métrica para competência?

Como Robert Harvey diz em seu comentário, a paixão não é realmente indicativa de uma programação competente. Comparado à experiência, é uma qualidade principalmente ortogonal - ou seja, existe:

• programadores apaixonados e competentes e
• programadores desapaixonados e tecnicamente competentes e
• programadores apaixonados e tecnicamente incompetentes e
• programadores apaixonados e não tecnicamente incompetentes,
• etc etc.

O último exemplo é importante em nosso contexto - anos de experiência também mostram que um determinado programador conseguiu, de alguma forma, funcionar em seu trabalho, enquanto um programador disfuncionalmente apaixonado poderia, por exemplo, recusar-se a participar mesmo do sistema mais simples de gerenciamento de tarefas (digamos, notas de post-it do Scrum), porque "isso me atrasa".

Isenções de responsabilidade finais

Antes de tudo, e felizmente, "anos de experiência" são frequentemente avaliados "vagamente" - ou seja, se você estiver se candidatando a um emprego na linguagem X, mas tiver apenas experiência "comercial" na linguagem Y, semelhante ao X, que também é frequentemente levado em consideração.

Em segundo lugar, pessoalmente, eu não sou fã de "N anos de experiência" e não sou o único. Existe uma alternativa simples - especificar "experiência em" . Isso geralmente é suficiente como filtro, uma vez que os candidatos são forçados a documentar essa experiência em seus currículos - se você conseguir um candidato para uma posição de programação que anteriormente apenas executou garçons (e isso acontece!), Você sabe que algo pode estar errado.

"Anos de experiência" é mais uma escala de probabilidade do que uma medida de algo concreto. Com mais anos, você tem uma chance maior de que uma pessoa tenha encontrado coisas como:

• Participou de um evento semelhante a uma crise.
• Viu um projeto do começo ao fim.
• Viu um projeto falhar ao iniciar ou terminar.
• Trabalhou no código legado.
• Trabalhou em uma lousa em branco e fez alguma coisa.
• Implementou decisões de design.
• Projetou um sistema.
• Escreveu um bug, lançou uma correção incorreta, desativou um servidor; Estragou tudo, essencialmente.
• Corrigiu um erro.
• Encontrou os casos extremos estranhos no idioma em que trabalham e viu um lugar em que eles são importantes.
• Aprendeu que as coisas atualmente na base de código podem ser idiotas.
• Observe que essas coisas são uma amostra pequena e não obrigatória e também incluem dezenas de pequenas coisas que podem ser encontradas trabalhando em um ambiente ativo.

Novamente, é uma coisa casual, e depende inteiramente de / onde / eles obtiveram esses anos de experiência. Uma pessoa poderia ter trabalhado em um único projeto em uma equipe de várias centenas de pessoas e se tornado altamente especializada. Outro poderia estar em uma pequena loja julgada por incêndio e tornar-se mais generalista ao lidar com servidores / instalação / codificação / QA / DBA / gerenciamento de projetos. Há também pessoas que se vêem recebendo o mesmo ano de experiência repetidamente.

É uma medida aproximada, mas, em média, uma pessoa terá sido exposta a mais eventos de aprendizado em potencial quanto mais tempo trabalha e é útil como um ponto de dados preliminar. O restante do currículo (e mais importante ainda a entrevista) é para descobrir o que eles realmente sabem e o que realmente fizeram.

Eu responderei a isso abordando cada uma das suas perguntas no post.

A questão é como você sabe quando um candidato tem os anos de experiência necessários?

Normalmente, é isso que o processo de entrevista pretende filtrar. São realizadas várias entrevistas e você normalmente pode avaliar a experiência de um candidato em relação a alguns de seus próprios desenvolvedores internos.

O que você espera de uma pessoa com x anos de experiência?

Você esperaria que eles cumprissem os requisitos de trabalho especificados em um posto de trabalho. Por exemplo:

"Estamos à procura de um desenvolvedor PHP sênior com mais de 10 anos de experiência trabalhando em arquitetura e design de sistemas para reestruturar nossas ferramentas de sistema como arquiteto-chefe, enquanto gerenciamos a quantidade de K de desenvolvedores seniores e juniores e os guiamos ao longo do caminho. O trabalho também requer ... (etc. etc.) "

O que uma pessoa com x anos de experiência pode fazer com alguém com y anos (com y <x) não pode fazer?

Você está vendo a experiência errada neste caso. Os postos de trabalho não exigem apenas número de anos, mas também experiência nas tecnologias que a empresa está usando. Como se você pudesse ter 10 anos de experiência no desenvolvimento de C ++, e diga que sou uma empresa de jogos procurando desenvolvedores de C ++ com até 5 anos de experiência. Você ainda não seria meu candidato ideal porque nunca trabalhou na indústria de jogos antes. Meu posto de trabalho especificaria: X quantidade de anos de experiência nos aspectos A, B, C da programação.

Pode haver casos com algum programador apaixonado com anos de experiência que possui vasto conhecimento e trabalhou em vários projetos e outro programador com experiência de x anos (x> y) que trabalhou em poucos projetos e não possui tanta experiência.

Leia minha resposta anterior. A experiência está ligada às ferramentas nas quais você tem experiência. X vários anos nas ferramentas A, B, C.

Por que não pode ser retomada para algo assim "se você conhece essa tecnologia e sabe como fazer essas coisas (seja design, comunicação, estimativas, etc.), então você é adequado para o nosso trabalho"?

Isso pode e acontece. Se você pode provar a si mesmo, a experiência em anos não importa. Para um cara como você, você parece mais adequado para uma loja de desenvolvedores menor, onde o entrevistador / recrutador é um desenvolvedor. As empresas maiores normalmente têm RHs fazendo esse tipo de coisa, e é por isso que eles tornam os requisitos de trabalho tão amplos que você basicamente precisa de um doutorado com mais de 15 anos de experiência para escrever pequenas funções em seu site (exagero, mas isso explica as falhas) no recrutamento de programadores, especialmente para as grandes empresas - embora nem todas sofram dessa doença)

A experiência de anos é simplesmente um filtro que fornece uma estimativa "aproximada" do que é esperado da pessoa que utiliza as habilidades desejadas listadas na descrição do trabalho.

Aqui está muito bonito o que eu esperaria, mas outros podem ter idéias diferentes:

2 anos ou menos - Você deve ser capaz de executar tarefas específicas que são instruídas a fazer, com os empregadores sabendo que haverá uma curva de aprendizado com uma quantidade razoável de supervisão para a maioria dessas tarefas.

3 - 5 anos - Você deve ser capaz de executar as tarefas que lhe são solicitadas, sem muita manipulação, porque já deve ter realizado tarefas semelhantes em sua experiência de 0 a 2 anos. Você também deve começar a mostrar alguma iniciativa "inteligente" e poder lidar com tarefas menores que não são necessariamente definidas claramente. (por exemplo, seja capaz de projetar módulos a partir dos requisitos, onde você mesmo deve rastrear alguns desses requisitos).

5 - 7 anos - Você deve poder trabalhar por conta própria e decidir quais são essas "tarefas" de cima. Você deve ser capaz de lidar com tarefas de tamanho médio que não estão claramente definidas. (por exemplo, ser capaz de projetar / implementar / vender subsistemas). Você também deve começar a liderar equipes de subsistemas nesse período. Faça as apresentações necessárias dos subsistemas pelos quais eles são responsáveis, pelo menos para a equipe interna.

8 - 10 anos - Pode-se confiar que recebam subsistemas muito grandes e / ou críticos do projeto. Especialista residente em diversas tecnologias. Pode liderar grandes equipes de subsistemas. Faça apresentações dos subsistemas pelos quais eles são responsáveis ​​pelo cliente.

Mais de 10 anos - Pode lidar com praticamente qualquer tarefa de software lançada para eles, dentro dos limites da descrição do trabalho E da maioria das outras tarefas de software semi-relacionadas. Especialista residente em um grande número de áreas de software. Pode liderar grandes projetos, desde requisitos até selloff. Compreende o design do sistema e não apenas o design do módulo / subsistema. É capaz de projetar sistemas confiáveis, robustos e de manutenção. É a interface do software para o cliente, incluindo apresentações da perspectiva do sistema. Pode reunir adequadamente propostas de propostas e agendas.

Embora os anos de definição da experiência sejam vagos, não é apenas para benefício do empregador, mas também é um guia para quem procura emprego. Portanto, se você for contratado, alegando que tem 8 a 10 anos de experiência e entrar no trabalho e precisar receber todas as pequenas tarefas que precisar, o melhor é que o seu futuro na empresa seja "muito limitado" se você durar muito. por muito tempo. As primeiras impressões são difíceis de mudar; portanto, mesmo se você melhorar como desenvolvedor, as pessoas provavelmente ainda manterão sua impressão original sobre você.

Eu já vi um bom número de desenvolvedores "seniores" contratados que desapareceram em questão de meses ou em alguns anos no programa de "desenvolvimento de funcionários", que é realmente apenas o caminho mais rápido para ser o primeiro a lista de demissões. Se esses mesmos desenvolvedores chegaram a um nível mais baixo (é claro que isso significa salários mais baixos), eles podem muito bem ter sido considerados contratados com sucesso e vistos como tendo desempenho adequado.