Em um artigo anterior
sobre a implementação da metodologia Agile em nossa startup, abordamos parcialmente a questão da gestão de pessoas. Neste artigo, mostrarei como recrutamos essa equipe, que classificação usamos, que testes e métodos verificamos seu profissionalismo e adequação.
Modelo de Recrutamento
Como em qualquer empresa jovem, nosso trabalho no campo da seleção de pessoal começou com o desenvolvimento de um modelo de recrutamento. A situação era a seguinte: já tínhamos uma equipe de funcionários “indígenas”, todos com alto nível de qualificação e com altos cargos. Essas pessoas tiveram que ser descarregadas de alguma forma, ou seja, não havia necessidade de especialistas do mercado ganharem competência; portanto, durante o período de expansão ativa da equipe, o grande número de vagas era de junho. Antes de colocar vagas nos locais de recrutamento, decidimos elaborar nossa classificação interna de acordo com o nível de qualificação e de acordo com os requisitos para diferentes categorias de desenvolvedores.
A seguinte classificação foi derivada:
Nível 0 - fullzero-developer, uma pessoa passou por alguns cursos, aprendeu as construções básicas e semânticas de uma determinada linguagem, leu vários artigos sobre o Haber sobre tópicos de hype, como resultado, há um adesivo máximo no laptop do programador.
Nível 1 - um desenvolvedor júnior, uma pessoa que escreve bem o código, conhece bem as pilhas, conhece as tendências atuais, sabe como decompor um problema e resolvê-lo por conta própria.
Nível 2 - desenvolvedor intermediário, uma pessoa possui todas as qualidades juniores listadas acima e também pode expressar sua opinião competente sobre o problema que está sendo resolvido com base na análise de recursos e pode influenciar o curso de sua implementação dentro da estrutura de sua cadeia de ferramentas escolhida.
Nível 3 - desenvolvedor sênior, ele também é um líder, pai, pai, uma pessoa que transforma e projeta tarefas de um plano de negócios para um plano de desenvolvimento, distribui essas tarefas em intermediários e junho, controla e ajuda na sua implementação.
Foram adicionados critérios a esta classificação como: conhecimento de nossas ferramentas, adequação, experiência de trabalho de cerca de um a dois anos e pelo menos um projeto implementado com sucesso, capacidade de expressar pensamentos claramente, presença de habilidades de comunicação, capacidade de admitir erros e deficiências (autocrítica saudável - é uma ferramenta poderosa). A prioridade para o conjunto, como mencionado acima, foi colocada nos desenvolvedores juniores, pois nossa experiência em lidar com intermediários mostrou que, em regra, essas pessoas já são estragadas por algum tipo de pilha de tecnologia e abordagens "únicas" de outras empresas. Além disso, a prática mostrou que há um grande número de pessoas no mercado que estão acostumadas a viver em uma estrutura vertical rígida, onde colocam sobre a mesa um aldet de material proveniente de tarefas mastigadas, que só precisa ser preenchido na forma de um código, e a tarefa dos idosos é bater nos batentes com um pau na cabeça . Mas o importante é que, quando a ação ocorre em uma startup jovem, e a equipe tem apenas cerca de trinta pessoas, cada uma delas carregada em um tanque cheio, não há tempo para uma decomposição pessoal de cada funcionário, pois isso equivale a concluir esta tarefa. Nessas condições, quando a escrita do código ocupa cerca de dez por cento do tempo total de execução da tarefa, é necessário incluir não apenas os dedos, mas também a cabeça. É exatamente isso que está escrito na "bíblia" de todos os programadores - Stephen McConnell "Código Ideal", também conhecido como Redbook (não deve ser confundido com a revista feminina americana).
E então uma onda nos cobriu ...
Quem não entrou em nós, a partir de personagens que acreditam que são do meio porque escreveram um aplicativo inteiro no Android, que tem até 37 downloads no Google Play, terminando com pessoas que se consideram super signatárias porque trabalharam como desenvolvedores líderes em alguns estúdios, embora seu trabalho, em geral, tenha sido reduzido à transferência de tarefas do departamento de design para o departamento de desenvolvimento, ou seja, eles não tinham experiência em projetar ou gerenciar o desenvolvimento, mas havia muita ambição e muita ambição . Havia também aqueles que, com sete meses de experiência em programação, se consideravam signatários e exigiam um salário de 240 mil, sem sequer resolver tarefas elementares para os juniores. Do nosso ponto de vista, essas pessoas nem eram Joons. A abordagem é simples: se uma pessoa programa diretamente do coração, ela é apenas um programador, mas se uma pessoa faz uma programação ruim ou não faz nada, ela não é júnior, simplesmente não é programadora. Aqui fomos ajudados por um maravilhoso hack ao vivo para a retirada desses candidatos, chamado de “Lei do encanamento”, que diz: “Todo novo encanador que chega a um novo local de trabalho derrama lama em outro encanador, dizendo que ele tem um braço de desentupidor e que agora tudo precisa ser feito zero. " Na prática, funciona mais ou menos assim: o candidato chega à posição júnior, fornece a ele algum código pronto, por exemplo, um fragmento do kernel do Linux e pergunta o que ele acha dessa decisão. Se ele começa a cuspir e diz algo como: “Que tipo de manuscrito escreveu isso? Tudo precisa ser refeito aqui! Dê-me tempo e escreverei tudo de novo ”, para que o encanador esteja na sua frente e sua primeira prioridade é repreender o encanador anterior.
Michelangelo disse nesta ocasião: "Pego uma pedra, corto tudo desnecessário". O grande mestre não escreveu scripts, mas compreendeu que uma pessoa competente se aproxima do objeto de trabalho com o desejo de entendê-lo e, se necessário, transformá-lo, mas não destruí-lo e transformá-lo em pó. Ou seja, se uma pessoa responde a essas perguntas: "Se o código funciona em produção e executa suas funções, isso é bom, em alguns lugares acho que você pode melhorar esse código, se necessário, eu posso mostrá-lo.", Em seguida, com essa pessoa, você pode e deve continuar o diálogo .
Outra técnica para definir jones de baixa habilidade é focar em hype e hype stacks. Se uma pessoa chega a uma entrevista e começa a derramar abordagens de tendência, e à pergunta legítima: "Como você chegou a essa conclusão e analisou essas ferramentas?" - fazendo uma careta com a careta que atingiu a iluminação do idoso, ele responde: “Você pode escrever qualquer coisa nela, o futuro está por trás dela!”. Então, na sua frente, um júnior fraco, na melhor das hipóteses, que não tem análise de recursos, pilhas e outras ferramentas, apenas informações superficiais sobre ferramentas e abordagens de campanha publicitária.
Um pouco mais sobre a entrevista
Além do acima, ao contratar um programador, é muito importante obter uma posição aberta dele sobre seu conhecimento em uma pilha específica. Você decide a pilha e ele escolhe o idioma em que ele é "wai wai wai quão forte", digamos que ele seja um highlander do JavaScript. Há um conjunto de tarefas prontas, por exemplo, isto:
setTimeout(()=>{console.log('Hello World!')}, 1000); while (true) { let a = false; };
Se a pergunta desta tarefa for: “Quando o Hello World!” Será exibido ? ", Ele começa a gaguejar no estilo de responder:" Bem ... uh ... olha ... depois de completar o loop while true ou depois de um segundo "- isso significa que ele absolutamente não conhece a pilha, está mentindo sobre suas habilidades, que provavelmente estão próximas de para zero. O fato é que a construção while carregará o pré-processador e, como JS é de thread único, o loop principal nunca emitirá um evento de um timer. I.e. a resposta correta é nunca.
Se uma pessoa não está pronta para avaliar adequadamente e honestamente seu conhecimento, não consegue ler o código de outra pessoa, então que tipo de trabalho em equipe pode ser discutido. Se uma pessoa não provar ser um "encanador" e lidar com as tarefas, confirmando seu conhecimento da pilha ou for construtiva sobre a tarefa, seus erros e incompetência parcial, há uma chance de que ela se torne seu novo funcionário e, no futuro, possa crescer em lado de níveis mais altos de classificação.
Há momentos em que uma pessoa não concorda com a classificação interna da empresa e reage negativamente à afirmação de que ela não está no meio ou mesmo em junho, e que sua decisão não funcionará. Nesse caso, se ele continuar insistindo, você pode seguir o princípio e executar sua solução no ambiente, naturalmente esse design acaba sendo inoperante, ou seja, a pessoa estragou tudo. Então ele pode começar a esmagar a autoridade de seu trabalho anterior. Por exemplo, houve casos em que uma pessoa após tal falha declarou que era um funcionário muito valioso de um grande banco e foi muito apreciada lá. Mas, na realidade, acontece que outras 12 mil pessoas como ele trabalhavam nesse banco, e o departamento de RH simplesmente ignorou sua incompetência e, depois de passar cerca de um ano lá, ele agora declara seu status de especialista. E aqui, onde há uma equipe de cerca de vinte programadores, cada um dos quais é versado em seus próprios negócios, ele simplesmente se perde incapaz de trabalhar de acordo com o antigo esquema de funcionários. Nosso CEO, Ilya Bykonya, diz o seguinte: "Para mim, como para o atual desenvolvedor e fundador da empresa, uma autoridade é a habilidade da pessoa, e onde ele trabalhou e qual posição ocupou é de importância secundária".
Resumir
Talvez haja uma falha em nossa abordagem para avaliar os candidatos. E o fato de "o abaixarmos na classificação", dizendo que ele não é do meio, mas junho ou pior, faz uma piada cruel conosco. Talvez estejamos perdendo os futuros Napoleões, como o Império Russo ao mesmo tempo? Quem sabe ... Mas, do nosso ponto de vista, essa estratégia é totalmente justificada por sua eficácia e, no final, Napoleão ainda perdeu a guerra do Império Russo.