Hoy no pasé una entrevista… pero aprendí a pensar un poquito más como arquitecto

Hace poco participé en un proceso para un rol de arquitectura de software.
No lo pasé 🥲. Pero, pues como todo, pude aprender de mis errores en el proceso.
Decidí escribir este post porque creo que hablar de los procesos que no salen bien también es valioso, especialmente cuando uno puede convertirlos en aprendizaje técnico y personal.
Además, “si el niño quiere ser arquitecto, entonces que aprenda de lo bueno y de lo malo.” 💪🏻

💬 Reflexión personal

Todo esto desde mi entendimiento, pero hubo puntos donde me mataron y no fue lindo ajajaja.
Una vez me plantearon el caso de uso de cómo se autenticaban los usuarios… me morí 😅 porque lo había asimilado como una caja negra, es decir, asumí que eso vendría de algún lado y, por ende, solo debía conectar eso con mi solución y listo. (Grave error.)
No pude responder adecuadamente cómo se autenticarían en los dispositivos, tampoco cómo sería la carga de archivos y datos de las matrículas. Solo definí un punto: el tratamiento y normalización de datos, pero eso no fue suficiente.
Porque claro, ¿qué pasa si en un país los repositorios de datos están en una base de datos, pero en otro están en un CSV o incluso en un FTP? Entonces… ¿cómo madres recibo eso? Y PUFFFF voliado.com 😂 Me consumieron los nervios y bloqueo total.

Cabe resaltar que, obvio, no soy arquitecto —es mi aspiración— y hoy de nuevo toqué tierra. Ahora sé que me falta mucho por recorrer.
Uno de mis errores pudo ser el ego y pensar que era Jesucristo ajajaj. Llevo 7 años como desarrollador, así que asumí muchas cosas, pero ahora entiendo que los años no siempre se traducen en experiencia en el campo.
La experiencia nace de esos momentos en los que te das cuenta de que incluso te cuesta definir un simple modelo ETL o un API Gateway.
Asi que nada, a estudiar como se debe, porque debemos mejorar.

Por otro lado, también me mataron cuando me preguntaron:
“¿Y cuántos dispositivos se van a conectar a este sistema, a esta solución?”

Y yo, enseguida: “UYYYY princesss, ¿cómo así?” 😂
Tampoco lo tuve en cuenta. Resulta que hay datos públicos (según entendí), y en promedio, por estación de policía —o no sé, ajajaja, ya lo olvidé también— se conectan unos 200 dispositivos.
Ahora, eso por sede y luego por país… ¿cómo gestionamos esa concurrencia de conexiones?
Además, un punto muy crítico fue: ¿y si la conexión es vía GSM y la imagen pesa 1 MB (lo de la imagen lo asumí yo), y el máximo de transferencia vía GSM es de 20 KB por segundo? Entonces nos tomaría un minuto subir la imagen.
¿Y si nos envían imágenes cada minuto del día? ¿Cómo tratamos eso?
Y PUFFF, me sobrecargué yo ajajaja, porque según yo, con encolar esa madre y subirla a S3 ya todo nice… pero no.

Asi que ser arquitecto es bien perro 😅. Me dejaron purgado ajajaj, pero bueno, ¡vamos a seguir intentándolo!

---

🚀 El reto técnico

El desafío consistía en diseñar la arquitectura completa de una plataforma para la detección de vehículos hurtados.
El sistema debía recibir datos desde cámaras ANPR, correlacionarlos con bases policiales de distintos países, y permitir que los agentes de la fuerza pública consultaran evidencias, ubicaciones y reportes a través de un portal web seguro.

Los requisitos incluían:

• Justificar cada decisión técnica.
• Y explicar cómo escalar el sistema a nivel internacional.

Fue un reto completo: técnico, conceptual y comunicativo, pero me corcharon en algunos puntos, y más perdido o embolatado no pude estar 😂.

---

🧩 Mi enfoque

Dividí mi trabajo en tres partes:

1. Modelado con C4

Usé IcePanel para construir tres niveles:

• Contexto: actores, sistemas externos y relaciones principales.
• Contenedores: APIs, colas, servicios y bases de datos.
• Componentes: desglosé el servicio de ingesta en módulos internos (validación, idempotencia, metadatos, evidencias, publicación).

2. Documentación con ADR

Creé un ADR en Markdown donde registré:

• Las decisiones arquitectónicas clave.
• Patrones utilizados (BFF, Event-Driven, CQRS light, Idempotent Consumer).
• Modelo de datos lógico.
• Riesgos, mitigaciones y próximos pasos.

3. Vista de despliegue en AWS

Generé un diagrama con Mermaid, mostrando:

• API Gateway y WAF como capa pública.
• ECS/Fargate para los microservicios.
• SQS/Kinesis como bus de eventos.
• RDS Aurora, DynamoDB y S3 como almacenamiento principal.

---

💬 El feedback que recibí

A pesar del esfuerzo, no superé la entrevista final.
Sin embargo, el feedback fue muy valioso:

• Los nervios jugaron un papel importante; no logré comunicar con calma el razonamiento detrás de mis decisiones y esto me impidió responder con claridad las preguntas.
• No contemplé todos los requerimientos ni las partes del sistema que la empresa esperaba ver, por ejemplo, asumir como “caja negra” el flujo de autenticación y conexión.
• Me faltó mostrar toma de decisiones consciente (por qué elegí una tecnología y no otra).
• Y algo crucial: debí apoyarme y usar herramientas de IA durante el desarrollo del reto, pero parte de mi proceso inicial se apoyó demasiado en ellas.

Fue duro escucharlo, pero honesto.
Y me hizo reflexionar sobre lo que realmente significa ser arquitecto: no solo diseñar sistemas o hacer dibujitos, sino también pensar, justificar y comunicar con claridad.

---

🔍 Lo que aprendí

1. La arquitectura empieza en los requerimientos.
   No basta con dibujar cajas y flechas; hay que entender las necesidades del negocio.

2. Gestionar los nervios también es una habilidad técnica.
   Puedes saber mucho, pero si no logras transmitirlo, el mensaje no llega.

3. Defender decisiones es más importante que acertarlas todas.
   Un arquitecto no adivina el futuro, lo razona.

4. La IA no reemplaza el criterio.
   Puede ayudarte a documentar, pero no debe pensar por ti.

5. Documentar bien es parte de ser arquitecto.
   El ADR fue un punto fuerte. Escribir decisiones es tan importante como tomarlas.

---

🛠 Qué haré distinto la próxima vez

• Crearé una plantilla de análisis de requerimientos antes de diseñar.
• Haré simulaciones para practicar bajo presión.
• Explicaré mis decisiones, incluso las imperfectas.
• Usaré la IA solo como apoyo, no como pilar.

---

🌱 Reflexión final

A veces, no pasar una entrevista no es un fracaso, sino una clase práctica de arquitectura aplicada.
Este reto me obligó a pensar en el diseño, los flujos de datos, la seguridad, la escalabilidad y la comunicación técnica.
Seguiré compartiendo mi proceso, porque aprender en público también es crecer como profesional.

“Perder una entrevista no te define. Pero cómo aprendes de ella, sí.”

---

🧠 Lo que hice

• IcePanel – Modelado C4
• Mermaid Chart – Diagramas de despliegue

---