Mira diez búsquedas de "full stack developer" y vas a notar un patrón que no tiene nada que ver con amplitud técnica. La mayoría le pide a una sola persona que sea dueña del frontend, del backend, de la base de datos, a veces de la infraestructura, todo por el presupuesto de un solo salario de nivel medio. "Full stack" en muchas de esas búsquedas no describe un conjunto de habilidades. Describe un problema de headcount que la empresa decidió resolver pidiendo un generalista en lugar de contratar un equipo.
Eso no es lo que significa full stack cuando llevas una década haciendo esto, y hacer como que sí es de donde viene buena parte de la confusión, y buena parte del cinismo del mercado sobre el término.
La versión junior: amplitud sin profundidad, y está bien en esa etapa
Al principio de una carrera, "full stack" suele significar simplemente "tocó React y tocó una API REST", y no hay nada de malo en eso. La amplitud es como descubres en qué te quieres especializar en serio. Construyes una app CRUD de punta a punta, aprendes que el frontend y el backend tienen modos de falla completamente distintos y modelos mentales completamente distintos, y sales del otro lado con un mapa aproximado de todo el territorio, aunque todavía no conozcas bien ninguna región en particular.
El problema no es que exista esta versión de full stack. El problema es que muchas empresas contratan para esta versión y después esperan que venga con el criterio de un senior, porque el título del puesto suena igual sin importar si la persona detrás tiene dos años de experiencia o doce.
La versión senior: profundidad en más de una capa, más el criterio para saber cuál importa ahora
Un full stack developer senior no es alguien que sabe un poco de todo. Es alguien que profundizó lo suficiente en al menos dos capas del stack como para tomar decisiones arquitectónicas reales en cada una, y que desarrolló el criterio para saber, frente a un problema concreto, cuál capa merece esa profundidad ahora y cuál solo necesita funcionar.
Ese criterio es la parte que no aparece en un bullet point del currículum. Es la diferencia entre "puedo escribir un componente de React" y "sé que este problema puntual de manejo de estado le corresponde al servidor, porque llevarlo al cliente va a generar un bug de sincronización en el momento en que alguien abra dos pestañas al mismo tiempo". Es la diferencia entre "puedo escribir una query SQL" y "sé que esta query se va a caer con diez veces el volumen de datos actual, y sé exactamente qué índice lo resuelve en lugar de adivinar". Ninguna de las dos viene de la amplitud. Vienen de haberse quemado con la decisión equivocada al menos una vez en cada capa, y de haber internalizado la lección.
Por qué se trata a "full stack" como una degradación de la especialización, y por qué eso está al revés
Hay una narrativa en partes de la industria que dice que full stack es lo que aceptas cuando no eres lo suficientemente bueno para especializarte, que la profundidad real vive con el experto en backend o el experto en frontend que pasó años en exactamente una capa. Esa narrativa invierte la causalidad para un tipo específico de ingeniero.
Algunas de las mejores decisiones arquitectónicas vienen de alguien que entiende los dos lados de una frontera lo suficientemente bien como para ver dónde un problema se está resolviendo del lado equivocado. Un especialista en backend puede construir una API bellamente normalizada que obliga al frontend a hacer tres viajes de red para renderizar una sola pantalla. Un especialista en frontend puede construir una interfaz hermosamente responsiva que esconde un patrón de queries que sale caro en silencio en cada carga de página. El ingeniero que pasó tiempo real en las dos capas es el que detecta ese desajuste antes de que salga a producción, no porque tenga más talento que cualquiera de los dos especialistas, sino porque puede ver la costura que ninguno de los dos está mirando.
Esto no significa que full stack sea superior a la especialización. Muchos problemas realmente necesitan a alguien que pasó cinco años exclusivamente en sistemas distribuidos o exclusivamente en performance de renderizado, y ninguna cantidad de amplitud reemplaza eso. Significa que el marco de "full stack es el camino superficial" está equivocado con suficiente frecuencia como para no tratarlo como una suposición por defecto.
La señal que separa a un full stack developer senior de la lista de deseos de una búsqueda laboral
Si la idea de full stack de una empresa es "hace el trabajo de un ingeniero de frontend, uno de backend y uno de DevOps por un solo salario", eso no es un requisito de habilidades, es una decisión de presupuesto disfrazada de título de puesto. La señal suele estar en cómo está definido el rol: si no hay margen para decir "esta pieza específica de infraestructura necesita a alguien que realmente se especialice en eso", y la expectativa es que una sola persona sea dueña de literalmente todo con profundidad senior, la búsqueda no está describiendo a un full stack developer. Está describiendo tres trabajos con la esperanza de que una persona muy cansada los cubra los tres.
Un rol de full stack genuinamente senior se ve distinto. Viene con el reconocimiento de que la profundidad es finita incluso para alguien con más de una especialidad, y la expectativa no es omnisciencia, es el criterio para saber cuándo profundizar, cuándo una solución superficial realmente alcanza, y cuándo decir "esto necesita a alguien que viva en esta capa a tiempo completo, y ese no voy a ser yo durante los próximos tres meses".
Cómo se construye esto en la práctica, porque no pasa con cursos
Nadie se convierte en full stack developer senior siguiendo un plan de estudios que cubre frontend, backend e infraestructura en secuencia. Pasa por hacerte dueño de una funcionalidad de punta a punta suficientes veces como para sentir personalmente el costo de una mala decisión tomada en una capa apareciendo como un bug en otra. Aprendes indexación de bases de datos no en un curso sino con una query que tiró abajo una página en producción. Aprendes manejo de estado en frontend no con un tutorial sino con un reporte de bug sobre datos desactualizados entre dos pestañas abiertas que te tomó cuatro horas reproducir.
Ese tipo de aprendizaje es más lento que leer un programa que promete "full stack en doce semanas", y también es la única versión que realmente produce el criterio que implica el título. No hay atajo para haberse equivocado en las dos capas suficientes veces como para saber dónde suele esconderse el riesgo real.
Cómo aparece esto en una entrevista técnica, y por qué la mayoría de las entrevistas no lo detectan
La mayoría de las entrevistas de full stack evalúan amplitud rotando por una lista de preguntas: una sobre estado en React, una sobre un join en SQL, una de system design básico, cada una lo suficientemente superficial como para entrar en quince minutos. Ese formato premia a quien memorizó la superficie de cada capa y no dice casi nada sobre si el candidato tiene el criterio descrito arriba, porque el criterio no se manifiesta en fragmentos aislados de quince minutos.
Una señal mejor viene de un solo problema que atraviesa capas y obliga a un tradeoff entre ellas: dónde debería vivir esta validación, por qué mover este cálculo del cliente al servidor cambia el modo de falla, qué se rompe primero si esta funcionalidad tiene éxito más allá de la escala para la que se construyó. Esas preguntas no tienen una rúbrica limpia, que es exactamente por qué la mayoría de los procesos de entrevista las evita en favor del formato de lista. Pero son el único formato que realmente distingue a quien tocó cada capa de quien razonó a través de todas ellas bajo presión.
Si eres tú quien está siendo entrevistado y el proceso es todo lista y ningún tradeoff entre capas, vale la pena notarlo. No es necesariamente una alarma por sí sola, pero es una señal de si el equipo que te está evaluando realmente entiende para qué está contratando, o si está usando "full stack" como abreviatura de "sabe un poco de todo" sin haber pensado mucho más allá de eso.
La etiqueta no es el problema. Su devaluación sí.
Nada de esto es un argumento para jubilar el término. Full stack es una descripción real y útil de un tipo real de ingeniero, uno que puede moverse por todo el sistema y ver las costuras que a veces los especialistas de cada lado no ven. El problema es que el término se estiró para cubrir tanto a ese ingeniero como al atajo de dotación de personal de una empresa, y los dos terminan metidos bajo las mismas dos palabras en una búsqueda laboral.
Si eres senior y full stack, el movimiento útil no es rechazar la etiqueta. Es ser explícito, en las entrevistas y en cómo hablas de tu propio trabajo, sobre cuál de las dos versiones eres: la que tiene profundidad real en más de una capa y el criterio para saber dónde importa, no la que le están pidiendo que sea cuatro títulos de puesto al precio de uno.
