Programa Especializado en Software
Lee el mercado técnico, demuestra cómo trabajas y prepárate para la evaluación técnica
Al terminar vas a saber qué pide realmente el mercado para tu rol, qué evidencia técnica necesitas mostrar y cómo prepararte para live coding, system design y take-homes sin estudiar al azar.
Tu stack consigue atención. Tu evidencia y tu forma de pensar deciden cuánto más quieren evaluarte.
Antes de empezar
En un proceso técnico llega un momento en el que tu candidatura deja de ser solamente un CV.
Alguien de ingeniería revisa tu experiencia, tu stack, los proyectos que puedes mostrar y, sobre todo, la coherencia entre lo que dices que sabes hacer y la evidencia disponible.
No siempre será un tech lead. Puede ser un engineering manager, un senior engineer o cualquier persona del equipo que participe en la evaluación. Y tampoco existe un cronómetro universal: nadie necesita exactamente tres minutos para decidir qué piensa de tu perfil.
Pero esa primera revisión suele ser rápida por una razón sencilla: quien evalúa necesita decidir si hay suficientes señales para invertir más tiempo en conocerte. Revisar candidatos normalmente compite con muchas otras responsabilidades dentro de ingeniería, así que cuanto más fácil sea entender tu perfil, mejor.
Por eso un perfil técnico fuerte no intenta demostrar todo lo que sabes. Hace algo más útil: permite entender rápidamente qué construyes, con qué tecnologías trabajas, qué tipo de problemas sabes resolver y qué nivel de profundidad puedes defender.
Este programa asume que ya trabajaste tu CV, LinkedIn, búsqueda, entrevistas y negociación en el programa principal. Nada de eso se repite aquí. Nos concentramos exclusivamente en la capa técnica: cómo leer el mercado, cómo presentar evidencia de tu trabajo y cómo prepararte para las evaluaciones que realmente aparecen en procesos de software.
Lo que vas a poder hacer al terminar
Construir una muestra de vacantes de tu rol y detectar qué tecnologías aparecen de forma consistente
Separar requisitos centrales de nice to have
Combinar stack y dominio para posicionar mejor tu experiencia
Auditar tu GitHub o construir evidencia alternativa si tu código profesional es privado
Practicar un live coding haciendo visible tu razonamiento
Estructurar una conversación de system design antes de empezar a dibujar arquitectura
Entregar un take-home que otra persona pueda levantar, revisar y entender sin depender de ti
Diagnosticar qué fundamentos técnicos necesitas reforzar y convertir esas brechas en un plan de práctica de cuatro semanas
Lo que se trabaja, lección por lección
- 01El mercado real: qué stacks contrata EE. UU. desde LATAM
- 02GitHub y portafolio: qué mira alguien técnico cuando abre tu perfil
- 03Live coding: cómo pensar mientras programas
- 04System design: cómo estructurar antes de dibujar cajas
- 05Take-home: cómo entregar código que otra persona puede evaluar
- 06Tu plan de preparación técnica
Con qué sales de este módulo
Cada módulo termina en algo que queda hecho, no en apuntes:
- Mapa de demanda de tu rol · hoja de cálculo
- Perfil de GitHub o portafolio técnico auditado · enlace
- Grabación de una práctica de live coding · archivo
- Plantilla de system design · documento
- Plantilla de README para take-homes · documento
- Plan de práctica de cuatro semanas · documento
- Banco técnico de 40 preguntas clasificado en A/B/C · documento
Lo que no te garantiza esto
Un GitHub ordenado no sustituye experiencia que todavía no tienes. Un buen README no convierte seis meses de Java en cuatro años de Java, y si la empresa busca esos cuatro años, ninguna plantilla cambia esa decisión.
Tampoco hay forma de leer el mercado que garantice que el mercado te elija. Tu mapa te dice dónde hay demanda, no si vas a quedar en una vacante: hay presupuestos que se congelan y prioridades que cambian a mitad del proceso. Y practicar entrevistas no garantiza que una empresa concreta te contrate.
Lo que sí puedes evitar es perder oportunidades por problemas corregibles:
- no saber qué pide tu mercado;
- presentar evidencia que no representa tu nivel;
- resolver en silencio;
- dibujar arquitectura antes de entender el problema;
- entregar un proyecto que nadie puede ejecutar;
- estudiar muchas cosas que tu proceso nunca va a evaluar.
Preguntas frecuentes
1. Mi código pertenece a mi empleador y mi GitHub está vacío. ¿Eso me descarta? No, y publicarlo para llenarlo sí te puede meter en un problema serio. La alternativa es el caso técnico escrito de la lección 2, más un repo propio pequeño y terminado.
2. ¿Cuánto pesa el título universitario frente al portafolio? Depende del proceso y no hay regla única. Mientras más experiencia demostrable tienes, menos pesa el título y más pesa la evidencia. Hay empresas que filtran por título y no lo vas a saber de antemano.
3. ¿Tengo que prepararme para system design aunque sea junior? Solo si aparece en los procesos de las empresas de tu mapa. El formato gana peso con el seniority y en roles que piden decisiones de arquitectura. Estudiarlo porque el programa lo incluye, y no porque tu mercado lo pida, es justo el error que la lección 6 intenta evitar.
4. ¿Aprendo el stack que veo en todos lados o profundizo el que ya uso? Míralo en tu mapa de demanda. Si tu stack aparece con volumen sostenido, profundizar y sumarle un dominio suele rendir más rápido. Cambiar de stack es una decisión de largo plazo, no la respuesta a una racha de silencio.
5. ¿Puedo usar IA durante un live coding o un take-home? Pregunta al inicio, sin excepción, y respeta la regla del proceso. Unas empresas la prohíben, otras observan cómo verificas lo que devuelve. Asumir el permiso sin preguntar es lo único que sí se lee mal: la duda que deja no es sobre la herramienta.
El vocabulario de este módulo
Stack — Lenguajes, frameworks y herramientas con los que se construye un producto.
Dominio — El negocio donde vive el software: pagos, salud, logística.
Fork — Copia de un repositorio ajeno. Si no le agregaste nada, no es tuyo.
Repo destacado — El que fijas en tu perfil para que se vea primero. En GitHub, pinned.
Overlap — Horas en que tu jornada coincide con la del equipo. Se declara en UTC.
Live coding — Programación resuelta en vivo, con alguien observando.
System design — Conversación donde diseñas un sistema a alto nivel: requisitos, componentes, cuellos de botella.
Take-home — Prueba técnica que resuelves por tu cuenta, con un plazo, y entregas como repositorio.
Idempotencia — Operación que da el mismo resultado se ejecute una vez o varias.
Cobertura de pruebas — Porcentaje de código que ejecutan los tests. Mide cuánto se recorre, no si se probó lo que importa.
¿Es este tu punto débil?
El test de empleabilidad te dice gratis qué te falta y en qué orden resolverlo. Y si ya lo sabes, el programa completo se abre entero el primer día.