Tecnología Informal:
Entrevistas técnicas

Escuchá el Podcast en Spotify

Episode Transcript

19 - Entrevistas técnicas - Tecnología Informal Significa que el error de la entrevista me costó más de dos 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, inversión, producto, cultura y 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 una habilidad 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. 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 que desean 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: 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 cubrir 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. Uno tiene que hacer muchas entrevistas, volverse bueno en hacerlas y enfrentarse cara a cara con el rechazo: se tiene que buscar ser rechazado, ahí es donde uno encuentra sus límites. Recordemos que las empresas que más pagan en el mundo, las americanas, pagan desde 150 mil 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écnica tiene entre tres y cinco entrevistas técnicas, y tiene 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 backend, frontend, data o alguna otra disciplina. Cada entrevista toma entre cuarenta y cinco y sesenta minutos, por lo que el compromiso de tiempo es de entre cinco y ocho horas por empresa. Además, entre ponerlas en un calendario, cancelaciones, imprevistos, los procesos toman realmente entre dos y seis semanas para completarse. Al final de este proceso de entrevista, 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 Stripe, Robinhood o OpenSea, está muy por debajo del 50%. La enorme mayoría de los candidatos fracasan en el proceso. 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 con los requerimientos. El proceso de entrevista técnica tiene entre 3-5 entrevistas técnicas, cada entrevista toma entre 45-60 minutos, por lo que el compromiso de tiempo es de entre 5-8 horas por empresa. El margen para error en las entrevistas es bajo y el valor de hacerlas bien es muy alto. Y hay que apuntar a hacerlas todas bien. Históricamente, las 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 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 no se puede aprender en el trabajo, sino que se aprende leyendo libros y estudiando, lo que es mucha fricción para los programadores. Si no aprendés a hacer estos problemas, desde el vamos nunca vas a poder pasar a entrevistas en 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 cuarenta horas de práctica, uno puede terminar el proceso de entrenamiento. Para profundizar en la habilidad, 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 reimplementarlos. Estos problemas son muy mecánicos y poco realistas, por lo que cada vez que uno entrevista, tiene que practicar otra vez y refrescar la memoria muscular y cognitiva. La forma más fácil de hacer más plata es negociando mejor. Con Silver.dev ayudamos a decenas de programadores a conseguir aumentos de salario y mejores condiciones, y te podemos ayudar a vos. Si estás entrevistando o negociando una oferta, conectá con nosotros para que te ayudemos a conseguir lo mejor que puedas. Trabajamos solo por resultado: o te hacemos más plata o no pagás. Mirá términos y condiciones en silver.dev/nego. En el episodio 3 de Tecnología Informal, mencioné 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 implementar 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 conjugar 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étera? Además, 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 sobre 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 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 lo que estás haciendo. Puede ser escribir una API para un backend o una página para un frontend 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, se escribe un código más realista que expone entendimientos de patrones y estilo de código. Estas entrevistas son mucho más fáciles y además son trucables. Se puede practicar para esas. 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. Si uno responde una pregunta que no le hicieron, la entrevista se vuelve un "no" inmediatamente. Casi todas las empresas de categoría que usan estos problemas tienen un set de problemas chico, y terminan siendo compartido 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 solo un problema de front end, hacer un Tetris. En casa hice el Tetris unas veinte veces, con un reloj al lado. Llegué a implementar un Tetris entero con rotación de piezas y desaparición de líneas en veinticinco 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 deciden no poner el esfuerzo cuando entrevistan en varias empresas a la vez, bajando sus chances de éxito. Hay que ir a cada entrevista como si se jugase tu vida, porque es justamente lo que te está jugando. Todavía me da bronca cuando fracasé la entrevista en Breaks.com en el 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 más CSS a mano y mejorar mis chances. El paquete accionario de Breaks de esa época se multiplicó por cinco. Si me hubiesen ofrecido 500 mil dólares de acciones en ese momento, significa que el error de la entrevista me costó más de 2 millones de dólares. Para pasar estas entrevistas, en general, hay que llegar lejos en el desafío técnico. Hay un punto que se considera necesario para aprobarla. 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étera. 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 empresa 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 la entrevista en cualquier dirección. Hay servicios de preparación de entrevistas enfocados en ayudar con esto. Algunos reclutadores a veces hacen entrevistas de práctica con candidatos para evaluar y ejercitar. 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 dos horas, pero que es una gran mentira, porque termina tomando ocho horas o más. Una empresa en la que entrevisté me mandaron cuatro páginas de Figma con requerimientos de agregar componentes a su sistema de UI, test, error handling y más. Me tomó como doce 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 treinta minutos y un take homes es un domingo entero de codeo. Los take home 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 de 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 prefieran 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 más 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. 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. La segunda parte es la documentación: buscan que puedas documentar y explicar decisiones 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 ponele emojis, color, títulos, para armar una jerarquía y que luzca pulido. Para realmente resaltar sobre otros candidatos, la clave es proveer una idea nueva u 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 de problema, pero uno no sabe si quiere ver un skill específico, 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. 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 a argentinos para ahorrarse costos. 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. 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 siempre tiene una pregunta implícita en su cabeza, ¿es el candidato uno de los míos? 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 inventable 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 al 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 diez o quince 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 a cientos. 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 Uala, Globant to IBM. Es todo más o menos lo mismo, depende de cuánto te paguen 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. 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 al fracaso. Por eso es tan común que programadores cambien de trabajo de la mano de un conocido, 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 ha trabajado a cuarenta horas por semana y, digamos, cuarenta y ocho semanas anuales, nos da mil novecientos veinte horas de trabajo anual. Un proceso de entrevista te toma ocho 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 a silver.dev que aceptaron trabajos en una empresa sin haber terminado los procesos de entrevistas en otras, porque no quieren perder el tiempo. Eso no maximiza el valor de su trabajo ni 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 mindkiller. 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, incluso en empresas que uno les favorezca, y luego, cuando estén en manos las ofertas, empezar el proceso de selección. Si uno avanza en su carrera más metódicamente, cada vez que cambia de trabajo va a entrevistarse en al menos cuatro o cinco 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 al proceso de entrevista casi como chiste. Mi tasa de aprobación de entrevistas es de tres rechazos en mis últimas quince. Como mencioné, Breaks, una de las más dolidas. Aunque luego entrevisté otra vez, me hicieron una oferta y lo rechacé yo. Tomá a Breaks. Una de mis entrevistas más memorables 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 profesionales y económicos. El esfuerzo necesario para volverse bueno es una gota en el océano de trabajo de una carrera. 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.