/ Documentar proyectos ML / Crecer profesionalmente
Cómo usar tu proyecto de machine learning para crecer profesionalmente
Un proyecto de ML bien documentado y presentado vale más en una búsqueda de empleo que diez proyectos mal explicados.
"Siempre les preguntamos sobre sus proyectos. Intentamos evaluar sus habilidades técnicas, pero también queremos asegurarnos de que sean capaces de hablar sobre el proyecto y los resultados de una manera comprensible." Esta frase de Michael Hupp, manager de data science en G2 Crowd, resume lo que los reclutadores realmente evalúan cuando revisan un portafolio de ML (Dataquest — Data Science Portfolio Guide).
El portafolio no es el código. Es la capacidad de comunicar el razonamiento detrás del código. Un notebook con resultados excelentes que nadie puede leer en dos minutos no compite con un proyecto bien documentado que explica el problema, las decisiones y el impacto de forma que cualquier reclutador técnico puede evaluar.
Este artículo trata el proyecto terminado como un activo de carrera y explica las tres transformaciones que lo convierten en uno: de notebook a README que cuenta una historia, de tesis a caso de estudio presentable, y de proyecto individual a señal de autoridad en LinkedIn.
Tabla de contenido:
Lo que los reclutadores realmente evalúan en un portafolio de ML
Los reclutadores técnicos en ML evalúan tres cosas al revisar un portafolio, en este orden: si el candidato puede formular problemas reales, si puede tomar decisiones técnicas justificadas, y si puede comunicar los resultados de forma que un equipo no técnico los entienda. El código es el último factor, no el primero.
Esto contradice la intuición de la mayoría de los candidatos, que invierten la mayor parte del tiempo en mejorar el modelo y muy poco en documentar el razonamiento detrás de las decisiones. He visto esta asimetría repetirse en decenas de proyectos: candidatos que habían construido modelos técnicamente sólidos pero que no podían explicar por qué habían elegido ese dataset, por qué esa métrica, o por qué ese modelo sobre las alternativas.
La pregunta que define si un proyecto de portafolio funciona: ¿puede alguien leer el README en dos minutos y entender el problema que se resolvió, la decisión más relevante que se tomó, y el resultado que se obtuvo? Si la respuesta es no, el proyecto técnico no importa.
¿Tu portafolio no está generando entrevistas?
Si tienes proyectos en GitHub pero no recibes respuesta de los reclutadores, o si en las entrevistas no puedes hablar de tus proyectos con fluidez, puedo revisar tu portafolio y decirte exactamente qué cambiaría para que funcione.
Termina ya tu proyecto
Ya tomaste cursos… pero no sabes cómo aplicarlo
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro · Acceso inmediato
Las tres transformaciones del proyecto al activo de carrera
Transformación 1: De notebook a README que cuenta una historia
El README es la primera y frecuentemente la única cosa que un reclutador lee en un repositorio. Si el README no comunica el proyecto en dos minutos, el reclutador pasa al siguiente candidato.
La estructura mínima que funciona: el problema real que se resolvió (en una línea), por qué ML era la herramienta apropiada para ese problema, la decisión técnica más relevante que se tomó y por qué, el resultado principal con su contexto (no solo el número), y la limitación principal que el candidato reconoce. Esta estructura de cinco elementos hace que el proyecto cuente una historia en lugar de listar componentes.
El error más frecuente en READMEs de proyectos ML: documentar cómo correr el código en lugar de documentar qué problema resuelve. Las instrucciones de instalación y ejecución son necesarias, pero van al final, no al inicio.
Transformación 2: De tesis a caso de estudio presentable
Una tesis de 80 páginas no se puede presentar en una entrevista de 30 minutos. Pero tampoco es necesario: lo que el entrevistador necesita es el caso de estudio, no el documento completo.
El caso de estudio de entrevista tiene exactamente cinco elementos: el problema en una frase, los datos disponibles y su limitación principal, la decisión técnica que no era obvia y por qué se tomó, el resultado clave con su contexto de impacto, y la lección más importante que se aprendió. Estos cinco elementos caben en cinco diapositivas o en cinco minutos de conversación.
Qué cortar sin perder rigor: el código, las ecuaciones y los apéndices. Qué nunca cortar: el problema, la decisión no obvia y la limitación honesta. Un candidato que admite las limitaciones de su propio trabajo demuestra más madurez técnica que uno que presenta el modelo como infalible.
Transformación 3: De proyecto individual a señal de autoridad en LinkedIn
LinkedIn no es un CV — es una plataforma de contenido. Un post sobre un proyecto de ML que muestra el razonamiento detrás de una decisión técnica genera más visibilidad que actualizar el perfil con el proyecto en la sección de experiencia.
La estructura que genera engagement sin sonar autopromocionado: describir el problema en términos que quien no es técnico pueda entender, explicar una decisión que no era obvia y el trade-off que implicó, compartir el resultado concreto con su limitación honesta, y cerrar con la pregunta o la lección que dejó el proyecto. Esta estructura funciona porque da valor a quien lee, no solo promociona al autor.
Cuántos proyectos necesitas realmente
La respuesta basada en la evidencia de reclutadores: 3-5 proyectos sólidos superan a 15 proyectos superficiales. En Quora, una respuesta votada positivamente miles de veces lo formula directamente: "Nobody will pay you to do something you've never done before" — la demostración de competencia, no el volumen, es lo que convence (Quora — Data Science Portfolio).
Un proyecto bien documentado que muestra que el candidato puede pensar el problema de principio a fin — desde la formulación hasta las limitaciones — es más valioso que una colección de notebooks donde cada uno reproduce un tutorial de Kaggle. La diferencia no es técnica. Es comunicacional.
El criterio para decidir qué proyectos incluir: ¿puedes hablar de este proyecto durante 10 minutos en una entrevista técnica sin leer notas? Si no, el proyecto no está listo para el portafolio, independientemente de qué tan buenas sean sus métricas.
Termina ya tu proyecto
Ya tomaste cursos… pero no sabes cómo aplicarlo
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro · Acceso inmediato
Señales de que tu portafolio actual no está funcionando
Estas son las señales concretas — detectadas en foros y en revisiones reales de portafolios — que indican que el portafolio tiene un problema de comunicación, no de calidad técnica:
- Aplicas a posiciones y no recibes respuesta aunque tienes los proyectos en el perfil.
- En entrevistas te preguntan sobre los proyectos y no puedes hablar de ellos con fluidez durante más de dos minutos.
- Tu GitHub tiene actividad pero no cuenta una historia coherente de qué problemas puedes resolver.
- Los proyectos en tu CV no están conectados con el tipo de roles que buscas — datasets genéricos en lugar de problemas del dominio donde quieres trabajar.
- Los READMEs de tus proyectos explican cómo instalar las dependencias pero no explican por qué el proyecto existe.
Cada una de estas señales tiene una solución técnica específica. Ninguna requiere construir proyectos nuevos desde cero — todas se resuelven mejorando cómo se documenta y presenta el trabajo que ya existe.
Preguntas frecuentes sobre portafolio y carrera en ML
¿GitHub es obligatorio para conseguir trabajo en data science?
Para roles técnicos en ML, sí es prácticamente necesario. Pero lo que importa no es la cantidad de repositorios sino la calidad de cómo están documentados. Un proyecto con un README claro vale más que veinte notebooks sin contexto.
¿Qué tipo de proyectos valoran más los reclutadores?
Los proyectos propios sobre problemas reales, seguidos por tesis bien documentadas. Los proyectos de Kaggle con datasets estándar tienen poco valor diferenciador porque los tienen todos los candidatos. Lo que distingue es demostrar que se puede formular el problema, no solo ejecutar el modelo.
¿Cómo presento un proyecto en entrevistas si mis resultados no son perfectos?
Con honestidad y análisis. Los entrevistadores no esperan resultados perfectos — esperan que el candidato entienda por qué obtuvo los resultados que obtuvo. Un modelo mediocre bien analizado demuestra más madurez técnica que uno con buenas métricas que el candidato no puede defender.
¿Sirve incluir proyectos de cursos en el portafolio?
Solo si están significativamente extendidos más allá del ejercicio del curso. Un proyecto de curso que se queda en el dataset del tutorial no añade valor diferenciador. El mismo proyecto replicado con datos propios, o con un análisis extendido de las limitaciones, ya es diferente.
¿Cómo diferencio mi portafolio si todos tienen los mismos datasets?
Usando datos de problemas reales de tu área de interés o experiencia previa. Si no tienes acceso a datos propios, el diferenciador no es el dataset sino la profundidad del análisis y la claridad del README. Un proyecto sobre Titanic con un README excepcional puede superar a un proyecto con datos únicos pero sin contexto.
Si tienes proyectos terminados pero tu portafolio no está generando las entrevistas que esperas, puedo revisarlo y decirte exactamente qué cambiaría. También puedo ayudarte a preparar cómo hablar de tus proyectos en entrevistas técnicas.
Termina ya tu proyecto
Ya tomaste cursos… pero no sabes cómo aplicarlo
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro · Acceso inmediato