Carrera profesional y entrevistas EntrevistasTema 4

Contar una decisión técnica como la contaría alguien senior

«Usamos PostgreSQL» no es una decisión: es un dato. Una decisión se cuenta con las alternativas que había, el criterio que desempató y lo que se resignó a cambio. Es la diferencia más visible entre niveles en una entrevista.

9 min de lectura3 bloques para tocar17 de sept de 2026

«Contame una decisión técnica de la que estés orgulloso.» Una respuesta frecuente: «migramos a microservicios y funcionó muy bien». Fin. Quien escucha no sabe qué problema había, qué se consideró, ni por qué eso era mejor que lo otro.

Contar decisiones es una habilidad separada de tomarlas, y es la que más rápido ubica a alguien en un nivel. Lo que se escucha no es qué elegiste: es si sabías que estabas eligiendo.

Las cinco partes

Cómo se cuenta una decisión

El problema, con su restricción. No «necesitábamos escalar», sino «los reportes tardaban 40 segundos y el cliente más grande amenazaba con irse».
Las alternativas reales. Dos o tres que se consideraron en serio, incluida la de no hacer nada.
El criterio que desempató. Qué se priorizó y por qué eso, en ese contexto. Es la parte que muestra criterio en vez de preferencia.
Lo que se resignó. Toda decisión cuesta algo. Nombrarlo es lo que distingue a alguien que decidió de alguien que eligió lo que le gustaba.
Qué pasó después. El resultado, y si algo salió distinto de lo previsto, mejor todavía.

Relato de nivel inicial	Relato con criterio
«Elegimos MongoDB porque era más flexible»	«Los datos venían de tres proveedores con formatos que cambiaban seguido. Evaluamos normalizar en relacional, que nos obligaba a migrar el esquema con cada cambio, contra guardar el documento crudo. Elegimos lo segundo porque priorizamos absorber cambios sin desplegar; a cambio resignamos consultas cruzadas, que resolvimos con una vista materializada»
«Hicimos un refactor grande y quedó mucho mejor»	«Tocar el módulo de precios llevaba tres días y causaba la mitad de los incidentes. Consideramos reescribirlo entero, que eran dos meses, o extraer sólo el cálculo, que eran tres semanas. Hicimos lo segundo porque no podíamos frenar las entregas; quedó conviviendo con el código viejo un año, que fue el costo»

La columna derecha no es más técnica: tiene alternativas, criterio y costo.

Contar errores es donde más se gana

Contraintuitivamente, las historias de decisiones que salieron mal suelen puntuar más que las exitosas, siempre que estén bien contadas:

	Error mal contado	Error bien contado
De quién fue	«El requerimiento estaba mal»	«Asumí que el volumen no iba a crecer y no lo verifiqué»
Cómo se detectó	«Se cayó»	«Lo vimos cuando el tiempo de respuesta se duplicó; no teníamos alerta para eso»
Qué se hizo	«Lo arreglamos»	«Revertimos en veinte minutos, y después agregamos el índice y la alerta»
Qué quedó	Nada	«Desde entonces, cuando asumo algo sobre volumen, lo escribo en el documento y lo verifico con datos»

La última fila es la que convierte un error en evidencia de madurez.

Antes de seguir, predecí

Te preguntan por una decisión técnica que salió mal. ¿Qué conviene contar?

Cuando no tenés decisiones grandes para contar

Es la preocupación típica de quien empieza, y casi siempre es falsa: las decisiones chicas también tienen alternativas y criterio.

Decisión chica	Cómo se cuenta igual
Cómo estructurar un módulo	«Podía dejarlo en un archivo o separarlo por responsabilidad; lo separé porque tres personas iban a tocarlo la misma semana»
Qué biblioteca usar	«Había dos; elegí la más chica aunque hacía menos, porque la otra traía veinte dependencias para algo que usábamos en una pantalla»
Cómo manejar un error	«Podía propagarlo o devolver un valor por defecto; lo propagué porque silenciarlo habría escondido un problema de datos»
Qué probar	«Prioricé los tests del cálculo de descuentos porque era lo que más cambiaba y lo que más plata movía»

Ninguna es una decisión de arquitectura. Todas muestran que sabías que estabas eligiendo.