Método STAR: 50 ejemplos reales para entrevistas tech en LATAM

Método STAR: 50 ejemplos reales para entrevistas tech en LATAM

Por qué el método STAR es la habilidad más subestimada de cualquier búsqueda laboral

Pasaste meses aprendiendo React, estudiando algoritmos, haciendo LeetCode a las 11 de la noche. Y cuando llega la ronda de behavioral interview, te quedás en blanco.

No porque no tengas historias. Las tenés. El problema es que bajo presión, el retrieval falla. Tu cerebro intenta correr RAG sobre tus propias experiencias y el context window se llena de ruido: nervios, el acento del entrevistador, el inglés que de repente se siente pesado.

El método STAR no es una técnica de comunicación. Es un sistema de indexación de tu memoria bajo presión.

Este artículo te da 50 ejemplos reales, con respuestas completas, código donde aplica, y variantes en inglés para cuando la entrevista es en el idioma que no es el tuyo.

Qué es el método STAR (la versión que importa)

S — Situación: el contexto mínimo necesario. 1-2 oraciones. No más.

T — Tarea: tu responsabilidad específica en esa situación. Qué se esperaba de vos.

A — Acción: lo que VOS hiciste. No el equipo. Vos. Verbos en primera persona del singular.

R — Resultado: números, impacto, aprendizaje. Si no tenés número exacto, estimá con honestidad.

El error más común

La mayoría de los candidatos pasan el 70% del tiempo en S y T, y llegan al resultado con 10 segundos de "y todo salió bien". Invertí esa proporción. Las Acciones y el Resultado son el 80% de lo que el entrevistador quiere escuchar.

Duración ideal

• Presencial o videollamada: 90 segundos a 2 minutos por respuesta.
• Si pedís que te hagan más preguntas de seguimiento, estás en el camino correcto.
• Si el entrevistador dice "¿y qué hiciste vos específicamente?" es porque perdiste el hilo en el "nosotros".

Las 8 categorías de preguntas behavioral en empresas tech

Antes de los ejemplos, necesitás entender qué evalúan:

| Categoría | Qué mide | Señal de alerta |

|---|---|---|

| Conflicto | Madurez, comunicación | Culpar a otros |

| Liderazgo | Iniciativa sin título | Protagonismo vacío |

| Fracaso | Honestidad, aprendizaje | Negar el error |

| Decisión bajo incertidumbre | Criterio, velocidad | Parálisis por análisis |

| Colaboración | Empatía, flexibilidad | "Yo hice todo" |

| Priorización | Juicio de impacto | No tener criterio claro |

| Crecimiento técnico | Curiosidad, autonomía | Estancamiento |

| Persuasión/influencia | Comunicación, data | Imponer sin escuchar |

LAS 50 PREGUNTAS CON RESPUESTAS COMPLETAS

BLOQUE 1: RESOLUCIÓN DE PROBLEMAS TÉCNICOS

1. Contame sobre un bug difícil que tuviste que debuggear.

*Pregunta en inglés: "Tell me about a challenging bug you had to debug."*

Situación: Estaba trabajando en una API de pagos para un e-commerce en Colombia. Teníamos un bug que solo aparecía en producción, con ciertas tarjetas Visa, a las 2-3 AM hora local.

Tarea: Era el único backend developer de guardia ese fin de semana. El bug estaba generando cobros duplicados en el 0.3% de las transacciones.

Acción:

Primero repliqué el patrón: los duplicados ocurrían siempre con transacciones que tardaban entre 28-32 segundos. Revisé el código del webhook de la pasarela:

// El problema estaba acá — timeout sin idempotency key
async function handlePaymentWebhook(payload: PaymentPayload) {
  const payment = await db.payments.findUnique({
    where: { external_id: payload.transaction_id }
  });
  
  if (payment?.status === 'completed') {
    return { ok: true }; // Llegábamos hasta acá pero...
  }
  
  // ...si el webhook llegaba DOS VECES antes de que el primero
  // terminara de escribir en DB, ambos pasaban este check
  await processPayment(payload);
}

El problema era una race condition: la pasarela reintentaba el webhook a los 30 segundos si no recibía respuesta, y nuestra función a veces tardaba exactamente ese tiempo en escribir en base de datos. Dos webhooks del mismo pago llegaban solapados.

La solución fue implementar un lock distribuido con Redis:

async function handlePaymentWebhook(payload: PaymentPayload) {
  const lockKey = `payment_lock:${payload.transaction_id}`;
  const lock = await redis.set(lockKey, '1', 'NX', 'EX', 60);
  
  if (!lock) {
    // Otro proceso ya está manejando este webhook
    return { ok: true, duplicate: true };
  }
  
  try {
    const payment = await db.payments.findUnique({
      where: { external_id: payload.transaction_id }
    });
    
    if (payment?.status === 'completed') {
      return { ok: true };
    }
    
    await processPayment(payload);
  } finally {
    await redis.del(lockKey); // Liberar siempre, incluso en error
  }
}

Resultado: Los cobros duplicados cayeron a cero. Documenté el patrón para el equipo y agregamos un test de carga que simula webhooks concurrentes. En el siguiente sprint, aplicamos la misma solución preventivamente a otros 3 endpoints que tenían el mismo patrón.

2. ¿Tuviste que tomar una decisión técnica sin tener toda la información que querías?

*"Tell me about a time you had to make a technical decision with incomplete information."*

Situación: Éramos una startup fintech en México y necesitábamos elegir entre PostgreSQL y MongoDB para nuestro nuevo módulo de analytics antes de un lanzamiento en 6 semanas. No teníamos datos claros sobre el volumen final de transacciones.

Tarea: Me pidieron hacer la recomendación con argumentos sólidos en 48 horas.

Acción: En lugar de buscar la respuesta perfecta, definí los criterios de decisión bajo incertidumbre:

1. 1¿Qué es más caro de equivocarse? Si proyectábamos mal para arriba, escalar era el problema. Si proyectábamos mal para abajo, quedábamos sin features.
2. 2¿Qué podíamos cambiar después? La base de datos es difícil de migrar. El esquema es más flexible.

Armé una tabla de trade-offs con tres escenarios: 10k, 100k y 1M eventos/día. PostgreSQL ganaba en dos de tres porque nuestro equipo lo conocía, el modelo relacional matcheaba con los reportes que necesitábamos, y JSONB nos daba la flexibilidad esquemática que queríamos explorar.

Presenté la recomendación con el razonamiento explícito y dije: "Si en 3 meses superamos 500k eventos diarios o el esquema cambia drásticamente, esta decisión merece revisión."

Resultado: Elegimos PostgreSQL. A los 4 meses teníamos 80k eventos diarios y el esquema había cambiado 3 veces. La decisión se sostuvo. Lo más valioso fue documentar el razonamiento: cuando 6 meses después alguien preguntó "¿por qué no usamos MongoDB?", la respuesta ya estaba escrita.

3. Contame sobre una vez que tuviste que optimizar código que no escribiste vos.

*"Tell me about a time you had to optimize code you didn't write."*

Situación: Heredé el módulo de búsqueda de un producto SaaS B2B en Argentina. Los usuarios se quejaban de que la búsqueda tardaba 8-12 segundos.

Tarea: Reducir la latencia a menos de 2 segundos sin cambiar la interfaz ni los resultados.

Acción: Lo primero fue medir, no asumir. Agregué logging de performance en cada paso:

import time
import logging

def search_products(query: str, filters: dict) -> list:
    start = time.perf_counter()
    
    # Paso 1: normalizar query
    normalized = normalize_query(query)  # ~0.001s - OK
    
    # Paso 2: fetch de base de datos
    t1 = time.perf_counter()
    raw_results = db.execute("""
        SELECT p.*, c.name as category_name, 
               array_agg(t.name) as tags
        FROM products p
        JOIN categories c ON p.category_id = c.id
        JOIN product_tags pt ON p.id = pt.product_id
        JOIN tags t ON pt.tag_id = t.id
        WHERE p.name ILIKE %s OR p.description ILIKE %s
        GROUP BY p.id, c.name
    """, [f'%{normalized}%', f'%{normalized}%'])
    logging.info(f"DB query: {time.perf_counter() - t1:.3f}s — {len(raw_results)} rows")
    # ⚠️ 7.2 segundos acá

El problema era la query SQL: ILIKE '%query%' no puede usar índices. Para 2 millones de productos, era un full table scan.

La solución fue implementar búsqueda full-text con PostgreSQL:

-- Agregar columna de búsqueda
ALTER TABLE products ADD COLUMN search_vector tsvector;

-- Crear índice GIN
CREATE INDEX products_search_idx ON products USING GIN(search_vector);

-- Trigger para mantener actualizado
CREATE TRIGGER products_search_update
BEFORE INSERT OR UPDATE ON products
FOR EACH ROW EXECUTE FUNCTION
tsvector_update_trigger(search_vector, 'pg_catalog.spanish', 
                        name, description);

-- Query optimizada
SELECT p.*, c.name as category_name
FROM products p
JOIN categories c ON p.category_id = c.id
WHERE p.search_vector @@ plainto_tsquery('spanish', $1)
ORDER BY ts_rank(p.search_vector, plainto_tsquery('spanish', $1)) DESC
LIMIT 50;

Resultado: La búsqueda pasó de 8 segundos a 180ms en promedio. El NPS del módulo de búsqueda subió de 23 a 71. Documenté el patrón y en el siguiente sprint lo aplicamos a otros 2 módulos con problemas similares.

4. ¿Alguna vez tuviste que refactorizar un sistema legacy mientras seguía en producción?

*"Tell me about refactoring a legacy system while keeping it running."*

Situación: Una app de facturación en Chile con 7 años de antigüedad, escrita en PHP vanilla con toda la lógica de negocio mezclada en los archivos de presentación. 4,000 clientes activos dependían del sistema.

Tarea: Modernizar el backend sin cortar el servicio, en un equipo de 2 personas.

Acción: Usé el patrón Strangler Fig: en lugar de reescribir todo, fui migrando módulo por módulo detrás de un proxy.

Primero configuré un router que enviaba el tráfico al sistema viejo por default:

# nginx.conf — strangler fig proxy
location /api/ {
    # Por default, va al sistema viejo
    proxy_pass http://legacy-php:8080;
    
    # Módulos migrados van al nuevo sistema
    location /api/invoices/ {
        proxy_pass http://new-service:3000;
    }
    location /api/customers/ {
        proxy_pass http://new-service:3000;
    }
}

Luego migré módulo por módulo: primero los de menor riesgo (catálogos read-only), después los transaccionales. Cada migración tenía un feature flag para poder hacer rollback en 30 segundos.

Resultado: En 8 meses migramos el 80% del sistema sin un solo corte de servicio. Los 3 incidentes que tuvimos se resolvieron en menos de 5 minutos por los feature flags. El equipo ganó confianza en el patrón y ahora lo aplicamos proactivamente en proyectos nuevos.

5. Contame sobre una vez que tuviste que aprender una tecnología nueva muy rápido.

*"Tell me about a time you had to learn a new technology quickly."*

Situación: Me asignaron a un proyecto de migración a Kubernetes. El cliente lo quería en producción en 6 semanas. Yo nunca había usado K8s en producción, solo algunos tutoriales.

Tarea: Diseñar e implementar la arquitectura de deployment para una app con 12 microservicios.

Acción: En lugar de intentar aprenderlo todo, identifiqué el 20% del conocimiento que resolvería el 80% del trabajo: pods, deployments, services, ingress, y configmaps. Bloqueé 3 horas diarias solo para esto durante las primeras 2 semanas.

Armé un cluster de práctica en minikube y desplegué versiones simplificadas de los servicios reales. Cuando me trababa, no googleaba respuestas: buscaba la documentación oficial primero, y solo si no entendía buscaba Stack Overflow.

El bloqueo más grande fue la gestión de secretos. Encontré 3 enfoques distintos en distintos posts. En lugar de elegir uno al azar, documenté los trade-offs y los presenté al tech lead para que tomara la decisión con contexto.

Resultado: El cluster estuvo en producción a tiempo, con 2 días de margen. En las primeras 4 semanas post-lanzamiento tuvimos 99.7% de uptime. Lo más importante: al final del proyecto, había documentado todo el proceso de aprendizaje, que se convirtió en el onboarding para el siguiente developer que se sumó al equipo.

BLOQUE 2: TRABAJO EN EQUIPO Y CONFLICTOS

6. Contame sobre un desacuerdo técnico con un compañero.

*"Tell me about a technical disagreement with a teammate."*

Situación: Estaba en un equipo de 4 developers en una empresa de logística en Bogotá. Yo proponía usar GraphQL para la nueva API; el lead developer insistía en REST. El debate se puso tenso en una reunión.

Tarea: Llegar a una decisión técnica sin dañar la relación con el equipo ni bloquear el proyecto.

Acción: Pedí una reunión específica para el tema, no en el calor del momento. Preparé una tabla comparativa honesta, incluyendo puntos donde REST ganaba claramente (familiaridad del equipo, ecosistema de herramientas internas, debugging más simple). Fui el primero en citar esos puntos.

El argumento que cambió la conversación no fue técnico: fue de riesgo de equipo. "Si usamos GraphQL, las primeras 4 semanas voy a ser el único que pueda debuggear los problemas de N+1 queries. Eso nos hace frágiles. Si decidimos usarlo igual, propongo un spike de 1 semana donde todos practiquen con un módulo chico antes."

El lead aceptó el spike. Al final del spike, el equipo decidió por REST por sus propios motivos. No los míos.

Resultado: La decisión fue genuinamente colectiva. El lead me agradeció haber presentado los argumentos con sus limitaciones, no solo las ventajas. 3 meses después, cuando llegó un proyecto donde GraphQL era obvio, el mismo lead lo propuso.

7. ¿Alguna vez tuviste que dar feedback difícil a un compañero?

*"Tell me about a time you had to give difficult feedback to a colleague."*

Situación: Un compañero de equipo junior entregaba código que funcionaba pero con muy mala calidad: sin tests, nombres de variables sin semántica, funciones de 200 líneas. Sus PRs tardaban horas en revisarse y eso bloqueaba al equipo.

Tarea: Como semi-senior del equipo, ayudar a que mejore sin desanimarlo ni crear un ambiente hostil.

Acción: Evité el feedback en los code reviews (que ya tenían un tono crítico). Pedí una 1:1 informal. Empecé preguntando qué cosas del trabajo le resultaban más difíciles. Me dijo que no le daban tiempo de hacer las cosas bien, que siempre había urgencia.

Eso cambió mi enfoque. El problema no era solo él, era sistémico. Le propuse trabajar juntos en un módulo pequeño, pair programming, para que viera mis hábitos en contexto real. No para enseñarle; para que viera cómo yo manejaba la presión del tiempo.

En esas 3 horas de pair programming mostré cómo escribir un test primero en 5 minutos ahorraba 30 minutos de debugging después. Lo hice visible.

Resultado: Su calidad de código mejoró gradualmente en los siguientes 2 meses. Lo más importante: él mismo empezó a pedir feedback activamente. En la retro de fin de trimestre mencionó ese pair programming como el momento que más lo había hecho crecer.

8. Contame sobre una vez que tuviste que colaborar con alguien con quien era difícil trabajar.

*"Tell me about working with a difficult colleague."*

Situación: En un proyecto de 4 meses con un diseñador UX que constantemente cambiaba los mockups después de que ya estaban implementados. Había retrabajos casi semanales.

Tarea: Encontrar una forma de trabajar que redujera el retrabajo sin crear fricción con el diseñador.

Acción: En lugar de quejarme al PM, pedí una reunión directa. Pregunté qué lo hacía cambiar los diseños después de que estaban en código. Su respuesta me sorprendió: él no sabía cuándo estábamos "en código" un diseño. Para él, un mockup aprobado en Figma no significaba que ya estuviera construido.

Propuse un protocolo simple: cuando un diseño pasaba a desarrollo, yo le mandaba un mensaje en Slack con el link al PR. Eso era la señal de "congelar". Si necesitaba cambios, primero me consultaba para estimar el impacto.

Resultado: Los retrabajos cayeron un 70% en las siguientes 6 semanas. El diseñador y yo terminamos con un flujo que el resto del equipo adoptó para otros proyectos. La clave fue que el problema era de comunicación, no de actitud.

9. ¿Alguna vez tuviste que trabajar con un equipo distribuido en múltiples zonas horarias?

*"Tell me about working across time zones."*

Situación: Estaba en una empresa argentina trabajando con un equipo de backend en España y frontend en México. La diferencia de horarios hacía que solo teníamos 2 horas de overlap por día.

Tarea: Coordinar un sprint donde los tres equipos dependíamos secuencialmente unos de otros.

Acción: El problema de fondo era la dependencia secuencial: España terminaba una API, México la consumía, yo integraba ambas. Si España se bloqueaba, México esperaba, y yo esperaba después.

Propuse documentación de contratos de API antes de que alguien escribiera una sola línea de código. España definía el contrato OpenAPI, México y yo dábamos feedback en 24 horas, y solo entonces empezábamos a desarrollar. Usamos mocks mientras la API real no estaba lista.

También propuse una regla: cualquier blocker que no se podía resolver asíncronamente en 2 horas se escalaba a la ventana de overlap, no se esperaba hasta el día siguiente.

Resultado: El sprint de 3 semanas terminó a tiempo. Los blockers que antes duraban 24-48 horas pasaron a resolverse en 2-4 horas. El equipo adoptó el patrón de "contrato antes de código" para todos los proyectos inter-equipo.

10. Contame sobre una vez que tuviste que integrar el trabajo de otro developer que estaba mal hecho.

*"Tell me about a time you had to integrate poorly written code from another developer."*

Situación: Un contractor externo entregó un módulo de integración con una API de terceros. El código "funcionaba" pero no manejaba errores, no tenía tests, y los nombres de funciones eran incomprensibles. Me lo pasaron a mí para que lo integrara al sistema principal.

Tarea: Integrar el módulo sin romper nada, en 2 semanas, con el contractor ya fuera del proyecto.

Acción: Lo primero que hice fue escribir tests de caracterización: tests que documentan el comportamiento actual del código, no el deseado. Eso me permitió hacer cambios con confianza.

// Test de caracterización — documenta el comportamiento actual
describe('externalApiModule (characterization)', () => {
  it('returns null on API timeout instead of throwing', async () => {
    // Descubrí esto leyendo el código: silencia el error
    mockApi.simulateTimeout();
    const result = await fetchData('user-123');
    expect(result).toBeNull(); // comportamiento actual, no ideal
  });
  
  it('does NOT retry on 429 rate limit', async () => {
    mockApi.return429();
    const result = await fetchData('user-123');
    expect(result).toBeNull(); // debería reintentar, pero no lo hace
  });
});

Luego envolví el módulo en una capa que sí manejaba errores correctamente, sin tocar el código original. El módulo original quedó como "caja negra" con su comportamiento documentado.

Resultado: La integración estuvo lista en 10 días. La capa de wrapping capturó 3 casos de error silenciados que hubieran llegado a producción. Compartí el patrón de "tests de caracterización" en el knowledge sharing del equipo.

BLOQUE 3: LIDERAZGO E INICIATIVA

11. Contame sobre una iniciativa técnica que tomaste sin que te la pidieran.

*"Tell me about a technical initiative you took without being asked."*

Situación: El proceso de deployment de la empresa tardaba 45 minutos y requería que alguien estuviera presente monitoreando. Era manual, propenso a errores, y bloqueaba releases.

Tarea: Nadie me pidió resolverlo. Lo hice porque me estaba afectando a mí y al equipo.

Acción: Usé mis últimas 2 horas de los viernes durante 3 semanas para automatizarlo. No pedí permiso, pero sí comunicaba avance al tech lead semanalmente para que supiera qué estaba haciendo y pudiera parar si había un problema de prioridades.

El resultado fue un pipeline de CI/CD con GitHub Actions que incluía tests automáticos, análisis estático, y deployment con rollback automático si los health checks fallaban.

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run tests
        run: npm test -- --coverage
        
      - name: Deploy
        run: ./scripts/deploy.sh
        
      - name: Health check
        run: |
          sleep 30
          status=$(curl -s -o /dev/null -w "%{http_code}" $HEALTH_URL)
          if [ $status -ne 200 ]; then
            echo "Health check failed, rolling back..."
            ./scripts/rollback.sh
            exit 1
          fi

Resultado: El deployment pasó de 45 minutos manuales a 8 minutos completamente automático. El equipo hizo el doble de releases en el trimestre siguiente. El tech lead lo presentó como caso de éxito en la all-hands.

12. ¿Alguna vez tuviste que liderar un proyecto sin tener autoridad formal?

*"Tell me about leading a project without formal authority."*

Situación: Un proyecto de migración de base de datos afectaba a 3 equipos. Nadie era el "responsable" del proyecto completo: solo había responsables de cada área.

Tarea: Alguien tenía que coordinar el trabajo inter-equipo. Me ofrecí voluntariamente.

Acción: La clave fue no asumir autoridad que no tenía. En cambio, creé visibilidad: un doc compartido con el estado de cada dependencia, actualizado diariamente. No era un tablero de management, era una herramienta de coordinación que todos podían editar.

Cuando había bloqueos, no escalaba primero. Iba directo a la persona con el bloqueo y preguntaba: "¿Qué necesitás para avanzar?" Si la respuesta era algo que yo podía conseguir, lo hacía. Si no, lo subía al canal de coordinación con el contexto completo.

También documentaba las decisiones con el razonamiento. No "decidimos usar X", sino "decidimos usar X porque Y, considerando Z. Si Z cambia, hay que revisitar."

Resultado: La migración terminó sin ningún incidente de coordinación. Al final del proyecto, el manager de uno de los equipos me pidió que hiciera lo mismo para la siguiente migración. El doc de decisiones se convirtió en un template que el equipo usa hasta hoy.

13. Contame sobre una vez que identificaste un riesgo que otros no habían visto.

*"Tell me about identifying a risk others had missed."*

Situación: Estábamos a 2 semanas de lanzar una nueva funcionalidad de pagos. En una revisión de arquitectura, noté que el manejo de timeouts no estaba contemplado en el flujo de reembolso.

Tarea: Levantar el riesgo de forma constructiva, no como crítica, y ayudar a resolverlo en el tiempo disponible.

Acción: Antes de hablar en la reunión, simulé el escenario: ¿qué pasaba si la API del banco tardaba más de 30 segundos? El resultado era un estado de limbo: el usuario no sabía si su reembolso había procesado o no, y nosotros tampoco.

Presenté el riesgo con el escenario concreto, no con la queja abstracta. Y llegué con dos opciones para resolverlo: una que tomaba 3 días (implementar un job de reconciliación) y una que tomaba medio día (mostrar un estado "procesando" con un email de confirmación posterior, y agregar el job en el sprint siguiente).

El equipo eligió la opción rápida para el lanzamiento y la completa para el sprint siguiente.

Resultado: En las primeras 3 semanas post-lanzamiento, tuvimos 12 reembolsos con timeout. Ninguno quedó en estado de limbo. Ningún usuario llamó a soporte por un reembolso perdido. El PM me agradeció que hubiera llegado con opciones, no solo con el problema.

14. ¿Alguna vez mentoreaste a alguien?

*"Tell me about a time you mentored someone."*

Situación: Una desarrolladora junior que se sumó al equipo tenía muy buena lógica de programación pero le costaba mucho escribir código mantenible. Sus funciones hacían 5 cosas a la vez.

Tarea: Ayudarla a desarrollar el criterio para detectar y separar responsabilidades, no solo darle reglas.

Acción: En lugar de decirle "dividí esto en funciones más pequeñas", le hice preguntas: "Si mañana hay que cambiar la lógica de validación, ¿dónde tenés que ir? ¿Cuántas líneas tenés que entender antes de hacer el cambio?" Esas preguntas la hacían ver el problema por sus propios medios.

Le propuse un ejercicio: revisar código que ella había escrito 3 meses antes y escribir preguntas que le haría al autor. Con distancia temporal era más fácil ver los problemas sin ponerse a la defensiva.

También le recomendé revisar PRs de los developers más senior, no para copiar el estilo, sino para notar qué preguntas le hacían en los code reviews y por qué.

Resultado: En 4 meses, el tiempo promedio de code review de sus PRs cayó de 40 minutos a 15 minutos. Lo más satisfactorio fue cuando empezó a hacer las mismas preguntas que yo le hacía, pero sola, en sus propios code reviews.

15. Contame sobre una vez que tuviste que priorizar en medio de múltiples urgencias.

*"Tell me about managing multiple urgent priorities at once."*

Situación: Un lunes a las 9 AM llegué con: (1) un bug en producción que afectaba el login de usuarios premium, (2) una feature que el CEO quería demostrar en una reunión ese mismo día a las 3 PM, y (3) una revisión de código urgente que bloqueaba a otro developer.

Tarea: Decidir el orden sin tener a mi manager disponible (estaba viajando).

Acción: El criterio que usé fue impacto en usuarios reales primero. El bug de login afectaba revenue directamente: si los usuarios premium no podían entrar, probablemente no renovaban. Eso primero.

Le mandé un mensaje al CEO explicando la situación y proponiéndole: "Puedo mostrarte la feature a las 5 PM en lugar de las 3 PM, o puedo mostrarte el estado actual sin las últimas mejoras a las 3 PM. ¿Cuál preferís?" Respondió que a las 5 PM estaba perfecto.

Le avisé al developer bloqueado que iba a revisar su código en 2 horas. Le di una dirección sobre los puntos que probablemente necesitaban cambio para que pudiera trabajar mientras tanto.

Resultado: El bug de login estuvo resuelto en 90 minutos. La demo fue a las 5 PM como prometí. La revisión de código estuvo antes de las 12. Mi manager, cuando volvió, me dijo que había manejado exactamente como él hubiera esperado.

BLOQUE 4: FRACASOS Y APRENDIZAJES

16. Contame sobre un error que cometiste en el trabajo.

*"Tell me about a mistake you made at work."*

Situación: Hice un deploy en producción un viernes a las 6 PM sin avisar al equipo. Pensé que era un cambio menor: actualizar una dependencia de seguridad.

Tarea: Nadie me pidió que lo hiciera ese viernes. Lo hice por iniciativa propia y sin seguir el proceso.

Acción: El deploy causó un error en la integración con el proveedor de emails: la nueva versión de la librería tenía una API incompatible. Durante 3 horas, los emails de bienvenida no se enviaron. Nadie lo notó hasta el lunes.

Cuando me di cuenta (el lunes a la mañana), lo primero que hice fue revertir el cambio. Luego armé el diagnóstico completo: cuántos usuarios afectados (340), qué información no recibieron, cuál era la ventana de tiempo. Luego mandé el resumen al equipo y al manager con el plan de mitigación: enviar los emails manualmente para los usuarios afectados y agregar un test de integración para ese escenario.

Resultado: Los 340 usuarios recibieron sus emails con una semana de retraso. Ninguno canceló ni se quejó (los emails de bienvenida eran informativos, no transaccionales). El aprendizaje que dejé documentado: "Deploys después de las 4 PM los viernes tienen que ser aprobados explícitamente por el tech lead, sin importar el tamaño del cambio."

17. ¿Alguna vez fallaste en cumplir un deadline?

*"Tell me about a time you missed a deadline."*

Situación: Prometí entregar una integración con una API de terceros en 2 semanas. Tardé 4 semanas.

Tarea: La integración era crítica para el lanzamiento de una feature que el equipo de ventas ya estaba prometiendo a clientes.

Acción: El error fue en el proceso de estimación: asumí que la documentación de la API era correcta. No lo era. Tres endpoints tenían comportamientos distintos a los documentados. Descubrí esto a mitad del segundo sprint.

Mi error más grande fue no comunicar el riesgo de retraso hasta que ya era inevitable. Esperé demasiado esperando que pudiera resolverlo solo.

Cuando finalmente lo comuniqué, llegué con un plan actualizado: qué estaba hecho, qué faltaba, y cuánto tiempo realista necesitaba. También propuse una versión reducida que podría entregarse en tiempo para no bloquear el lanzamiento.

Resultado: El equipo de ventas pudo lanzar con la versión reducida. La versión completa llegó 2 semanas después. El aprendizaje más importante: las estimaciones tienen que incluir explícitamente el tiempo de descubrimiento cuando la dependencia es externa. Ahora siempre agrego un "spike de validación" de 2-3 días antes de estimar cualquier integración.

18. Contame sobre un proyecto que no salió como esperabas.

*"Tell me about a project that didn't go as planned."*

Situación: Lideré la construcción de un sistema de recomendaciones para un e-commerce. Tardamos 3 meses en construirlo. Cuando salió a producción, el CTR era menor que el de las recomendaciones manuales que teníamos antes.

Tarea: Como tech lead del proyecto, entender qué había fallado y cómo comunicárselo al equipo y a los stakeholders.

Acción: Antes de hablar con nadie, pasé 2 días analizando los datos. La hipótesis que habíamos asumido era que los usuarios preferían recomendaciones personalizadas por comportamiento. Los datos mostraban otra cosa: en nuestro mercado (LATAM, mobile, sesiones cortas), los usuarios preferían recomendaciones por "lo que otros compraron", no por "lo que vos viste".

El modelo que construimos era técnicamente correcto pero respondía la pregunta equivocada.

En la postmortem, presenté el análisis honestamente: el equipo técnico ejecutó bien, la hipótesis de producto estaba mal validada. Propuse un proceso para validar hipótesis de comportamiento con experimentos pequeños antes de invertir meses de desarrollo.

Resultado: El sistema fue rediseñado con el patrón correcto en 6 semanas (mucho más rápido porque la infraestructura ya existía). El CTR subió 34% sobre la línea de base. El proceso de validación de hipótesis que propuse fue adoptado por el equipo de producto.

19. ¿Alguna vez tomaste una decisión técnica que resultó ser equivocada?

*"Tell me about a technical decision that turned out to be wrong."*

Situación: Decidí usar microservicios para una aplicación nueva en una startup con 3 developers. Argumenté que nos daría escalabilidad y flexibilidad.

Tarea: Era mi propuesta, mi responsabilidad.

Acción: A los 2 meses era claro que habíamos sobreingenieriado la solución. Teníamos 8 servicios que 3 developers no podían mantener eficientemente. Los deployments eran complejos, el debugging distribuido consumía más tiempo del que nos ahorraba la "escalabilidad".

En lugar de defender la decisión, hice el análisis de deuda técnica y lo presenté al equipo. El costo de mantener la arquitectura actual era mayor que el costo de migrar a un monolito modular. Propuse un plan de migración gradual.

Resultado: En 6 semanas consolidamos en un monolito modular. La velocidad de desarrollo se duplicó. Aprendí que la arquitectura correcta no es la más sofisticada; es la que el equipo puede mantener con los recursos disponibles.

20. Contame sobre una vez que perdiste la confianza de alguien en el trabajo.

*"Tell me about a time you lost someone's trust at work."*

Situación: Un PM dependía de mis estimaciones de tiempo para comprometer fechas con clientes. En 3 sprints consecutivos, mis estimaciones estuvieron 40-60% por debajo del tiempo real.

Tarea: La relación con el PM estaba tensa. Los clientes estaban molestos por los retrasos.

Acción: Pedí una reunión directa con el PM. En lugar de explicar o justificar los retrasos, pregunté: "¿Qué información necesitás de mí para poder planificar con confianza?" Eso abrió una conversación sobre qué era lo que realmente necesitaba.

El problema de fondo era que yo daba estimaciones sin rangos. "2 semanas" vs "entre 2 y 4 semanas, con 80% de confianza en 2 semanas si las dependencias externas responden rápido." Ese contexto era lo que el PM necesitaba para manejar las expectativas de los clientes.

Durante el siguiente mes, empecé a dar estimaciones con rangos explícitos y condiciones. Si algo iba a cambiar la estimación, lo comunicaba inmediatamente.

Resultado: En 2 meses, el PM me dijo que volvía a confiar en mis estimaciones. Lo que cambió no fue que fuera más preciso; fue que fui más honesto sobre la incertidumbre. Los clientes podían manejar mejor los rangos que las fechas exactas que después se movían.

BLOQUE 5: COMUNICACIÓN Y PERSUASIÓN

21. Contame sobre una vez que tuviste que explicar un concepto técnico complejo a alguien no técnico.

*"Tell me about explaining a technical concept to a non-technical person."*

Situación: El CEO de la empresa quería entender por qué necesitábamos invertir en deuda técnica. Para él, era código que "ya funcionaba".

Tarea: Conseguir la aprobación para dedicar 2 semanas del sprint a refactoring, sin el contexto técnico.

Acción: Usé una analogía que resonó: "Imaginate que la empresa ocupa un edificio. Con el tiempo, algunos pasillos se taparon con muebles, algunas habitaciones se volvieron depósitos, y agregar una habitación nueva requiere mover 5 mesas primero. El edificio sigue funcionando. Pero cada vez que querés hacer algo nuevo, tardás el doble porque tenés que mover los muebles."

Luego lo traduje a números reales: en el último trimestre, el 30% del tiempo de desarrollo fue "mover muebles" — código de setup, adaptadores, workarounds para problemas viejos. Si reducíamos eso al 10%, liberábamos 3 semanas de desarrollo por trimestre.

Resultado: El CEO aprobó las 2 semanas. La analogía del edificio se convirtió en el lenguaje compartido del equipo para hablar de deuda técnica en las all-hands. El CEO empezó a incluir "mantenimiento del edificio" como item en el planning de producto.

22. ¿Alguna vez tuviste que convencer a tu equipo de adoptar una nueva práctica o herramienta?

*"Tell me about convincing your team to adopt a new practice."*

Situación: El equipo no escribía tests. Cada vez que alguien tocaba código viejo, rompía algo en otro lado sin saberlo.

Tarea: Convencer a un equipo que "no tenía tiempo para tests" de que los tests les ahorraban tiempo.

Acción: La teoría no funciona. Necesitaba demostración. Pedí permiso para hacer un experimento de 2 sprints: yo escribía tests para el módulo que tenía más bugs históricos. El equipo podía ver el resultado y decidir.

En 2 sprints, el módulo pasó de 4 bugs reportados por sprint a 0. El tiempo de debugging cayó de ~6 horas semanales a ~30 minutos. Esos números eran de nuestro propio historial de tickets.

Cuando presenté los resultados, no dije "debemos escribir tests". Dije: "Acá está lo que pasó. ¿Qué queremos hacer?"

Resultado: El equipo adoptó testing como práctica. No al 100% de cobertura de un día para el otro, sino gradualmente, empezando por los módulos más críticos. 6 meses después, la tasa de bugs en producción había caído 60%.

23. Contame sobre una vez que tuviste que presentar resultados negativos a stakeholders.

*"Tell me about presenting negative results to stakeholders."*

Situación: Un experimento A/B en el que habíamos invertido 6 semanas de desarrollo resultó en métricas neutras. El nuevo onboarding no mejoraba ni empeoraba la activación.

Tarea: Presentar los resultados a producto, diseño y management sin que pareciera tiempo perdido.

Acción: Antes de la reunión, pasé tiempo entendiendo POR QUÉ el resultado fue neutro, no solo QUÉ fue el resultado. Los datos mostraban que el nuevo onboarding mejoraba la activación en mobile pero la empeoraba en desktop, y los efectos se cancelaban.

Llegué a la reunión con eso: no "fracasó", sino "aprendimos algo que no sabíamos". El producto funciona diferente según el dispositivo. Eso era un insight accionable.

También llegué con una propuesta: en lugar de un onboarding único, optimizar por dispositivo. Eso podría capturar la mejora que veíamos en mobile sin sacrificar desktop.

Resultado: El stakeholder más escéptico dijo al final de la reunión: "Esta es la presentación de resultados negativos más útil que vi." El experimento de onboarding por dispositivo se aprobó para el siguiente trimestre.

24. ¿Alguna vez tuviste que push back a un requerimiento del cliente o de producto?

*"Tell me about a time you pushed back on a requirement."*

Situación: El equipo de producto quería que agregáramos una funcionalidad que requería guardar contraseñas de usuarios en texto plano para hacer una integración con un sistema legacy.

Tarea: Bloquear ese requerimiento sin decir simplemente "no se puede".

Acción: Documenté el riesgo de seguridad con lenguaje específico: "Si hay un breach de datos en el futuro y se descubre que almacenamos contraseñas en texto plano, el impacto legal y reputacional va a ser desproporcionadamente mayor que la funcionalidad que ganamos."

Luego llegué con alternativas: (1) OAuth para la integración, que no requería contraseñas. (2) Un campo de API key separado que el usuario generaba voluntariamente. (3) Proponer al proveedor del sistema legacy que actualizaran su API.

La primera opción era técnicamente más difícil pero posible. Ofrecí hacer el análisis de implementación para el siguiente sprint.

Resultado: El requerimiento se redefinió usando OAuth. Tardó 1 sprint más de lo esperado, pero el producto de salida era más seguro y mejor desde la experiencia de usuario. El proveedor del sistema legacy, cuando vio que implementamos OAuth, actualizó su propia documentación para recomendar ese patrón.

25. Contame sobre una vez que tuviste que negociar un scope con tu equipo de producto.

*"Tell me about negotiating scope with your product team."*

Situación: Un sprint con 3 semanas de duración tenía 6 semanas de trabajo comprometido. El PM insistía en que todo era urgente.

Tarea: Reducir el scope sin crear conflicto y sin que el equipo prometiera lo que no podía cumplir.

Acción: En lugar de decir "no podemos hacer todo esto", pedí una sesión de priorización de 30 minutos con el PM. La pregunta fue: "Si solo pudiéramos lanzar 3 cosas de las 6 este sprint, ¿cuáles te moverían las métricas más importantes?"

Esa pregunta puso la responsabilidad de priorizar en product, no en tech. Y abrió una conversación sobre qué era realmente urgente vs. qué era urgente porque alguien lo había pedido hace tiempo.

Terminamos con 3 items comprometidos y 2 en "best effort" con expectativas claras.

Resultado: El sprint cerró con los 3 items comprometidos y 1 de los best effort. El PM empezó a hacer la sesión de priorización al comienzo de cada sprint. La dinámica de "todo es urgente" se fue disolviendo porque el equipo tenía un proceso para tomarlo en serio.

BLOQUE 6: ADAPTACIÓN AL CAMBIO

26. Contame sobre una vez que tuviste que pivotar en medio de un proyecto.

*"Tell me about pivoting mid-project."*

Situación: A la mitad de un proyecto de 3 meses para construir un sistema de reportes, el cliente cambió completamente los requerimientos. La nueva dirección del negocio hacía obsoleto el 60% de lo que habíamos construido.

Tarea: Adaptar el equipo y el plan sin desmoralizar a nadie y sin perder el trabajo útil.

Acción: Lo primero que hice fue mapear qué del trabajo existente era reusable. Del 60% "obsoleto", el 30% era infraestructura (base de datos, autenticación, pipeline de datos) que servía igualmente para los nuevos requerimientos. Solo el 30% era descartable.

Presenté ese análisis antes de hablar del plan nuevo. "No tiramos 3 meses de trabajo; tiramos 6 semanas de código específico de reportes. El resto sigue."

Luego reorganicé el backlog con el cliente, item por item, estimando en días cuánto de lo que querían se podía construir sobre lo existente. Eso les dio una imagen honesta del costo del pivote.

Resultado: El proyecto se extendió 4 semanas en lugar de las 12 que el cliente había temido. El equipo no tuvo pérdida de motivación significativa porque entendió desde el primer día qué se tiraba y por qué. El cliente nos contrató de nuevo para el siguiente proyecto.

27. ¿Alguna vez tuviste que trabajar con tecnologías o metodologías con las que no estabas de acuerdo?

*"Tell me about working with technology or methods you disagreed with."*

Situación: Me contrataron en un equipo que usaba una metodología de deploy con scripts bash caseros para todo. Yo venía de equipos con CI/CD robusto y me parecía frágil.

Tarea: Trabajar efectivamente con esa metodología mientras construía contexto para proponer mejoras.

Acción: El primer mes no propuse nada. Observé y tomé notas: cuántas veces los scripts fallaban, cuánto tiempo tardaban, qué casos no manejaban. Quería entender por qué el equipo los había adoptado, no solo sus limitaciones.

Descubrí que los scripts bash habían sido escritos porque la empresa tenía restricciones de red muy específicas que hacían que las soluciones estándar de CI/CD no funcionaran directamente. El equipo ya había intentado Jenkins y GitHub Actions y habían tenido problemas.

Con ese contexto, propuse mejoras incrementales en lugar de un reemplazo: primero agregar manejo de errores a los scripts existentes, luego agregar tests, luego explorar si las nuevas versiones de las herramientas manejaban las restricciones de red.

Resultado: Pasé 3 meses mejorando los scripts antes de proponer un cambio de herramienta. Cuando lo propuse, el equipo confió en la propuesta porque vieron que entendía sus restricciones. El nuevo sistema tomó 4 meses en implementarse, pero el equipo lo adoptó completamente.

28. Contame sobre una vez que tuviste que cambiar de rol o responsabilidades inesperadamente.

*"Tell me about an unexpected change in your role or responsibilities."*

Situación: El tech lead del equipo renunció 3 semanas antes de un lanzamiento crítico. No había plan de sucesión. El manager me preguntó si podía cubrir el rol temporalmente.

Tarea: Acepté sin saber exactamente qué implicaba. Las responsabilidades no estaban documentadas.

Acción: Lo primero fue un 1:1 urgente con el tech lead saliente para mapear qué estaba en vuelo: qué decisiones pendientes había, qué contexto no estaba documentado, qué riesgos conocía que el equipo no.

Esa reunión de 2 horas fue la más valiosa de las 3 semanas. Salí con un doc de 3 páginas de contexto que de otra forma hubiera tardado semanas en reconstruir.

Para el lanzamiento, reduje el scope agresivamente a lo crítico y documenté todo el proceso de decisión para que el próximo tech lead no tuviera que reconstruir el contexto desde cero.

Resultado: El lanzamiento salió a tiempo. No sin problemas, pero sin incidentes críticos. 2 meses después, cuando llegó un nuevo tech lead, el doc de contexto que armé fue su primer punto de partida. Me dijo que le había ahorrado un mes de onboarding.

29. ¿Alguna vez tuviste que adaptarte rápido a un cambio de prioridades que venía de arriba?

*"Tell me about adapting to a sudden change in priorities from leadership."*

Situación: Estábamos en la mitad de un sprint cuando el CEO anunció que la empresa iba a entrar en un mercado nuevo y necesitaba un MVP en 3 semanas.

Tarea: Replanificar sin tirar el trabajo del sprint actual y comunicar claramente qué era posible.

Acción: Lo primero que hice fue llevar una estimación honesta al manager antes de comprometer nada. No "podemos" o "no podemos"; sino "si priorizamos esto, acá está lo que dejamos de hacer y las consecuencias de cada opción."

Mapeé el trabajo del sprint actual en tres categorías: (1) cosas que había que terminar de todas formas porque tenían deuda de usuarios actuales, (2) cosas que podían pausarse sin consecuencias inmediatas, (3) cosas que se podían reorientar hacia el nuevo MVP.

Resultó que el 40% del sprint era reorientable. Llegué al CEO con ese análisis y le pregunté qué era el MVP mínimo del MVP: qué tenía que estar para que pudiera mostrar el producto a los primeros usuarios del nuevo mercado.

Resultado: El MVP estuvo en 3 semanas. Era mínimo, pero era real. Los usuarios del mercado nuevo empezaron a dar feedback desde la semana 4. El trabajo del sprint no reorientado se retomó en el sprint siguiente sin problemas.

30. Contame sobre una vez que tuviste que manejar incertidumbre alta en un proyecto.

*"Tell me about managing high uncertainty in a project."*

Situación: Me asignaron a un proyecto de integración con una regulación nueva que todavía no era definitiva. La ley cambiaría en 4 meses, pero no sabíamos exactamente cómo.

Tarea: Empezar a construir sin saber exactamente qué había que construir.

Acción: Identifiqué las partes del sistema que no cambiarían independientemente de cómo terminara la regulación: la infraestructura de datos, la capa de autenticación, el modelo de permisos. Esas las construí primero.

Para las partes que dependían de la versión final de la ley, diseñé la arquitectura para que fueran intercambiables: interfaces bien definidas, lógica encapsulada en módulos que podían reemplazarse sin afectar el resto del sistema.

También hablé directamente con el equipo legal para entender qué aspectos de la regulación eran más probables de cambiar. Eso me permitió priorizar la flexibilidad donde más la necesitaba.

Resultado: Cuando la regulación se publicó definitivamente, el 70% del sistema ya estaba construido y era compatible. Solo el 30% necesitó ajustes. La arquitectura modular hizo que esos ajustes tomaran 2 semanas en lugar de las 8 que hubieran tomado si no lo hubiéramos planificado así.

BLOQUE 7: CRECIMIENTO TÉCNICO Y APRENDIZAJE

31. Contame sobre una vez que tuviste que resolver un problema completamente fuera de tu área de expertise.

*"Tell me about solving a problem outside your area of expertise."*

Situación: Era developer backend y me pidieron diagnosticar un problema de performance en el frontend. El equipo de frontend estaba saturado y el problema afectaba directamente una integración con mi API.

Tarea: Diagnosticar y al menos aislar el problema, aunque la solución fuera del equipo de frontend.

Acción: En lugar de pretender que sabía frontend, fui transparente: "No soy experto en esto, pero voy a documentar todo lo que encuentro para que cuando el equipo de frontend mire el problema, tengan el contexto completo."

Empecé por herramientas que entendía: las Chrome DevTools de network. Vi que el problema era un waterfall de 12 requests API que se hacían secuencialmente. La página esperaba el resultado de cada uno antes de pedir el siguiente.

// Patrón problemático que encontré en el código:
async function loadDashboard() {
  const user = await fetchUser();          // 200ms
  const projects = await fetchProjects();  // 180ms
  const notifications = await fetchNotifications(); // 150ms
  const activity = await fetchActivity();  // 220ms
  // Total: ~750ms secuencial
}

// El patrón correcto:
async function loadDashboard() {
  const [user, projects, notifications, activity] = await Promise.all([
    fetchUser(),
    fetchProjects(),
    fetchNotifications(),
    fetchActivity()
  ]);
  // Total: ~220ms (el más lento)
}

Documenté el problema con capturas de la timeline de Network, el código problemático identificado, y la propuesta de solución. Le pasé eso al equipo de frontend.

Resultado: El equipo de frontend implementó la solución en 30 minutos. El tiempo de carga de la página cayó de 2.1 segundos a 0.8 segundos. El developer de frontend que lo implementó me agradeció el diagnóstico y dijo que le había ahorrado horas de búsqueda.

32. ¿Alguna vez implementaste una mejora que nadie había pedido pero que marcó una diferencia?

*"Tell me about an unrequested improvement that made a difference."*

Situación: Notaba que el equipo perdía mucho tiempo cada mañana poniendo en marcha el entorno de desarrollo local: varios pasos manuales, dependencias que a veces fallaban, diferencias entre las máquinas de cada developer.

Tarea: Nadie me había pedido resolver esto. Lo hice en mis horas libres.

Acción: Dockericé el entorno de desarrollo completo con un script de setup de un solo comando:

# Antes: 20-30 minutos de setup manual
# Después:
git clone proyecto && cd proyecto && make setup

# Makefile
setup:
	cp .env.example .env
	docker-compose up -d
	docker-compose exec app npm install
	docker-compose exec app npm run db:migrate
	docker-compose exec app npm run db:seed
	@echo "Listo. http://localhost:3000"

Antes de presentarlo, lo probé con 2 compañeros que nunca habían configurado el proyecto para asegurarme de que funcionaba desde cero.

Resultado: El tiempo de setup cayó de 30 minutos a 5. Los nuevos developers podían contribuir código en su primer día. Cuantificado a lo largo del año, el equipo de 6 personas recuperó aproximadamente 60 horas de tiempo productivo.

33. Contame sobre una vez que tuviste que desaprender algo que creías correcto.

*"Tell me about a time you had to unlearn something you believed was correct."*

Situación: Venía de un contexto donde "siempre preferir microservicios" era un dogma. En mi nuevo trabajo, propuse dividir el monolito en servicios y el tech lead me frenó con datos concretos.

Tarea: Entender por qué mi creencia era incorrecta en ese contexto, sin defenderme.

Acción: El tech lead me mostró métricas: el tiempo de latency entre servicios en su arquitectura era mayor que el overhead del monolito. Con su equipo de 4 personas, el costo de operar múltiples servicios era más alto que el beneficio.

Lo que tuve que desaprender no era que los microservicios sean malos, sino que son una solución a un problema específico de escala y de organización. Con equipos pequeños y sistemas jóvenes, generan más problemas de los que resuelven.

Pregunté qué recursos me recomendaba leer para entender mejor cuándo cada arquitectura tiene sentido. El tech lead me pasó algunos papers de la época de Netflix y Amazon sobre sus decisiones de arquitectura, incluyendo los errores.

Resultado: Cambié mi forma de recomendar arquitecturas: ahora empiezo por el tamaño del equipo y el stage del producto antes de hablar de opciones técnicas. Soy mucho más escéptico de las "mejores prácticas" que no tienen contexto.

34. ¿Alguna vez recibiste feedback que al principio rechazaste pero luego resultó útil?

*"Tell me about feedback you initially rejected but later found valuable."*

Situación: En un code review, un developer senior criticó que mis funciones eran "demasiado puras" y que estaba sacrificando legibilidad por elegancia funcional. Lo tomé a mal porque yo sentía que el código estaba bien.

Tarea: No había ninguna tarea explícita. Fue un momento de ego que tuve que manejar.

Acción: En lugar de responder en el momento, cerré el PR y seguí con otra cosa. Volví 2 días después cuando se me había pasado la reacción inicial.

Leí los comentarios otra vez con distancia. Tenía razón en varios puntos. Mis funciones de 3 líneas con composición eran hermosas para alguien que las escribía, pero para el siguiente developer que leyera el código sin contexto, eran un puzzle.

Le mandé un mensaje al reviewer diciéndole que había vuelto a revisar sus comentarios y que tenía razón. Le pregunté cómo hubiera escrito el mismo código él. Su respuesta fue una lección de pragmatismo.

Resultado: Refactoreé el código con ese criterio. El PR se aprobó en 20 minutos en la siguiente revisión. Lo más valioso: desarrollé el hábito de leer el código que escribo como si lo estuviera leyendo por primera vez, 6 meses después. Esa pregunta cambió cómo evalúo mi propio trabajo.

35. Contame sobre una habilidad técnica que desarrollaste por tu cuenta.

*"Tell me about a technical skill you developed on your own."*

Situación: Notaba que en todas las empresas donde había trabajado, la parte de infraestructura y deployment era una caja negra para el equipo de desarrollo. Dependíamos del "DevOps guy" para todo.

Tarea: Nadie me pidió aprenderlo. Lo decidí porque quería ser autosuficiente.

Acción: Me fijé metas concretas y acotadas, no "aprender DevOps" (que es demasiado amplio). Primero: poder deployar mi propio proyecto side project sin ayuda. Segundo: entender los deployments del trabajo lo suficiente para diagnosticar problemas básicos.

Armé un proyecto real (no un tutorial): un bot de Telegram que monitoreaba precios. Tenía que desplegarlo en un VPS, configurar nginx, manejar los certificados SSL, y hacer que se auto-restarteara si se caía. Cada obstáculo era un aprendizaje obligatorio.

Tardé 3 fines de semana, pero al final tenía experiencia con cosas reales, no simuladas.

Resultado: 4 meses después, cuando el DevOps del trabajo se fue de vacaciones y un certificado SSL venció en producción, pude renovarlo solo en 15 minutos. El CTO lo notó. Eso me abrió la puerta a participar en decisiones de infraestructura que antes no eran "mi área".

BLOQUE 8: IMPACTO EN EL NEGOCIO

36. Contame sobre una vez que tu trabajo tuvo un impacto directo en el negocio.

*"Tell me about a time your work had a direct business impact."*

Situación: La página de checkout de un e-commerce tenía un abandono del 68%. El equipo de negocio pensaba que era problema de precio o producto. Yo tenía una hipótesis diferente.

Tarea: Sin que me lo pidieran, armé un análisis de los logs de error en el checkout.

Acción: Los logs mostraban que el 23% de los abandonos ocurrían exactamente en el paso de validación de tarjeta. Profundicé: el validador de tarjeta rechazaba todas las tarjetas prepago de Mercado Pago. En LATAM, esa es una forma de pago muy común, especialmente en usuarios jóvenes.

Documenté el hallazgo con datos: cuántos usuarios afectados, cuántas transacciones perdidas estimadas, qué se necesitaba para resolverlo. La solución técnica era cambiar la regex de validación de tarjeta y agregar soporte para bins de prepago.

// Validación anterior — rechazaba prepago
const isValidCard = (cardNumber: string): boolean => {
  return luhnCheck(cardNumber) && isKnownBin(cardNumber);
};

// Validación actualizada
const isValidCard = (cardNumber: string): boolean => {
  return luhnCheck(cardNumber);
  // Los bins desconocidos ahora pasan al procesador
  // El procesador decide si acepta o rechaza
};

Resultado: En el primer mes post-fix, el abandono en ese paso cayó del 23% al 4%. El conversion rate total del checkout subió 8 puntos porcentuales. En términos de revenue mensual, representó un incremento de aproximadamente $15k USD para ese cliente.

37. ¿Alguna vez tuviste que tomar decisiones con impacto en el costo de infraestructura?

*"Tell me about making decisions with infrastructure cost implications."*

Situación: El costo de AWS de la empresa había subido un 140% en 6 meses. El CFO preguntó qué estaba pasando.

Tarea: Me asignaron hacer el análisis. No era parte de mis responsabilidades usuales.

Acción: Empecé por el dashboard de Cost Explorer, segmentado por servicio. El 60% del incremento venía de S3 y CloudFront. Investigué qué había cambiado: un feature nuevo que guardaba imágenes de usuario sin ningún proceso de optimización ni limpieza.

Los usuarios subían imágenes originales de 5-15MB. Esas imágenes se guardaban sin comprimir y se servían directamente sin CDN caching apropiado. Con 50,000 usuarios activos, el storage y el egress crecían linealmente.

Propuse tres cambios:

1. 1Comprimir imágenes al momento del upload (reducción de 80% en tamaño)
2. 2Configurar lifecycle policies en S3 para archivar a Glacier las imágenes inactivas
3. 3Configurar Cache-Control headers correctamente en CloudFront

// Sharp para compresión en el momento del upload
import sharp from 'sharp';

async function processUserImage(buffer: Buffer): Promise<Buffer> {
  return sharp(buffer)
    .resize(800, 800, { fit: 'inside', withoutEnlargement: true })
    .jpeg({ quality: 80, progressive: true })
    .toBuffer();
}

Resultado: Los cambios tomaron 1 sprint. El mes siguiente, el costo de AWS bajó 55% respecto al pico. El patrón de compresión de imágenes se adoptó en todos los uploads del sistema.

38. Contame sobre una optimización de performance que tuvo impacto en el usuario.

*"Tell me about a performance optimization that affected users."*

Situación: La app mobile de una fintech tardaba 4-6 segundos en mostrar el saldo y las transacciones recientes al abrir la app. En focus groups, los usuarios describían la app como "lenta" aunque el resto funcionaba bien.

Tarea: Mejorar el perceived performance de la pantalla principal.

Acción: La raíz del problema no era lentitud en la API sino el orden de las llamadas. La app esperaba 3 APIs secuenciales antes de mostrar cualquier cosa. Mientras, el usuario veía un spinner.

Cambié la estrategia a dos etapas: mostrar datos cacheados del último cierre de sesión inmediatamente (sin spinner), y actualizar en background. El usuario veía su saldo en 0.2 segundos, aunque fuera el del día anterior. En los próximos 2-3 segundos, los datos reales reemplazaban los cacheados sin interrumpir la experiencia.

También paralelicé las llamadas a API:

// Antes: secuencial
let balance = await fetchBalance()
let transactions = await fetchTransactions()
let notifications = await fetchNotifications()

// Después: paralelo
async let balance = fetchBalance()
async let transactions = fetchTransactions()
async let notifications = fetchNotifications()

let (b, t, n) = try await (balance, transactions, notifications)

Resultado: El tiempo hasta el primer contenido visible cayó de 4 segundos a 0.2 segundos. En la siguiente encuesta de satisfacción, la percepción de "velocidad de la app" subió de 3.1 a 4.4 sobre 5. La tasa de abandono en el primer segundo cayó 34%.

39. ¿Alguna vez encontraste una oportunidad de negocio en el trabajo técnico?

*"Tell me about finding a business opportunity in technical work."*

Situación: Mientras implementaba integraciones con APIs de terceros para un cliente de e-commerce, noté que el proceso de mapping de campos entre sistemas diferentes era siempre el mismo problema, resuelto manualmente cada vez.

Tarea: Era trabajo técnico de rutina, pero vi un patrón.

Acción: Documenté el patrón y construí una herramienta interna reutilizable en lugar de código específico por cliente. La herramienta podía mapearse a nuevas integraciones en 2 horas en lugar de 3 días.

Cuando terminé, lo presenté al manager no como "construí una herramienta" sino como "esto podría reducir el costo de onboarding de nuevos clientes un 80% para este tipo de integración".

Resultado: La herramienta se usó en 7 clientes en los siguientes 6 meses. Estimamos que ahorró aproximadamente 60 días-persona de trabajo. Mi manager la incluyó en la propuesta técnica para nuevos prospectos como diferenciador.

40. Contame sobre una vez que tuviste que hacer mucho con pocos recursos.

*"Tell me about a time you had to do a lot with limited resources."*

Situación: Startup en etapa temprana. Yo era el único developer. Necesitábamos lanzar un MVP en 6 semanas con un budget de $0 para infra.

Tarea: Construir algo que pudiera onboardear a los primeros 100 usuarios sin caerse.

Acción: La clave fue elegir las batallas de build vs. buy con criterio. Solo construí lo que era el diferencial del producto; todo lo demás lo compré o usé en versión gratuita.

Usé Vercel (free tier) para hosting, Supabase (free tier) para base de datos y auth, Resend (free tier) para emails. El costo de infra al lanzar: $0.

Para el código, usé Next.js con el router de app porque me daba backend y frontend en el mismo repositorio, reduciendo la complejidad de operar dos sistemas.

La priorización técnica fue brutal: si una feature no estaba en el user journey del "caso central" de uso, no existía. Nada de onboarding fancy, nada de dashboards de analytics internos, nada de notificaciones push.

Resultado: El MVP estuvo en 5 semanas. Onboardeamos 150 usuarios en el primer mes con 99.9% de uptime. El costo de infra hasta el mes 4 fue $0. En el mes 5, cuando Supabase y Vercel se quedaron chicos, la arquitectura era lo suficientemente simple para migrar sin reescribir.

BLOQUE 9: SITUACIONES ESPECÍFICAS DE INGENIERÍA EN LATAM

41. ¿Cómo manejaste trabajar en un producto para el mercado LATAM con sus particularidades técnicas?

*"Tell me about building a product for the Latin American market."*

Situación: Construía un sistema de pagos para un marketplace en varios países de LATAM. El desafío no era el código, eran los contextos: cada país tenía su propia moneda, sus propias regulaciones de pagos, y sus propios medios de pago preferidos.

Tarea: Diseñar un sistema que funcionara en México (OXXO, SPEI), Colombia (PSE, Nequi), Argentina (Mercado Pago, transferencias) y Chile (Khipu, WebPay) sin duplicar código para cada país.

Acción: Diseñé una capa de abstracción de proveedores de pago con una interfaz común:

interface PaymentProvider {
  countryCode: string;
  createPaymentIntent(amount: number, currency: string): Promise<PaymentIntent>;
  handleWebhook(payload: unknown): Promise<PaymentResult>;
  getAvailableMethods(): PaymentMethod[];
}

class MercadoPagoProvider implements PaymentProvider {
  countryCode = 'AR';
  // implementación específica de Mercado Pago
}

class OXXOProvider implements PaymentProvider {
  countryCode = 'MX';
  // implementación específica de OXXO
}

// Factory que elige el proveedor correcto por país
function getPaymentProvider(countryCode: string): PaymentProvider {
  const providers: Record<string, PaymentProvider> = {
    'AR': new MercadoPagoProvider(),
    'MX': new OXXOProvider(),
    // ...
  };
  return providers[countryCode] ?? defaultProvider;
}

Otro desafío LATAM: la conectividad variable. Diseñé el flujo para que fuera tolerante a conexiones lentas: operaciones largas con feedback de progreso, reintentos automáticos, y estados persistidos para que el usuario no perdiera el progreso si se cortaba la conexión.

Resultado: El sistema funcionó en 4 países desde el lanzamiento. El volumen de transacciones fallidas por problemas técnicos fue menor al 1%. Cuando se sumó Chile al año siguiente, tomó 2 semanas en lugar de los 2 meses estimados originalmente porque la arquitectura estaba preparada.

42. Contame sobre una experiencia trabajando en remote para una empresa del exterior.

*"Tell me about working remotely for a company outside your country."*

Situación: Mi primera posición full-remote para una empresa estadounidense, desde Argentina. Nunca había trabajado en inglés de forma sostenida ni en un contexto cultural tan diferente.

Tarea: Ser efectivo desde el primer sprint, en un idioma que no era el mío, con una diferencia horaria de 5 horas.

Acción: Los primeros 2 meses los usé principalmente para observar y calibrar: cómo comunicaba el equipo, cuál era el tono en los code reviews, qué nivel de detalle se esperaba en los updates de Slack.

Para el idioma, adopté una práctica concreta: escribía mis mensajes importantes en un borrador primero, los leía en voz alta (mentalmente), y los enviaba solo cuando estaba seguro de que comunicaban exactamente lo que quería decir. Al principio tardaba el doble. Con el tiempo, ese paso desapareció.

Para la diferencia horaria, documentaba el estado de mi trabajo al final de mi día de forma que el equipo en los EEUU pudiera continuar o hacer preguntas sobre mi trabajo mientras yo dormía. Eso redujo los blockers de "esperamos tu respuesta".

Resultado: A los 3 meses, el manager dijo en mi primera evaluación que yo era uno de los miembros del equipo con mejor comunicación asíncrona. Lo que parecía una desventaja (la diferencia horaria) se convirtió en un hábito de documentación que el equipo adoptó.

43. ¿Alguna vez tuviste que lidiar con la inestabilidad económica afectando un proyecto tech?

*"Tell me about dealing with economic instability affecting a tech project."*

Situación: En Argentina, la devaluación cambió el pricing de la app que construíamos en USD a mitad del proyecto. Los usuarios locales que pagaban en pesos de repente veían el precio triplicado.

Tarea: Implementar precios en moneda local con actualización automática, sin que cada cambio de tipo de cambio requiriera un deploy.

Acción: Moví el price book de constantes hardcodeadas en el código a una tabla de base de datos con un sistema de reglas:

CREATE TABLE pricing_rules (
  country_code VARCHAR(2),
  currency VARCHAR(3),
  base_price_usd DECIMAL(10,2),
  fx_rate DECIMAL(10,4),
  updated_at TIMESTAMPTZ DEFAULT NOW(),
  PRIMARY KEY (country_code)
);

-- Vista calculada que los productos usan
CREATE VIEW current_prices AS
SELECT 
  country_code,
  currency,
  base_price_usd,
  fx_rate,
  ROUND(base_price_usd * fx_rate, 2) as local_price,
  updated_at
FROM pricing_rules;

Agregué un cron que actualizaba los tipos de cambio diariamente desde una API pública. Los precios en moneda local se recalculaban automáticamente. Para los usuarios existentes, añadí un grandfathering: el precio al momento de la suscripción se respetaba por 30 días.

Resultado: Cuando ocurrió la siguiente devaluación (3 meses después), los precios se actualizaron automáticamente sin un deploy ni una decisión de producto de urgencia. El churn relacionado con el precio cayó porque los usuarios que pagaban en pesos veían precios razonables en su contexto local.

44. Contame sobre una vez que tuviste que construir para usuarios con conectividad limitada.

*"Tell me about building for users with limited connectivity."*

Situación: Una app de educación financiera para usuarios de zonas rurales en México. Los usuarios usaban 3G intermitente, teléfonos gama baja, y tenían datos limitados.

Tarea: La app existente pesaba 3.2MB en el bundle inicial y tardaba 8 segundos en cargar en 3G.

Acción: Implementé una estrategia de PWA con offline-first:

// Service Worker para cachear recursos críticos
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('app-v1').then(cache => 
      cache.addAll([
        '/',
        '/styles/critical.css',
        '/js/app.js',
        // Solo los recursos del "core path"
      ])
    )
  );
});

// Estrategia stale-while-revalidate para contenido
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      const fresh = fetch(event.request).then(response => {
        caches.open('dynamic').then(cache => 
          cache.put(event.request, response.clone())
        );
        return response;
      });
      return cached ?? fresh;
    })
  );
});

También reduje el bundle de 3.2MB a 480KB con code splitting agresivo, lazy loading de rutas, y compresión de imágenes. Los datos del usuario se sincronizaban en background cuando había conexión, no en el momento de la acción.

Resultado: El tiempo de carga en 3G cayó de 8 segundos a 2.1 segundos. La app funcionaba (con funcionalidad reducida) completamente offline. La tasa de abandono en el onboarding cayó 45%. Los usuarios con conectividad más baja tenían el mismo acceso al contenido crítico que los usuarios con buena conexión.

45. ¿Alguna vez tuviste que trabajar con regulaciones o compliance específico de LATAM?

*"Tell me about working with LATAM-specific regulations or compliance."*

Situación: Implementar una integración con la facturación electrónica en México (CFDI 4.0). Las reglas del SAT cambian con frecuencia y la documentación oficial es famosa por ser ambigua.

Tarea: Construir la integración de forma que los cambios regulatorios no requirieran un deploy de emergencia.

Acción: Separé la lógica de negocio de las reglas regulatorias en capas distintas. Las reglas que cambiaban (catálogos de códigos, validaciones de campos, formatos) vivían en configuración que podía actualizarse sin deploy. La lógica estructural (cómo armar el XML, cómo firmarlo, cómo enviarlo al SAT) estaba en código estable.

También invertí tiempo en construir un validador local que simulaba las validaciones del SAT antes de enviar. Cada vez que el SAT rechazaba un comprobante, agregaba el caso al conjunto de tests.

Resultado: En 18 meses, el SAT publicó 4 cambios a los catálogos. Ninguno requirió un deploy. Solo un cambio (una nueva regla de validación de RFC) requirió código nuevo. El sistema tenía 99.4% de tasa de éxito en la primera presentación de comprobantes.

BLOQUE 10: SITUACIONES EN ENTREVISTAS TÉCNICAS DE FAANG/SCALE-UPS

46. ¿Cómo contribuiste a la cultura técnica de tu equipo?

*"How did you contribute to your team's technical culture?"*

Situación: Me sumé a un equipo que no tenía una cultura de documentación. El conocimiento vivía en la cabeza de las personas más antiguas.

Tarea: Construir un hábito de documentación sin que nadie lo sintiera como overhead.

Acción: En lugar de proponer "documentemos más", empecé a documentar yo mismo y a hacer visible el beneficio. Cada vez que encontraba algo no documentado y lo tenía que investigar, escribía la respuesta en la wiki. Cada vez que terminaba una investigación sobre un bug, dejaba un "postmortem liviano" de 5 párrafos.

El cambio cultural vino cuando un developer nuevo usó mis docs para resolver un problema en 20 minutos que hubiera tardado 2 horas sin esa información. Lo mencionó en público. Eso fue el catalizador.

Propuse una práctica simple: "doc or didn't happen". Si implementabas algo que otros necesitarían entender, dejabas un párrafo en la wiki antes de cerrar el ticket.

Resultado: En 6 meses, la wiki pasó de 40 páginas (principalmente desactualizadas) a 180 páginas activas. El tiempo de onboarding de nuevos developers cayó de 4 semanas a 10 días. En la encuesta interna de satisfacción, "acceso a conocimiento" pasó del item más bajo al tercero más alto.

47. Contame sobre tu contribución más orgullosa en código.

*"Tell me about your proudest technical contribution."*

Situación: Un sistema de matching de candidatos con vacantes que tardaba 4 horas en procesar el batch diario. Con el crecimiento de usuarios, iba a llegar a 12 horas en 6 meses.

Tarea: Reducir el tiempo de procesamiento a menos de 30 minutos.

Acción: Perfilé el proceso y encontré que el 90% del tiempo era un algoritmo de similaridad de texto que se ejecutaba en Python puro. Para cada par candidato-vacante, calculaba la similaridad de coseno entre vectores TF-IDF.

La optimización fue en dos capas:

Capa 1 — Reducir el espacio de búsqueda: En lugar de comparar todos los candidatos con todas las vacantes, filtré primero por criterios hard (seniority, país, skills obligatorias). Solo el 3% de los pares pasaban el filtro inicial.

Capa 2 — Vectorizar el cálculo: Reemplazé el loop Python por operaciones matriciales con NumPy:

import numpy as np
from sklearn.metrics.pairwise import cosine_similarity

# Antes: O(n*m) con loop Python — muy lento
def calculate_matches_naive(candidates, jobs):
    results = []
    for candidate in candidates:
        for job in jobs:
            score = cosine_similarity(candidate.vector, job.vector)
            results.append((candidate.id, job.id, score))
    return results

# Después: operación matricial vectorizada — mismo resultado, 100x más rápido
def calculate_matches_vectorized(candidate_matrix, job_matrix):
    # candidate_matrix: shape (n_candidates, n_features)
    # job_matrix: shape (n_jobs, n_features)
    scores = cosine_similarity(candidate_matrix, job_matrix)
    # scores: shape (n_candidates, n_jobs)
    return scores

Resultado: El batch pasó de 4 horas a 18 minutos. Eso era 13x de mejora. Con el filtrado hard previo, la calidad del matching también mejoró porque los candidatos veían vacantes más relevantes. La tasa de "Ya apliqué" subió 22%.

48. ¿Alguna vez tuviste que diseñar un sistema que escalara?

*"Tell me about designing a system for scale."*

Situación: Una app de notificaciones en tiempo real que funcionaba bien con 1,000 usuarios concurrentes. El cliente proyectaba llegar a 50,000 usuarios concurrentes en 6 meses.

Tarea: Rediseñar la arquitectura de notificaciones para que soportara 50x más carga.

Acción: Primero identifiqué el bottleneck del sistema actual: cada notificación abría una conexión a la base de datos para leer la lista de destinatarios, construir el mensaje, y actualizar el estado. A 1,000 usuarios, eran 1,000 conexiones potencialmente simultáneas.

El rediseño separó las responsabilidades en tres capas:

Capa 1 — Ingestión: Un endpoint que solo escribe en una cola (Redis Streams). Ningún procesamiento, solo persistencia. Latency < 5ms garantizada.

Capa 2 — Procesamiento: Workers que consumen la cola, construyen los mensajes, y los escriben en grupos por tipo de notificación. Escalables horizontalmente.

Capa 3 — Delivery: Conexiones persistentes WebSocket manejadas por un servidor de estado mínimo. Los workers publican en un pub/sub que los servidores de WebSocket escuchan.

[App] → POST /notify → [Queue: Redis Streams]
                              ↓
                    [Workers (x N)] → [Pub/Sub: Redis]
                                              ↓
                              [WebSocket Servers (x M)] → [Clients]

Resultado: Hicimos un load test con 60,000 usuarios concurrentes simulados antes del lanzamiento. El sistema se mantuvo estable con una latencia promedio de 120ms por notificación. En producción, 2 meses después del rediseño, llegamos a 45,000 usuarios concurrentes durante un evento en vivo sin incidentes.

49. Contame sobre una decisión de arquitectura que tomaste pensando en el largo plazo.

*"Tell me about an architecture decision you made with the long term in mind."*

Situación: Una startup de HR tech necesitaba una API para sus primeros clientes. Los fundadores querían lanzar en 4 semanas. Yo podía construir algo rápido y simple, o algo más estructurado que tardara 6 semanas.

Tarea: Recomendar el trade-off correcto entre velocidad ahora y deuda técnica después.

Acción: La pregunta que hice fue: "¿Qué tan seguido van a cambiar los requerimientos de negocio en los próximos 6 meses?" La respuesta fue: mucho. Estaban buscando product-market fit.

Con eso en mente, la inversión correcta no era en escalabilidad técnica (para 10 clientes iniciales no era necesario) sino en flexibilidad de negocio: una arquitectura donde agregar nuevas entidades, nuevas reglas, y nuevos flujos fuera barato.

Propuse un diseño con separación clara entre dominio y delivery, y con un esquema de base de datos que no requiriera migrations complejas para cambios de producto:

// Diseño flexible: entidades con metadata JSON para campos variables
interface HREntity {
  id: string;
  type: 'employee' | 'position' | 'review';
  data: Record<string, unknown>; // campos específicos del tipo
  created_at: Date;
  updated_at: Date;
}

// En lugar de 15 tablas rígidas, 3 tablas + índices en campos frecuentes
// Los campos nuevos van en data.* sin migration

Resultado: En 6 meses, el esquema de datos cambió 7 veces. Ningún cambio requirió una migración compleja. El 6 meses que tardó el diseño vs. 4 se recuperó en la primera semana de cambios cuando el equipo no tuvo que reescribir migrations.

50. ¿Cómo mediste el impacto técnico de tu trabajo?

*"How did you measure the technical impact of your work?"*

Situación: Como developer senior, me daba cuenta de que hacía muchas mejoras que no podía cuantificar en una evaluación de desempeño o en una entrevista.

Tarea: Construir el hábito de medir el impacto antes, durante y después de cada trabajo significativo.

Acción: Para cada proyecto significativo, empecé a documentar tres números antes de empezar: la métrica que quería mover, el valor actual, y el valor objetivo. Al terminar, actualizaba con el resultado real.

Para trabajo técnico que no tenía métricas obvias, desarrollé proxies:

• Tiempo de build: antes/después
• Tiempo de review promedio de PRs en el módulo: antes/después
• Frecuencia de bugs en producción del área: antes/después
• Tiempo de onboarding de developers nuevos al módulo: antes/después

## Mejora X — Log de impacto

**Antes:**
- Tiempo de build: 8 min
- PR review promedio: 45 min
- Bugs/sprint en el módulo: 3.2

**Objetivo:**
- Tiempo de build: <3 min
- PR review: <20 min
- Bugs/sprint: <1

**Después (6 semanas):**
- Tiempo de build: 2.4 min ✓
- PR review: 18 min ✓
- Bugs/sprint: 0.8 ✓

Resultado: En mi siguiente evaluación de desempeño, pude presentar 8 mejoras con números concretos. Dos de ellas directamente contribuyeron a mi ascenso. Fuera de las evaluaciones, el hábito de medir antes me hizo más disciplinado en elegir qué mejoras valían la pena.

Cómo practicar estas respuestas (el método)

Leerlas no alcanza. El problema que describimos al principio — el retrieval falla bajo presión — se resuelve solo con práctica activa.

Paso 1: Armá tu banco de historias

Tomá las 8 categorías de la tabla del comienzo. Para cada categoría, escribí UNA historia de tu experiencia real. No inventes. Si no tenés experiencia en alguna categoría, pensá en proyectos personales, trabajos freelance, o situaciones académicas.

Paso 2: Practicá en voz alta, no en silencio

El ensayo mental no prepara tu cerebro para la presión verbal. Tenés que decirlo en voz alta. Solo, con un espejo, con una IA, o con un compañero. Lo que importa es que tu sistema fonológico practique, no solo tu sistema de lectura.

Paso 3: Los 90 segundos

Cronometrá. Si una respuesta dura menos de 60 segundos, te falta profundidad en las Acciones. Si dura más de 2 minutos, estás perdido en la Situación. El sweet spot es 90 segundos.

Paso 4: El test de "¿y qué hiciste VOS?"

Grabate y escuchate. Contá cuántas veces decís "nosotros" vs. "yo". En las Acciones, el ratio tiene que ser 80% "yo". Los entrevistadores quieren saber qué hiciste vos, no el equipo.

Paso 5: El inglés

Si vas a entrevistar en inglés, practicá en inglés. No alcanza con saber la historia en español y "traducirla" en el momento. El retrieval bajo presión tiene que ser en el idioma de la entrevista.

Las preguntas de seguimiento más comunes (y cómo responderlas)

Después de tu respuesta STAR, el entrevistador casi siempre pregunta:

"¿Qué hubieras hecho diferente?"

La trampa es defender tu decisión original. La respuesta correcta es honesta: "Hubiera [algo concreto], porque ahora sé que [lección aprendida]."

"¿Cómo manejaste el impacto en las otras personas del equipo?"

Señal de que quieren ver empatía y comunicación. Describí cómo comunicaste, no solo qué decidiste.

"¿Cuánto tiempo duró el impacto?"

Necesitás saberlo. Si no lo sabés, decí: "No lo seguí sistemáticamente, pero lo que sí sé es [lo que mediste]."

"¿Lo volverías a hacer de la misma forma?"

Variante de la primera. Honestidad con aprendizaje.

Una nota sobre el inglés en entrevistas

Si entrevistás en inglés para una empresa del exterior y el español es tu lengua dominante, el método STAR te ayuda de una forma específica: reduce la carga cognitiva.

Cuando tenés la historia estructurada (S-T-A-R), tu cerebro no tiene que generar el contenido Y buscar las palabras en inglés al mismo tiempo. Solo tiene que buscar las palabras. Eso es el 50% de la carga.

Los errores gramaticales menores importan mucho menos de lo que creés. Los entrevistadores de empresas tech que contratan en LATAM saben que el inglés no es tu primer idioma. Lo que evalúan es si podés comunicar ideas complejas de forma clara. Eso lo controlás con el método STAR.

*Querés practicar estas preguntas en voz alta con feedback inmediato? En InterviewHack.ai generamos un set personalizado con las preguntas más probables para la vacante específica a la que estás aplicando, y practicás hablando — con corrección palabra por palabra de tu inglés y tus respuestas.*