Um currículo para uma função de DevOps ou engenharia de plataforma lê-se melhor quando dá destaque à fiabilidade, à responsabilidade de escala de prevenção, a migrações de infraestrutura e a ferramentas de que outras equipas dependem, em vez dos tópicos centrados em funcionalidades que um currículo geral de engenharia de software costuma usar. Os dois tipos de currículo partilham a maior parte da mesma estrutura: experiência por ordem cronológica inversa, um resumo curto, uma secção de competências e tópicos que descrevem resultados em vez de tarefas. O que muda é que resultados realmente impressionam neste tipo de função, já que quem beneficia do trabalho de infraestrutura costuma ser outros engenheiros e não utilizadores finais, e o próprio trabalho fica muitas vezes invisível quando corre bem.
Porque muda o foco
Uma funcionalidade construída por um engenheiro de software tem normalmente um antes e depois visível: um ecrã que não existia, um percurso que passava de cinco passos para dois. O trabalho de infraestrutura e plataforma raramente alcança esse mesmo resultado visível, porque o melhor resultado possível é muitas vezes que nada mude do ponto de vista do utilizador: uma implementação que antes acordava alguém às duas da manhã já não o faz, um serviço que caía sob carga já não cai. Um currículo para este tipo de função tem de tornar essa fiabilidade invisível compreensível para um leitor que nunca trabalhou em infraestrutura, nomeando o que dependia do trabalho e o que teria falhado sem ele.
Descrever a fiabilidade e o tempo de atividade com honestidade
O trabalho de fiabilidade convida à mesma armadilha descrita em quantificar o impacto de engenharia no currículo sem inventar números: um número tentador mas não verificável como "melhorou o tempo de atividade em 40%" quando esse número nunca foi realmente acompanhado. Onde existe uma métrica real, ainda hoje verificável a partir de um painel ou de um relatório de incidente, tem o seu lugar no currículo tal como está. Onde não existe, o âmbito e um estado antes-e-depois descrito pesam o mesmo sem o risco.
Escala de prevenção e resposta a incidentes como conteúdo do currículo
A responsabilidade de escala de prevenção merece ser referida diretamente em vez de escondida numa linha vaga como "apoio a sistemas de produção", porque sinaliza um nível de responsabilidade operacional que uma função puramente centrada em funcionalidades não tem. O que se lê bem é a forma dessa responsabilidade: para que sistema ou sistemas estava de prevenção, como funcionava a rotação a grandes traços, e uma coisa concreta que mudou graças a um incidente que resolveu.
Migrações e alterações de infraestrutura que valem a pena referir
Uma migração, uma alteração de plataforma ou uma troca de ferramenta merece o seu próprio tópico quando é o tipo de projeto a que outros engenheiros tiveram de se adaptar, em vez de uma alteração puramente interna que ninguém fora da equipa notou. Referir o que mudou e porquê fornece normalmente mais informação do que apenas mencionar o nome da tecnologia de destino.
Ferramentas de que outras equipas dependem
Uma ferramenta interna merece o mesmo tratamento de uma funcionalidade voltada para o cliente: o que faz, quem a usa, o que substituiu. Apresentar projetos pessoais num currículo de engenheiro de software aborda a mesma estrutura subjacente para trabalho construído fora de um emprego formal, e aplica-se igualmente bem a uma ferramenta interna construída dentro de um emprego.
Exemplo ilustrativo: um tópico reescrito em torno da responsabilidade de infraestrutura
Antes, vago e orientado a funcionalidades: "Trabalhei em infraestrutura e implementação para a equipa de backend." Depois, reescrito em torno de responsabilidade, âmbito e um estado antes-e-depois descrito: "Responsável pela pipeline de implementação dos onze serviços da equipa de backend; antes a pipeline exigia um passo de aprovação manual por cada serviço antes da implementação, e após a reescrita, um conjunto de testes bem-sucedido bastava para implementar automaticamente, reduzindo de três para um o número de engenheiros que precisavam de estar disponíveis no momento do lançamento."
Agrupar uma lista longa de ferramentas e plataformas
A secção de competências de um engenheiro de plataforma costuma ser mais longa do que a de um programador típico, abrangendo ao mesmo tempo fornecedores de cloud, ferramentas de orquestração, sistemas de monitorização e linguagens, exatamente o tipo de lista longa e mista que beneficia de agrupamento por categorias em vez de uma única linha sem ordem.
Crie o seu
O modelo Developer da CVBuilderKit é construído em torno de entradas orientadas por projetos e responsabilidade, o que serve tanto para trabalho de infraestrutura e plataforma como para código de aplicações. Comece a partir dele, ou de um documento em branco, em o criador e reescreva os seus tópicos de fiabilidade, escala de prevenção e migração em torno do que realmente dependia do trabalho antes de recorrer a um número que atualmente não consegue comprovar.