Una prueba técnica PHP para candidatos sirve cuando ayuda a responder una pregunta concreta sobre el trabajo: ¿puede la persona mantener una API, investigar un fallo o colaborar en una aplicación existente? No debería medir quién dispone de más tiempo libre, conoce una herramienta concreta o adivina las preferencias personales de quien revisa.
Para que el resultado sea útil, el equipo debe definir primero las capacidades relevantes, elegir un formato proporcionado y evaluar con criterios observables. La prueba es una parte del proceso, no un sustituto de la conversación sobre experiencia, colaboración y contexto.
Empieza por las tareas reales del puesto
Antes de escribir un enunciado, aclara qué hará la persona durante sus primeros meses. Un puesto centrado en mantener una aplicación heredada requiere capacidades distintas a uno que desarrolla servicios nuevos. En el primer caso pueden importar la lectura de código, la investigación de errores y la seguridad de cambios pequeños; en el segundo, el diseño de una API o la definición de límites entre componentes.
Elige dos o tres capacidades prioritarias y vincula cada una con una tarea observable. Por ejemplo, si el puesto requiere mantener una API PHP, se puede evaluar cómo se valida una entrada y cómo se explica el comportamiento ante datos inválidos. No es necesario cubrir todo el lenguaje, el framework y la arquitectura en una sola prueba.
También conviene distinguir requisitos imprescindibles de conocimientos que se pueden aprender. Si el equipo puede enseñar una herramienta tras la incorporación, convertirla en condición de acceso puede excluir perfiles capaces sin mejorar la predicción del desempeño.
Elige el formato según lo que necesitas observar
Una revisión de código es apropiada cuando el trabajo consiste en mantener una base existente. Se puede entregar un fragmento breve con un defecto o una decisión discutible y pedir que la persona identifique riesgos, proponga cambios y señale qué probaría. Así se observa lectura y criterio sin exigir construir una aplicación desde cero.
Una conversación técnica resulta útil para explorar decisiones, experiencia y comunicación. Funciona mejor con preguntas ancladas en situaciones concretas y tiempo para que la persona exponga supuestos, alternativas y consecuencias. No debe convertirse en un interrogatorio de memoria sobre sintaxis o detalles poco relevantes.
Un ejercicio práctico acotado puede aportar evidencia sobre implementación cuando esa capacidad es central. Limítalo a una tarea pequeña, como completar una validación o corregir un caso de error en un ejemplo autocontenido. Si se requiere una solución extensa, puede ser más razonable dividir la evaluación en una revisión guiada y una conversación que exigir horas de trabajo en casa.
El formato debe permitir demostrar la capacidad evaluada, no premiar el dominio de un entorno particular. Si el puesto depende de un framework específico, indica cuál y por qué; si no, acepta soluciones equivalentes y valora el razonamiento.
Define un ejercicio con contexto y límites explícitos
Un buen enunciado explica el objetivo, el contexto mínimo, las restricciones y la forma de entregar el resultado. Indica qué comportamiento se espera, qué partes del código se pueden modificar, si hay dependencias disponibles y cuánto tiempo debería ocupar la tarea. Aclara también si se permite consultar documentación y qué herramientas se pueden utilizar.
El ejercicio debe ser representativo, pero no una funcionalidad lista para incorporar al producto. Evita pedir una integración completa, una migración amplia o una característica que el negocio necesita publicar. Si el caso se parece a una tarea real, usa un escenario reducido y ficticio, sin datos ni código confidencial. El resultado de selección no debe convertirse en trabajo de producción gratuito.
El tiempo estimado es un límite de diseño, no una prueba de velocidad. Comunica qué hacer si no se completa todo y anima a priorizar. Es preferible observar una solución parcial bien explicada a favorecer a quien pudo dedicar muchas horas fuera del proceso.
Evalúa con una rúbrica observable
Define la rúbrica antes de revisar candidaturas. Una escala breve —por ejemplo, insuficiente, adecuado y sólido— puede bastar si cada nivel describe evidencias concretas. Evita etiquetas vagas como buen encaje o código elegante, que pueden ocultar preferencias personales.
- Razonamiento: identifica supuestos, explica decisiones y reconoce límites o alternativas.
- Corrección y legibilidad: resuelve el caso planteado con código comprensible y cambios proporcionados.
- Seguridad: trata de forma adecuada entradas, errores y datos sensibles según el contexto del ejercicio.
- Pruebas: elige casos relevantes y explica qué comportamiento cubren, incluso si no escribe una suite completa.
- Colaboración: hace preguntas pertinentes, comunica incertidumbres y responde a observaciones sin ocultar desacuerdos.
No todos los criterios tienen el mismo peso para cada puesto. Una vacante de mantenimiento puede priorizar comprensión y cautela; otra, diseño de interfaces. Explicita esas prioridades y separa errores críticos —como una exposición evidente de datos— de detalles estilísticos que no cambian el resultado.
Revisa el trabajo y pregunta por las decisiones
La evaluación debe tener una secuencia común. Quienes revisan pueden puntuar primero de manera independiente y después comparar evidencias. Esto reduce el efecto de la primera impresión y permite detectar criterios ambiguos. Si hay diferencias, la conversación debería referirse a fragmentos concretos y a la rúbrica, no a intuiciones sobre la personalidad.
En el seguimiento, pregunta por una decisión específica: qué cambiaría con más tiempo, qué caso de prueba añadiría o qué riesgo consideró prioritario. Las preguntas deben permitir aclarar el razonamiento, no introducir de repente requisitos que no aparecían en el enunciado. Da espacio para explicar decisiones distintas de las que el equipo habría tomado.
Valora la respuesta a una observación como evidencia de colaboración, no como obediencia. Una persona puede defender razonadamente otra alternativa. La capacidad de explicar compromisos y revisar una solución ante nueva información suele ser más informativa que coincidir con una preferencia del entrevistador.
Reduce sesgos y ofrece alternativas razonables
Usa las mismas instrucciones, criterios y tiempo para todas las personas que optan al mismo puesto. Cuando sea posible, oculta datos no pertinentes durante la primera revisión y limita los comentarios no estructurados. Acepta formatos equivalentes si miden la misma capacidad: una conversación guiada puede sustituir una tarea en casa cuando el objetivo es entender el razonamiento.
Pregunta con antelación si se necesita un ajuste de formato o accesibilidad y acuerda una alternativa sin penalización. No supongas que las pausas, la rapidez al hablar o el estilo de comunicación informal indican nivel técnico. Del mismo modo, el uso de documentación debe tratarse de forma consistente: en el trabajo habitual, consultar referencias puede ser normal.
Detecta una prueba desproporcionada antes de publicarla
Revisa la tarea desde la perspectiva de una persona candidata. ¿El alcance cabe en el tiempo comunicado? ¿La información permite empezar sin adivinar requisitos? ¿Se evalúan capacidades del puesto o familiaridad con una convención interna no explicada? ¿El equipo podría aprovechar directamente el resultado comercial? Una respuesta preocupante a esta última pregunta exige reducir o reemplazar el ejercicio.
También son señales de alerta una lista extensa de requisitos, una evaluación basada en gusto personal, instrucciones contradictorias o una promesa implícita de que la solución perfecta es necesaria. Si el equipo necesita varias horas para resolver la tarea, probablemente no está bien acotada para una selección inicial.
Lista de comprobación para mejorar el proceso
- Relacionar cada criterio con una responsabilidad real del puesto.
- Elegir el formato más corto que permita observar la capacidad buscada.
- Comunicar contexto, herramientas, límites de tiempo y condiciones de entrega.
- Definir niveles de evaluación con ejemplos de evidencia antes de recibir resultados.
- Aplicar preguntas de seguimiento comparables y permitir explicar alternativas.
- Recoger comentarios de candidatos y revisores para detectar confusión o carga innecesaria.
Una prueba técnica PHP para candidatos no necesita ser compleja para ser rigurosa. Su calidad depende de que mida algo relevante, con una carga razonable y una evaluación coherente. Si después de varias convocatorias los resultados no ayudan a distinguir las capacidades que el puesto requiere, revisa el diseño antes de aumentar la dificultad.
