019. Entrevistas técnicas en Startups
- 24:23
- Fri Dec 12 2025
- Temporada 1 • Ep. 13
La guía definitiva para entrevistas de programación. En este episodio de proporciones bíblicas vemos cómo son y cómo practicar para que te vaya bien.
Significa que el error de la entrevista me costó más de 2 millones de dólares.
La enorme mayoría de los candidatos fracasan en el proceso.
Bienvenidos a Tecnología Informal. Un espacio para hablar de carrera, de inversión, de producto, de cultura y de todo lo relacionado con startups.
Yo soy Gabriel Benmergui y soy un programador con más de una década de experiencia viviendo y trabajando en California, Estados Unidos.
Hacer buenas entrevistas técnicas es un skill fundamental para progresar en la carrera y lograr mayores ingresos. Hoy vamos a hacer un deep dive en entrevistas: cómo funcionan, cómo practicar y cómo evitar errores caros.
El proceso de entrevistas técnicas
Los procesos de entrevistas están rotos. Es algo que se dice con frecuencia en el mercado cuando se habla de las malas experiencias de evaluación, la necesidad de prepararse y el tiempo que toma resolver los desafíos de las empresas. Esta experiencia ardua y a veces negativa es una gran barrera para los desarrolladores para pasar de una empresa a otra. Y, en contra de sus propios intereses, terminan favoreciendo procesos de entrevistas más fáciles usando referidos y contactos personales para tomar decisiones de carrera.
Hoy vengo a proponer algo distinto: que uno tiene que hacer muchas entrevistas, volverse bueno en hacerlas y enfrentarse cara a cara con el rechazo. Es más, se tiene que buscar ser rechazado. Ahí es donde uno encuentra los límites de su propio conocimiento, habilidad, comunicación y entendimiento del mercado.
Cuando uno descarta empresas para ahorrarse el trabajo de prepararse para las entrevistas, comete un error estratégico grave que tiene un impacto grande en la carrera. Las empresas que saltean procesos de entrevistas son las que no se pueden dar el lujo de elegir a los empleados y tienen que bajar la calidad de su staff para poder conseguir suficientes posiciones. Esto no solo afecta al salario, sino también a los contactos que se generan en los compañeros de trabajo, los productos en los que vas a trabajar y tu carrera en general.
Recordemos que las empresas que más pagan en el mundo, las americanas, pagan desde 150.000 dólares por juniors hasta cientos de miles de dólares más para seniors. Para poder entrar en las empresas que pagan en esta categoría, hay que ser bueno en las entrevistas. Así que veamos con detalle este proceso.
El proceso de entrevista técnico
El proceso de entrevista técnico tiene entre 3 y 5 entrevistas técnicas y desafíos para escribir código en vivo, ejercicios de diseño de sistema y ejercicios específicos para el rol al que uno aplica, que puede ser back-end, front-end, data o alguna otra disciplina. Cada entrevista toma entre 45 y 60 minutos, por lo que el compromiso de tiempo es de entre 5 y 8 horas por empresa. Además, entre ponerlas en un calendario, cancelaciones, imprevistos, los procesos toman realmente entre 2 y 6 semanas para completarse.
Al final de este proceso, todos los entrevistadores dan una opinión de Hire o No Hire y se toma una decisión. En general, dos No Hire alcanzan para rechazar un candidato y una sola opinión negativa fuerte puede alcanzar para ser rechazado, si es una entrevista clave o viene del Hiring Manager. Además, las entrevistas también nivelan para los roles y para la oferta que se va a hacer. Mientras mejor te vaya, más plata te van a ofrecer.
El margen para error en las entrevistas es bajo y el valor de hacerlas bien es muy alto. Hay que apuntar a hacer todas bien. En mi experiencia, la tasa de Pass Rate, es decir, la aprobación de candidatos, en empresas como Scribd, Robinhood o OpenSea, está muy por debajo del 50%. La enorme mayoría de los candidatos fracasan en el proceso.
La entrevista de código en vivo
La entrevista más fundamental de todas siempre es la de escribir código en vivo. En estos desafíos, el entrevistador presenta una definición de problema y el candidato tiene que, en vivo, encontrar e implementar la solución algorítmica o de diseño para cumplir requerimientos.
Históricamente, empresas como Google o Facebook impusieron el modelo de problemas de estructuras de datos y algoritmos, parecido a la programación competitiva. Estos problemas están optimizados para elegir a gente con educación universitaria reciente, ya que son muy parecidos a lo que uno ve en las primeras materias de algoritmos en la universidad, pero que no son muy aplicables al día a día de la mayoría de los programadores. Se maneja recursión, pilas, árboles, grafos y algoritmos piolas o creativos.
Los argentinos le tienen pánico a esta entrevista porque la mayoría, yo incluido, no tenemos mucha educación formal y no lo podés aprender en el trabajo. Esto se aprende leyendo libros y estudiando, lo que es mucha fricción para programadores. Si no aprendés a hacer estos problemas, desde el vamos, nunca vas a poder pasar a entrevistas FANG: Facebook, Google, Amazon. Tampoco en casi cualquier empresa top tier que esté en la etapa serie C en adelante. Es decir, empresas que tienen el lujo de elegir a los empleados.
Para pasar esta entrevista hay dos caminos. Una es la Biblia de Interviewing, "Cracking the Coding Interview". Este libro fue escrito por una ingeniera que pasó por Google y es una guía definitiva a la teoría y práctica de los conceptos y problemas variados de ciencias de la computación. Viene con decenas de problemas que, si uno resuelve, está prácticamente listo. Con aproximadamente 40 horas de práctica, uno puede terminar el proceso de entrenamiento.
Para profundizar en el skill acá, la segunda opción es ir directamente a plataformas de prueba como LeetCode, HackerRank o Coderbyte. Acá uno tiene que usar la plataforma para escribir el código que luego corre y es verificado con test cases en el backend. Resolver problemas acá te da la experiencia muscular y la variedad de problemas para incrementar tus chances enormemente. Es más, es probable que los problemas que te toquen en las entrevistas ya estén en estas plataformas y uno simplemente tenga que reimplementarlas.
Estos problemas son muy mecánicos y poco realistas, por lo que cada vez que una entrevista, tiene que practicar otra vez y refrescar la memoria muscular y cognitiva.
Entrevistas de Producto o Diseño de Sistemas
En el episodio 3 de Tecnología Informal, menciono que la entrevista que más falla en los argentinos son las de Producto o Diseño de Sistemas. Una entrevista que casi no existe en Argentina es pedirle al candidato, en base a un conjunto ambiguo de requerimientos, que cree un sistema que pueda servir como un MVP de un producto.
En consultoría, que es lo más común en Argentina, te dicen exactamente qué hacer y no participan los programadores en el proceso creativo de producto, por lo que están usualmente perdidos en esta entrevista. En Robinhood, le pedíamos a los candidatos que diseñen una aplicación de chat para familias. La expectativa es que el candidato transforme eso en requerimientos funcionales y no funcionales. ¿Qué features va a tener la plataforma? ¿Y cómo hay que hacerlo para que escale y ande bien?
Luego de aclarar requerimientos, hay que elegir el stack. ¿Qué bases de datos se van a usar? ¿Cómo se implementa una API para este servicio? ¿Cómo es la arquitectura de los clientes? En esta conversación se revela la experiencia y entendimiento técnico de los candidatos. Pueden conjurar distintas tecnologías o solo conocen las que utilizaron. Entienden el propósito de un load balancer, un CDN, caching, queuing, sockets, fault tolerance, scaling, etc.
Otra razón por la que los programadores argentinos patinan acá es que se evalúa la comunicación. No solo hay que saber y entender técnicamente, sino hay que poder comunicarse y hacerlo con claridad. Esta entrevista es clave para llegar a ser senior en una empresa de categoría. Y sin pasarla, se disipan para siempre los puestos de Staff Engineer.
Para pasar esta entrevista hay varios caminos. El más corto es estudiar. Hay libros y páginas educativas donde uno puede leer arquitectura de sistemas. A mí me gusta "Rocking the System Design Interview", un curso de Educative.io, que tiene recursos para estudiar distintas partes de los sistemas y respuestas detalladas a preguntas clásicas como ¿Cómo se diseña Uber? o ¿Cómo se diseña Twitter?
La parte comunicacional es más difícil. Hay que tener un cierto nivel de inglés, pero también práctica y comodidad para comunicarse. En este aspecto, hay que aprovechar muchas oportunidades en los trabajos actuales para comunicar ideas, escribir documentos y generar este tipo de contenido activamente. En el episodio 16, "Comunicarse en Inglés", hay más tips.
El error fatal de comunicación en estas entrevistas es no entender bien los requerimientos o no entender las preguntas del entrevistador sobre desafíos técnicos o funcionales de tu diseño. Si uno responde a una pregunta que no le hicieron, la entrevista se vuelve un no inmediatamente. Un truquito para evitar esto sería siempre repetir la pregunta con el entrevistador y confirmar que lo que estás haciendo es lo que quiere que hagas. En esta entrevista, yo frecuentemente le pregunto al entrevistador: "¿Esto es lo que buscabas?"
Cambios en la industria: problemas más realistas
Un cambio fuerte en la industria en los últimos años fue reemplazar los problemas de coding estilo LeetCode por problemas más realistas de la industria y orientados al rol. Puede ser escribir una API para un back-end o una página para un front-end engineer. Estos problemas son mucho más efectivos para evaluar la experiencia práctica de los candidatos, donde además de necesitar menos preparación, escriben código más realista que expone entendimientos de patrones y estilos de código.
Estas entrevistas son mucho más fáciles y además son trucables. Se puede practicar para esas. Casi todas las empresas de categoría que usan estos problemas tienen un set de problemas chico y terminan siendo compartidos en plataformas como Glassdoor. Así, uno puede llegar a saber específicamente el problema de la entrevista y practicar acorde.
Una empresa en la que entrevisté para un rol de front-end tenía sólo un problema de front-end: hacer un Tetris. En casa hice el Tetris unas 20 veces con un reloj al lado. Llegué a implementar un Tetris entero con rotación de piezas y desaparición de líneas en 25 minutos. Bueno, entero no, sin música.
A pesar de que esta entrevista es más fácil de trucar con preparación, muchos candidatos decían no poner el esfuerzo cuando entrevistan en varias empresas a la vez, bajando sus chances de éxito. Hay que ser implacable y ponerle la garra a cada entrevista como si se jugase tu vida, porque es justamente lo que te estás jugando.
Todavía me da bronca cuando fracasé la entrevista en Brex en 2018. Me pidieron hacer una UI que hice en dos tercios del tiempo de entrevista, pero tomé un atajo. En lugar de hacer CSS casero, usé una librería como Bootstrap, que estaba permitido en el proceso. Todavía no sé si me rebotaron por ese atajo, pero podría haber demostrado más capacidad escribiendo CSS a mano y mejorar mis chances. El paquete accionario de Brex de esa época se multiplicó por 5. Si me hubiesen ofrecido 500.000 dólares de acciones en ese momento, significa que el error de la entrevista me costó más de 2 millones de dólares.
Consejos para entrevistas técnicas
Para pasar estas entrevistas, en general hay que llegar lejos en el desafío técnico. Hay un punto que se considera necesario para probarla. Para esto hay que escribir código rápido y que funcione. Hay que escribir código de a poco y probarlo frecuentemente para no descubrir mucho más adelante que el código tiene muchos bugs, y aunque conceptualmente esté bien, no funcione.
También hay una segunda parte que es muy importante, que es la comunicación, las prácticas de limpieza del código, etc. Esta segunda parte en realidad evalúa la experiencia de los programadores en un ambiente donde otros programadores le hayan revisado el código. Más bien, una cultura de Code Reviews. En Open Source o empresas Serie B en adelante, se refuerzan prácticas básicas que quedan grabadas en el cerebro, y no tener estos tics se percibe como una debilidad técnica o falta de experiencia.
Cómo se comunica uno y la forma en la que hace las cosas puede dar vuelta a la entrevista en cualquier dirección. Hay servicios de preparación de entrevistas enfocados en ayudar con esto. Algunos recruiters a veces hacen entrevistas de práctica con candidatos, para evaluar y ejercitar.
Take Homes
Una tendencia que se estaba muriendo pre-pandemia, pero se popularizó luego, son los Take Homes. Son tareas o ejercicios que requieren escribir bastante código para cumplir un set de requerimientos. Las empresas siempre te dicen que deberías hacerlo en 2 horas, pero es una gran mentira, porque termina tomando 8 horas o más.
Una empresa en la que entrevisté me mandó 4 páginas de Figma, con requerimientos de agregar componentes en su sistema de UI, tests, error handling y más. Me tomó como 12 horas y me rechazaron por un bug.
Muchos candidatos le tienen miedo a los Live Coding Interview, y dicen que quieren Take Homes, pero después no los hacen, porque se dan cuenta que una entrevista en vivo son 30 minutos, y un Take Home es un domingo entero de codeo.
Los Take Homes se volvieron populares para empresas chicas, porque estiman que les toma menos tiempo entrevistar a más gente, y porque no tienen un proceso de entrevistado serio todavía. Yo creo que no les conviene. Los empleados senior y habilidosos ya practican para entrevistas en vivo, por lo que reducen su pool de candidatos en la peor manera posible. Esto me lo confirmó una vez el CEO de Triplebyte, que pre-pandemia me dijo que la tasa de contratación de candidatos que prefieren Take Home es menor a los que deciden ir por Live Coding, indicando una baja de la calidad de los candidatos. Además, los problemas Take Home toman mucho más tiempo en evaluar, y las evaluaciones son inconsistentes.
Dicho esto, recordar que mientras más opciones tenga uno, mejores son sus prospectos de salarios, así que vale la pena evaluar cómo hacerlas bien como candidato.
La clave de esta entrevista es enfocarse en la experiencia del que va a revisar tu solución, no en escribir un código que más o menos anda. La evaluación de código siempre es pobre y apresurada, pero sí se busca que pase un linter. Es decir, que el código tenga buen formato y esté organizado, y que no haya hacks o cosas groseras. Es importante la funcionalidad y la documentación. Hay que testear bien que los requerimientos se cumplen y la solución anda. Y aunque es difícil que no haya bugs, uno puede quedar muy bien exponiendo un test plan.
En la entrega del Take Home, digan exactamente qué tiene que hacer el entrevistador para ver que tu solución funciona. Qué tiene que instalar, cómo tiene que correr y qué tiene que pasar. Si uno presenta un código sin esta guía, el entrevistador lo tiene que descifrar con más trabajo, y es posible que entre en un camino donde tu programa no anda, o tiene un bug, o algún requerimiento extra. Si pasa eso, se acabó la evaluación y te van a rechazar.
La segunda parte es la documentación. Ellos buscan que puedas documentar y explicar decisiones técnicas o estratégicas de tu sistema. La documentación tiene que tener un buen formato, pero que no sea larga, y que no sea un bloque de texto. Parece tonto, pero poné emojis, color, títulos para armar una jerarquía y que luzca pulido.
Para realmente resaltar sobre los candidatos, la clave es proveer una idea nueva o original. Puede ser una solución alternativa y poco intuitiva. Una presentación única o un feature extra que no fue pedido. A mí una vez me habían pedido que haga una solución con Redux, y yo dije que no. Lo hice de otra manera, con una interfaz similar y una buena argumentación de por qué.
Un último tip acá es aclarar las expectativas con el entrevistador. A veces te tiran una definición del problema, pero uno no sabe si quiere ver un skill específico o si evalúan de una manera particular. Pregunten explícitamente si esperan un programa muy pulido, si quieren error handling, si quieren una demo en video o imágenes. Es una lástima ser una solución que fracasa porque el entrevistador no aclaró qué es lo que evalúa.
Behavioral, Cultura y Producto
Luego de las entrevistas duras, siempre hay al menos una entrevista llamada Behavioral, Cultura y/o Producto. Más allá de la evaluación técnica, el entrevistador quiere saber si hay un buen fit cultural y si estaría bueno trabajar con vos. Aunque esta entrevista es blanda y muy subjetiva, hay varios obstáculos que afectan desproporcionadamente a los candidatos argentinos.
El primer filtro es el de clase. El entrevistador siempre tiene una pregunta implícita en su cabeza: ¿Es el candidato uno de los míos? Los programadores que no trabajaron en startups o no trabajaron íntimamente con americanos exponen la diferencia de clase al toque. Dicen que no se graduaron de la universidad, que no entienden cómo funciona la inmigración o el estilo de vida americano, que la calidad de vida donde están ellos es baja, tienen un Android en vez de un iPhone, que eligen siempre productos gratuitos. El más típico y más dañino es decir: "las empresas americanas contratan argentinos para ahorrarse costo".
El desafío principal para pasar el filtro de clase es sacar la imagen del trabajador precarizado de un país pobre. Constantemente argentinos hacen entrevistas en cuartos cerrados y desorganizados, con cables de paredes expuestos, con la ropa rota. ¿Vos querés que te perciban como un compañero más? Aunque seas un poco distinto en lenguaje y experiencia de vida. Este filtro es un inmencionable porque se puede percibir como discriminación para los entrevistadores americanos, pero es el más común. Por favor, cuídense de cómo se presentan en cámara y cuídense de lo que dicen.
El segundo filtro es que la entrevista de producto o cultura es bidireccional. Es la entrevista donde el candidato tiene más oportunidad y espacio para entrevistar a la empresa. ¿Cómo le va el producto? ¿Cuántos usuarios tiene? ¿Cuánta plata hace? ¿Cuánta plata tiene la empresa en el banco? ¿Cómo se compara con los competidores?
La razón por la que los argentinos fallan en este filtro es porque no tienen experiencia en startups. Y a pesar de tener 10 o 15 años en la industria, no han desarrollado el know-how y los músculos para elegir empresas. En una empresa grande como Mercado Libre o Rappi, los programadores entran de asientos. Es un proceso muy anónimo, y la mayoría de los programadores eligen casi exclusivamente por salario. El mercado de talento argentino castiga las ofertas de acciones, y en consecuencia el éxito de la empresa está muy poco ligado a la compensación. Al programador argentino le preocupa más que suba su salario y tenga trabajo el mes que viene, que el éxito de la empresa dentro de una década, y por lo tanto no ejercitan el músculo de elegir empresas.
Rappi o PedidosYa, Brubank o Ualá, Globant o IBM, es todo más o menos lo mismo, depende de cuánto te pagan por mes. Desde el punto de vista americano, una persona que no entiende nada de inversión o de startups o de todo lo demás, es percibido como un mercenario, o hasta un analfabeto de la industria. Además, con esa insensibilidad, los candidatos frecuentemente no saben lo que hace la empresa ni le importa, mostrando una falta de interés y fit que te puede tirar abajo.
¿Quiénes son los competidores de la empresa? ¿Cuál es el producto competidor? ¿Cuál es el área más delicada e importante del negocio? Son todas preguntas que tenés que poder responder.
El esfuerzo y la estrategia
Todo esto de las entrevistas requiere bastante esfuerzo y compromiso. Hay que trabajar fuera del área laboral, estudiar, practicar, enfrentarse a decenas de horas de conversación y también fracaso. Por eso es tan común que programadores cambien de trabajo de la mano de un conocido, que les adelanta una oportunidad con menos entrevistas, donde se saltean pasos.
Además, con la demanda de talento argentino en picos históricos, muchas empresas han reducido la dificultad y longitud de las entrevistas como mecanismo para conseguir más talento. Y muchos ingenieros terminan favoreciendo esos procesos.
Que un programador elija un trabajo sobre otro por la longitud o la dificultad del proceso de entrevistas es una tragedia. Poniéndolo en perspectiva, cada año trabajado a 40 horas por semana y digamos 48 semanas anuales nos da 1920 horas de trabajo anual. Si un proceso de entrevista te toma 8 horas, ahorrarse eso es menos del 0,5% de tu trabajo anual. Si uno acepta un trabajo que paga 10, 20 o 30% menos para ahorrarse ese 0,5% de esfuerzo, terminaron perdiendo mucho más. Son meses de trabajo perdidos por año.
Me ha pasado frecuentemente con candidatos de Silver.dev que aceptaron trabajos en una empresa sin haber terminado los procesos de entrevistas en otras porque no querían perder el tiempo. Pero el tiempo lo pierde el que no maximiza el valor de su trabajo y la evaluación de largo plazo de su carrera.
Otra razón por la que los desarrolladores no se entrevistan es por el miedo. Tienen miedo a lo desconocido. Tienen muy pocas entrevistas en su historial y no saben cómo funcionan. O miedo a dañar su propia autoestima. Tienen miedo a sentirse mal por los rechazos. "Fear is the mind killer". La receta para este problema es más motivacional. La mejor manera de lidiar con este miedo es ir corriendo directo a la fuente. Es más, usar ese miedo como un barómetro, como información que te está diciendo que hay algo importante para descubrir o superar.
Fundamentalmente, para elegir bien hay que tener opciones claras y definidas. Y hay que separar la generación de opciones de la selección final. Primero, generar todas las opciones posibles, aun en empresas que uno desfavorezca y luego, cuando estén en mano las ofertas, empezar el proceso de selección.
Si uno avanza en su carrera más metódicamente, cada vez que cambie de trabajo va a entrevistarse en al menos 4 o 5 empresas por salto. Lo que hace que en una década uno tenga decenas de entrevistas de experiencia. Cuando uno se vuelve bueno en las entrevistas, con la práctica y con la experiencia real, no solo las chances de recibir ofertas suben, sino que el proceso se vuelve divertido. Se llega al Nirvana de las entrevistas. A mí ya me divierte ser entrevistado. Y la razón es que la parte técnica y dura es trivial de pasar. Lo que más importa es ver el fit cultural, qué te gustaría hacer, cómo serían tus compañeros de trabajo. Y la verdad, tratar el proceso de entrevista es un chiste.
Mi tasa de aprobación de entrevistas es de 3 rechazos en mis últimas 15. Como mencioné, Brex una de las más dolidas. Aunque luego entrevisté otra vez, me hicieron una oferta y lo rechacé yo. Tomá, Brex.
Una de mis entrevistas más memorables fue cuando me pidieron hacer un Sudoku en vivo. Y en lugar de hacerlo con React como pedía mi entrevistador, utilicé las herramientas de bajo nivel para hacerlo todo en HTML crudo y ver cómo se rompía todo y nos reíamos con el entrevistador. El punto se vuelve más que conseguir un sí técnico, sino conseguir un "sí, qué divertido trabajar con esta persona". ¿Vos querés que los entrevistadores luchen por vos en el proceso de comité, que vuelvan y te tiren cada vez más plata para que trabajes con ellos?
Ignorar el proceso de entrevistas es una manera de limitar tus prospectos emocionales y económicos. El esfuerzo necesario para volverse bueno es una gota en el océano de trabajo de una carrera. Te estás jugando tu vida laboral, tomátelo en serio.
Si les gustó el podcast de hoy, se vienen muchos más. Suscribite al podcast en Spotify o seguime en Twitter en @Conanbatt para estar al tanto de todo el contenido.
¡Hasta la próxima!