Si llevas meses con una vacante abierta, la explicación de siempre es que el talento escasea. Esa respuesta cuenta la mitad de la historia, y la otra mitad cambia lo que conviene hacer.
Si llevas meses con una vacante de desarrollador PHP senior abierta, probablemente ya hayas escuchado la explicación de siempre: el talento escasea. Es una respuesta cómoda, y solo cuenta la mitad de la historia.
La otra mitad la tienen los propios desarrolladores, y la dicen sin rodeos cuando alguien pregunta en público por qué es tan difícil contratar. La respuesta que más se repite no es «no hay suficiente gente». Es «no nos dan oportunidad como juniors, y sin juniors no hay de dónde salgan más seniors». Es «las vacantes piden veinte requisitos y solo necesitan cinco». Incluso desarrolladores con diez y hasta treinta años de experiencia en PHP dicen estar buscando trabajo activamente, sin encontrarlo fácil.
Las dos partes tienen razón. Y entender por qué ayuda más que repetir la palabra «escasez».
Esto no es una anécdota aislada de tu empresa. Es un patrón con nombre en la industria de reclutamiento: el «unicornio», una vacante armada por comité, donde cada persona que la revisa (el gerente, recursos humanos, la política interna de la compañía) le agrega un requisito más sin ver el efecto acumulado de lo que ya agregaron los demás. Nadie decide individualmente pedir un imposible. El resultado, sí lo es.
El problema se agrava con un detalle técnico: muchas empresas filtran currículums de forma automática, buscando palabras clave exactas. Para no perder al candidato ideal, quien redacta la vacante mete cada palabra clave posible «por si acaso», inflando la lista todavía más allá de lo que el puesto realmente necesita el primer día.
Y aquí se cierra el círculo. Cuando una vacante pide de más, los candidatos capaces se autoexcluyen: alguien que cumple quince de veinte requisitos, con frecuencia, simplemente no aplica, asumiendo que no calificará. Eso reduce el grupo de candidatos que tu empresa realmente ve. Un grupo más delgado refuerza la sensación de que «no hay talento», lo que justifica no invertir en formar perfiles junior, porque total, parece más simple buscar seniors ya hechos. Con menos juniors entrando hoy, en unos años hay menos gente acumulando la experiencia para volverse senior. El círculo vuelve a empezar, un poco más cerrado que antes.
Nadie en esta cadena actúa de mala fe. Quien contrata responde de forma razonable a un riesgo real: contratar mal cuesta caro. Quien busca empleo tampoco exagera, porque su experiencia de que le piden de más y no le dieron oportunidad como junior es exacta. Es un problema estructural, no una discusión de quién tiene razón.
Antes de descargar, tres preguntas rápidas sobre tu equipo de desarrolladores PHP. Es información que usamos para entender, del lado de quienes lo viven, por qué cuesta tanto contratar y retener talento PHP senior. Tardan menos de un minuto, y las dos últimas son opcionales.
(*)Obligatorio.
Esto merece decirse con la misma honestidad que el resto: el problema no es que no exista quien buscar. Hay cuatro correcciones concretas al proceso, y ninguna cuesta dinero.
Esto no resuelve el problema de fondo, que es estructural y de toda la industria, pero sí amplía de inmediato el grupo real de candidatos que tu vacante puede alcanzar.
Corregir el proceso de contratación ayuda, pero no es instantáneo. Publicar mejor una vacante no acorta a la mitad un proceso que hoy toma semanas o meses. Y mientras esa vacante sigue abierta, el sistema que depende de esa persona sigue funcionando en producción, con el mismo riesgo de siempre.
Aquí vale la pena separar dos preguntas que suelen mezclarse. Una es «¿cómo resolvemos la contratación?», con las correcciones de arriba, a mediano plazo. La otra es «¿qué protege el sistema mientras tanto?», y esa no puede esperar al primer día del nuevo desarrollador.
La respuesta a la segunda no depende de resolver la primera. El soporte comercial sobre el runtime PHP, con parches de seguridad respaldados por el mismo equipo que mantiene el lenguaje y SLA de respuesta ante incidentes, existe exactamente para cubrir ese periodo, dure seis meses o tres años, sin que el sistema quede expuesto mientras la contratación avanza a su propio ritmo.
Zend Server llega a fin de fabricación en diciembre de 2026 y a fin de vida en diciembre de 2027. Con esas dos fechas ya hay un calendario real para pensar el plan a un horizonte de tres a cinco años, y no solo para la próxima vacante.
Piensa en dos formas de proteger un sistema. Una es tener siempre a alguien de guardia, vigilando cada puerta, atento a cada parche pendiente. Es agotador, y depende de que esa persona nunca falte. La otra es construir una muralla con foso alrededor: una capa de protección que no depende de quién esté de guardia hoy.
El soporte comercial de ZendPHP funciona como esa segunda opción. Protege el sistema, con parches y respuesta garantizada, para que tu equipo de desarrollo se dedique a construir, no a vigilar.
No es una promesa de que nunca pasará nada. Es tiempo y margen real para decidir con calma si la salida a tres o cinco años es corregir la contratación, migrar de tecnología, o ambas cosas a la vez, en lugar de decidirlo de urgencia la noche que algo se rompe.
Descarga la guía en PDF
Una copia para llevar y compartir con tu equipo.
Descargar el PDF →Normalmente no es por falta de candidatos, sino porque la vacante describe a alguien que no existe. Cuando cada revisión interna añade un requisito, la lista final se vuelve imposible y los candidatos capaces se autoexcluyen antes de aplicar.
Los que vayas a necesitar el primer día, y pedidos como prácticas en vez de como años: arquitectura, pruebas automatizadas y diseño de APIs. Si la lista de indispensables pasa de cinco, conviene revisarla en conjunto antes de publicar.
Separando indispensables de deseables, pidiendo prácticas en vez de antigüedad, considerando a quien cumple el 80 % con un plan de acompañamiento, y ampliando la búsqueda a Latinoamérica.
Es el número de personas que tendrían que desaparecer de un equipo para que un sistema deje de poder mantenerse. Cuando ese número es uno, todo el conocimiento operativo vive en una sola cabeza y cualquier ausencia se convierte en un riesgo real para el sistema, no solo en una molestia de calendario.
El soporte comercial sobre el runtime PHP: parches de seguridad respaldados por el equipo que mantiene el lenguaje y un SLA de respuesta ante incidentes. No depende de resolver la contratación y cubre el periodo completo, dure lo que dure.
PHP sin soporte en producción: qué significa y qué riesgos implica
Los tres riesgos reales de un runtime EOL (seguridad, cumplimiento y estabilidad) y el calendario de versiones de referencia.
Leer la guía →PHP 8.1 y 8.2: fechas de fin de vida y qué hacer antes
PHP 8.2 llega a su EOL el 31 de diciembre de 2026: las dos opciones que tienes antes de esa fecha.
Leer la guía →Cómo migrar de Zend Server a ZendPHP + ZendHQ
Zend Server llega a su fin de vida en diciembre de 2027: guía de migración en seis pasos, sin downtime.
Leer la guía →PHP sin soporte y cumplimiento normativo: PCI-DSS, ISO 27001 y CNBV*
Por qué un runtime EOL es un hallazgo crítico en auditoría, y cómo documentar el soporte continuo.
*La CNBV (Comisión Nacional Bancaria y de Valores) es el regulador del sector financiero en México.
Leer la guía →ZendHQ: observabilidad para PHP sin cambiar código
Captura de excepciones, Z-Ray y JobQueue centralizados para todos los servidores PHP.
Leer la guía →Calendario de versiones PHP y fechas de fin de vida
Tabla de referencia rápida con las fechas oficiales de EOL, de PHP 7.2 a 8.4.
Ver el calendario →