Um currículo para uma função de analista ou cientista de dados difere de um currículo de engenheiro de software generalista sobretudo naquilo que recebe destaque, não na sua forma básica. A experiência por ordem cronológica inversa, um resumo curto e pontos centrados em resultados continuam a aplicar-se, mas um currículo centrado em dados começa pela pergunta que uma análise respondeu e pela decisão que mudou, indicando com honestidade a dimensão e a origem dos dados, em vez de se apoiar no processo ou no modelo que produziu a resposta. Um painel concluído, um modelo treinado ou um processo bem construído não é, por si só, o resultado que merece constar num currículo; a decisão que uma equipa tomou de forma diferente por causa disso é que merece.
Porque muda a ênfase no trabalho centrado em dados
O currículo de um engenheiro de software generalista costuma ser reconhecido pelo que foi lançado: uma funcionalidade, um serviço, um sistema que agora funciona em produção e que alguém consegue apontar. O trabalho centrado em dados traz frequentemente um tipo diferente de resultado. Um relatório que uma equipa de liderança usou para escolher entre dois planos, uma segmentação que mudou a forma como um orçamento de marketing foi repartido, uma verificação que assinalou um problema real num conjunto de dados antes de chegar a um sistema a jusante, nada disso aparece da mesma forma que uma funcionalidade lançada. Um currículo para este tipo de função tem de declarar a decisão explicitamente, em vez de presumir que quem lê liga sozinho um gráfico ou um modelo ao que aconteceu depois. Esta abordagem importa sobretudo nas funções de analista e cientista de dados, onde o resultado diário é frequentemente a resposta a uma pergunta que alguém realmente colocou, não uma funcionalidade com que um utilizador interage diretamente.
Nomear a pergunta que um projeto respondeu, não apenas a ferramenta usada
Um ponto que começa pela ferramenta, "Construí um modelo de previsão de churn em Python com scikit-learn", diz a quem lê que tecnologia esteve envolvida antes de dizer o que quer que seja sobre porque é que o trabalho importava. Um ponto que começa pela pergunta que o trabalho respondeu dá o benefício ao leitor primeiro: qual dos vários passos de integração previa melhor um cliente cancelar em dois meses, se uma alteração de preços proposta reduziria de forma plausível os registos numa determinada região, qual de duas alterações de produto concorrentes uma equipa deveria priorizar. A ferramenta continua a ter lugar no ponto, só que mais tarde, quando quem lê já sabe porque é que a análise existia em primeiro lugar. Esta ordem importa mais no trabalho centrado em dados do que numa grande parte do trabalho de engenharia geral, porque a pergunta que uma análise foi construída para responder é frequentemente o elemento mais legível para quem lê fora da equipa.
Descrever os dados com honestidade: dimensão, origens e âmbito
Indicar a dimensão e a forma dos dados com que um projeto realmente trabalhou dá a quem lê uma noção de escala sem precisar de um número de precisão inventado. Uma descrição honesta nomeia coisas de que realmente se recorda ou pode verificar: aproximadamente quantos registos ou linhas estavam envolvidos, quantas fontes distintas foram combinadas para construir o conjunto de dados, até onde os dados recuavam no tempo, e se o trabalho correu uma única vez como análise pontual ou de forma recorrente segundo um calendário. Declarar o âmbito com honestidade, por exemplo "combinei dados de três sistemas internos que cobrem cerca de dois anos de atividade", resiste a uma pergunta de seguimento de uma forma que uma estatística inventada e impossível de verificar sobre o impacto da análise não resiste. Quando uma análise mudou realmente uma métrica acompanhada e esse número ainda é algo que se pode apontar, merece constar no currículo tal como é; quando não é esse o caso, o âmbito e a decisão que informou sustentam o ponto igualmente bem por si só.
Agrupar ferramentas pela etapa do processo em que se situam
A lista de ferramentas de uma função de dados abrange frequentemente uma linguagem de consulta, uma biblioteca de modelação, uma ferramenta de visualização e um sistema de agendamento ou orquestração ao mesmo tempo, e agrupar essa lista pela etapa do processo em que cada ferramenta se situa, ingestão, transformação, análise e modelação, depois relatórios ou visualização, dá a quem lê uma leitura mais rápida da forma da experiência de um candidato do que uma linha longa sem ordenação. Quem procura alguém confortável a assumir um processo de ponta a ponta consegue ver essa forma de imediato a partir de quatro grupos curtos por etapa do processo, e quem procura especificamente experiência de modelação pode ir diretamente a esse grupo em vez de ler para além de uma ferramenta de agendamento e uma de visualização para o encontrar.
Exemplo ilustrativo: um ponto construído em torno de uma decisão que informou
Exemplo ilustrativo, antes e depois. Antes, guiado pela ferramenta: "Usei SQL e Python para analisar dados de utilização de clientes e construir um modelo de churn." Depois, guiado pela pergunta e pela decisão: "Analisei cerca de dezoito meses de dados de utilização em duas linhas de produto para identificar que passo de integração previa melhor o cancelamento em sessenta dias; a conclusão levou a equipa de produto a redesenhar esse único passo em vez de todo o fluxo de integração." Nada na versão reescrita inventa uma percentagem ou um resultado que a pessoa não conseguisse realmente descrever; declara a pergunta, o âmbito aproximado dos dados e a decisão que a conclusão mudou, tudo coisas que a pessoa realmente testemunhou.
Onde quantificar o impacto ainda se aplica
A mesma cautela contra inventar um número aplica-se aqui como em qualquer outro ponto do currículo: um número real, atualmente verificável a partir de um painel ou de um relatório, merece ser declarado diretamente, uma impressão recordada e arredondada numa percentagem limpa não. Quantificar o impacto de engenharia num currículo sem inventar números trata esta distinção com mais detalhe, e a mesma abordagem de âmbito e decisão aplica-se tão bem a um ponto centrado em dados como a um ponto de engenharia geral.
Crie o seu
O modelo Developer da CVBuilderKit está construído em torno de entradas guiadas por projetos e resultados, o que serve tão bem a lista de projetos de um analista ou cientista de dados como serve código de aplicação. Comece a partir dele, ou de um documento em branco, no editor, e faça cada ponto começar pela pergunta que um projeto respondeu antes de nomear a ferramenta que a respondeu.