Cómo responder "hablame de vos" en una entrevista tech (con ejemplos reales)
La pregunta más subestimada de cualquier proceso de selección. Casi todos la preparan mal — o directamente no la preparan — porque parece fácil. Es una trampa.
"Hablame de vos" no es un calentamiento. Es la primera señal que el entrevistador usa para decidir si seguir escuchando o empezar a pensar en el siguiente candidato.
En este artículo vas a encontrar la estructura exacta para responder bien, los errores que eliminan candidatos en los primeros 90 segundos, y 40 preguntas numeradas con respuestas detalladas — incluyendo código real para las variantes técnicas.
Por qué esta pregunta es diferente a todas las demás
Cuando te preguntan sobre recursión, hay una respuesta correcta. Cuando te preguntan sobre un bug que resolviste, hay una historia concreta que contar.
"Hablame de vos" no tiene respuesta correcta. Tiene respuestas que funcionan y respuestas que no. La diferencia está en que las que funcionan son específicas, relevantes para ESA empresa y ESE rol, y suenan como una persona real hablando, no como alguien recitando su LinkedIn.
La pregunta sirve para tres cosas al entrevistador:
- 1Calibrar cómo pensás: ¿organizás tus ideas? ¿sabés qué es relevante?
- 2Ver si investigaste: ¿tu respuesta tiene algo que ver con lo que buscan?
- 3Decidir el tono del resto: si arrancás bien, el entrevistador baja la guardia.
La estructura que funciona: Present-Past-Future (PPF) adaptada
La estructura más probada para esta pregunta tiene tres bloques de no más de 90 segundos totales:
Presente (15-20 segundos): Quién sos hoy. Rol actual, stack principal, tipo de problemas que resolvés.
Pasado (20-30 segundos): Cómo llegaste acá. Un hilo narrativo que explique por qué estás donde estás — no un CV oral.
Futuro (15-20 segundos): Por qué este rol en esta empresa. Conectado con algo concreto que investigaste.
El bloque que más candidatos omiten es el del futuro. Es también el que más diferencia.
Ejemplo completo (desarrollador backend, Python/Django)
"Hoy trabajo como desarrollador backend en una fintech de 80 personas, donde llevo el módulo de pagos y reportes — básicamente todo lo que toca Stripe y los webhooks de conciliación. Empecé como QA hace cuatro años, escribiendo tests para un sistema legacy en PHP, y en algún momento me di cuenta de que lo que más me importaba era entender por qué fallaban las cosas, no solo registrar que fallaban. Eso me llevó a pasarme a desarrollo. Ahora busco un equipo donde pueda meterme en problemas de escala real — vi que ustedes tienen el desafío de procesar N millones de transacciones diarias y eso es exactamente el tipo de problema que me interesa atacar."
Eso son 75 segundos. Tiene arco, tiene especificidad, tiene conexión con la empresa.
Los 7 errores que eliminan candidatos en los primeros 90 segundos
Error 1: Leer el CV en voz alta
El entrevistador tiene el CV. Repetirlo es desperdiciar tiempo de los dos. El CV lista hechos; tu respuesta tiene que darle sentido a esos hechos.
Error 2: Empezar con "Bueno..." o "Eh..." y nunca arrancar
El primer segundo importa. Si arrancás con ruido, el entrevistador ya formó una primera impresión negativa que va a tener que revertir el resto de la conversación.
Preparar el primer oraciones de memoria, textual, es legítimo y necesario.
Error 3: Hablar más de 3 minutos
Nadie pidió tu autobiografía. Más de 2 minutos sin parar es monólogo. El entrevistador empieza a desconectarse.
Error 4: No conectar con el rol
"Me gustan los desafíos" no conecta con nada. "Vi que están migrando de monolito a microservicios y eso es exactamente lo que hice en mi último año en [empresa]" sí conecta.
Error 5: Mencionar sueldo, beneficios o ubicación en esta etapa
Suena a que tu motivación principal es el contrato, no el trabajo. Guardalo para cuando te pregunten específicamente.
Error 6: Hablar mal de empleadores anteriores
Incluso si el despido fue injusto y el jefe era incompetente. El entrevistador inmediatamente piensa "en un año va a hablar así de nosotros".
Error 7: Responder la misma cosa en todas las entrevistas
La respuesta debería cambiar según la empresa. Una startup de 5 personas y una empresa de 2000 no buscan lo mismo. Si usás el mismo script para los dos, alguno de los dos va a sonar como que no investigaste.
Adaptaciones por tipo de rol
Para roles de frontend
Enfatizá la relación entre código y usuario final. "Lo que me importa es que lo que construyo tenga sentido para quien lo usa" es una línea que resuena en equipos de producto.
Para roles de backend
Enfatizá sistemas, escala, confiabilidad. "Me interesan los problemas que se ponen difíciles con volumen" es el tipo de framing que abre conversaciones técnicas interesantes.
Para roles de data / ML
Enfatizá el ciclo completo: desde el problema de negocio hasta el modelo en producción. Muchos candidatos de data solo hablan de modelos y pierden contexto de negocio.
Para roles de devops / SRE
Enfatizá la obsesión por la confiabilidad y los sistemas que se mantienen solos. "Menos héroes, más automatización" es una señal que le dice al entrevistador que pensás en sistemas, no en apagar incendios.
Para candidatos que cambian de stack
La narrativa del "por qué cambié" es crítica. No es una debilidad. Es tu historia de aprendizaje. Contala con causalidad: qué aprendiste en X que te llevó a querer hacer Y.
Cómo preparar tu respuesta en 20 minutos
Paso 1 (5 min): Escribí tres bullets sobre quién sos hoy. Stack principal, tipo de problema que resolvés, tamaño del equipo/empresa.
Paso 2 (5 min): Escribí el hilo que conecta cómo llegaste acá. Una sola línea causal, no una lista de trabajos.
Paso 3 (5 min): Leé la descripción del puesto y anotá dos o tres cosas concretas que conecten con tu experiencia.
Paso 4 (5 min): Grabate en voz alta y escuchate. El cerebro se engaña leyendo; la voz no miente.
Ese último paso es el que casi nadie hace y es el más importante. Leer la respuesta en tu cabeza y decirla en voz alta son dos procesos completamente distintos.
40 preguntas y respuestas detalladas
Las siguientes preguntas son variantes, follow-ups y derivados de "hablame de vos" que aparecen en entrevistas tech reales. Cada respuesta incluye la lógica detrás, no solo el ejemplo.
Pregunta 1: "Hablame de vos"
Por qué la preguntan: Es el punto de entrada. El entrevistador quiere ver cómo organizás información sobre vos mismo y si saben lo que buscan.
Respuesta de ejemplo (rol fullstack, 3 años de experiencia):
"Trabajo como desarrollador fullstack en una agencia digital donde llevo proyectos de e-commerce — principalmente Next.js en el frente y Node con PostgreSQL atrás. Llegué al desarrollo desde el diseño gráfico: empecé maquetando, después empecé a entender el CSS, después quise saber qué había detrás. Eso fue hace cinco años. Lo que más me gusta de donde estoy parado hoy es que puedo ver el problema completo — desde cómo se ve hasta cómo persiste en la base de datos. Ahora busco un equipo más enfocado en producto propio que en cliente; vi que ustedes tienen su propio SaaS y eso me interesa."
Por qué funciona: Tiene presente claro, tiene causalidad en el pasado, tiene conexión con la empresa.
Pregunta 2: "¿Por qué te interesa este rol?"
Por qué la preguntan: Quieren saber si aplicaste a 200 posiciones con el mismo CV o si realmente investigaste.
Respuesta de ejemplo:
"Dos cosas concretas. Una: el stack. Llevan varios años con Elixir en producción y es algo que estoy estudiando en serio desde hace ocho meses — tengo un proyecto personal con LiveView que me enseñó más sobre concurrencia que dos años de Node. Dos: el problema. El desafío de notificaciones en tiempo real a escala que mencionan en la descripción es exactamente el tipo de problema que me parece interesante atacar."
Por qué funciona: Nada de "porque es una empresa con valores" o "porque quiero crecer". Dos razones específicas y verificables.
Pregunta 3: "¿Cuál es tu mayor fortaleza como desarrollador?"
Por qué la preguntan: Quieren que te autoevalúes. También quieren ver si tu fortaleza es relevante para el rol.
Respuesta de ejemplo:
"Entender el sistema antes de proponer soluciones. Tengo una tendencia a leer el código antes de hablar. En mi equipo actual me pasó varias veces que alguien propone refactorizar algo y yo ya sé por qué está escrito así — porque hay un constraint que no es obvio desde afuera. Eso me hace más lento al principio pero mucho más preciso después."
Por qué funciona: La fortaleza es específica y viene con evidencia. No es "soy muy detallista" — es una conducta observable.
Pregunta 4: "¿Cuál es tu mayor debilidad?"
Por qué la preguntan: No quieren que les digas que trabajás demasiado. Quieren ver autoconciencia real y que tenés un plan para trabajar en eso.
Respuesta de ejemplo:
"La comunicación proactiva cuando algo se traba. Cuando tengo un bloqueante, mi instinto es seguir intentando resolver solo antes de pedir ayuda. Aprendí que eso retrasa al equipo más que pedir ayuda temprano. Lo que estoy haciendo ahora es poner un límite personal: si llevo más de dos horas atascado en algo, lo comunico aunque no tenga la solución."
Por qué funciona: Es real, tiene consecuencias concretas, y tiene un plan activo — no "estoy trabajando en ello".
Pregunta 5: "¿Por qué querés salir de tu trabajo actual?"
Por qué la preguntan: Quieren saber si sos el tipo de persona que huye de algo o que va hacia algo. También quieren detectar red flags.
Respuesta de ejemplo:
"No es que quiera salir — estoy bien donde estoy. Lo que pasa es que llegué a un techo técnico en mi rol actual. El equipo es chico y las decisiones de arquitectura están bastante tomadas. Busco un lugar donde pueda proponer y defender decisiones técnicas, no solo implementarlas."
Por qué funciona: No habla mal del empleador actual, explica una razón de crecimiento legítima, y ya conecta con lo que busca.
Pregunta 6: "Contame sobre un proyecto del que estés orgulloso"
Por qué la preguntan: Quieren ver cómo narrás un problema técnico, qué decisiones tomaste, y qué aprendiste.
Respuesta de ejemplo:
"Migré el sistema de autenticación de una app de ~50k usuarios activos de JWT sin refresh tokens a un esquema con refresh rotation. El desafío fue hacerlo sin downtime y sin forzar re-login a todos los usuarios. Lo que hice fue un período de compatibilidad doble: el servidor aceptaba los dos formatos durante 30 días, con un flag en la base de datos por usuario que indicaba si ya había recibido el token nuevo. Después del período, apagué el soporte del formato viejo. Ningún usuario notó el cambio."
Por qué funciona: Tiene problema concreto, solución específica, y métrica de éxito ("ningún usuario notó el cambio" es un resultado, no una opinión).
Pregunta 7: "¿Cómo te describís a vos mismo como desarrollador?"
Por qué la preguntan: Es una variante de "hablame de vos" enfocada en la identidad profesional.
Respuesta de ejemplo:
"Desarrollador de producto más que de features. Me importa por qué existe una funcionalidad antes de cómo la voy a implementar. Eso a veces significa preguntar más que codear al principio, lo que puede parecer lento pero suele evitar reescribir cosas."
Por qué funciona: Dice algo sobre cómo trabajás, no solo qué sabés hacer.
Pregunta 8: "¿Dónde te ves en cinco años?"
Por qué la preguntan: Quieren ver si tus objetivos de carrera tienen algo que ver con lo que la empresa puede ofrecerte.
Respuesta de ejemplo:
"Llevando decisiones técnicas a nivel de sistema — arquitectura, elección de stack, tradeoffs de escala. No necesariamente como manager; hay equipos donde eso es un rol de staff engineer y otros donde viene con gestión. Depende del equipo. Lo que sí sé es que en cinco años quiero que las decisiones que tomé en el código sean parte de cómo funciona algo que usan muchas personas."
Por qué funciona: Es ambicioso pero no delirante. No dice "CEO en cinco años". Deja espacio para que la empresa moldee el camino.
Pregunta 9: "¿Qué te hace diferente de otros candidatos?"
Por qué la preguntan: Es una pregunta incómoda que busca que te diferencies con evidencia, no con adjetivos.
Respuesta de ejemplo:
"La combinación de entender el lado de producto y el técnico. No es que sea el mejor programador en la sala, pero soy el que menos veces escucha un requerimiento, lo implementa, y después se entera de que nadie lo quería así. Eso viene de haber trabajado cuatro años en equipos donde no había un PM claro y alguien tenía que hablar con los usuarios."
Por qué funciona: No dice "soy apasionado y trabajo duro". Dice algo específico y respaldable.
Pregunta 10: "¿Preferís trabajar solo o en equipo?"
Por qué la preguntan: Quieren entender cómo encajás con su dinámica de trabajo.
Respuesta de ejemplo:
"Las dos cosas en momentos distintos. Para entender un problema nuevo, prefiero el silencio — necesito leer el código, el contexto, tomar notas. Para resolver algo complicado donde hay más de una forma razonable de encararlo, prefiero pensar con otra persona. El pair programming a mi ritmo actual es una o dos horas por día, no ocho."
Por qué funciona: Es honesto y matizado. No dice "soy un jugador de equipo" ni tampoco "soy muy independiente". Da información real.
Pregunta 11: "¿Cómo manejás el feedback negativo?"
Por qué la preguntan: Quieren ver si tenés ego frágil o madurez para procesar crítica.
Respuesta de ejemplo:
"El primer instinto es defensivo — eso es honesto. Pero aprendí a pausar antes de responder. En mi última code review importante, el tech lead me señaló que una función de 80 líneas era innecesariamente compleja. Mi reacción inicial fue querer explicar por qué cada línea era necesaria. Decidí esperar, releer al día siguiente, y tenía razón el tech lead. Ahora cuando recibo feedback, escribo lo que entendí, espero unos minutos, y después pregunto si lo entendí bien."
Por qué funciona: Muestra el proceso real, incluyendo la parte incómoda.
Pregunta 12: "¿Qué sabés de nuestra empresa?"
Por qué la preguntan: Esta es la verificación directa de si investigaste.
Respuesta de ejemplo (para una startup de fintech):
"Sé que son una fintech B2B de pagos para pymes, con foco en LATAM. Vi el post de su CTO sobre la migración de Django a FastAPI — el punto sobre la deuda técnica en los serializers me resonó porque enfrenté algo similar. También leí que lanzaron hace ocho meses el módulo de cobros recurrentes. Por eso me interesa el rol de backend: parece que están en una fase donde todavía se pueden tomar decisiones de arquitectura interesantes."
Por qué funciona: No repite el about page. Conecta algo concreto con su propia experiencia.
Pregunta 13: "¿Cuál es tu stack favorito y por qué?"
Por qué la preguntan: Quieren ver si tenés opiniones fundadas o solo listás herramientas.
Respuesta de ejemplo:
"Para backend en APIs que van a crecer: FastAPI con PostgreSQL. FastAPI porque la inferencia de tipos hace que la documentación y la validación salgan del mismo lugar que el código — menos cosas que mantener sincronizadas. PostgreSQL porque cuando el problema se complica, prefiero tener un motor de consultas maduro debajo. Para proyectos chicos o scripts con deadline corto, me quedo en Python puro o Go dependiendo de si necesito concurrencia."
Por qué funciona: Tiene razones, tiene contexto ("para X, Y"), y no pretende que un stack sea la respuesta a todo.
Pregunta 14: "¿Cómo aprendés cosas nuevas?"
Por qué la preguntan: Quieren saber si dependés de cursos o si tenés un sistema propio.
Respuesta de ejemplo:
"Leyendo código en producción de otras personas. El mejor recurso que encontré para aprender un framework nuevo es buscar un proyecto real en GitHub con tests y leer los tests primero — te dicen qué se supone que hace el código sin que tengas que deducirlo. Después leo la implementación. Cuando algo no tiene tests, leo los issues cerrados para entender qué fue roto y cómo se arregló."
Por qué funciona: Es un método específico y reproducible, no "hago cursos en Udemy".
Pregunta 15: "¿Alguna vez tuviste un conflicto con un compañero? ¿Cómo lo resolviste?"
Por qué la preguntan: Inteligencia emocional bajo presión. Quieren saber si sos el tipo de persona que escala conflictos o que los resuelve.
Respuesta de ejemplo:
"Tuve un desacuerdo con un compañero sobre la estrategia de testing en un módulo nuevo — él quería test de integración para todo, yo quería separar unitarios e integración. El debate se estaba poniendo circular. Lo que hice fue proponer escribir los dos enfoques para el mismo caso de uso y comparar tiempo de escritura, tiempo de ejecución, y qué tan claro era el mensaje de falla. Lo hicimos, el resultado fue mixto — su enfoque era más simple para un caso pero el mío escalaba mejor con más casos. Terminamos con una guía interna con criterios para cuándo usar cada uno."
Por qué funciona: El conflicto era sobre algo técnico, lo resolvieron con datos, y el resultado fue una solución mejor que cualquiera de las dos posiciones originales.
Pregunta 16: "¿Qué tipo de ambiente de trabajo preferís?"
Por qué la preguntan: Compatibilidad cultural. También quieren saber si vas a chocarte con su forma de trabajar.
Respuesta de ejemplo:
"Prefiero ambientes donde hay expectativas claras pero autonomía sobre cómo llegar ahí. No necesito microgestión para entregar — pero sí necesito saber qué es éxito para una tarea antes de empezarla. Los mejores contextos en los que trabajé tenían tickets con criterios de aceptación claros y post-mortems cuando algo salía mal, no búsqueda de culpables."
Por qué funciona: Describe un ambiente preferido con especificidad. No dice "me gusta el buen ambiente de trabajo".
Pregunta 17: "¿Qué es lo que más y lo que menos te gusta de programar?"
Por qué la preguntan: Quieren ver autoconciencia sobre tu relación con el trabajo diario.
Respuesta de ejemplo:
"Lo que más me gusta es el momento en que entendés un sistema que parecía opaco. Ese click cuando de repente el diagrama en tu cabeza tiene sentido completo. Lo que menos me gusta es la documentación que nadie va a leer porque está mal escrita desde el principio. No es que me moleste documentar — me molesta documentar mal. Cuando lo hago bien es satisfactorio; cuando se convierte en burocracia vacía es lo peor de la semana."
Por qué funciona: Honesto, específico, y el "lo que menos me gusta" tiene matices reales.
Pregunta 18: "¿Tenés experiencia trabajando remoto?"
Por qué la preguntan: Trabajo remoto tiene sus propios desafíos. Quieren saber si ya los navegaste.
Respuesta de ejemplo:
"Cuatro años full remoto. Lo que aprendí es que la comunicación asincrónica necesita más estructura que la presencial — cuando no podés pararte y preguntar, el mensaje escrito tiene que ser lo suficientemente claro para que la otra persona lo entienda sin contexto adicional. Desarrollo el hábito de escribir el contexto antes de la pregunta, no la pregunta primero."
Por qué funciona: Experiencia real más aprendizaje específico sobre comunicación remota.
Pregunta 19: "¿Cómo priorizás cuando tenés varias tareas urgentes?"
Por qué la preguntan: Quieren ver cómo pensás bajo presión y si dependés de que te digan qué hacer.
Respuesta de ejemplo:
"Pregunto primero: ¿urgente para quién y cuándo? 'Urgente' muchas veces significa 'me lo acordé hoy'. Después miro impacto y reversibilidad — las cosas irreversibles primero, siempre. Si dos tareas son igualmente urgentes e igualmente reversibles, voy a quien me lo pidió y pregunto cuál quieren primero. Prefiero esa conversación de 30 segundos a adivinar y equivocarme."
Por qué funciona: Tiene un proceso real, no solo "priorizo según impacto" (que no dice nada).
Pregunta 20: "¿Qué esperás de tu próximo manager?"
Por qué la preguntan: Quieren saber si sos compatible con el estilo de liderazgo que tienen.
Respuesta de ejemplo:
"Que me dé contexto de por qué, no solo qué. Puedo implementar cualquier cosa si entiendo el objetivo detrás — si no entiendo el por qué, implemento literalmente lo que me dijeron aunque haya una solución mejor. Y que sea predecible: no necesito un manager que esté siempre disponible, pero sí uno que cuando hace una promesa la cumple."
Por qué funciona: Describe necesidades reales sin sonar exigente. No dice "que me deje hacer lo que quiero".
Pregunta 21: "¿Cómo explicarías [concepto técnico] a alguien no técnico?" (variante de hablame de vos para roles que interactúan con PMs)
Por qué la preguntan: Comunicación transversal. Quieren saber si podés traducir entre mundos.
Ejemplo con "API REST":
"Una API REST es como un menú de restaurante. El restaurante tiene una cocina que sabe hacer cosas — preparar platos, revisar ingredientes. El menú es la lista de lo que podés pedir y cómo pedirlo. Vos como cliente pedís algo del menú, la cocina lo prepara y te lo trae. No necesitás saber cómo funciona la cocina. La API es el menú: define qué podés pedir y en qué formato te lo van a dar."
Por qué funciona: La analogía es concreta, no condescendiente, y no omite la idea central.
Pregunta 22: "¿Tenés experiencia con sistemas distribuidos?"
Por qué la preguntan: Quieren calibrar el nivel técnico real, no el del CV.
Respuesta de ejemplo con código:
"Sí, principalmente en el contexto de microservicios con comunicación por eventos. El problema más interesante que resolví fue consistencia eventual entre dos servicios — orders y inventory — cuando el bus de mensajes podía entregar el mismo evento más de una vez."
Código de ejemplo de idempotencia en el consumidor:
# handlers/inventory_handler.py
import hashlib
from redis import Redis
redis = Redis()
def handle_order_created(event: dict) -> None:
# Generar un ID determinístico del evento
event_id = hashlib.sha256(
f"{event['order_id']}:{event['type']}".encode()
).hexdigest()
# Verificar si ya procesamos este evento
key = f"processed_event:{event_id}"
already_processed = redis.set(key, "1", nx=True, ex=86400) # TTL: 24h
if not already_processed:
return # Entrega duplicada — ignorar silenciosamente
# Lógica real de negocio
for item in event["items"]:
reserve_inventory(item["sku"], item["quantity"])"El patrón es simple: cada evento tiene un ID determinístico, guardamos los que procesamos con TTL, y el handler es idempotente."
Por qué funciona: Conecta la teoría con un problema real y muestra el código que lo resuelve.
Pregunta 23: "¿Qué aprendiste en tu trabajo actual que no esperabas aprender?"
Por qué la preguntan: Curiosidad y autoconciencia. Quieren ver si aprendés de la experiencia o solo acumulás años.
Respuesta de ejemplo:
"Aprendí que la mayoría de los problemas de rendimiento no son de algoritmos. Son de queries mal escritas o de N+1 sin detectar. Entré a mi trabajo actual seguro de que Django era lento para nuestro caso de uso. Después de perfilar, el problema era que en un endpoint cargábamos objetos relacionados con 40 queries separadas donde podría ser una. Mejoré el tiempo de respuesta de 800ms a 90ms sin cambiar nada del stack."
Por qué funciona: Tiene un número real y una lección que contradice la intuición inicial.
Pregunta 24: "¿Alguna vez tomaste una decisión técnica equivocada?"
Por qué la preguntan: Quieren ver si aprendés de errores o si los negás.
Respuesta de ejemplo:
"Elegí MongoDB para un proyecto nuevo porque era el stack que conocía bien. A los seis meses teníamos queries de agregación tan complejas que ninguno del equipo las podía leer. El problema era que los datos eran intrínsecamente relacionales — usuarios, proyectos, permisos — y yo los estaba guardando como si fueran documentos independientes. Migramos a PostgreSQL en una semana de trabajo. Lo que aprendí: la elección de base de datos tiene que venir del modelo de datos, no de lo que ya sabés usar."
Por qué funciona: La equivocación es real, la causa fue clara, y el aprendizaje es aplicable.
Pregunta 25: "¿Cómo manejás la deuda técnica?"
Por qué la preguntan: Quieren saber si pensás a largo plazo o solo entregás features.
Respuesta de ejemplo:
"La trato como un ítem del backlog con costo real, no como algo que existe en la sombra. Cuando identifico deuda técnica importante, la documento con: qué es, qué cuesta mantenerla (en tiempo de desarrollo mensual), qué costaría arreglarla. Con esos números es una conversación de negocio, no técnica. Cuando el costo mensual de mantenerla supera el costo de arreglarla en seis meses, casi siempre se aprueba el fix."
Por qué funciona: Convierte un problema técnico en un argumento económico. Es exactamente cómo los buenos ingenieros hablan de deuda técnica.
Pregunta 26: "¿Qué hacés cuando no sabés la respuesta a algo en una entrevista técnica?"
Por qué la preguntan: Quieren ver honestidad y cómo pensás en voz alta.
Respuesta de ejemplo:
"Digo que no lo sé directamente. Después, si el tema me resulta familiar aunque no recuerde el detalle, lo digo: 'No recuerdo el nombre exacto pero el patrón que describís suena a X — ¿es eso?' A veces tengo la intuición correcta aunque me falte el vocabulario. Y si es algo completamente nuevo para mí, pregunto si puedo razonar desde los principios que sí conozco y ver hasta dónde llego."
Por qué funciona: Honestidad más proceso de razonamiento. Los entrevistadores valoran mucho "sé lo que no sé".
Pregunta 27: "¿Cómo te preparás para una entrevista técnica?"
Por qué la preguntan: Quieren ver si invertís en el proceso o si llegás a improvisar.
Respuesta de ejemplo:
"Dos cosas. Una: repaso los fundamentos del área relevante para el rol — no intento aprender algo nuevo en la semana previa. Dos: me preparo para hablar de mis proyectos con claridad. Eso significa ensayar en voz alta, no solo pensar. La diferencia entre lo que creés que vas a decir y lo que sale cuando lo decís en voz alta es enorme."
Por qué funciona: Tiene método. Y el punto sobre hablar en voz alta es técnicamente correcto y sorpresivo.
Pregunta 28: "¿Tenés preguntas para nosotros?"
Por qué la preguntan: Quieren saber si investigaste y si tu curiosidad es real.
Respuesta de ejemplo (set de 3 preguntas):
"Sí, tengo tres. Primera: ¿cuál fue el mayor problema técnico que resolvió el equipo en el último año? Segunda: ¿cómo se ve un onboarding exitoso — qué haría alguien nuevo en sus primeros 90 días para que lo consideren exitoso? Tercera: ¿qué es lo que más les gusta de trabajar acá y qué cambiarían si pudieran?"
Por qué funciona: Las tres preguntas piden información real. No son "¿cuál es la cultura de la empresa?" que está en la web.
Pregunta 29: "¿Podés contarme sobre tu experiencia con testing?"
Por qué la preguntan: Testing es el canario en la mina de la calidad. Si alguien no testea, probable que haya otras deudas.
Respuesta de ejemplo con código:
"Testo principalmente con pytest para backend. El patrón que más uso es Arrange-Act-Assert con fixtures bien nombradas."
# tests/test_payment_processor.py
import pytest
from unittest.mock import MagicMock, patch
from decimal import Decimal
from payments.processor import PaymentProcessor
from payments.models import Payment, PaymentStatus
@pytest.fixture
def mock_stripe_client():
client = MagicMock()
client.charges.create.return_value = {
"id": "ch_test_123",
"status": "succeeded",
"amount": 1499 # centavos
}
return client
@pytest.fixture
def processor(mock_stripe_client):
return PaymentProcessor(stripe_client=mock_stripe_client)
def test_successful_payment_updates_status(processor, mock_stripe_client):
# Arrange
payment = Payment(
id="pay_123",
amount=Decimal("14.99"),
currency="USD",
status=PaymentStatus.PENDING
)
# Act
result = processor.charge(payment)
# Assert
assert result.status == PaymentStatus.COMPLETED
assert result.external_id == "ch_test_123"
mock_stripe_client.charges.create.assert_called_once_with(
amount=1499,
currency="usd",
idempotency_key=f"pay_{payment.id}"
)
def test_failed_payment_does_not_raise(processor, mock_stripe_client):
mock_stripe_client.charges.create.side_effect = Exception("Card declined")
payment = Payment(id="pay_456", amount=Decimal("14.99"), currency="USD")
result = processor.charge(payment)
assert result.status == PaymentStatus.FAILED"Lo que me importa en un test es que el mensaje de falla diga qué falló sin tener que leer la implementación."
Por qué funciona: Muestra código real con las consideraciones correctas (idempotency key, mocks bien aislados, mensajes de falla claros).
Pregunta 30: "¿Cómo manejás el estrés en fechas límite?"
Por qué la preguntan: Quieren saber si sos el tipo que trabaja 20 horas o el tipo que recalibra expectativas.
Respuesta de ejemplo:
"Lo primero que hago cuando siento que una fecha está en riesgo es comunicarlo lo antes posible — no el día antes del deadline. Después separo qué es necesario para la fecha y qué puede ir en una segunda iteración. Casi siempre hay partes del scope que se pueden mover sin bloquear lo crítico. Y en situaciones donde el trabajo está bien definido y simplemente es mucho, me apoyo en mis compañeros — prefiero pedir ayuda temprano que desaparecer en un bloqueo."
Por qué funciona: Describe priorización real y comunicación proactiva. No dice "bajo la cabeza y trabajo hasta terminar".
Pregunta 31: "¿Qué es lo más complejo que programaste?"
Por qué la preguntan: Quieren entender el techo técnico real.
Respuesta de ejemplo:
"Un sistema de matching en tiempo real para conectar tutores con estudiantes según disponibilidad, materia, nivel y preferencias de comunicación. El desafío era que los datos de disponibilidad cambiaban constantemente — un tutor podía ponerse disponible o no disponible con segundos de diferencia — y teníamos que mostrar resultados actualizados sin martillar la base de datos."
Código del núcleo:
// lib/matching/availability-cache.ts
import { Redis } from "ioredis";
export class AvailabilityCache {
private readonly TTL_SECONDS = 30;
constructor(private readonly redis: Redis) {}
async setTutorAvailable(tutorId: string, subjects: string[]): Promise<void> {
const pipeline = this.redis.pipeline();
// Guardar disponibilidad individual con TTL
pipeline.setex(
`tutor:available:${tutorId}`,
this.TTL_SECONDS,
JSON.stringify({ tutorId, subjects, timestamp: Date.now() })
);
// Agregar a los sets por materia para búsqueda rápida
for (const subject of subjects) {
pipeline.zadd(
`subject:available:${subject}`,
Date.now(),
tutorId
);
pipeline.expire(`subject:available:${subject}`, this.TTL_SECONDS);
}
await pipeline.exec();
}
async findAvailableTutors(
subject: string,
limit = 10
): Promise<string[]> {
const cutoff = Date.now() - this.TTL_SECONDS * 1000;
// Buscar tutores disponibles en la última ventana de tiempo
return this.redis.zrangebyscore(
`subject:available:${subject}`,
cutoff,
"+inf",
"LIMIT",
0,
limit
);
}
}"La solución fue una capa de cache en Redis con TTL corto. Los tutores mandaban un heartbeat cada 20 segundos para mantener su disponibilidad. Si no mandaban el heartbeat, automáticamente desaparecían del pool. Esto nos permitió tener resultados casi en tiempo real sin queries pesadas a Postgres."
Por qué funciona: El problema es real, la solución tiene componentes reconocibles, y el código muestra decisiones concretas (pipeline de Redis, TTL, sorted sets para búsqueda).
Pregunta 32: "¿Qué diferencia hay entre un buen código y un gran código?"
Por qué la preguntan: Filosofía de ingeniería. Quieren ver si pensás más allá de "funciona".
Respuesta de ejemplo:
"El buen código hace lo que promete y tiene tests. El gran código hace lo que promete, tiene tests, y la persona que lo va a modificar en un año entiende por qué existe cada parte. La diferencia está en que el buen código resuelve el problema presente y el gran código anticipa las preguntas del futuro sin sobrediseñar. No siempre se puede o vale la pena escribir gran código — el contexto importa. En una startup en etapa temprana, el gran código a veces es el que se puede tirar sin drama cuando el producto cambia."
Por qué funciona: Es matizado. No idealiza. Reconoce tradeoffs reales.
Pregunta 33: "¿Cómo documentás tu código?"
Por qué la preguntan: Documentación es un proxy de cómo pensás en el mantenimiento a largo plazo.
Respuesta de ejemplo:
"Documentar el qué lo hace el código; documentar el por qué es mi responsabilidad. Los comentarios que escribo casi siempre son sobre decisiones: por qué elegí este algoritmo y no ese otro, por qué este timeout tiene ese valor, qué constraint del negocio hace que esta parte sea rara. El tipo de comentario que no escribo: explicar lo que ya dice el nombre de la variable."
Ejemplo de comentario útil vs. inútil:
# MAL: dice lo que el código ya dice
# Multiplicar precio por cantidad
total = price * quantity
# BIEN: explica la decisión no obvia
# El redondeo va a floor() y no a round() porque el contrato con el
# proveedor de pagos penaliza fracciones de centavo hacia arriba.
# Ver: https://internal-wiki/payments-contract-2024
total = math.floor(price * quantity * 100) / 100Por qué funciona: La distinción qué/por qué es una heurística real que los buenos ingenieros usan. El código de ejemplo lo hace concreto.
Pregunta 34: "¿Tenés experiencia con code reviews? ¿Cómo los encarás?"
Por qué la preguntan: Code reviews bien hechos son la forma más eficiente de transferir conocimiento en un equipo.
Respuesta de ejemplo:
"Como revisor, separo los comentarios en tres niveles: bloqueantes (hay un bug real o un problema de seguridad), sugerencias importantes (no bloquea el merge pero vale la pena discutirlo), y nits (cosas menores de estilo o preferencia). Los marco explícitamente — 'blocking:', 'suggestion:', 'nit:' — para que quien lo recibe sepa qué tiene que resolver y qué es opcional. Como autor, cuando recibo feedback, distingo entre 'no entendí el comentario' (pregunto antes de cambiar) y 'no estoy de acuerdo' (lo digo explícitamente con la razón, no resuelvo el comentario sin discutirlo)."
Por qué funciona: Tiene un sistema concreto, tanto para dar como para recibir. Muy pocos candidatos piensan los code reviews en ambas direcciones.
Pregunta 35: "¿Qué sabés de [tecnología que no usaste pero está en el stack de ellos]?"
Por qué la preguntan: Quieren saber si sos honesto sobre lo que no sabés y si podés aprender.
Ejemplo con Kubernetes:
"No tengo experiencia práctica con Kubernetes en producción. Lo que sé es conceptual: orquestación de contenedores, pods, services, deployments, la diferencia entre ReplicaSets y StatefulSets. Jugué con un cluster local con minikube pero no lo puse en producción. Soy honesto sobre eso. Lo que puedo decir es que cuando aprendí Docker pasé de cero a cómodo en producción en tres semanas — espero que el tiempo de rampa con Kubernetes sea similar o menos."
Por qué funciona: Honestidad sobre el gap, calibración del nivel actual, evidencia de velocidad de aprendizaje.
Pregunta 36: "¿Cómo te mantenés actualizado con las novedades del sector?"
Por qué la preguntan: Quieren saber si tu curiosidad es activa o pasiva.
Respuesta de ejemplo:
"Sigo tres o cuatro newsletters técnicas que filtran el ruido — Bytebytego para arquitectura, Pragmatic Engineer para carrera e industria, y los release notes de las herramientas que uso en producción. Y leo código. Cuando sale una versión nueva de FastAPI o SQLAlchemy, abro el changelog y si hay algo que no entiendo, busco el commit que lo implementó. Es la forma más rápida de entender qué problema estaban resolviendo."
Por qué funciona: Recursos específicos y reales. Y el punto sobre leer commits es sofisticado — pocos candidatos lo mencionan.
Pregunta 37: "¿Cómo explicarías una arquitectura que diseñaste?"
Por qué la preguntan: Comunicación técnica estructurada.
Respuesta de ejemplo:
"Empiezo por el problema de negocio, no por los componentes. Si arranco diciendo 'tenemos un API gateway con tres microservicios y un message broker' no le digo nada a nadie sobre por qué existe eso. Arranco por: 'el problema era que tres equipos distintos necesitaban modificar partes del sistema sin bloquear a los otros, y el sistema necesitaba escalar partes de manera independiente'. Después de que el porqué está claro, los componentes tienen sentido."
Diagrama en texto:
Problema: N equipos, M servicios, acoplamiento alto
[API Gateway]
|
+----------+----------+
| | |
[Servicio A] [Servicio B] [Servicio C]
| | |
+----------+----------+
|
[Message Bus]
|
[Servicio D]
(analytics)
Consecuencia: A puede deplegar sin afectar B o C.
D consume eventos sin bloquear el flujo principal.Por qué funciona: Muestra el meta-proceso de comunicación técnica, no solo el resultado.
Pregunta 38: "¿Qué es lo que más te cuesta de trabajar en equipo?"
Por qué la preguntan: Quieren autoconciencia real, no otra versión de "trabajo demasiado duro".
Respuesta de ejemplo:
"Los procesos que existen por inercia. Cuando hay una reunión semanal de estado que todos sabemos que podría ser un documento, o un ritual de planning que tarda cuatro horas para decidir lo que se podría decidir en cuarenta minutos, me cuesta mantener la energía. No lo callo — lo señalo con respeto — pero reconozco que puede sonar impaciente. Aprendí a elegir cuándo vale la pena señalarlo y cuándo el costo social es mayor al beneficio."
Por qué funciona: Es una limitación real con contexto. No es una queja — es autoconciencia con aprendizaje.
Pregunta 39: "¿Qué harías en tus primeros 30 días en este rol?"
Por qué la preguntan: Quieren ver iniciativa, humildad para escuchar primero, y pensamiento estratégico.
Respuesta de ejemplo:
"Los primeros 15 días: escuchar. Leer el código existente, hablar con cada persona del equipo para entender qué los frena, leer los tickets cerrados del último mes para entender qué tipo de problemas tienen. En días 15 a 30: identificar una contribución de baja complejidad que demuestre que entendí el stack y el proceso. No proponer grandes cambios antes de entender por qué las cosas están como están."
Por qué funciona: La distinción entre los primeros 15 y los segundos 15 días muestra madurez. Muchos candidatos dicen "traería ideas frescas" — que es exactamente lo opuesto a lo que los equipos realmente necesitan en el onboarding.
Pregunta 40: "¿Algo más que quieras que sepamos de vos?"
Por qué la preguntan: Es una segunda oportunidad. Quieren ver si tenés algo importante que no cubrió la entrevista.
Respuesta de ejemplo:
"Dos cosas que no surgieron en la conversación y que creo que son relevantes. Uno: hablo con usuarios. En mi rol actual, cada mes tengo una llamada con dos o tres usuarios del producto — no porque sea parte de mi rol, sino porque entender por qué usan el producto cambia cómo lo construyo. Dos: tengo un proyecto open source en TypeScript para parsing de PDFs que tiene 400 estrellas en GitHub. No es un proyecto enorme, pero es el primero donde alguien externo reportó un bug que yo no había encontrado, y ese proceso de triage y fix fue muy formativo."
Por qué funciona: Agrega dimensión que no es obvia del CV. El detalle del proyecto open source con una métrica y un aprendizaje específico es mucho más poderoso que "contribuyo a open source".
Preguntas frecuentes sobre esta pregunta
¿Tengo que memorizar la respuesta?
La primera oración, sí. El resto, no. Memorizar una respuesta larga suena a recitación. Pero tener claridad sobre los tres bloques (presente, pasado, futuro) y ensayarlos en voz alta varias veces es suficiente para sonar fluido sin sonar robótico.
¿Cuánto tiempo debería durar la respuesta?
Entre 60 y 90 segundos. Si la entrevista es en inglés como segundo idioma, podés ir un poco más lento — pero no más de 2 minutos. Si el entrevistador quiere más, va a preguntar.
¿Tengo que decir exactamente lo mismo en todas las entrevistas?
No. El bloque del futuro debería cambiar siempre según la empresa. Los bloques de presente y pasado pueden ser más estables, pero el énfasis debería alinearse con lo que busca cada empresa.
¿Qué hago si estoy cambiando de carrera y no tengo experiencia directa?
Enfatizá las habilidades transferibles con especificidad. "Cinco años de diseño gráfico me enseñaron a ver sistemas — qué elemento visual comunica qué y por qué — y eso aplica directamente a cómo pienso el UX de una interfaz" es mucho más poderoso que "me apasiona la tecnología".
¿Cómo adaptás la respuesta si tenés muchos años de experiencia?
El riesgo con más experiencia es el monólogo. Con 15 años de carrera, la selección es más importante que la completitud. Elegí los dos o tres hitos más relevantes para el rol específico y construí el hilo desde ahí. Nadie necesita el recorrido completo.
El ejercicio que cambia todo
La práctica en voz alta es la diferencia entre creer que sabés responder y saber que sabés responder.
Grabate respondiendo estas preguntas. Escuchate. Vas a notar:
- Frases que parecían claras escritas son confusas cuando las decís
- Muletillas que no sabías que tenías
- Respuestas que duran el doble de lo que deberían
Ese es el trabajo real de preparación para una entrevista. No leer más artículos — sino practicar hasta que las respuestas salgan solas bajo presión.