Não existe uma forma fiável de atribuir uma percentagem a um trabalho de engenharia que nunca foi medido, e inventar um número só para satisfazer o conselho genérico "quantifique o seu impacto" é pior do que deixar o número de fora, porque uma estatística inventada ou está errada ou é impossível de defender se alguém perguntar de onde veio. O que pode ser descrito com honestidade, mesmo sem uma métrica registada, é o âmbito: quão grande era o sistema, quantas pessoas ou serviços dependiam dele, com que frequência era executado, e o que mudou de facto entre um estado anterior e um estado posterior. São factos que normalmente conseguirá reconstruir a partir da memória, de um histórico de tickets ou de um relatório pós-incidente, e que soam muito mais credíveis a quem lê o currículo do que um número saído do nada.
Porque é que o conselho "basta acrescentar um número" falha sem uma métrica
A maior parte dos conselhos sobre currículos diz aos engenheiros para quantificarem cada linha, e o conselho não está errado em si: quem percorre dezenas de currículos reage de facto melhor a algo concreto do que a uma afirmação vaga. O problema é que muito trabalho de engenharia real nunca foi registado de uma forma que produza uma percentagem limpa. Muitas equipas não mantêm um painel de controlo para cada alteração, muito impacto sente-se em vez de se medir, e muitos engenheiros mudam de função antes de alguém voltar a verificar se a alteração do trimestre anterior ajudou de facto. Perante essa lacuna, o atalho tentador é escrever um número que soa mais ou menos certo e esperar que ninguém pergunte de onde veio. É exatamente essa armadilha que este artigo pretende ajudar a evitar, porque um número que quem entrevista consegue desmontar com uma única pergunta de seguimento causa mais dano do que nenhum número.
Medidas honestas que existem mesmo sem uma métrica registada
Existem vários tipos de detalhe concreto para praticamente qualquer trabalho de engenharia, quer tenha ou não sido registada uma métrica para ele. O âmbito descreve a dimensão daquilo que foi tocado: quantos serviços uma alteração abrangeu, a dimensão da base de código, quantos endpoints ou tabelas foram afetados. A escala descreve quanto o sistema suportava: quantos pedidos servia, quantos registos armazenava, quantas equipas construíam sobre ele, expresso em termos que se podem afirmar com confiança em vez de um número adivinhado. A frequência descreve com que regularidade algo era executado ou usado: uma tarefa em lote executada todas as noites, um pipeline de implementação usado por cada engenheiro da equipa, um relatório gerado a cada trimestre fechado. O estado antes e depois descreve o que era verdade antes da alteração e o que passou a ser depois, em linguagem simples em vez de percentagem: o que costumava falhar, o que costumava exigir um passo manual, o que costumava exigir alguém em regime de prevenção, e o que deixou de ser verdade assim que o trabalho foi implementado. Quem dependia disso identifica o público real: a equipa que usava a ferramenta construída, o serviço que chamava a API mantida, a prevenção que deixou de ser acionada pelo problema resolvido. Cada um destes pontos é algo vivido de facto e descritível em primeira mão, o que o torna bastante mais defensável do que uma percentagem arredondada.
Exemplo ilustrativo: uma linha reescrita em torno do âmbito em vez de uma percentagem
Antes, vaga e sem quantificação: "Responsável pelo desempenho do serviço de checkout." Depois, reescrita em torno do âmbito e de um estado antes/depois descrito em vez de um número inventado: "Responsável pela camada de consultas à base de dados do serviço de checkout, o único caminho por onde passava cada compra do site; antes da reescrita, as consultas lentas eram a causa mais comum de um checkout bloqueado que a equipa de suporte tinha de escalar, e depois da implementação essa categoria de reclamação deixou de aparecer na triagem semanal." Nada na versão reescrita é uma estatística adivinhada. Indica aquilo de que o candidato era responsável, quão central era essa parte para o sistema, como era o problema antes e o que mudou depois, tudo a partir de algo que o candidato de facto testemunhou e não de um número reconstruído posteriormente.
O que deixar de fora da reescrita
A linha a manter está entre um número que hoje se consegue apontar, vindo de um painel, de um relatório pós-incidente ou de uma métrica de facto acompanhada na altura, e um número reconstruído a partir de uma memória vaga do género "parecia que as coisas ficaram muito mais rápidas". O primeiro pode ser citado diretamente sem problema. O segundo é precisamente aquele que vale a pena reescrever usando antes linguagem de âmbito e de antes/depois, porque uma impressão recordada e arredondada para um número que soa bem é exatamente o tipo de afirmação que se desfaz perante uma única pergunta concreta numa entrevista. A versão baseada no âmbito acima resiste a essa pergunta, porque cada parte dela é algo descritível com as próprias palavras sem depender de um número nunca de facto registado.
Como isto se encaixa no padrão mais amplo de transformar funções em conquistas
Reescrever em torno do âmbito em vez de uma estatística inventada é uma aplicação específica de uma mudança mais ampla, que se aplica muito para lá da engenharia: transformar uma descrição daquilo de que se era responsável numa descrição do que de facto mudou como resultado. Transformar funções em conquistas no currículo aborda esse padrão de reescrita mais amplo com exemplos de funções fora da engenharia, para quem tem linhas que hoje se leem como uma lista de tarefas atribuídas em vez de resultados.
Redigir esta linha
Como escrever um currículo aborda as escolhas de redação que levam este tipo de reescrita ao resto do currículo, e o modelo developer do CVBuilderKit foi construído precisamente para este tipo de entrada centrada em âmbito e em projeto. Comece a partir de um documento existente ou em branco no construtor e reescreva cada linha usando o âmbito e um estado antes/depois descrito antes de recorrer a um número que, de facto, não se consegue defender.