Função humana ou parar de contratar tecnologia

Eu não achava que iria escrever um artigo sobre isso, e mais ainda sobre Habr, mas como eles dizem, "algo precisa ser feito com isso". Dorido.

Nos 10 anos de minha carreira, primeiro como Administrador de Sistemas, depois como Engenheiro de Sistemas e DevOps, tendo conseguido ser um artista simples, técnico e líder de equipe, visitei e conduzi dezenas de entrevistas em empresas de vários tamanhos em diferentes países, participando da formação de requisitos ao procurar funcionários e ... gente, contratar é escuridão.

Eu acho que o estilo e a maneira de contratar que vive e prospera agora prejudicam funcionários e empresas.

Vou tentar explicar o porquê.

Quem o empregador está procurando?

Tudo depende de qual plano considerar esta questão.
Do ponto de vista dos negócios, o empregador procura uma unidade que possa executar as funções necessárias a um custo mínimo.

No nível de chefes de departamento, vice-diretores etc. os requisitos mudam um pouco e são detalhados - eles precisam de uma pessoa cujo salário se encaixe no orçamento, que possa ser encontrado no mercado com os fundos disponíveis e que executará as tarefas que seu gerente definirá para ele nos interesses dos negócios.

Nesse nível, geralmente é determinado o dinheiro específico que a empresa está disposta a pagar pelo trabalho e, a partir desse nível, o RH ordena a procura de um funcionário que atenda aos critérios e, em seguida, os candidatos que passaram nos primeiros filtros vêm para uma entrevista.

Vale a pena conversar sobre tudo isso.

Para começar a recrutar funcionários, você precisa saber quem procurar.
Para isso, são formulados requisitos para candidatos que se candidatam a uma vaga.
Por uma questão de padronização, as grandes empresas ainda têm uma lista de regras sobre como conduzir entrevistas e até treinamentos internos com o título de "entrevistador licenciado".

E tudo funciona nojento.

Dependendo da estrutura da empresa e da competência dos gerentes, a lista de requisitos é formada nos estilos de "precisamos de um programador de front-end, os requisitos são comuns" a "precisamos de um programador de front-end com conhecimento de <lista de 30 itens> , experiência de trabalho de pelo menos 23 meses e experiência exigida em empresas de FMCG por pelo menos 2 anos . ”

Às vezes, até funcionários tecnicamente competentes estão envolvidos e recebem a tarefa de "formar uma lista completa de habilidades e tecnologias que você usa por escrito" e tudo isso com alguns ajustes deixa a vaga no bloco "requisitos".
Em casos ainda mais raros, a tarefa é "formar um teste para testar o conhecimento necessário", o que dá origem a várias tarefas de teste no Hackerrank, consistindo em tarefas infinitamente distantes dos trabalhadores.

Qualquer que seja a abordagem usada para a formação de requisitos dessa faixa, ela funciona mal.

Por que isso funciona mal?

A pilha de tecnologia na indústria é enorme.
Mais do que você pode imaginar ou escrever nos requisitos (embora também haja listagens de requisitos de três páginas).
Além disso, a pilha na empresa também mudará mais cedo ou mais tarde.
Os líderes mudarão, a plataforma de software mudará, um novo fornecedor virá com uma boa oferta.
Mas as pessoas permanecerão. Se eles não fogem ou não precisam acioná-los, porque não conseguem executar novas funções.

O desejo de formalização é compreensível. É psicologicamente seguro e remove o estresse da cabeça.

Mas isso interfere na contratação e em mais trabalhos .

Os profissionais de contratação perdem um grande número de pessoas talentosas simplesmente porque as palavras-chave não correspondem.
Veja o LinkedIn com "você tem 27% das habilidades correspondentes a este trabalho". Ou na primeira página da emissão de HH / Indeed / Glassdoor, para vagas com calçados de requisitos e conhecimento de tecnologia.

Seguindo as regras, os entrevistadores fazem perguntas ilusórias , percebendo que não têm nada a ver com tarefas futuras. Na maioria das vezes, eles próprios não conhecem outras respostas além daquelas escritas no questionário e não entenderão a resposta correta se ela não for padrão.
Especialmente quando a empresa possui muitos especialistas com diferentes especializações, e as regras e perguntas são as mesmas para todos.

Não seguindo as regras, os entrevistadores começam a confiar em seu conhecimento possivelmente muito específico e a fazer perguntas que, novamente, não ajudam de maneira alguma a determinar como a pessoa executará as tarefas que a enfrentarão.
Ele pode ser de outro projeto para desenvolver um sistema específico, ele pode muito (não) amar o ML, ele pode (não) amar o Go / Python / Perl / C # / C ++ / C / Java / Scala, desprezar ou adorar Puppet / Salt / CFEngint / Chef etc.
Só porque ele é um homem e ele não tem nada em que confiar, exceto por sua própria experiência e gosto.

Tais entrevistas são estressantes para todos os envolvidos.

A maioria dos entrevistados ainda é desagradável ao escrever críticas negativas sobre os candidatos. A impressão dos candidatos após essas entrevistas também está longe de ser positiva. Os gerentes estão chateados com o fato de a vaga não ser fechada, os RHs são forçados a enviar mais e mais cartas e mensagens, perguntando-se por que o candidato que eles forneceram não se encaixou, porque "atende perfeitamente aos requisitos".

Esses problemas nascem do fato de o sistema de pesquisa de funcionários ter sido projetado para encontrar não um bom funcionário com o chefe, mas uma determinada função, tentando descrevê-lo através do número máximo de requisitos.

Listas, palavras-chave, tags, listas de perguntas para entrevistas no estilo de "quantos argumentos a função de substring leva" - eles estragam tudo.

Esse sistema de seleção, por um lado, dá origem a “entrevistadores” profissionais que se enquadram em posições que não são objetivamente atraentes e, por outro lado, impedem que especialistas normais trabalhem na empresa e trazem muitos benefícios, porque usaram Puppet em vez de Salt, escreveram em Python 2.7 em vez do 3.5, eles usaram o Symphony em vez do Laravel, Docker, não RKT, Docker Swarm, não Kubernetes ou etcd, não Consul.

Todas as ferramentas são alteradas e substituídas.
Após 1-2 anos, o conhecimento atual sobre ferramentas será irrelevante; após 5 anos, ninguém mais se lembrará. Tudo terá que ser alterado, a função do funcionário também poderá mudar junto com o ambiente e os projetos.
A grande maioria das empresas não tem problemas em que você precisa conhecer 8 algoritmos de classificação e lembrar de todos os recursos do Spring Boot Core ou de quais bibliotecas npm ele conhece.
Não faz diferença qual sistema de gerenciamento de configuração uma pessoa conhece no início ou quantos argumentos para java ele se lembra.
Se uma pessoa sabe como executar uma determinada função dentro de uma determinada estrutura, isso não significa que seja um bom especialista.
Isso significa apenas que, por coincidência, ele sabe executar uma determinada função aqui e agora.

De fato, com base na minha experiência, outros critérios são muito mais importantes para o candidato (e futuro funcionário bem-sucedido):

• Você precisa ser adequado, ser capaz de raciocinar e aprender, ser capaz de fazer suposições razoáveis ​​sobre o que você não sabe.
• Você precisa ter conhecimentos básicos sobre sistemas operacionais, redes e tecnologias relevantes.
• Você precisa entender o que está por trás das ferramentas usadas e por que essas ferramentas são necessárias (ou não).
• É preciso ter crenças sobre como trabalhar e força para segui-las.
• Em resumo - você precisa ser capaz de pensar em um sentido amplo.

Veja as grandes empresas de sucesso, seus requisitos para os candidatos. Eles especificam tecnologias minimamente, apenas para indicar uma certa base na qual confiar.

Aqui está o que a Yandex escreve em suas vagas na posição de Administrador do Sistema nos requisitos:

• Experiência em administração Unix / Linux - mais de três anos;
• experiência na administração de aplicativos de código aberto (servidores web, bancos de dados, servidores de correio etc.);
• conhecimento de tecnologias de rede TCP / IP;
• experiência em programação em linguagens de script (shell, python, perl);
• a capacidade de aprender com a experiência dos colegas e compartilhar seus próprios com eles;
• No ano passado, você trabalhou em uma posição semelhante.

E aqui está o que está nos desejos:

• experiência em projetar sistemas que operam de forma contínua e sem problemas (24x7x365);
• habilidades analíticas para prevenir e solucionar problemas rapidamente.

E aqui estão os requisitos para a posição de SRE do Google :

• Bacharel em Ciência da Computação ou área técnica relacionada que envolve codificação (por exemplo, física ou matemática), ou experiência prática equivalente.
• Experiência com algoritmos, estruturas de dados, análise de complexidade e design de software.
• Experiência em um ou mais dos seguintes: C, C ++, Java, Python, Go, Perl ou Ruby.

E aqui estão os desejos:

• Interesse em projetar, analisar e solucionar problemas de sistemas distribuídos em larga escala.
• Abordagem sistemática de solução de problemas, juntamente com fortes habilidades de comunicação e um senso de propriedade e motivação.
• Capacidade de depurar e otimizar código e automatizar tarefas de rotina.

É muito melhor prestar mais atenção às descrições de cargo do que a empresa faz e o que o candidato terá que fazer do que listar todas as 10 estruturas usadas em seus projetos.

Mude a abordagem das entrevistas.

Peça o básico em entrevistas, peça para raciocinar em voz alta, faça perguntas amplas (e esteja preparado para ouvir mais de uma vez uma resposta que será uma surpresa para você), construa um diálogo, comunique, compartilhe informações. Procure um terreno comum, tente entender como uma pessoa pensa e por que ela pensa assim.

A maioria das pessoas que fiz esta pergunta (assim como eu) concorda que de fato 15 a 20 minutos de comunicação são suficientes para garantir que a pessoa seja adequada e determinar seu nível e, em 10 minutos , é necessário que entender que uma pessoa não se encaixa perfeitamente.
Ao mesmo tempo, testes e pesquisas técnicas profundas praticamente não afetam o resultado .

Sim, durante esse período, você terá que esforçar suas habilidades cerebrais e de comunicação para aqueles que conduzem entrevistas.

A alta gerência deve aprender a confiar naqueles que conduzem essas entrevistas e em quem, no futuro, trabalhará com pessoas contratadas.

Você precisará abandonar as tags, a filtragem maluca (e impensada) e a excessiva, mas tão calma, padronização.

Você terá que assumir responsabilidade expandida pelo resultado da contratação, conforme "Aqui estão os resultados dos testes, ele respondeu 98% das perguntas, não sei por que ele falhou no projeto" não funcionará mais.

O fluxo de entrada de candidatos, incluindo os inadequados, aumentará.

Mas pense por si mesmo - será que vale a pena?