Tiempo estimado de lectura: 4 min
- Ideas clave:
- Un portafolio debe estar desplegado y ser interactivo: un repo sin deploy parece inacabado.
- Evita proyectos clonados sin valor propio: extiende, añade persistencia real y automatizaciones.
- La higiene del repo (commits, lint, README) y métricas de rendimiento son señales decisivas para reclutadores.
- Cada proyecto necesita contexto: problema, desafíos, solución y resultados para evaluar tu rol y criterio.
Introducción
Si quieres que un Tech Lead o un reclutador técnico te dé 30 segundos de atención, evita estos puntos fatales: 5 errores en tu portafolio que hacen que los reclutadores te descarten. No es cuestión de ego: es criterio. Tu portafolio debe demostrar capacidad para entregar software completo, mantenible y pensado para usuarios reales.
A continuación reviso cada error con ejemplos concretos y pasos accionables para arreglarlo hoy mismo.
Errores (visión general)
Estos cinco errores cubren la mayoría de rechazos rápidos: ausencia de deploy, proyectos repetidos, repositorios sin higiene, ignorar rendimiento y no dar contexto sobre tu rol y decisiones.
1) Error: Repo-only — no hay deploy público
Por qué descarta: pedir a alguien que clone, instale dependencias y configure .env es pedir demasiado. Si tu proyecto no está vivo, parece inacabado.
Cómo arreglarlo:
- Frontend: despliega en Vercel o Netlify. Conecta el repo y tendrás CI/CD automático.
- Fullstack: usa Railway o Render para apps con base de datos.
- Si el deploy es complejo, añade un video demo (Loom) de 90s mostrando el flujo y las partes críticas.
- Incluye un enlace “Live demo” visible en tu README y en tu web personal.
Resultado esperado: el reclutador entra a una URL, interactúa y juzga tu producto, no tu README.
2) Error: Proyectos clonados de tutorial (Tutorial Hell)
Por qué descarta: miles tienen el mismo to-do o clon de Netflix. No muestra iniciativa ni resolución de problemas reales.
Cómo arreglarlo:
- Extiende: añade autenticación real (Clerk, Auth0 o Supabase Auth — Supabase).
- Añade persistencia real y migraciones (Postgres en Supabase).
- Incorpora automatizaciones: conecta acciones a un workflow en n8n para notificaciones, integraciones o pipelines.
- Integra un pequeño componente de IA (p. ej. sugerencias automáticas con OpenAI) para mostrar cómo orquestas APIs.
Resultado esperado: un proyecto transformado en MVP, con decisiones de producto y arquitectura justificadas.
3) Error: GitHub vertedero — commits y código sucio
Por qué descarta: commits como “fix” o “final” y logs de debugging muestran falta de hábitos profesionales.
Cómo arreglarlo:
- Mensajes significativos: adopta Conventional Commits.
- Ejemplos:
feat(auth): add magic link login,fix(api): handle null response.
- Ejemplos:
- Calidad automática: configura ESLint + Prettier y husky con lint-staged para bloquear commits que no pasen checks.
- README ejecutivo: qué hace, por qué elegiste el stack, cómo ejecutar en 3 pasos y dónde ver la demo.
Ejemplo simple de hook:
{
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.js": ["eslint --fix", "prettier --write", "git add"]
}
}Resultado esperado: un repositorio que un equipo puede clonar y entender en minutos.
4) Error: Ignorar rendimiento y arquitectura
Por qué descarta: un sitio lento o con CLS alto demuestra desconocimiento de experiencia de usuario y escala.
Cómo arreglarlo:
- Mide primero con Lighthouse. Apunta a LCP < 2.5s y CLS < 0.1.
- Optimiza imágenes (WebP,
srcset/<Image />en Next.js), usa lazy loading y divide bundles. - Revisa el backend: evita N+1 queries, usa índices y paginación.
- Documenta cambios: “Reducí LCP de 4s a 1.8s migrando a WebP y estableciendo fetchpriority=high”.
Resultado esperado: métricas reales que respalden tus decisiones.
5) Error: Falta de contexto — galería sin historia
Por qué descarta: imágenes bonitas no cuentan si no explicas tu rol, desafío técnico ni decisiones.
Cómo arreglarlo:
- Cada proyecto debe tener un case study corto:
- Problema que resolvías.
- Desafío(s) técnico(s).
- Solución implementada (tech + porqué).
- Resultados o aprendizajes (métricas si hay).
- Incluye diagrama simple de arquitectura (Draw.io o un PNG) y captura de la pipeline CI/CD.
Resultado esperado: el reclutador entiende qué hiciste, cómo piensas y qué aportarías al equipo.
Checklist inmediato (haz esto hoy)
- [ ] Despliega tu proyecto más importante y añade el link en README.
- [ ] Refactoriza 1 repositorio: limpia
console.log, mejora nombres y añade README. - [ ] Configura Husky + lint-staged y obliga Conventional Commits.
- [ ] Crea un case study para tu proyecto estrella (máx. 400 palabras).
- [ ] Corre Lighthouse y documenta 1 mejora de rendimiento.
Tu portafolio es tu carta de presentación técnica. No se trata de impresionar con muchas tecnologías, sino de demostrar que puedes entregar software limpio, desplegado y con criterio. Aplica estas correcciones y tu próxima revisión no será un cierre de pestaña, será una invitación a la entrevista.
Dominicode Labs
Si trabajas con automatizaciones, workflows o incorporación de IA —temas mencionados en este artículo— puedes encontrar recursos y experimentos relacionados en Dominicode Labs. Es una continuación natural para explorar plantillas y ejemplos prácticos de integración entre apps, pipelines y componentes de IA.
FAQ
- ¿Por qué debo desplegar un proyecto aunque sea pequeño?
- ¿Cómo demuestro que mi proyecto no es solo un tutorial clonado?
- ¿Qué son Conventional Commits y por qué importan?
- ¿Qué métricas de rendimiento debo mostrar?
- ¿Qué debe incluir un case study corto?
- ¿Es necesario añadir una pipeline CI/CD visible?
¿Por qué debo desplegar un proyecto aunque sea pequeño?
Porque un deploy permite al reclutador interactuar con tu producto y evaluar la experiencia real. Pedir que clonen el repo añade fricción y reduce la probabilidad de revisión.
¿Cómo demuestro que mi proyecto no es solo un tutorial clonado?
Extiende el proyecto con características reales: autenticación, persistencia con migraciones, integraciones o automatizaciones. Documenta las decisiones de producto y arquitectura para mostrar criterio.
¿Qué son Conventional Commits y por qué importan?
Son un estándar para mensajes de commit que facilita entender cambios, generar changelogs y coordinar trabajo en equipo. Mensajes claros muestran hábitos profesionales y mejoran mantenimiento.
¿Qué métricas de rendimiento debo mostrar?
Mide con Lighthouse y apunta a objetivos prácticos: LCP < 2.5s y CLS < 0.1. Documenta las mejoras que hiciste y cómo las lograron (optimización de imágenes, lazy loading, etc.).
¿Qué debe incluir un case study corto?
Problema que resolvías, desafíos técnicos, solución implementada (tech + porqué) y resultados o aprendizajes. Incluye métricas y un diagrama simple si es posible.
¿Es necesario añadir una pipeline CI/CD visible?
Sí: una pipeline mostrable (captura o enlace) demuestra que piensas en entrega continua, tests y despliegue reproducible. Facilita la evaluación técnica del proyecto.
Leave a Reply