Una **entrevista para ingenieros sénior con revisión de diseño** pide al candidato que examine una propuesta técnica, ordene los cambios que necesita y explique cómo seguir adelante. Entrega los mismos requisitos a todos los candidatos y evalúa su razonamiento con criterios explícitos. Lo que interesa observar es cómo relacionan cada decisión con sus consecuencias.

Este formato corresponde a una responsabilidad concreta: revisar la propuesta de otro ingeniero antes de que el equipo se comprometa a llevarla a cabo. Te ofrece algo tangible que comentar sin pedir al candidato que invente un sistema entero ni que aporte documentos confidenciales de una empresa anterior.

La guía de Michael Lynch sobre [cómo escribir un documento de diseño de software eficaz](https://refactoringenglish.com/excerpts/write-an-effective-design-doc/) ha suscitado [un nuevo debate en Hacker News](https://news.ycombinator.com/item?id=49696125) esta semana. Su artículo, publicado en junio de 2026, propone centrar estos documentos en las decisiones importantes y dedicarles un esfuerzo proporcional al trabajo. De ahí surge una pregunta útil para una entrevista: ¿sabe esta persona distinguir qué decisiones merecen atención primero?

El ejercicio que sigue es un ejemplo ficticio y original que puedes adaptar. Los tiempos, los datos y la guía de puntuación son propuestas editoriales, **no una prueba de selección validada**. No se hacen afirmaciones sobre su precisión predictiva ni sobre los resultados de contratación.

## Parte de la responsabilidad de diseño que tendrá el puesto

**Utiliza una revisión de diseño cuando revisar propuestas forme parte del trabajo real.** La categoría sénior, por sí sola, no indica si la persona deberá evaluar controles de acceso, procesos de datos, interacciones del frontend o cambios de infraestructura.

Redacta una frase con el responsable de contratación: «Este ingeniero revisará las propuestas de cambios en el backend de nuestro producto para clientes y ayudará al equipo a decidir qué se puede publicar». Después, distingue las decisiones que deberá saber tomar al incorporarse del contexto que piensas enseñarle.

La [guía de análisis de puestos](https://www.opm.gov/policy-data-oversight/assessment-and-selection/job-analysis/) de la Oficina de Gestión de Personal de Estados Unidos (OPM) relaciona las decisiones de selección con las tareas reales y las competencias que exigen. Aplica ese principio al caso concreto. Si el puesto se centra en el frontend del producto, tendrás que sustituir el ejercicio de exportación del backend, por mucho que a tus entrevistadores les guste hablar de colas.

Del mismo modo, la [guía de pruebas de trabajo](https://www.opm.gov/policy-data-oversight/assessment-and-selection/other-assessment-methods/work-samples-and-simulations/) de la OPM señala que las competencias evaluadas deben ser las que se esperan del candidato al incorporarse. No conviertas el conocimiento de una convención interna en un requisito oculto para aprobar si piensas enseñarla después de contratar.

Convierte esa responsabilidad en criterios observables antes de invitar a nadie. Nuestra guía para [definir perfiles de candidato ideal](/docs/building-ideal-candidate-profiles) puede ayudarte. Acota el ejercicio para que cada revisor pueda explicar qué parte del puesto anunciado corresponde a cada criterio.

## Entrega toda la documentación necesaria para la revisión

**Aporta el contexto que permita dar una respuesta razonada.** La documentación debe incluir el objetivo, las restricciones operativas, la solución propuesta, la respuesta que esperas y las condiciones en las que trabajarán los candidatos.

Para una primera prueba piloto, podrías plantear 30 minutos de preparación y una conversación de 30 minutos. Son tiempos de partida para probar con compañeros, no duraciones comprobadas. Si revisar la documentación exige más esfuerzo del anunciado, redúcela antes de usarla con candidatos.

Aclara que pueden entregar notas breves y que no puntuarás el diseño de las diapositivas, la calidad de la prosa ni el número de comentarios. Ofrece una versión de texto accesible. Explica cómo solicitar un ajuste de formato o de tiempo y facilita un contacto para dudas.

Especifica las reglas sobre consulta de documentación, búsquedas en internet, ayuda de IA y colaboración. Si exiges una herramienta concreta, facilita el acceso. La conversación puede revelar más detalles del razonamiento; no demuestra la autoría ni impide que alguien reciba ayuda externa.

Utiliza datos sintéticos y una propuesta ficticia. No pidas diseños internos de las empresas anteriores del candidato ni uses el ejercicio para resolver tareas pendientes de tu producto. Para decidir el esfuerzo, la remuneración y la comunicación del proceso, consulta [cómo estructurar ejercicios de código](/blog/how-to-structure-code-assignments).

## Prueba esta propuesta ficticia de exportación de datos

**Pide al candidato que revise una propuesta acotada, en lugar de diseñar una plataforma de exportación desde cero.** Todo lo que figura en esta sección debe formar parte de la documentación que entregas, incluidas las restricciones que permiten aceptar respuestas distintas.

### El contexto que recibe el candidato

Tu empresa ficticia ofrece una aplicación de gestión. Cada organización cliente tiene sus propios registros. Sus administradores autorizados quieren exportar los registros de su organización a un archivo CSV, un formato de texto que pueden abrir en una hoja de cálculo.

La primera versión tiene estos requisitos y restricciones:

- Un administrador puede solicitar la exportación de los registros de su organización.
- El archivo contiene información privada del cliente. Haber iniciado sesión no basta para autorizar el acceso a los datos de todas las organizaciones.
- El mayor cliente actual tiene 200 000 registros. No has medido el tiempo de generación de la exportación ni el consumo máximo de memoria.
- Los clientes aceptan esperar hasta diez minutos a que el archivo esté listo. No necesitan exportaciones programadas en la primera versión.
- La aplicación ya dispone de procesos en segundo plano y almacenamiento privado de archivos.
- Dos ingenieros tienen una semana para preparar la primera versión. Pueden reducir el alcance inicial si explican cómo afecta a los clientes.
- El equipo no ha acordado cuánto tiempo se conservarán los archivos ni qué ocurrirá si un administrador pierde el acceso después de solicitar una exportación.

Estas cifras definen el supuesto ficticio. No son recomendaciones sobre el tamaño de tu aplicación, los plazos que debes prometer ni el personal necesario.

### La propuesta que hay que revisar

> Añadir un botón Exportar al panel del cliente. El navegador envía el identificador de la organización a un nuevo endpoint. Este comprueba que el solicitante haya iniciado sesión, carga los registros de esa organización, genera el CSV y lo sube al almacenamiento de archivos antes de devolver una URL de descarga.
>
> Guardar la URL en el perfil del usuario para que el panel muestre su última exportación. La URL seguirá siendo válida indefinidamente. Si la petición supera el tiempo de espera, mostrar un error y pedir al usuario que vuelva a pulsar Exportar.
>
> Incluir todos los campos disponibles para evitar nuevas peticiones. Añadir un test que compruebe que un usuario con la sesión iniciada recibe un enlace de descarga. Después del lanzamiento, añadir exportaciones periódicas y un generador de exportaciones configurable.

La propuesta está incompleta a propósito. Díselo expresamente a los candidatos. Les pides que la mejoren, no que adivinen si el entrevistador cree en secreto que ya es correcta.

### La respuesta que solicitas

Pide cuatro cosas:

1. Identificar los tres cambios que priorizarían antes de esta primera versión y explicar qué consecuencia evita o resuelve cada uno.
2. Recomendar una forma de lanzar la versión que respete las restricciones e indicar qué dejarían fuera.
3. Plantear una pregunta pendiente cuya respuesta podría cambiar su recomendación.
4. Describir qué pruebas o datos necesitarían antes de aprobar el cambio, incluidos tests o mediciones.

No hace falta implementar nada. Los candidatos pueden usar un esquema, una lista o un documento breve. Pueden explicitar sus supuestos, pero no deben cambiar un requisito sin advertirlo para que encaje con su arquitectura preferida.

## Busca prioridades que respondan a la propuesta

**Una revisión útil distingue entre un problema que impide el lanzamiento, una duda, una mejora y trabajo futuro.** Detectar doce problemas no es automáticamente mejor que identificar tres importantes y proponer una respuesta coherente.

En este ejercicio, el acceso plantea un problema concreto. La propuesta confía en un identificador de organización enviado por el navegador y solo describe una comprobación de sesión iniciada. El candidato debería relacionar esa carencia con el requisito de que los administradores accedan únicamente a los registros de su organización. «Añadir seguridad» aporta menos que explicar dónde se debe comprobar la autorización.

La generación dentro de la petición web también merece análisis. El número de registros y la falta de mediciones no demuestran que la generación síncrona vaya a fallar. Sí indican que la propuesta no ha demostrado que pueda completarse de forma fiable dentro de los límites de la petición. Fíjate en si el candidato distingue un problema observado de un riesgo que hay que comprobar.

El enlace sin caducidad y la falta de una respuesta para la pérdida de acceso dejan al descubierto una decisión de producto pendiente. Una buena revisión puede preguntar quién debe poder descargar un archivo ya generado y durante cuánto tiempo. No debería inventar una regla de conservación y presentarla como un requisito que ya figuraba en el enunciado.

La [guía de revisión de código de Google](https://google.github.io/eng-practices/review/reviewer/looking-for.html) pide examinar el diseño, la funcionalidad, los casos límite y la complejidad, incluido el trabajo innecesario para posibles necesidades futuras. Son aspectos útiles para esta revisión. La guía trata de revisiones de ingeniería, no de la validez de este ejercicio de selección.

En este caso, el generador de exportaciones configurable puede esperar: no es necesario para la primera versión. Si un candidato dedica la revisión a diseñarlo, debería explicar por qué merece tiempo antes que las cuestiones de acceso y entrega ya planteadas.

## Admite varios planes de lanzamiento razonables

**Puntúa cómo encaja el plan con las restricciones, no si coincide con tu implementación favorita.** Anota alternativas plausibles antes de entrevistar para que los revisores no conviertan una preferencia no declarada en un requisito.

Un candidato podría proponer generar el archivo con los procesos en segundo plano existentes, registrar cada solicitud de exportación, usar almacenamiento privado y ofrecer una ruta de descarga que compruebe la autorización. Podría explicar cómo gestiona las solicitudes repetidas, cómo se informa al usuario de que el archivo está listo o de que la generación ha fallado y qué mediciones permiten comprobar el objetivo de diez minutos.

Otro podría empezar por una versión reducida para clientes que no superen un límite explícito de volumen, mientras mide la generación antes de decidir cuánto trabajo debe pasar a segundo plano. Esa respuesta exige reconocer una limitación: todavía no atiende al cliente más grande. El candidato debe buscar un acuerdo sobre la reducción del alcance, en lugar de afirmar que cumple el requisito original.

Ambos planes siguen necesitando las comprobaciones de acceso pertinentes y una decisión expresa sobre el acceso a los archivos a lo largo del tiempo. Una implementación más sencilla no justifica omitir requisitos. Una más elaborada tampoco merece más puntos por incluir más componentes.

Compara el razonamiento de los planes. ¿Explica el candidato qué puede salir mal, quién lo notaría y qué datos cambiarían la decisión? ¿Reconoce el coste de su propia recomendación? Estas observaciones sirven más que contar términos de arquitectura.

También puedes registrar un desacuerdo justificado. Si un candidato cuestiona el objetivo de diez minutos o el plazo de una semana, pregunta qué le diría al responsable de producto y qué alternativa ofrecería. Cuestionar una restricción no es lo mismo que pasarla por alto.

## Utiliza las mismas preguntas centrales en la conversación

**Prepara la conversación antes de ver la respuesta del candidato.** Mantén las preguntas centrales y utiliza preguntas aclaratorias para entender el razonamiento que presente cada persona.

La [guía de entrevistas estructuradas de la OPM](https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews/) describe preguntas predeterminadas y criterios de puntuación comunes. Puedes aplicar ese principio con una breve guía de conversación:

- ¿Qué problema resolverías primero y por qué va antes que los demás?
- ¿Qué te haría elegir otra forma de lanzar la versión?
- ¿En qué puntos depende tu plan de información que no te hemos dado?
- ¿Qué pedirías que revisara otro especialista?

Después, comunica el mismo dato adicional a todos los candidatos: «Producto confirma que los administradores que pierdan el acceso ya no deben poder descargar exportaciones generadas anteriormente». Pregunta qué cambia en su plan y qué hay que probar.

Avisa de antemano de que la conversación incluirá un requisito adicional. Debe ser una oportunidad para revisar una decisión, no una encerrona para poner a prueba su reacción. Anota si explican un cambio, identifican una protección ya prevista o necesitan más información.

No improvises escenarios cada vez más difíciles para los candidatos que te impresionen. Si a una persona le planteas una caída regional y a otra un cambio de redacción, las puntuaciones resultantes corresponden a ejercicios distintos.

## Puntúa a partir de lo que has observado

**Define qué significa cada puntuación antes de la reunión de evaluación.** Cada criterio debería dar lugar a una nota que otro revisor pueda examinar, en vez de una etiqueta como «aplomo de perfil sénior».

La tabla es una propuesta inicial. Adapta las dimensiones al puesto y prueba las descripciones de cada nivel. Mantén la opción «Información insuficiente» cuando el ejercicio o la conversación no permitan juzgar un aspecto.

| Criterio | Indicios limitados | Cumple lo que se evalúa | Indicios más sólidos |
|---|---|---|---|
| Relaciona los riesgos con los hechos | Menciona preocupaciones generales sin señalar dónde surgen | Relaciona un problema con la propuesta y su efecto en el cliente | Distingue además las carencias conocidas de las cuestiones que requieren mediciones |
| Prioriza el lanzamiento | Enumera cambios sin explicar el orden | Separa los cambios imprescindibles del trabajo que puede esperar | Explica las consecuencias y el coste de ese orden |
| Evalúa alternativas | Indica una herramienta o un patrón preferido | Explica un plan que responde a las restricciones | Identifica una alternativa creíble y cuándo convendría elegirla |
| Responde a información nueva | Repite la respuesta original sin abordar el nuevo dato | Explica qué cambia o por qué una decisión previa ya lo contempla | Detalla las consecuencias para el acceso, los tests y las preguntas pendientes |
| Concreta cómo actuar tras la revisión | Deja comentarios que exigen mucha interpretación | Expone un problema concreto, su justificación y el siguiente paso | Identifica quién debe decidir o aportar los datos que faltan |

Una nota de evaluación podría decir: «Detectó que hay que comprobar la autorización para el identificador de organización; pidió un test con un administrador de otra organización». Otra podría ser: «Recomendó una cola, pero no la relacionó con la duración de la petición ni explicó cómo gestionar los fallos».

Separa estas observaciones de la decisión final de contratación. Un ejercicio solo permite observar una parte del puesto. No determina la capacidad de programar, todas las habilidades de colaboración ni la preparación para cualquier responsabilidad sénior. Nuestra [guía de cuadros de evaluación estructurados](/blog/skills-based-hiring-structured-scorecards) explica cómo organizar los criterios en el conjunto del proceso.

## Prepara a los revisores antes de usar el ejercicio

**Comprueba que los revisores entiendan la documentación y apliquen los niveles de puntuación de forma uniforme.** Pide a compañeros que completen el ejercicio, anota el esfuerzo real y puntúa sus respuestas de forma independiente antes de comentarlas.

Cuando los revisores discrepen, examina el motivo. ¿Uno premió que se nombrara un servicio concreto? ¿Otro dio por hecho un requisito que no figuraba en la documentación? ¿La respuesta era ambigua o la descripción de la puntuación era demasiado amplia? Corrige el ejercicio o la guía antes de que los candidatos se encuentren con el mismo problema.

Guarda una versión de la documentación y de la guía de conversación con cada evaluación. Si cambias los requisitos entre entrevistas, registra el cambio y valora si las puntuaciones anteriores siguen siendo comparables. No mejores las instrucciones a mitad de una ronda de selección sin dejar constancia.

Pregunta a los participantes de la prueba piloto dónde les faltó contexto y qué instrucciones les hicieron dedicar tiempo innecesario. Elimina el trabajo que no contribuya a un criterio explícito. Esta prueba ayuda a mejorar la organización; no demuestra validez predictiva ni ausencia de sesgos.

Asigna revisores que entiendan las decisiones que se evalúan. Si el ejercicio se convierte en un examen especializado de seguridad, incorpora a un revisor cualificado y haz explícito ese requisito, o bien reduce la tarea. El responsable de contratación debe velar por que el puesto, el ejercicio y el equipo evaluador encajen entre sí.

## Organiza la etapa de revisión de diseño en Kit

**Mantén el enunciado, los criterios y las observaciones de los revisores vinculados a la etapa del candidato.** El equipo de contratación sigue siendo quien debe redactar un ejercicio pertinente y decidir qué conclusiones permiten las respuestas.

En Kit, incluye el documento en el enunciado privado de una etapa de prueba práctica y recoge el análisis escrito del candidato mediante un archivo o un enlace a su respuesta. Asigna revisores y criterios de puntuación, y después programa la conversación como una entrevista en directo. Los criterios admiten descripciones, pesos y escalas; tu equipo aporta la guía de evaluación.

Durante una ronda de revisión activa, cada revisor entrega su propia valoración antes de ver las revisiones completadas por sus compañeros. Esto facilita la secuencia de revisión; no demuestra equidad ni corrección. Kit no proporciona una prueba validada de revisión de diseño ni juzga automáticamente la arquitectura.

Termina el enunciado y los criterios de la prueba práctica antes de invitar a candidatos: sus condiciones de evaluación se bloquean cuando el primero llega a la etapa. Si configuras una remuneración, Kit registra la solicitud de pago; tu equipo envía el dinero.

Empieza con una responsabilidad, una propuesta y una lista breve de decisiones que el candidato deba saber explicar. Haz una prueba piloto con tus revisores, corrige las partes confusas y explica a los candidatos qué trabajo les pides exactamente.

> [!CTA]
> **Diseña una etapa en torno al trabajo.** Usa Kit para organizar los criterios y los comentarios del ejercicio de revisión de diseño que redacte tu equipo. [Empieza tu prueba gratuita](/users/sign_up)