Un currículum para un puesto de analista o científico de datos se diferencia de un currículum de ingeniero de software generalista sobre todo en lo que se prioriza, no en su forma básica. La experiencia en orden cronológico inverso, un resumen breve y viñetas centradas en resultados siguen aplicando, pero un currículum centrado en datos encabeza con la pregunta que respondió un análisis y la decisión que cambió, y describe con honestidad el tamaño y la fuente de los datos, en lugar de apoyarse en el proceso o el modelo que produjo la respuesta. Un panel terminado, un modelo entrenado o un proceso bien construido no es en sí mismo el resultado que merece aparecer en un currículum; la decisión que un equipo tomó de forma distinta gracias a ello sí lo es.
Por qué cambia el énfasis en el trabajo centrado en datos
El currículum de un ingeniero de software generalista suele reconocerse por lo que se lanzó: una función, un servicio, un sistema que ahora funciona en producción y que alguien puede señalar. El trabajo centrado en datos suele tener un tipo de beneficio distinto. Un informe que un equipo directivo usó para elegir entre dos planes, una segmentación que cambió cómo se repartió un presupuesto de marketing, una comprobación que detectó un problema real en un conjunto de datos antes de que llegara a un sistema posterior, nada de eso se ve de la misma forma que una función lanzada. Un currículum para este tipo de puesto tiene que declarar la decisión explícitamente, en lugar de asumir que quien lo lee conectará por sí mismo un gráfico o un modelo con lo que ocurrió después. Este enfoque importa especialmente en los puestos de analista y científico de datos, donde el resultado diario suele ser la respuesta a una pregunta que alguien realmente planteó, no una función con la que un usuario interactúa directamente.
Nombrar la pregunta que respondió un proyecto, no solo la herramienta usada
Una viñeta que empieza por la herramienta, "Construí un modelo de predicción de cancelación de clientes en Python con scikit-learn", le dice al lector qué tecnología estaba implicada antes de decirle nada sobre por qué importaba el trabajo. Una viñeta que empieza por la pregunta que respondió el trabajo le da al lector el beneficio primero: qué paso de incorporación, entre varios, predecía mejor la cancelación de un cliente en dos meses, si un cambio de precios propuesto reduciría de forma plausible los registros en una región determinada, cuál de dos cambios de producto en competencia debería priorizar un equipo. La herramienta sigue teniendo su lugar en la viñeta, solo que más tarde, una vez que el lector ya sabe por qué existía el análisis en primer lugar. Este orden importa más en el trabajo centrado en datos que en gran parte del trabajo de ingeniería general, porque la pregunta que un análisis se construyó para responder suele ser lo más legible para alguien fuera del equipo.
Describir los datos con honestidad: tamaño, fuentes y alcance
Nombrar el tamaño y la forma de los datos con los que realmente trabajó un proyecto le da al lector una idea de la escala sin necesitar una cifra de precisión inventada. Una descripción honesta nombra cosas que realmente puedes recordar o comprobar: aproximadamente cuántos registros o filas estaban implicados, cuántas fuentes distintas se combinaron para construir el conjunto de datos, hasta cuándo se remontaban los datos, y si el trabajo se ejecutó una sola vez como un análisis puntual o de forma recurrente según un calendario. Declarar el alcance con honestidad, por ejemplo "combiné datos de tres sistemas internos que cubrían aproximadamente dos años de actividad", aguanta una pregunta de seguimiento de una forma en la que no lo hace una estadística inventada e imposible de verificar sobre el impacto del análisis. Cuando un análisis realmente cambió una métrica seguida y esa cifra sigue siendo algo que puedes señalar, merece aparecer en el currículum tal cual; cuando no es así, el alcance y la decisión que informó sostienen la viñeta igual de bien por sí solos.
Agrupar las herramientas según su lugar en el proceso
La lista de herramientas de un puesto de datos suele abarcar a la vez un lenguaje de consulta, una biblioteca de modelado, una herramienta de visualización y un sistema de programación u orquestación, y agrupar esa lista según el lugar que ocupa cada herramienta en el proceso, ingesta, transformación, análisis y modelado, y después informes o visualización, le da al lector una lectura más rápida de la forma de la experiencia de un candidato que una línea larga sin ordenar. Alguien que busca a una persona cómoda liderando un proceso de principio a fin puede ver esa forma de inmediato en cuatro grupos breves por etapa del proceso, y alguien que busca específicamente experiencia en modelado puede ir directo a ese grupo en lugar de leer pasando por una herramienta de programación y otra de visualización para encontrarla.
Ejemplo ilustrativo: una viñeta construida alrededor de una decisión que informó
Ejemplo ilustrativo, antes y después. Antes, guiado por la herramienta: "Usé SQL y Python para analizar datos de uso de clientes y construir un modelo de cancelación." Después, guiado por la pregunta y la decisión: "Analicé aproximadamente dieciocho meses de datos de uso en dos líneas de producto para identificar qué paso de incorporación predecía mejor la cancelación en sesenta días; el hallazgo llevó al equipo de producto a rediseñar ese único paso en lugar de todo el flujo de incorporación." Nada en la versión reescrita inventa un porcentaje o un resultado que la persona no pudiera describir realmente; declara la pregunta, el alcance aproximado de los datos y la decisión que cambió el hallazgo, todo cosas que la persona vivió de verdad.
Dónde sigue aplicando cuantificar el impacto
La misma cautela contra inventar una cifra aplica aquí igual que en cualquier otro punto de un currículum: una cifra real, verificable ahora mismo desde un panel o un informe, merece declararse directamente, y una impresión recordada redondeada a un porcentaje limpio no. Cuantificar el impacto en ingeniería en un currículum sin inventar cifras cubre esta distinción con más detalle, y el mismo enfoque de alcance y decisión aplica igual de bien a una viñeta centrada en datos que a una de ingeniería general.
Crea el tuyo
La plantilla Developer de CVBuilderKit está construida alrededor de entradas guiadas por proyectos y resultados, lo que encaja tan bien con la lista de proyectos de un analista o científico de datos como con código de aplicación. Empieza desde ella, o desde un documento en blanco, en el editor, y haz que cada viñeta empiece por la pregunta que respondió un proyecto antes de nombrar la herramienta que la respondió.