Qué hace un Full Stack Developer: perfil, descriptor y qué evaluar al contratar

Un aviso que pide un "Full Stack Developer que haga de todo" no describe un cargo: describe una urgencia. Y suele producir el mismo resultado: CVs imposibles de comparar, entrevistas que se vuelven una lista de frameworks y una contratación que descubre demasiado tarde que el candidato era fuerte en una sola capa.

Un Full Stack Developer es un profesional de software capaz de llevar un flujo de producto desde la interfaz que usa una persona hasta los servicios, datos e integraciones que lo sostienen. Su valor no está en acumular logos de tecnologías. Está en conectar decisiones: qué se muestra, qué valida el servidor, dónde vive el dato, cómo se observa una falla y qué se puede cambiar sin romper lo demás.

En el Diccionario de Cargos — desarrollador de software está la base de habilidades del rol. Esta guía sirve para convertir esa base en una contratación real.

Qué hace un Full Stack Developer en la práctica

No es un unicornio que conoce todos los lenguajes. En una empresa sana, suele hacerse responsable de un dominio o flujo completo: por ejemplo, registro y onboarding, una compra, un dashboard operativo o una integración con un tercero.

Según el contexto, su trabajo incluye:

• Construir interfaces accesibles, claras y mantenibles.
• Diseñar o consumir APIs, validar datos y manejar errores de forma explícita.
• Modelar datos y entender las consecuencias de una consulta, migración o permiso.
• Escribir pruebas proporcionadas al riesgo y dejar trazabilidad para depurar incidentes.
• Participar en revisiones, despliegues y decisiones de arquitectura sin convertir cada cambio pequeño en una asamblea.

La combinación cambia por empresa. Una SaaS B2B puede requerir 60% backend y 40% frontend; una plataforma de operaciones puede invertir esa relación; un producto nuevo puede pedir más capacidad de descubrimiento. Esas proporciones no se adivinan en entrevista: se declaran antes de abrir la búsqueda.

Full stack, frontend, backend y software engineer: no los mezcles

El error frecuente es publicar "full stack" cuando el problema real es que falta una persona senior de backend, alguien que cuide experiencia de usuario o una base de plataforma. Un buen título atrae; un mandato claro selecciona.

Cómo armar el descriptor de cargo

Parte con la plantilla de descriptor de cargo, pero reemplaza la lista infinita de herramientas por decisiones del negocio.

1. Propósito: define el flujo, producto o dominio que esta persona debe mejorar. "Apoyar al equipo TI" no da contexto suficiente.
2. Alcance por capa: especifica qué parte del tiempo irá a frontend, backend, datos e integraciones. Es mejor decir "React + API Node + PostgreSQL" que pedir diez frameworks intercambiables.
3. Entregables a 90 y 180 días: una funcionalidad operando, una integración estable, una deuda técnica reducida, una métrica de latencia o conversión mejorada.
4. Entorno real: tamaño del equipo, nivel de autonomía, revisión de código, cloud, CI/CD y quién define producto. Eso evita vender un cargo de producto dentro de una organización sin producto.
5. Excluyente versus deseable: separa experiencia imprescindible de curiosidad tecnológica. Pedir experiencia en cada herramienta del stack actual cierra la puerta a buenos ingenieros que pueden aprender una pieza menor.
6. Nivel esperado: describe las decisiones que debe tomar, no solo los años. Un senior puede descomponer un problema ambiguo y cuidar trade-offs; no se define por haber usado un framework desde su primera versión.
7. Banda y modalidad: transparencia temprana evita semanas de proceso con candidatos que nunca podrían aceptar la oferta.

Qué evaluar antes de contratar

El repositorio de GitHub y una conversación sobre arquitectura no bastan por sí solos. El trabajo full stack exige criterio técnico, pero también capacidad de priorizar y explicar decisiones a producto, diseño u operaciones.

Una evaluación razonable combina:

• Caso práctico acotado: un flujo pequeño con interfaz, API, persistencia o integración. Debe poder resolverse en un tiempo humano y conversarse después.
• Revisión de decisiones: por qué eligió un modelo de datos, qué validaría, cómo manejaría un error y qué dejaría para una siguiente iteración.
• Experiencia situada: pide un caso donde una entrega cruzó capas y qué hizo cuando algo falló en producción. "Usé React" no responde eso.
• Colaboración: explora cómo recibe feedback, qué documenta y cuándo escala una duda. El full stack suele tocar bordes entre equipos; la fricción invisible cuesta más que un framework pendiente.
• Referencias profundas: verifica el nivel de autonomía, calidad de entrega y capacidad de sostener software existente, no solo de iniciar proyectos.

La evaluación psicolaboral no sustituye una prueba técnica. Aporta otra evidencia para finalistas: juicio bajo presión, estilo de colaboración y ajuste al nivel de autonomía que realmente exige el equipo.

Señales de alerta en la búsqueda

Evita confundir velocidad con ausencia de método. Hay alertas simples que conviene mirar antes de una oferta:

• El candidato habla de herramientas, pero no puede explicar usuarios, restricciones ni resultados de un flujo que entregó.
• La prueba solo funciona en su computador y no hay conversación sobre errores, seguridad o mantenimiento.
• El aviso pide frontend, backend, infraestructura, datos, QA, diseño y gestión de producto para una sola posición junior.
• El equipo no puede responder qué problema de negocio resolverá la persona en sus primeros tres meses.

No todas son fallas del candidato. A veces la búsqueda está intentando reparar con una contratación una definición de producto que aún no existe.

Cuándo conviene headhunting TI

Un aviso abierto puede funcionar si el stack es conocido, la marca empleadora ya atrae desarrolladores y el alcance está bien definido. Pero si necesitas un perfil senior que combine producto, arquitectura y experiencia en una industria específica, la búsqueda se vuelve más angosta.

Ahí un proceso de headhunting puede mapear talento activo y pasivo contra el mismo descriptor, en lugar de filtrar palabras clave. El objetivo no es encontrar a quien diga que sabe de todo: es identificar a quien puede asumir el flujo que hoy es crítico para tu negocio y validarlo antes de que el costo aparezca en producción.

Preguntas frecuentes

¿Qué tecnologías debe saber un Full Stack Developer?

Las necesarias para el problema que resolverá. Especifica el stack actual y el nivel de profundidad requerido, pero prioriza fundamentos: modelado de datos, HTTP/APIs, pruebas, seguridad básica, control de versiones y capacidad de aprender una herramienta nueva.

¿Conviene contratar un junior full stack?

Sí, cuando trabajará con acompañamiento, un alcance delimitado y revisiones de código. No cuando la empresa espera que defina arquitectura, producto e infraestructura sin pares senior.

¿Full stack significa más barato que dos especialistas?

No necesariamente. Reduce coordinación en flujos acotados, pero no elimina la necesidad de especialistas cuando la complejidad lo exige. La decisión depende del producto, etapa y riesgos técnicos, no de sumar salarios en una planilla.

¿Headhunting o evaluación si ya tengo candidatos?

Si ya tienes una terna viable, prioriza una prueba técnica bien diseñada, referencias y evaluación de finalistas. Si no estás llegando al nivel de seniority o experiencia que el cargo requiere, empieza por búsqueda directa.