Checklist para entrevistar desarrolladores Laravel senior en 2026

Entrevistar a un desarrollador Laravel no debería ser un “adivina lo que pienso” ni un examen de sintaxis de PHP. Si lideras un equipo técnico y necesitas a alguien que aporte desde el día uno, este checklist te ayuda a separar experiencia real de humo en 60-90 minutos.

1. Fase de filtro: código asíncrono real

Antes de la entrevista, envía un code review asíncrono: 30 minutos, sin presión, resultados por escrito. Dale un pull request con problemas reales y pídele que lo revise.

El PR debe contener:

Un controlador gordo con lógica de negocio inline
Falta de type hints y docblocks
Una query N+1
Manejo de errores genérico (try-catch vacío)
Sin tests

Lo que buscas: que identifique al menos 3 problemas, que explique por qué son problemas, y que proponga soluciones concretas. No necesitas que acierte todo; necesitas ver su proceso de pensamiento.

2. Preguntas técnicas abiertas

Arquitectura Laravel

Pregunta	Lo que revela
”¿Cuándo usarías un Action vs un Job vs un Listener?”	Si entiende Service Layer, colas y eventos
”¿Cómo estructuras un módulo de facturación que crecerá a 10 microservicios?”	Visión de escalado, no solo CRUD
”¿Qué harías si un job falla después de 3 reintentos?”	Conocimiento de colas, failed jobs, alertas
”¿Cómo versionas una API interna que usan 4 equipos?”	API versioning, contracts, breaking changes

Testing

Pregunta	Lo que revela
”¿Cuándo un test unitario no es suficiente?”	Si entiende pirámide de testing
”¿Cómo testearías que una factura se envía por email?”	Fakes, Mail fake, event testing
”¿Qué son los Pest architectures y cuándo usarías cada uno?”	Si conoce Pest > PHPUnit a fondo

IA en el flujo de trabajo

Pregunta	Lo que revela
”¿Qué tareas delegas a Claude Code y cuáles revisas siempre?”	Si usa IA con criterio, no como muleta
”¿Cómo aseguras calidad en código generado por IA?”	Proceso de review, comprensión real
”¿Qué MCP servers usas o construirías?”	Si está al día con ecosistema AI/agentes

3. Code review conjunto (en vivo)

Dedica 20 minutos a esto. Comparte pantalla con un fragmento de código real de tu producto (o uno preparado) y pídele que lo critique en voz alta:

// Código para revisión conjunta
class OrderController extends Controller
{
    public function process(Request $request)
    {
        $order = Order::find($request->order_id);
        $order->status = 'processing';
        $order->save();
        
        $user = User::find($order->user_id);
        Mail::send('emails.order', ['order' => $order], function ($m) use ($user) {
            $m->to($user->email);
        });
        
        PaymentGateway::charge($order->total);
        
        return redirect()->back()->with('success', 'Order processed');
    }
}

Señales positivas:

Señala que el controlador tiene demasiadas responsabilidades
Pregunta qué pasa si PaymentGateway falla (falta try-catch, transacción)
Nota la falta de validación (no se verifica si la orden existe)
Pregunta por qué se envía el email antes del pago
Menciona que Order::find debería ser findOrFail

Señales de alerta:

Dice que “está bien” sin criticar nada
Solo señala problemas de sintaxis (punto y coma, etc.)
No menciona transacciones de base de datos

4. Criterio arquitectónico: diseño en pizarra

Dale 15 minutos para diseñar (en papel, Excalidraw o donde se sienta cómodo) la solución a un problema real:

Escenario: “Nuestra aplicación Laravel debe procesar pagos recurrentes. El usuario sube un archivo CSV con pagos del mes, el sistema valida cada fila, procesa el cobro y notifica al usuario si hay errores. ¿Cómo lo modelarías?”

Lo que buscas:

Separación en capas (CSV parser, validator, payment processor, notifier)
Manejo de errores por fila (no fallar todo por un error)
Colas para pagos lentos (cada pago en un job)
Testing: cómo probar cada pieza
¿Menciona un Action o un Service class?

5. Evaluación de comunicación y actitud

Un desarrollador senior no solo escribe código: comunica decisiones técnicas a no técnicos.

Pregunta: “Imagina que el CEO pregunta por qué una feature que parecía sencilla va a llevar dos semanas en lugar de dos días. ¿Cómo le respondes?”

Lo que buscas:

Explica el problema sin jerga técnica innecesaria
Ofrece opciones (solución rápida vs solución correcta)
No menosprecia la pregunta del CEO
Muestra criterio de priorización

Tabla resumen de señales

Área	Señal positiva	Señal de alerta
Código	Critica, sugiere, pregunta	Dice que “está bien”
Testing	Pregunta “¿cómo lo testeas?”	No menciona tests
Arquitectura	Separa responsabilidades, nombra patrones	Todo en controladores
IA	Usa herramientas con criterio	No usa IA o la usa sin revisar
Comunicación	Explica, simplifica, opciones	Se pierde en tecnicismos o no sabe explicar
Colas	Menciona jobs, reintentos, fallos	Solo sabe “dispatch”
Base de datos	Transacciones, índices, N+1	Queries planas sin pensar

Conclusión

El mejor desarrollador Laravel no es el que escribe código más rápido; es el que toma decisiones que ahorran trabajo al equipo. Busca criterio, no sintaxis.

Si prefieres saltarte el proceso y contratar a alguien que ya cumple todo esto, revisa mi stack, mi experiencia y mi disponibilidad.

Ignacio Amat