Saudações a todos vocês, meus caros leitores!
Hoje quero compartilhar meus pensamentos sobre um tema já bastante discutido e, possivelmente, debatê-lo nos comentários.
Com bastante frequência, me deparo com artigos sobre as más práticas de entrevistas para a posição de programador, que, a meu ver, são bastante relevantes e, espero, legíveis pelos departamentos de RH de empresas grandes e pequenas.
Na nossa região, pelo que posso perceber, existe uma demanda por entidades interessantes como engenheiros DevOps. Eu me incluo entre aqueles que não compreendem muito bem essa expressão (sim, sim, metodologia DevOps, etc.), por isso vejo uma certa diferença nos caminhos de desenvolvimento dessa categoria de especialistas.
Em primeiro lugar, acredito firmemente que cada pessoa tem seu próprio conjunto de interesses, mesmo na área profissional; ou seja, alguns preferem a nuvem, outros se dedicam a explorar profundamente servidores de aplicação, configurando Java minuciosamente, e há quem escreva código em Python ou, Deus nos livre, em YAML. Assim, aparecem os chamados engenheiros de infraestrutura, engenheiros de construção, desenvolvedores sêniores de YAML 🙂
Tudo isso permite, por um lado, encontrar alguém que se encaixe perfeitamente no seu conjunto de tarefas, enquanto, por outro lado, cria mal-entendidos durante as entrevistas.
Com base na minha experiência pessoal, participando de dezenas de entrevistas, além de haver atuado em várias como respondente, quero compartilhar minha visão sobre tudo o que está acontecendo.
O primeiro e, provavelmente, meu antípater favorito — a preferência por alguém que faça tudo ou a dúvida sobre quem realmente é necessário, vamos analisar uma quantidade de candidatos e então decidiremos. Isso provavelmente se aplica a qualquer área, mas aqui existem suas peculiaridades.
Como percebi, as pessoas estão mais inclinadas a se candidatar a vagas com a palavra DevOps do que a de Administrador de Sistemas, embora, na minha opinião, ao nível sênior, o escopo de tarefas diferem bastante entre essas duas áreas.
Qualquer empregador que realmente precisa de um administrador de sistemas escreve no título da vaga DevOps, listando no corpo do pedido absolutamente tudo, K8S/Java/gradle/oracleDB e assim por diante, apesar de que na prática a pessoa estará lidando com a manutenção de um cluster K8S e o suporte à pilha OracleDB, sem interagir com a equipe.
Então, qual seria a interação no formato de desenvolvedores/operations?
Além disso, fica claro que não há um processo previsto para esse tipo de interação com a equipe e, na verdade, não existe um departamento de operações, e você terá que configurar os computadores dos desenvolvedores.
Esse tipo de vaga, na verdade, atende uma parte dos candidatos, mas vamos ser honestos, é um Administrador de Sistemas Sênior, então por que não querem escrever assim e o que há de vergonhoso nisso? A diferença no salário entre diferentes títulos de trabalho? Mas o orçamento da empresa é único, e, independentemente do nome do navio, ele navegará dentro do seu orçamento.
Além disso, ouvi dizer que agora o candidato automatiza tudo rapidamente e se integra ao desenvolvimento do produto em Python; qual é a diferença, o Python é o mesmo em todos os lugares. A diferença nas visões de mundo e nas abordagens não é considerada.
Normalmente, eu diferencio o nível dos especialistas que vêm e vejo minhas dificuldades específicas para cada um.
Junior — para mim, um Junior DevOps é alguém que dominou a administração de sistemas / desenvolvimento em um nível intermediário. Aqui é bom diferenciar os bons linuxers que querem crescer em uma nova área ou os desenvolvedores que têm vontade de fazer o bem para outros desenvolvedores. Pessoas competentes, com algumas habilidades de depuração, busca de logs, ou com algum histórico de projetos codificados.
Encontrei tanto administradores que tentaram algo e querem se aproximar das nuvens, quanto aqueles que experimentaram front-end, back-end e, por algum motivo, encontraram interesse nos processos DevOps.
Neste nível, sempre fico desconfortável quando começam a despejar um enorme conjunto de tecnologias, Puppet, Ansible — por que não experimentou tudo? K8S, K3S — qual a diferença? Quantos tipos de bancos de dados você conhece? Por que tão poucos? Como a criptografia funciona em Java? Especialmente aqueles que vêm do desenvolvimento, embora sejam profissionais muito valiosos, sempre há trabalho para eles nessa área.
Sempre me deixa perplexo quando acontece isso; a primeira coisa que quero perguntar é — por quê??? A segunda coisa que vem à mente é — o próprio entrevistador está pronto para responder perguntas sobre esse conjunto diversificado de tecnologias? Será que realmente querem contratar um júnior e carregar tudo nele?
Isso acontece frequentemente em várias consultorias, quando precisam vender uma pessoa para algum projeto e precisam de palavras mais legais para o currículo, ou a empresa não quer contratar ninguém, mas simplesmente observa que tipos de juniores existem.
Nível Médio
Aqui estão algumas extremidades, na minha opinião. Em primeiro lugar, é difícil determinar claramente se uma pessoa está se aproximando do nível de middle; ou tentam rebaixá-la para junior, ou começam a tratá-la como senior, tentando pegar um senior pelo preço de um middle (pois é, o mercado manda, nada pessoal).
O mais surpreendente que vi foi mergulhar fundo na codificação, usando Python, atormentando o Java GC, ou seja, temas já mais específicos, ou, ao contrário, redescobrir lacunas em conhecimentos que não são utilizados há muito tempo, explorando redes, tipos de drivers de sistemas operacionais, sorrindo e me divertindo como é que a pessoa pôde esquecer isso. E é aqui que acontece o mais interessante!
Para o nível middle, em minha opinião, o especialista forma um conjunto de interesses e uma visão pessoal sobre com o que ele quer trabalhar — aproveitar a onda de uma stack super nova, colocando-a em camadas de criação, ou se desenvolver para um assustador enterprise, mergulhando fundo na performance do código.
Na minha opinião, já é hora de perguntar sobre os processos nos quais a pessoa trabalhou, perguntar o que foi maximamente interessante e o que não foi, e então, com base nesses conhecimentos, construir um cluster de perguntas, mapeando-as inegavelmente para sua stack. Caso contrário, após uma conversa fascinante de uma ou duas horas sobre a configuração de um cluster OpenShift, contratamos a pessoa e a colocamos para construir monitoramento. Provavelmente, isso agradará a ambos os lados.
Nível Senior
Oh, meu nível favorito.
Diante de você está um especialista forte, que se desenvolveu em diversos tipos de projetos, uma pessoa que já sabe o que quer e o que não gosta tanto.
E então o show começa:
— perguntas profundas sobre administração de sistemas (veja o primeiro antipadrão)
— perguntas profundas sobre Linux de modo geral na área teórica, longe do conhecimento prático (a pergunta de topo dos níveis OSI)
— perguntas acadêmicas sobre codificação (porque o entrevistador não sabe bem a área, ele simplesmente foi solicitado a entrevistar um devops estranho)
Vou fazer aqui uma pequena observação. Uma vez, em uma entrevista, me pediram para escrever algum pedaço de código. No papel. Como todos gostam, escrevem todos os dias, o papel é tudo para nós.
Após finalizar a tarefa, depois de revisar minha lista e solução, foi emitido o veredito de que o algoritmo seria não otimizado. Eu sugeri que o entrevistador escrevesse seu próprio algoritmo, ao que recebi a resposta: 'Isso não faz parte da entrevista'. Pedi um minuto, fiz algumas alterações no código e mostrei, perguntando se era mais rápido ou mais lento. A resposta foi que iríamos para a próxima pergunta. A diferença estava na execução do código em um loop e sem loop, e eu tinha uma justificativa pronta sobre por que seria melhor fazer assim em vez de assado. Bem, depois disso, eu já não queria mais responder às perguntas e trabalhar com essa pessoa.
É importante levar em conta que somos todos diferentes e qualquer coisa que para você pode parecer insignificante pode afastar o candidato.
Normalmente, especialistas de nível Sênior têm uma pilha de tecnologias claramente definida. Mas não, é preciso começar a testar de forma próxima; por exemplo, você mencionou Ansible, ótimo, mas nós usamos Puppet, então você foi convidado apenas para isso, conte-nos sobre o Puppet. Maravilhoso! Já trabalhou com OpenShift? Nós temos K8s, não conhecemos as diferenças, mas sua experiência não é relevante. Excelente!
Há também essa subcategoria — pessoalmente, eu costumo pegar estagiários para desenvolver como júniores.
Eu gostaria que todos entendessem que um estagiário é uma entidade que ainda não está totalmente formada. Fico extremamente preocupado quando começam a pressionar estagiários para atingir o nível de Junior sólido e, depois, empurram estágios (às vezes não remunerados, que horror!).
Não é assim que se faz.
Na minha visão, estagiário é alguém que pode ser um estudante do último ano ou alguém que realmente deseja 'entrar na área de TI'.
Com estudantes, é simples — descubra o que eles estão estudando na universidade, o que fizeram por conta própria, observe em quais questões os olhos deles brilham — se brilharem, pergunte por que especificamente DevOps e o que sabem sobre isso. Sinta a pessoa e entenda se será agradável trabalhar com ela e se você quer ensinar algo especificamente para ela.
Com aqueles que querem 'entrar na área de TI', as coisas são um pouco mais rigorosas — observe como a pessoa se autoaprende, o que fez antes de chegar até você para a entrevista. Uma boa opção é verificar o GitHub, se existir, a frequência dos commits e quais exercícios foram realizados. Pergunte também por que DevOps, afinal, o front-end é mais divertido e interessante?
Por fim, gostaria de oferecer mais uma vez um conselho: defina quem você realmente precisa e você encontrará imediatamente a pessoa certa. Identifique as necessidades, veja o profissional como um especialista, descubra seus pontos fortes e os utilize com sucesso em seu trabalho. Seja atencioso com o entrevistado, ele veio até você para um diálogo, e não para uma competição sobre quem se sai melhor ou pior.
Fonte: habr.com
