Prueba de System Design para evaluar arquitectura de software

Es un formato de pregunta en el que la persona candidata responde dibujando: recibe un enunciado abierto y arma el diagrama en la propia plataforma, con la opción de adjuntar imágenes de apoyo. Sirve para evaluar lo que el código no muestra: arquitectura de sistemas, flujos de datos, diseño de procesos, recorridos e integraciones. Es el formato natural para ejercicios de system design en vacantes de ingeniería, pero funciona igual de bien para diseñar un embudo de ventas, un flujo de atención o un proceso de negocio en vacantes fuera de tecnología.

Sí, y para la mayoría de las etapas del embudo es la forma más justa. En la entrevista de system design en vivo, la persona candidata dibuja bajo presión, con un evaluador mirando, en 45 minutos apretados; parte de lo que se mide ahí es la resistencia al público. En el formato asíncrono, recibe el escenario, tiene el tiempo definido por la empresa para pensar y dibujar, y el evaluador revisa cuando quiera y cuantas veces quiera, comparando candidatos que respondieron exactamente el mismo problema. La recomendación de Coodesh es combinar el diagrama con una pregunta de video o audio en la misma evaluación, en la que la persona candidata explica sus decisiones: el dibujo muestra la solución, la explicación muestra el razonamiento.

Un escenario con restricciones explícitas, porque un system design sin restricciones no tiene respuesta incorrecta. En lugar de "diseña un sistema de mensajería", prefiere "diseña un servicio de notificaciones para 2 millones de usuarios, con un pico de 10 mil envíos por segundo, tolerancia a un retraso de hasta 1 minuto y presupuesto de infraestructura limitado; indica dónde falla primero el sistema". Las restricciones obligan a hacer trade-offs, y el trade-off es lo que diferencia a un sénior de alguien que memorizó un diagrama de referencia. En el campo de orientaciones para la revisión, describe lo que cubre una buena respuesta (particionamiento, colas, punto único de falla, costo) para que la revisión siga siempre la misma vara.

La evaluación es humana, apoyada por las orientaciones de revisión definidas al crear la pregunta: el objetivo del ejercicio y el método de evaluación quedan registrados junto a la pregunta y guían tanto al revisor como a la revisión asistida por inteligencia artificial, cuando se utiliza. En la práctica, el evaluador abre el diagrama, la explicación en video o audio si la hay, y puntúa según los criterios. Esto resuelve el problema clásico de las entrevistas de arquitectura: que cada entrevistador valore algo distinto. Con criterios escritos, dos evaluadores miran el mismo diagrama con la misma vara, y la decisión se vuelve auditable.

Puede intentarlo, y el diseño de la evaluación es lo que lo vuelve inútil. Primero, el formato acepta adjuntar imágenes porque hay usos legítimos, como fotografiar un borrador en papel; si la empresa quiere el dibujo hecho en la plataforma, basta con indicar en el enunciado que no se considerarán adjuntos. Segundo, los recursos de integridad de la evaluación registran la salida de la pestaña, una segunda pantalla y los pegados, así que el revisor ve si la persona candidata pasó la pregunta entera fuera de la plataforma. Tercero, y más eficaz: con una pregunta de explicación en video o una entrevista con IA a continuación, quien subió un diagrama que no dibujó se traba en la primera pregunta sobre por qué eligió esa cola o dónde se rompe el sistema con el doble de carga. Un diagrama bonito sin defensa es una señal, no una aprobación.

Para ingeniería, a partir del nivel semisénior, cuando las decisiones de arquitectura pasan a formar parte del trabajo, y es obligatorio en procesos de sénior, staff y liderazgo técnico, donde el diagrama dice más que el código. Fuera de ingeniería, funciona para cualquier cargo cuyo trabajo sea diseñar sistemas de otra naturaleza: analistas de procesos (flujos As Is y To Be), product managers (recorridos y arquitectura de funcionalidades), datos (pipelines) y operaciones. Para perfiles júnior de programación, un desafío de código suele medir mejor; la pizarra entra cuando lo que importa es la estructura, no la sintaxis.

Sí. En Biblioteca, al crear una pregunta, elige el tipo Pizarra, escribe el título y el enunciado, define el idioma (portugués, inglés o español), el tiempo, el nivel, el peso y las habilidades evaluadas, y completa las orientaciones de revisión con el objetivo de la pregunta y el método de evaluación. Las preguntas creadas quedan en la biblioteca exclusiva de tu empresa, accesibles solo para tu equipo, y pueden combinarse con cualquier otro formato en una evaluación. Puedes guardarla como borrador y publicarla cuando esté lista.

Puede estarlo. Hereda los recursos de integridad configurados en la evaluación: supervisión de salida de la pestaña, pantalla completa, detección de segunda pantalla, registro de pegados, grabación de la navegación y, si está activada, supervisión por webcam. Para ejercicios de system design, el conjunto más útil es la supervisión de pestañas y la grabación de la navegación, que muestran el proceso de construcción del diagrama, no solo el resultado. Los detalles de cada recurso están en la página de integridad y proctoring de Coodesh.