Salario de Desarrollador·a Full-stack
En España, el salario mediano de un puesto de Desarrollador·a Full-stack es de 48.000 € brutos al año; la mitad central de los salarios está entre 38.000 € y 60.000 €.
De un vistazo
- Salario mediano48.000 €
- Plazo de contratación50–75 días
- Experiencia3–6 años
Salario de Desarrollador·a Full-stack en España
Salario fijo bruto anual
- Percentil 25
- 38.000 €
- Mediana
- 48.000 €
- Percentil 75
- 60.000 €
| Nivel | Percentil 25 | Mediana | Percentil 75 |
|---|---|---|---|
| Junior | 23.000 € | 27.000 € | 32.000 € |
| Intermedio | 38.000 € | 48.000 € | 60.000 € |
| Senior | 58.000 € | 70.000 € | 88.000 € |
Para referencia: el Salario Mínimo Interprofesional (SMI) en España es de 1.221 € brutos al mes en 14 pagas desde el 1 de enero de 2026. (BOE-A-2026-3815: Real Decreto 126/2026, de 18 de febrero, por el que se fija el salario mínimo interprofesional para 2026)
Salario bruto anual de referencia para un·a Desarrollador·a Full-stack de nivel intermedio (3 a 6 años de experiencia profesional) en pymes españolas. Madrid y Barcelona en entorno SaaS o scale-up tiran hacia arriba (55-75 k€); resto del territorio y sectores tradicionales tiran hacia abajo (32-42 k€). Stack moderno (React + Node o Python, Postgres, Kubernetes) tira hacia arriba; stack legacy (PHP procedural, jQuery, monolitos Java antiguos) tira hacia abajo. Los puestos de ingeniería en España rara vez incluyen retribución variable estructural; algunas scale-ups ofrecen phantom shares o stock options.
Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software); InfoJobs, Estado del Mercado Laboral en España 2025; Honeypot State of Software Engineering Spain 2025
Cómo contratar a un·a Desarrollador·a Full-stack para su pyme
Antes de redactar la oferta, plantéate tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan los errores frecuentes en pyme tech española.
Pregunta 1: ¿Full-stack o especialista? El·la Full-stack cubre frontend y backend a un nivel intermedio-avanzado; los perfiles especialistas (Frontend puro, Backend puro) son más profundos en su dominio. En pyme tech de menos de 10 desarrolladores·as, Full-stack es casi siempre la opción correcta: la especialización solo se justifica a partir de un cierto volumen de equipo y de complejidad de producto. Si duda, opte por Full-stack con una orientación ligera (más bien frontend o más bien backend) según la necesidad del momento.
Pregunta 2: ¿Stack-Fit o seniority? Un·a persona desarrolladora con experiencia sólida en React, Node y Postgres no se vuelve productiva de inmediato en Vue, Python y MongoDB; necesita 2-4 semanas de adaptación. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sé explícito·a con tu stack en la oferta; eso ya filtra perfiles mal encajados. Si tu stack se considera legacy (PHP procedural, jQuery, ColdFusion), asúmelo y busca perfiles a los que les guste modernizar codebases en lugar de atraer perfiles decepcionados tras la incorporación.
Pregunta 3: ¿Qué porcentaje del tiempo dedicará a decisiones técnicas en autonomía? En pyme early-stage (menos de 5 desarrolladores·as), un·a Full-stack mid-level toma con regularidad decisiones de arquitectura (elección de librería, diseño de un nuevo servicio, refactor de zona crítica). En pyme más consolidada (más de 15 desarrolladores·as), ejecuta más bien dentro de un marco ya fijado por una persona tech lead. El perfil ideal cambia: autonomía y resolución en el primer caso, calidad de ejecución y colaboración en el segundo. Encuadre esta dimensión desde la propia oferta.
Si las tres respuestas convergen hacia un·a Full-stack a jornada completa (y no a un·a especialista o un·a tech lead), consulta el modelo listo para usar en la sección Descripción del puesto, más abajo.
Plantilla de descripción del puesto de Desarrollador·a Full-stack
[Nombre de empresa], pyme B2B del sector [sector] con sede en [ciudad], [X] personas en plantilla y [X] M€ de facturación, busca incorporar un·a Desarrollador·a Full-stack al equipo técnico de [X] personas.
Misión
Diseñar, desarrollar y mantener funcionalidades de producto sobre el conjunto de la stack ([frontend más backend más base de datos]), en autonomía sobre los temas familiares y en colaboración sobre las decisiones estructurantes. La persona reporta a la [Tech Lead / CTO / Dirección Técnica].
Responsabilidades
- Entregar funcionalidades de principio a fin: comprensión de la necesidad de producto, diseño técnico, implementación frontend más backend, tests, despliegue y seguimiento en producción.
- Participar en las decisiones de arquitectura del propio ámbito (elección de librería, refactor, diseño de un nuevo servicio).
- Mantener la calidad del código: revisión de las PRs de las personas compañeras, aplicación de convenciones, refactor al paso cuando proceda.
- Contribuir a la resolución de incidentes en producción (on-call o guardia según la organización).
- Documentar las decisiones técnicas importantes y las zonas de complejidad no trivial.
- Colaborar con producto, diseño y dirección en los briefs; cuestionar de forma constructiva las restricciones inviables o contraproducentes.
Perfil
- Imprescindible: [3 a 6] años de experiencia profesional en desarrollo web; dominio sólido de al menos un framework moderno de frontend (React, Vue, Svelte) y de backend (Node, Python, Ruby, Go o equivalente); experiencia de puesta en producción (despliegue, monitoring, gestión de incidentes).
- Valorable: familiaridad con nuestra stack [React más Node / Python / otra]; experiencia en pyme o startup (alta autonomía); contribuciones a open source o side projects públicos.
- Excluyente: ninguna experiencia de puesta en producción en autonomía; rechazo a tocar frontend o backend; rechazo sistemático de frameworks modernos.
Qué ofrecemos
- Retribución bruta anual: fijo [38-60] mil euros según experiencia. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
- Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
- Beneficios: [seguro médico, ticket restaurante, cheque transporte, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación y conferencias].
- Stack: [a completar: frontend, backend, base de datos, infraestructura, CI/CD, monitoring].
¿Buscas a alguien para este puesto? Job Studio convierte la plantilla en una oferta lista para publicar, con banda salarial sugerida y formulario de candidatura.
Preguntas de entrevista para Desarrollador·a Full-stack
15 preguntas estructuradas, agrupadas por tipo. Cada una indica la competencia que evalúa; despliégala para ver qué revela una buena respuesta.
Conductual 3
Describe la decisión técnica más difícil que tomaste en tu último puesto. ¿Por qué era difícil y cómo la resolviste?
Decisión técnicaLo que revela una buena respuesta
Capacidad de estructurar una decisión bajo incertidumbre: identificación de restricciones, compromisos explícitos, consulta a las partes implicadas, validación posterior con datos. Bonus: la persona candidata menciona haber cambiado de opinión durante el proceso o haber documentado la decisión para el futuro equipo. Quienes describen una decisión obvia con perspectiva revelan que nunca llegaron a deliberar realmente.
Cuéntame un bug en producción que resolviste. ¿Cuál era el síntoma, cómo lo diagnosticaste y cuánto tiempo te llevó?
Depuración e investigaciónLo que revela una buena respuesta
Método de depuración estructurado: reproducción, logs, instrumentación, hipótesis validadas con experimentos. Honestidad sobre la duración (un bug real de producción rara vez se cierra en menos de 30 minutos). Bonus: la persona candidata cita la causa raíz y el correctivo sistémico, no solo el hotfix. Las respuestas tipo reinicié el servicio sin diagnóstico revelan debilidad en investigación.
Describe un momento en el que tuviste que refactorizar o reescribir código que tú mismo·a habías escrito unos meses antes. ¿Qué había pasado entre medias?
Aprendizaje y humildadLo que revela una buena respuesta
Humildad técnica y capacidad de aprender. Bonus: la persona candidata identifica lo que habría hecho diferente desde el principio. Quienes afirman no haber tenido nunca que refactorizar su propio código mienten o no han mantenido código en producción durante el tiempo suficiente.
Situacional 3
Descubres en una code review una vulnerabilidad de seguridad (inyección SQL, secret en claro, falta de autenticación) en una PR de un·a colega senior. ¿Cómo reaccionas?
Coraje técnicoLo que revela una buena respuesta
Capacidad de señalar una debilidad técnica sin bloquear: comentario factual en la PR (aquí está el riesgo, esta es mi propuesta de solución), propuesta de solución, escalado al tech lead si la PR se mergea pese al comentario. Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico.
Un·a Product Manager te pide una funcionalidad que según tu estimación lleva 3 semanas. La persona PM la quiere en 1 semana. ¿Cómo reaccionas?
Comunicación con productoLo que revela una buena respuesta
Clarificación de la necesidad antes de negociar el plazo (quizá la feature pueda entregarse en dos fases o simplificarse). Propuesta de opciones: MVP en 1 semana más V2 en 2 semanas, recorte explícito de alcance, refuerzo de personal. Las respuestas del tipo lo hago en 1 semana si trabajo el fin de semana son una bandera roja (señal de mala gestión personal).
Te incorporas a un equipo con deuda técnica importante: tests insuficientes, despliegues manuales, monitoring casi inexistente. ¿Cuál es tu plan a 30 días?
Pragmatismo y priorizaciónLo que revela una buena respuesta
Diagnóstico primero: no intentar arreglarlo todo a la vez. Priorización por riesgo e impacto (típicamente: monitoring primero para ver, luego tests en zonas críticas, después automatización del despliegue). Validación con el equipo y con la persona tech lead antes de avanzar. Quienes se lanzan directamente a la reescritura completa muestran falta de pragmatismo.
Caso práctico 3
Diseño: queremos añadir a nuestra aplicación un sistema de notificaciones en tiempo real (por ejemplo: un·a compañero·a ha comentado tu documento). ¿Cómo lo diseñas?
Diseño de sistemasLo que revela una buena respuesta
Aclaraciones antes de proponer (volumen esperado, latencia objetivo, dispositivos soportados, persistencia de las notificaciones no leídas). Arquitectura coherente: push (WebSocket o Server-Sent Events) frente a pull (polling), persistencia (base de datos de notificaciones), idempotencia de los envíos, fallback por correo. Bonus: reconoce zonas de incertidumbre (haría un POC antes de comprometerme con WebSocket o SSE). Quienes se meten en el código sin aclarar restricciones revelan una debilidad de diseño.
Debug: tu API devuelve un 500 en el 2 por ciento de las peticiones. Los logs no muestran nada evidente. ¿Cómo investigas?
Depuración e investigaciónLo que revela una buena respuesta
Método estructurado: (1) elevar temporalmente el nivel de log en los endpoints afectados, (2) correlacionar con métricas (latencia, tamaño de payload, origen), (3) identificar un patrón (hora del día, tipo de petición, usuario·a concreto·a), (4) ordenar hipótesis (timeout de base de datos, race condition, memoria). Quienes se lanzan a decir seguro es la base de datos sin investigar revelan un sesgo.
Rendimiento: una página de tu aplicación tarda 8 segundos en cargar. Tienes 1 semana para bajarla por debajo de 2 segundos. ¿Plan de acción?
OptimizaciónLo que revela una buena respuesta
Medir antes de optimizar: DevTools, Lighthouse, profiler de servidor. Identificar el cuello de botella (rendering, consultas a base de datos, payload, CDN). Priorizar por esfuerzo por impacto. Las respuestas tipo añado caché sin diagnóstico revelan optimización prematura. Bonus: la persona candidata menciona que una página en 8 segundos en producción suele indicar un problema sistémico (N+1, payload enorme) y no una optimización local.
Técnica 3
¿Cuál es tu enfoque del testing? Describe tu último proyecto: cuántos tests, qué tipos, qué cobertura y qué mide realmente.
Calidad del códigoLo que revela una buena respuesta
Comprensión de la pirámide de tests (muchos unitarios, menos de integración, pocos end-to-end). Distinción entre cobertura y utilidad (90 por ciento de cobertura sobre código trivial vale menos que 60 por ciento sobre la lógica de negocio crítica). Bonus: la persona candidata cita una vez en que un test evitó una regresión real. Quienes responden testeo al 100 por ciento sin matizar muestran un juicio débil.
Diferencia entre una transacción de base de datos y un lock aplicativo. ¿En qué caso usarías uno y no el otro?
Fundamentos backendLo que revela una buena respuesta
Transacción de base de datos: atomicidad e isolation gestionadas por la base (ACID), acotadas a la duración de la transacción. Lock aplicativo: coordinación entre procesos o instancias vía Redis, ZooKeeper o similares; útil cuando la coordinación supera una única base de datos (microservicios, cola de tareas). Riesgo de deadlock en ambos casos. Quienes no saben distinguir los dos mecanismos crean race conditions en producción.
Llegas a una codebase React mal organizada: componentes de 500 líneas, props drilling de 5 niveles, sin separación entre lógica y presentación. Plan de acción a 60 días sin romper nada.
Pragmatismo y priorizaciónLo que revela una buena respuesta
Enfoque progresivo: (1) mapear componentes críticos y patrones recurrentes, (2) extraer hooks y lógica de negocio primero (impacto alto, riesgo bajo), (3) trocear componentes grandes por frontera de negocio (no por capricho técnico), (4) introducir un state manager solo donde el props drilling duela de verdad (Context o Zustand en pyme, Redux a partir de cierto volumen). Quienes quieren reescribirlo todo a React Server Components desde el día 1 carecen de pragmatismo.
Valores 3
¿Cómo recibes una code review crítica sobre código del que estabas convencido·a de haber hecho bien?
CoachabilityLo que revela una buena respuesta
Apertura: capacidad de separar el código del ego personal. Bonus: la persona candidata cita una vez en que cambió de opinión gracias a una review. Quienes describen haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para el trabajo en equipo en pyme.
¿Qué papel juegas en la transmisión técnica a perfiles junior o a las nuevas incorporaciones?
Mentoría y transmisiónLo que revela una buena respuesta
Postura activa de mentoría: pair programming, reviews pedagógicas (no solo aprobar y mergear), documentación de decisiones, transmisión de buenas prácticas. Quienes responden ayudo cuando me piden sin más concreción muestran una postura pasiva. En pyme con equipo técnico reducido, la capacidad de transmisión es clave para la sostenibilidad del equipo.
¿Cómo trabajas con un·a Product Manager o un·a diseñador·a? Describe una situación en la que devolviste un brief con cuestionamientos.
Juego en equipo con productoLo que revela una buena respuesta
Postura de partenariado: cuestionamiento constructivo basado en viabilidad o complejidad, propuesta de alternativas. Bonus: la persona candidata cita un caso en el que aceptó el brief inicial tras conversarlo (no está en oposición sistemática). Quienes describen a las personas PM o diseñadoras como gente que no entiende la técnica revelan debilidad de juego en equipo.
Salario y contratación por nivel
El mismo puesto en cada nivel: cuánto se paga, cuánta experiencia cabe esperar y cuánto suele durar la búsqueda.
Desarrollador·a Full-stack Junior
- Salario fijo bruto anual
- 27.000 €23.000 € – 32.000 €
- Experiencia
- 0–2 años
- Plazo de contratación
- 35–60 días
Desarrollador·a Full-stack (Intermedio)
- Salario fijo bruto anual
- 48.000 €38.000 € – 60.000 €
- Experiencia
- 3–6 años
- Plazo de contratación
- 50–75 días
Desarrollador·a Full-stack Senior
- Salario fijo bruto anual
- 70.000 €58.000 € – 88.000 €
- Experiencia
- 7–12 años
- Plazo de contratación
- 65–95 días
Salario de Desarrollador·a Full-stack por país
El mismo puesto y el mismo nivel en cada país que cubrimos, con cifras de fuentes del propio país.
| País | Mínimo | Valor central | Máximo |
|---|---|---|---|
| EspañaEsta página | 38.000 € | 48.000 € | 60.000 € |
| AlemaniaDeutsch | 50.000 € | 60.000 € | 75.000 € |
| FranciaFrançais | 45.000 € | 55.000 € | 70.000 € |
| Países BajosNederlands | 48.888 € | 57.600 € | 66.300 € |
| ItaliaItalianoMilano · sviluppo software · Junior Developer · 2–5 anni di esperienza | 33.000 € | — | 38.000 € |
Fuentes
- Alemania (consultado en mayo de 2026): Stepstone Gehaltsdaten Fullstack-Entwickler:in Deutschland 2026 · Stepstone Gehaltsreport 2026 · Honeypot State of Software Engineering Germany 2025 · Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
- Francia (consultado en mayo de 2026): APEC, Baromètre 2025 de la rémunération des cadres tech · INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques) · Talent.io, Étude rémunération tech France 2025
- Países Bajos (consultado en agosto de 2026): Nationale Vacaturebank — salaris Full stack developer in Nederland · Indeed — salaris Developer in Nederland
- Italia (consultado en octubre de 2026): Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
Dónde captar este perfil
LinkedIn
Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job SlotsCanal principal para perfiles tech en España, especialmente en Madrid y Barcelona. El sourcing activo (Recruiter Lite más InMails personalizados) es bastante más eficaz que las ofertas pasivas: los buenos perfiles Full-stack apenas miran ya el feed de empleo. Filtra con precisión por stack técnica (React + Node frente a TypeScript genérico) y seniority antes de contactar. Las secuencias genéricas obtienen tasas de respuesta menores al 5 por ciento; los mensajes personalizados con referencia clara a la stack y al producto se sitúan en torno al 15-25 por ciento.
InfoJobs
Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €El portal con mayor volumen de candidaturas activas en España, especialmente fuerte fuera de Madrid y Barcelona (Valencia, Sevilla, Zaragoza, Bilbao) y en perfiles tech de pyme tradicional. Genera volumen, no siempre señal: filtra con CV semiestructurado y test técnico breve para no perder tiempo en la fase de cribado. Más eficaz para stacks mainstream (PHP, Java, .NET) que para nichos modernos (Rust, Elixir). Útil como complemento de LinkedIn cuando se busca cubrir un puesto rápido.
Welcome to the Jungle España
Desde 890 € por oferta; planes anuales con tarifas reducidas para volumenAudiencia tech orientada a scale-up y pyme moderna, sobre todo en Barcelona y Madrid. Los perfiles WTTJ valoran la misión, la stack y la cultura del equipo técnico (vídeos, fotos, testimonios). Bien adaptado para marcas empleadoras jóvenes o productos nuevos. Menos eficaz fuera de las grandes ciudades o para stacks legacy. Boards tech de nicho como Tecnoempleo o Manfred (reverse recruiting español) son complementos útiles para perfiles senior que ya no usan LinkedIn activamente.
Manual de evaluación
El puesto de Desarrollador·a Full-stack se evalúa en cinco etapas. La prueba técnica (etapa 4) debe ser realista y acotada en tiempo: una prueba de 8 horas se convierte en la práctica en 24 horas de dedicación real, desmotiva a los buenos perfiles y no aporta mejor señal que una prueba bien diseñada de 2-3 horas.
Etapa 1: Lectura del CV
Busca coherencia de stack (un·a perfil React más Python no vuelve a Java sin 3-6 meses de readaptación), estabilidad (mínimo 18-24 meses por puesto previo) y señales de autonomía (proyectos personales, contribuciones a open source, side projects públicos). La titulación pesa menos que los últimos 3-5 años de experiencia real: un·a autodidacta con 5 años en producción sólida vale más que un·a recién egresado·a de escuela puntera con 2 años de prácticas alargadas.
Etapa 2: Phone screen (30 min)
Solo tres preguntas: (1) Describe el proyecto reciente del que te sientas más orgulloso·a; ¿cuál fue tu aportación concreta?, (2) ¿Qué decisión técnica tomó hace poco sobre la que aún tiene dudas? (humildad y reflexión), (3) ¿Por qué un cambio ahora? Salida: go o no-go en 5 minutos de debrief, no más. Evita las preguntas técnicas tipo trampa en esta fase.
Etapa 3: Entrevista técnica (60-90 min)
Pair programming o code review sobre un ejercicio acotado (45-60 min), seguido de 15-30 min de preguntas y respuestas sobre arquitectura y decisiones técnicas. Evalúa la capacidad de razonar en voz alta, de pedir aclaraciones y de iterar. Evita los algoritmos puramente académicos sin relación con el trabajo diario; prefiere un ejercicio que se parezca al día a día (refactor, añadir una feature, depurar un caso no cubierto).
Etapa 4: Ejercicio de diseño de sistema (60 min)
Discusión de arquitectura sobre un caso concreto: ¿Cómo diseñaría un sistema para [funcionalidad específica del producto]? Evalúa la capacidad de clarificar restricciones antes de proponer, de equilibrar simplicidad y escalabilidad y de reconocer zonas de incertidumbre. Es la etapa más predictiva para un·a Full-stack que tendrá que tomar decisiones técnicas en autonomía dentro de una pyme.
Etapa 5: Referencias (verificación estructurada)
Llama a dos referencias: un·a antiguo·a tech lead o manager directo y un·a antiguo·a compañero·a de equipo. Plantea a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿Volvería a contratarle mañana y por qué?, ¿Un ejemplo de decisión técnica difícil tomada en autonomía? La cuarta pregunta es la que revela el verdadero indicio de autonomía.
Cómo reconocer una gran contratación
| Competencia | Por debajo | En el nivel | Por encima |
|---|---|---|---|
| Solidez técnica | Tropieza con los fundamentos (HTTP, transacciones de base de datos, asincronía). Busca soluciones a base de prueba y error sin modelo mental claro. Difícil de subir a un nuevo lenguaje o framework. | Domina la stack actual en autonomía. Sabe aprender un framework nuevo en 2-4 semanas. Comprende los fundamentos lo suficiente para depurar en profundidad cuando hace falta. | Referente técnico del equipo en su stack y capaz de saltar a una nueva stack en pocas semanas. Anticipa trampas clásicas (race conditions, fugas de memoria, edge cases). Construye abstracciones útiles, no prematuras. |
| Diseño de sistemas y pragmatismo | Se mete en el código sin aclarar restricciones. Sobre-diseña (microservicios para un MVP) o infra-diseña (monolito spaghetti de 50 mil líneas). Difícil de hacer arbitrar entre simplicidad y escalabilidad. | Clarifica la necesidad antes de programar. Pragmático·a al arbitrar: no sobre-diseña para un futuro incierto, pero identifica zonas donde un poco de estructura compensará. Sabe pivotar cuando la hipótesis inicial no se sostiene. | Diseña sistemas que envejecen bien: abstracciones justas, dependencias mínimas, fronteras de negocio claras. Reconoce sus zonas de incertidumbre y propone POCs acotados. Forma al equipo en pensamiento sistémico. |
| Calidad e higiene del código | Sin estrategia de testing clara; añade tests para subir cobertura. Código mal estructurado (componentes de 500 líneas, copy-paste, números mágicos). Reviews superficiales. | Pirámide de tests adecuada en las zonas de negocio. Código legible, nombrado claro y funciones cortas. Reviews estructuradas con feedback accionable. Refactoriza al paso cuando es pertinente. | Referente de calidad del equipo: convenciones documentadas, automatización de controles (linters, type checkers, CI). Reviews pedagógicas que hacen progresar a los perfiles junior. Sabe decir no a código que pasa los tests pero envejecerá mal. |
| Autonomía y resolución | Se bloquea horas con un tema desconocido sin pedir ayuda, o pide ayuda a la mínima dificultad. Sin estrategia de depuración estructurada. | Sabe diagnosticar en autonomía sobre temas familiares; pide ayuda tras una investigación previa (resumen del problema, hipótesis, lo que ya ha intentado). | Alta resolución sobre temas no familiares: lee el código fuente de dependencias, instrumenta el runtime, aísla causas raíz. Documenta los aprendizajes para el equipo. |
| Comunicación y juego en equipo | Explica mal su trabajo a perfiles no técnicos. Postura defensiva en reviews. Trabaja en silo, comparte poco contexto. Postura de oposición sistemática frente a PMs o diseñadores·as. | Sabe explicar su trabajo a una persona PM o de dirección en lenguaje claro. Recibe la review de forma constructiva. Comparte contexto en revisiones de equipo y 1:1. | Puente entre la técnica y otras funciones. Modera debriefs técnicos, divulga arbitrajes, negocia plazos de forma transparente. Referente del equipo en comunicación transversal. |
Errores comunes al contratar para este puesto
Contratar por titulación o prestigio del empleador previo en lugar de por el código
Un·a graduado·a de escuela puntera con 2 años en una consultora grande o en una multinacional no es necesariamente más operativo·a que un·a autodidacta con 5 años en producción en startup o pyme. Las grandes estructuras alimentan a sus equipos con specs claras, code reviews exigentes y tooling sólido; en pyme falta ese andamiaje y la falta de autonomía se convierte en una carga. Pondera la prueba técnica y el ejercicio de diseño de sistemas por encima del pedigrí del CV.
Sobrevalorar los fundamentos algorítmicos para un puesto de producto
Un·a Full-stack en pyme casi nunca necesita optimizar un algoritmo de grafos o reimplementar un árbol B. Las pruebas tipo LeetCode filtran a los perfiles académicos en detrimento de los operativos (que sí saben entregar una funcionalidad completa en autonomía). Prefiere ejercicios que se parezcan al día a día: añadir una feature, depurar un caso no cubierto, refactorizar un componente sobrecargado.
Pedir pruebas técnicas de 8 horas o más
Una prueba de 8 horas se transforma en la práctica en 24 horas (con inversión emocional incluida), desmotiva a los mejores perfiles (que tienen otras opciones en paralelo) y no aporta mejor señal que una prueba bien construida de 2-3 horas. Mide la calidad del razonamiento, no la exhaustividad. Acota el tiempo esperado de forma explícita y acepta soluciones incompletas pero bien argumentadas.
Ignorar la fit con la stack y el ecosistema
Un·a desarrollador·a sólido·a en React más Node no se vuelve productivo·a en Vue más Python sin 2-4 semanas de adaptación. Un perfil con stack cercana (React, TypeScript, Postgres para una pyme con la misma stack) estará productivo·a en 1-2 semanas. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sé explícito·a con tu stack en el anuncio; eso ya filtra perfiles mal encajados.
Subestimar la importancia de la comunicación transversal
Un·a Full-stack en pyme habla casi a diario con personas de producto, diseño, a veces directamente con dirección o cliente. Contratar un perfil técnicamente sólido pero flojo en comunicación transversal produce fricciones: briefs mal entendidos, plazos opacos, conflictos con producto. Evalúa la comunicación explícitamente en la entrevista (preguntas situacionales con una persona PM, divulgación de un tema técnico).