Una compañía SaaS de 80 personas publica un aviso para Senior Full Stack durante seis semanas. Recibe 47 aplicaciones, 6 entran a entrevista, ninguna firma. La VP de Engineering culpa al "mercado escaso" y autoriza subir 18 por ciento la banda. Mismo aviso, 11 semanas adicionales, 12 aplicaciones más, dos finalistas, ambos eligen otra oferta. El problema nunca fue el sueldo. Fue el job description.
El año 2026 endureció la regla básica del reclutamiento tech: los profesionales senior tienen empleo, alta empleabilidad y filtros agresivos. No están buscando trabajo, están filtrando contexto. Reciben entre 8 y 15 mensajes de reclutamiento por semana, abren los que parecen serios y cierran el resto en menos de 12 segundos. Si el job description tropieza en el primer párrafo, no hay segunda oportunidad.
Esta guía entrega un framework operativo (JOBS), los anti-patterns más comunes con sus correcciones, evidencia interna sobre el impacto de variables del JD en la tasa de aplicación calificada y cuatro plantillas copy-paste para roles tech distintos. Aplica tanto si la compañía publica el aviso directo como si trabaja con un headhunter especializado: el JD sigue siendo el primer filtro, antes del recruiter y antes de la entrevista.
Por qué los senior ignoran el 90 por ciento de los avisos tech
El comportamiento del senior con seis o más años de experiencia es predecible cuando recibe un aviso. Lee título y primer párrafo, escanea la lista de requisitos, busca el rango salarial. Si en alguno de esos tres pasos encuentra fricción, la pestaña se cierra. No hay tercera lectura.
Los tres filtros más letales aparecen una y otra vez en avisos que después la compañía describe como "imposibles de cerrar":
- Jerga genérica vacía de contenido: "buscamos a una persona apasionada por la innovación en una compañía en crecimiento explosivo". El senior tradujo eso en automático a "no saben qué quieren, lo van a descubrir contigo".
- Lista de requisitos imposible: 5+ años en un framework de 3 años, manejo experto de Vue y React y Angular, "deseable" doctorado y bilingüismo nivel C2. Señal universal de que el JD lo escribió alguien que no entiende el stack.
- Sueldo oculto detrás de "competitivo": en 2026 la palabra "competitivo" significa exactamente lo contrario. Los senior la decodifican como "bajo, queremos negociar a la baja desde la primera llamada".
El cuarto filtro, menos discutido pero igual de fatal, es la opacidad del proceso. Cuando el JD no dice cuántas etapas tiene el proceso de selección, el senior asume que son siete, que se van a extender dos meses y que probablemente terminen en ghosting. Para entender por qué pasa esto en detalle conviene revisar la guía sobre señales del proceso de selección que espantan candidatos.
Impacto de elementos del JD sobre la tasa de aplicación calificada
Base interna IT Workers, 48 procesos tech 2025-2026. Tasa de aplicación calificada normalizada a 100 = JD mediano. Variación marginal al agregar o sacar cada elemento.
Anatomía de un job description ganador
Un JD que cierra senior tiene siete bloques en orden no negociable. Cada uno responde una pregunta específica que el lector se hace. Si la respuesta se demora o se diluye, la lectura termina.
1. Opener gancho de dos líneas
Responde por qué este rol existe ahora y qué cambia cuando la persona entra. No es la misión de la compañía. No es el about. Es una afirmación operativa que el lector entiende sin necesidad de contexto adicional.
Bueno: "estamos duplicando el volumen de transacciones en seis meses y necesitamos un Senior Full Stack que rediseñe el motor de pagos para soportar ese crecimiento". Malo: "somos una compañía innovadora en crecimiento explosivo que busca un talento apasionado por la tecnología".
2. Problema concreto que resuelve el rol
Tres a cinco oraciones que describen el problema real. Métricas reales, restricciones reales, deuda técnica real. Si la compañía no se atreve a describir el problema, ningún senior va a confiar en que entiende dónde se está metiendo.
3. Stack honesto con versiones
Listar el stack productivo con porcentajes aproximados de tiempo. Marcar explícitamente qué es legacy y qué se migra cuándo. Esta sección sola filtra la mitad del ruido: el senior decide en 30 segundos si el stack le interesa profesionalmente o no.
4. Expectativa 30 / 60 / 90 días
Tres bloques, uno por hito. Qué entregables se esperan en 30 días (aterrizaje), en 60 días (primer impacto medible), en 90 días (autonomía completa). Esta sección es la que más diferencia un JD profesional de uno genérico, porque obliga a la compañía a saber qué quiere.
5. Rango salarial visible
En Chile no es obligación legal, pero es ventaja competitiva. El senior aplica solo si el rango está dentro de su expectativa. Sin rango visible, el filtro lo aplica antes de aplicar. Para benchmarking de rangos por rol se puede consultar la guía salarial tech 2026.
6. Beneficios diferenciados y cuantificados
Lista de cuatro a seis beneficios reales, no genéricos. Presupuesto anual de formación con monto explícito, días libres adicionales con número, política de remoto formalizada con régimen claro, equipo personal entregado el día uno. Para profundizar en qué beneficios sí mueven la aguja conviene leer la guía sobre beneficios tech que retienen talento.
7. Proceso de entrevista descrito
Cuántas etapas, qué dura cada una, qué se evalúa, cuánto tiempo total. Ejemplo: cuatro etapas en dos semanas, llamada inicial de 30 minutos, pair programming técnico de 90 minutos, entrevista con equipo de 60 minutos, decisión y oferta. Esta sección transmite respeto por el tiempo del candidato y reduce el ghosting interno de la propia compañía.
¿Tu próximo JD no está cerrando senior? IT Workers entrega shortlist en 4 días con briefing operativo desde la primera llamada.
Activar procesoAnti-patterns con ejemplos y alternativa correcta
La forma más rápida de mejorar un job description tech es eliminar los anti-patterns comunes. Diez frases reales encontradas en avisos de los últimos 24 meses, con la versión que sí funciona.
| Anti-pattern | Alternativa correcta |
|---|---|
| Buscamos un rockstar / ninja / guru | Buscamos un Senior Backend con autonomía técnica probada en sistemas distribuidos |
| 5+ años React Native, Vue, Angular y Svelte | Experiencia productiva en React (must), familiaridad con un segundo framework (nice-to-have) |
| Salario competitivo según experiencia | Rango bruto mensual $5.500.000 - $7.200.000 CLP, según seniority y entrevista |
| Trabajo en startup de ritmo acelerado | Releases cada 2 semanas, on-call rotativo 1 semana cada 6, sprints de 2 semanas |
| Ambiente joven y dinámico | Equipo de 12 ingenieros, mediana de edad 32, política de no-meetings los miércoles |
| Buscamos pasión por aprender | Presupuesto anual de formación de $1.200.000 CLP por persona, 4 días al año para conferencias |
| Te integrarás a un equipo de alto rendimiento | Te sumas a un squad de 5 personas que rediseña el motor de búsqueda en los próximos 6 meses |
| Beneficios competitivos | 20 días hábiles de vacaciones, seguro complementario con cobertura dental, 5 días flex al año |
| Manejo de stack moderno | Python 3.12 con FastAPI, PostgreSQL 15, Redis, AWS (ECS, S3, Lambda), Datadog |
| Excelente trato humano y trabajo en equipo | Política formal de feedback bilateral cada 3 meses, 1:1 semanales con manager directo |
| Capacidad de trabajar bajo presión | 2 incidencias críticas mensuales en promedio, runbook documentado, rotación on-call clara |
| Modalidad híbrida flexible | 2 días presencial obligatorios (martes y jueves), 3 días remoto, oficina en Las Condes |
El patrón general es: cada palabra vaga se reemplaza por un número, una métrica o una restricción real. El senior con experiencia premia esa precisión incluso cuando los números no son ideales para él. Prefiere descartar antes que perder tiempo descubriéndolo en la segunda entrevista.
Framework JOBS: cuatro pilares del JD que cierra
JOBS es la sigla operativa que se usa en IT Workers para auditar avisos antes de publicar. Cada letra es un pilar con criterios duros de aprobación o rechazo.
J - Job Outcome
El rol resuelve un problema concreto que la compañía sabe nombrar. Si quien escribe el JD no puede responder en una línea "qué cambia cuando esta persona entra", el JD no está listo para publicar. El Job Outcome se redacta antes que cualquier otro bloque.
O - Outcome 30 / 60 / 90
Tres entregables medibles por hito. Aterrizaje a 30 días, primer impacto visible a 60 días, autonomía operativa a 90 días. Esto le da al candidato un mapa claro y a la compañía un sistema de evaluación temprana. Para entender cómo se aterriza ese plan operativamente conviene leer la guía sobre onboarding tech 90 días.
B - Beneficios diferenciados
Cuatro a seis beneficios cuantificados que distinguen a la compañía del promedio del mercado. Si los beneficios listados se encuentran en cualquier otro JD de la industria, no son diferenciales. La regla: si el senior podría copiar y pegar esta sección desde otro aviso sin notarlo, no aporta.
S - Señales de respeto
Cuatro señales mínimas: rango salarial visible, stack honesto sin marketing, proceso de entrevista descrito, política de remoto formalizada. Cada una es señal de que la compañía respeta el tiempo y la experiencia del candidato. La ausencia de cualquiera comunica lo contrario.
Un job description tech no es un manifiesto de requisitos imposibles, es una oferta de trabajo escrita para una persona específica que ya tiene empleo. Si no respeta su tiempo en los primeros tres párrafos, la cierra y no vuelve. — Pablo Herrera, Founder IT Workers
Por qué publicar rango salarial es ventaja competitiva en 2026
El argumento clásico contra publicar el rango es que "los actuales empleados se molestan" o que "los competidores ven cuánto pagamos". Ambos suenan razonables y son irrelevantes en la práctica. El primero se resuelve con una política de compensación coherente. El segundo se diluye porque los competidores ya saben lo que la compañía paga, lo levantan en cinco minutos con cualquier headhunter del mercado.
Los datos internos cruzados con benchmark público apuntan a la misma dirección: publicar el rango salarial real aumenta la tasa de aplicación calificada cerca del 90 por ciento, reduce el ruido del pipeline a la mitad y acorta el time-to-hire entre 25 y 35 por ciento. Para más contexto sobre los costos del proceso largo conviene revisar el análisis de el costo oculto de un puesto tech vacante.
Aplicaciones calificadas por mil impresiones según visibilidad del rango salarial
Comparación interna IT Workers, 32 procesos tech 2025-2026 con rol y banda equivalentes. Mismo cargo, mismo seniority, mismo canal, distinta visibilidad del salario en el aviso.
La conclusión operativa es directa: la compañía que no publica el rango está pagando un sobreprecio en tiempo y dinero a cambio de evitar una conversación interna que probablemente ya está pendiente. El senior interpreta el silencio como precio bajo y filtra antes. La compañía termina entrevistando candidatos fuera de banda, perdiendo semanas y reabriendo el proceso.
Regla simple: el rango publicado debe tener un rango real de variación. Publicar "$5.000.000 - $5.200.000 CLP" se lee como engaño. Publicar "$5.500.000 - $7.200.000 CLP" se lee como compromiso real con responder a la seniority del candidato. La amplitud del rango comunica casi tanto como el monto.
Plantillas copy-paste para cuatro roles tech
Cuatro plantillas operativas listas para adaptar. Cada una sigue el framework JOBS con el bloque opener, problema, stack, 30/60/90, rango, beneficios y proceso. Reemplazar las variables entre corchetes con datos de la compañía.
Plantilla 1 - Senior Full Stack Developer
Plantilla 2 - Engineering Manager
Plantilla 3 - Data Scientist
Plantilla 4 - Senior DevOps / Platform Engineer
Las cuatro plantillas comparten estructura, pero cada una respeta la convención del rol. Un Data Scientist espera ver mención al stack ML, métricas de negocio del modelo y política sobre take-homes. Un DevOps espera lead time, política on-call y migraciones reales. Adaptar la plantilla al rol específico es lo que diferencia un JD profesional de uno genérico.
¿El JD que vas a publicar pasa el filtro JOBS?
- Job Outcome respondido en una línea sin jerga corporativa.
- Outcomes 30/60/90 con entregables medibles, no responsabilidades.
- Beneficios cuantificados con montos y números, no listas genéricas.
- Rango salarial visible con amplitud real entre piso y techo.
- Stack listado con porcentajes de tiempo y versiones, no sólo nombres.
- Proceso de entrevista descrito con etapas, duración y total semanas.
- Cero palabras: rockstar, ninja, guru, apasionado, competitivo, dinámico.
Errores en la publicación que matan un JD bien escrito
Un buen JD se puede arruinar en el momento de la publicación. Tres errores recurrentes que las compañías cometen incluso después de hacer el trabajo de escritura.
Publicar en demasiados canales sin diferenciar
El mismo aviso copiado en LinkedIn, GetOnBoard, bolsas universitarias y el sitio web. Cada canal tiene una audiencia distinta y necesita un opener distinto. El senior de LinkedIn responde a contexto operativo. El recién egresado de bolsa universitaria responde a oportunidad de crecimiento. Mezclar lenguajes diluye el filtro.
No medir tasas de conversión del JD
Sin métricas, no hay aprendizaje. Las cuatro métricas mínimas a trackear son: impresiones del aviso, tasa de apertura, aplicaciones recibidas y aplicaciones calificadas (entran a entrevista). Si la tasa de apertura es baja, el problema es el título. Si la tasa de aplicación es baja, el problema es el cuerpo. Si la tasa calificada es baja, el problema son los filtros del JD que no estaban bien escritos.
No iterar cada dos semanas
Un JD que llevó 4 semanas sin generar shortlist es un JD muerto. Reescribirlo, ajustar el rango, refinar el opener. Las compañías que tratan el JD como documento estático pierden semanas. Las que lo iteran como copy de landing page cierran posiciones en la mitad del tiempo. Para más contexto sobre velocidades reales del mercado conviene revisar cuánto tarda contratar un perfil tech.
¿El JD ya está escrito pero no convierte? Auditoría operativa del aviso y rediseño completo en 48 horas si la búsqueda es B2B.
Auditar JDCaso real anonimizado: Fintech B reescribe el JD y cierra en 18 días
Fintech B, 120 personas, equipo de ingeniería de 28. Posición abierta: Senior Backend Engineer para el equipo de billing. El aviso original llevaba 9 semanas activo, 38 aplicaciones, 4 entrevistas, ninguna oferta firmada. La VP de Engineering pidió auditoría externa antes de subir el rango por segunda vez.
Diagnóstico del JD original
- Opener genérico: "compañía en crecimiento que busca un backend apasionado".
- Lista de 14 requisitos must-have, incluyendo experiencia en frameworks que no usa el equipo.
- Stack listado sin versiones ni porcentajes.
- Salario "competitivo, según experiencia".
- Beneficios genéricos: "ambiente joven, ping pong, viernes de cerveza".
- Proceso de entrevista no descrito (en la práctica eran 6 etapas y 7 semanas).
Cambios introducidos
Reescritura completa con framework JOBS, manteniendo el rango original sin subirlo. Los cambios fueron de forma, no de fondo económico. Opener específico: "estamos rediseñando el motor de facturación para soportar 5x el volumen actual y necesitamos un Senior Backend que lidere ese rediseño en los próximos 6 meses". Stack honesto: 80% Go con Postgres, 20% mantenimiento Python legacy. Outcomes 30/60/90 con entregables medibles. Rango publicado: $6.000.000 - $7.800.000 CLP. Beneficios cuantificados. Proceso descrito en 4 etapas en 2 semanas.
Resultado del JD reescrito
| Métrica | JD original (9 semanas) | JD reescrito (3 semanas) |
|---|---|---|
| Aplicaciones recibidas | 38 | 54 |
| Aplicaciones calificadas | 6 | 21 |
| Tasa calificación | 15.8% | 38.9% |
| Entrevistas con stakeholders | 4 | 7 |
| Ofertas extendidas | 1 (rechazada) | 2 (1 firmada) |
| Time-to-hire desde reapertura | N/A | 18 días |
El sueldo final ofrecido fue idéntico al rango previo. Lo que cambió fue exclusivamente el job description y la calidad de las conversaciones que generó. La VP de Engineering describió el resultado como "el mismo dinero buscando a otra audiencia". El proceso se cerró 18 días después del relanzamiento.
Preguntas frecuentes sobre cómo escribir un job description tech
¿Por qué los senior tech ignoran la mayoría de los job descriptions?
Los senior tienen alta empleabilidad y reciben 8 a 15 mensajes de reclutamiento por semana. Filtran agresivo. Cierran un JD en menos de 12 segundos si encuentran jerga genérica, lista de requisitos imposible, sueldo oculto o falta de claridad sobre el problema real a resolver. El 90 por ciento de los avisos tech viola al menos tres de esos criterios.
¿Cuál es la longitud ideal de un job description tech para senior?
Entre 350 y 600 palabras. Menos parece informal o poco serio, más se percibe como burocracia corporativa. La estructura ideal es opener gancho de dos líneas, problema concreto de la compañía, stack honesto, expectativas a 30/60/90 días, rango salarial visible, beneficios reales y proceso de entrevista descrito. Todo lo demás sobra.
¿Conviene publicar el rango salarial en un JD tech en Chile?
En Chile no existe obligación legal todavía, pero conviene mucho. Publicar rango salarial real aumenta la tasa de aplicación calificada cerca de 2 veces y reduce el ruido del pipeline a la mitad. Los candidatos senior interpretan la ausencia del rango como señal de que la compañía pagará bajo y filtran antes de hablar. Es ventaja competitiva, no transparencia.
¿Cómo evitar la lista de requisitos imposible en un JD tech?
Separar must-have y nice-to-have explícitamente. Los must-have son tres o cuatro elementos no negociables del stack y la seniority. Los nice-to-have van listados aparte con esa etiqueta. Si el job description pide 5 años de un framework que existe hace 3, o mezcla React Native con Vue y Angular en el mismo bullet, el senior cierra la pestaña. La regla es: si una persona real no puede tener todo eso, el JD está mal escrito.
¿Qué es el framework JOBS para escribir job descriptions tech?
JOBS es la sigla operativa de IT Workers para job descriptions que cierran senior. J de Job Outcome (qué problema concreto resuelve el rol), O de Outcome 30/60/90 (qué entregables se esperan en los primeros meses), B de Beneficios diferenciados (no listas genéricas, sí beneficios reales y específicos) y S de Señales de respeto (rango salarial, proceso de entrevista, política de remoto). Si los cuatro bloques están bien escritos, la tasa de aplicación calificada se multiplica.
¿Cómo escribir el opener gancho de un JD tech?
El opener son dos líneas que responden por qué este rol existe ahora y qué cambia cuando la persona entra. No es la visión de la empresa, no es la cultura, no es el about. Ejemplo bueno: estamos doblando el volumen de transacciones en seis meses y necesitamos un Senior Full Stack que rediseñe el motor de pagos para soportarlo. Ejemplo malo: somos una empresa innovadora en crecimiento que busca un talento apasionado.
¿Por qué fracasan los JD que usan rockstar ninja o guru?
Porque el senior con experiencia interpreta esas palabras como señal de cultura poco profesional y compensación por debajo de mercado. Quien escribe rockstar suele esperar trabajo nocturno sin compensación adicional, y quien escribe ninja suele tener equipos pequeños con un único responsable de todo el stack. Los senior ya pasaron por esos roles y los descartan en menos de un minuto.
¿Cómo describir el stack tecnológico de forma honesta?
Listar el stack real con versiones, separando productivo de legacy, e indicando porcentaje aproximado de tiempo en cada uno. Ejemplo: 70 por ciento Python 3.12 con FastAPI y PostgreSQL en producción, 30 por ciento mantenimiento de un servicio legacy en Django 2.2 que se migra en seis meses. Esa honestidad temprana evita el churn de los primeros 90 días cuando el senior descubre que firmaron por un stack que no era el real.
¿Qué beneficios sí mover la aguja en un JD tech senior?
Los beneficios específicos y cuantificados ganan a las listas genéricas. Presupuesto anual de formación con monto explícito, política de home office formalizada (no flexibilidad ambigua), días libres adicionales sobre lo legal, equipo personal de trabajo entregado el día uno, equity o stock options con valuación clara, y tiempo protegido para deep work. Ping pong y cervezas viernes no entran en la decisión de un senior con 8 años de experiencia.
¿Cómo describir el proceso de entrevista en el job description?
Listar las etapas con tiempo total estimado y duración por etapa. Ejemplo: 4 etapas en 2 semanas, llamada inicial 30 min, técnica con pair programming 90 min, entrevista con equipo 60 min, oferta. Esto evita el ghosting interno y respeta el tiempo del candidato. Los procesos que no se describen suelen tener 7 etapas y dos meses, y los senior aprenden a evitarlos.
¿Tu próximo proceso tech merece un job description que sí cierre senior?
IT Workers audita y reescribe el aviso, entrega shortlist en 4 días hábiles y mantiene garantía de 90 días sobre cada contratación. Modelo sin pago anticipado: solo cobramos al cerrar.
Activar proceso WhatsApp directo