#9 – Cómo preparar entrevistas de Live Coding
Cómo pasé de caer en entrevistas de Live Coding a recibir ofertas
Sólo hay dos cosas que me dieron verdadero pánico en mi vida: el examen de conducir y las entrevistas de live coding. La presión que se siente cuando te observan intentando resolver y programar la solución a un problema es difícil de entender hasta que no lo vives.
Después de hacer decenas de entrevistas, puedo decir que me siento cómodo en ellas. Sigo nervioso, sí. Pero ya no me bloqueo, puedo seguir una estructura y llegar a soluciones aceptables en la mayoría de casos.
Hace unas semanas te contaba cómo me preparé para entrar en empresas americanas. Hoy entramos en detalle en las entrevistas de live coding, explicando todo lo que he hecho para superar ejercicios de Google, Amazon, Stripe o MongoDB, entre otros.
En mi curso Algoritmos, Estructuras de Datos y Entrevistas de Programación cubro todo el proceso desde cero, con más de 50 ejercicios reales:
Complejidad algorítmica (Big O)
Estructuras de Datos (tablas hash, linked list, stack, queue, tree, graph, heaps y tries)
Recursividad y programación dinámica.
Algoritmos de ordenamiento y búsqueda
Mejora tu CV y cómo aplicar a vacantes de empleo.
Qué evalúan realmente en estas entrevistas
Mucha gente cree que lo que más cuenta en estas entrevistas es llegar a la mejor solución posible. Y si es sin ayuda, mejor.
Si bien es cierto que eso suma, no es lo más importante. Lo que más se valora es la comunicación, el razonamiento, la capacidad de adaptación y colaboración con el entrevistador y los conocimientos que tengas de las bases de la ingeniería de software.
Me han rechazado en entrevistas que resolví perfectamente, llegando a la solución óptima, por falta de comunicación. Y he pasado procesos en los que no pude llegar a la mejor solución, pero donde la colaboración fue muy buena.
1. Introducción (5-10 min)
La entrevista suele empezar con una fase de introducción que dura unos 5-10 minutos. Para esto, debes preparar un resumen de tu carrera, tus logros y tu puesto actual en un par de minutos como máximo. Enfatizo lo de preparar. Es la pregunta más típica y te va a ayudar llevarla lista.
Es importante no demorarse mucho en esto, ya que es una entrevista técnica y es fácil que el entrevistador pierda el hilo si sueltas demasiada información.
2. Presentación del problema y propuesta de primera solución (10-15 min)
A continuación, te presentan el problema y te dan un tiempo para que lo leas. No intentes ir con prisa y, bajo ningún concepto, pienses en tirar código todavía.
Léelo con calma y haz todas las preguntas que necesites. Hay cosas que pueden parecer obvias, pero si no están especificadas en los requisitos es mejor preguntar para establecer el alcance del problema.
Aquí llega el momento de proponer una primera solución. No tiene que ser la más óptima. Mucha gente se queda bloqueada en este punto por querer dar la mejor respuesta posible. Una solución subóptima es mil veces mejor que un folio en blanco.
Lo más importante es hablar mucho. El entrevistador no puede leer tu mente, y una de las cosas que quiere evaluar es cómo piensas. Además, si sabe lo que estás pensando, podrá darte pistas para resolver el ejercicio.
3. Optimización y escribir el código (20 min)
Una vez tenemos una primera solución que resuelve el ejercicio, es hora de optimizarla. Hasta este momento no has escrito ni una línea de código. Ha sido una conversación con el entrevistador y notas en texto plano.
Analiza la complejidad algorítmica de tu solución e intenta estimar cuál sería el Big O óptimo. Si te quedas bloqueado, puedes hacer un brainstorming de los algoritmos y estructuras de datos más comunes, ya que pueden ayudarte a optimizar la solución.
Una vez llegas a un acuerdo con el entrevistador, es hora de programar. Intenta escribir código lo más legible y sintácticamente correcto posible, pero esto no es lo que más se valora. Se entiende que el tiempo es muy limitado, por lo que no importa si cometes algún fallo de sintaxis o si no te acuerdas de alguna función.
Al acabar, repásalo y “ejecuta” ejemplos de forma manual en él, para comprobar que todo funciona como esperas. Si encuentras algún bug, coméntalo y soluciónalo si te da tiempo.
4. Cierre y preguntas (10-15 min)
Dependiendo del tiempo que te quede, el entrevistador puede hacerte más preguntas o dejarte hacer unos comentarios finales. Aquí puedes comentar aspectos que tendrías en cuenta, pero para los que no hay tiempo en una entrevista así: logging, métricas, tests, calidad del código, etc.
Finalmente, aprovecha la oportunidad para hacer buenas preguntas sobre el equipo y la empresa. Es un detalle que suma y puede marcar la diferencia si muestras interés real por la oportunidad.
Mi proceso de preparación
Si has llegado aquí, gracias por aguantar la chapa xD. Pero es muy importante conocer la estructura de estas entrevistas y lo que se valora, para entender cómo se preparan.
Complejidad Algorítmica
El concepto más importante para llegar a soluciones óptimas es el Big O. Te lo van a pedir y, aunque no lo hagan directamente, se asume que debes mencionarlo. Si no lo haces, penaliza.
No tienes que entrar en todas las matemáticas de la definición formal. De hecho, me sigue asustando echar un vistazo a la página de Wikipedia xD. Lo que sí tienes que conocer son las complejidades más comunes y cuándo se dan:
Complejidad Constante O(1). No importa el tamaño de entrada, el número de operaciones siempre es el mismo.
Complejidad logarítmica O(log n). Se da cuando el problema se reduce a una fracción del tamaño original en cada paso. Un ejemplo típico es la búsqueda binaria.
Complejidad lineal O(n). Algoritmos que crecen al mismo tiempo que la entrada.
Complejidad log-lineal O(n log n). Crecen a mayor ritmo que la lineal pero menos que la cuadrática. Son muy comunes en algoritmos de ordenamiento eficientes como quicksort o mergesort.
Complejidad cuadrática O(n^2). Se dan normalmente cuando tienes bucles anidados que recorren un mismo conjunto.
Complejidad Exponencial O(2^n). El número de operaciones se duplica cada vez que aumenta el tamaño de entrada.
Complejidad factorial O(n!). Se dan en algoritmos que deben explorar todas las permutaciones posibles de los elementos.
Ninguna complejidad es mala por sí misma, todo depende del problema que estés resolviendo. Pero en estas entrevistas técnicas, cuando una solución tiene complejidad cuadrática o mayor, normalmente es una señal de que el algoritmo puede optimizarse.
Estructuras de Datos y Algoritmos
El siguiente paso en mi preparación fue repasar todas las estructuras de datos que ya había visto en la universidad, pero que mi memoria había descartado xD. Primero de forma teórica y, a continuación, con ejercicios específicos para cada una de ellas.
Como ya he comentado muchas veces, yo seguí Cracking the Coding Interview, que ya tiene ejercicios específicos para cada estructura. Pero si no quieres pagar por libros o cursos, recomiendo mucho que busques en LeetCode, ya que puedes filtrar por el tipo de ejercicio.
En esta primera fase hacía 4-5 ejercicios easy y 1-2 medium. Para algunas estructuras, como trees, graphs y heaps también creaba una implementación propia para repasar la lógica interna, aunque esto no me aportó demasiado.
Sé que hay muchos temas, y puede agobiar un poco. En mi caso, el orden que seguí fue el siguiente:
Arrays, Strings y Hash Tables
Linked List
Stacks y Queues
Trees y Graphs
Heaps
Tries
Recursividad y Programación Dinámica
Algoritmos de Ordenamiento y Búsqueda
Manipulación de Bits
Tras cientos de entrevistas que he hecho como entrevistador y entrevistado, las más relevantes son sin duda los grafos y árboles, heaps, y la recursividad y programación dinámica.
Las que menos útiles me han resultado son los algoritmos de ordenamiento, ya que es rarísimo que te pidan implementar quicksort o merge sort a mano en una entrevista así, y la manipulación de bits, porque son ejercicios muy específicos, poco intuitivos y que en general se piden poquísimo (en mi caso nunca me pidieron uno).
Ejercicios y claves
Cuando filtras por tipo, se elimina uno de los mayores retos que tienen estos ejercicios: identificar qué estructuras de datos y patrones pueden ser útiles para llegar a la mejor solución.
Por eso, mi siguiente paso fue hacer ejercicios aleatorios en LeetCode. No es necesario hacer cientos de ejercicios para empezar a pasar este tipo de entrevistas, pero sí hace falta bastante práctica.
Al contrario de lo que se suele pensar, no hace falta hacer los hard sin sufrir. En mi experiencia, es más productivo enfocarse en los medium. Y, como puedes ver en la distribución de ejercicios, fue en lo que más me centré.
Cuando empecé, seguía listas recomendadas que encontraba por blogs, pero ahora LeetCode tiene rutas de estudio. Recomiendo hacer la Top 150, pero si no tienes tanto tiempo la Top 75 también es muy buena. Elige un problema y haz click en botón de aleatorio, porque si no ya sabes de antemano qué tipo de problema estás resolviendo.
Tras cientos de horas practicando y muchas entrevistas, estas son las claves que más me ayudaron a mejorar.
Clave 1: Esto es un maratón, no un sprint
De nada sirve hacer diez ejercicios un día si no abres LeetCode el resto de la semana. Tu cerebro necesita tiempo para asimilar estos problemas, y si los rusheas no vas a conseguirlo. Ponte como objetivo hacer al menos un ejercicio al día, pero dedicándole su tiempo. Yo siempre intento hacer tres al día en mis épocas de entrevistas.
Clave 2: No te rindas a la primera de cambio
Ver la solución sin luchar por resolver un ejercicio es tiempo perdido. Lo que yo suelo hacer es poner un temporizador con 40 minutos, que es lo que normalmente te dan en las entrevistas. Si en ese tiempo sigo sin tener ni idea de cómo resolverlo, echo un vistazo a las pistas. Y si las pistas no ayudan, 15-30 minutos más tarde voy a la solución.
Clave 3: No te dejes llevar por el nivel de dificultad
Va a llegar algún momento en el que te vas a frustrar, pero es importante no dejarte llevar por el nivel de dificultad. Es súper común encontrarse con ejercicios supuestamente fáciles en los que cuesta encontrar la mejor solución, y ejercicios difíciles que se resuelven en 10 minutos.
Clave 4: Aplica mientras te preparas
No esperes a estar cómodo para empezar a aplicar a ofertas, porque nunca lo vas a estar. Yo me sigo poniendo nervioso con estas pruebas hoy en día, después de toda mi experiencia. Además, en las entrevistas es donde más se aprende y se mejora, ya que es la única forma de practicar con la presión real.
Clave 5: Repite problemas después de unos días.
Especialmente si un ejercicio te costó o no pudiste resolverlo, no lo dejes aparcado. Vuelve a intentarlo unos días después.
Clave 6: Practica en voz alta
La única forma de practicar en un entorno real es con una entrevista. Pero eso no significa que no podamos simular cómo sería una. Intenta pensar en voz alta durante todo el ejercicio para que cuando llegue la entrevista te salga de forma más natural.
Clave 7: Practica con otras personas
Si tienes amigos o conocidos que también se están preparando, aprovéchalo y practica con ellos. Una vez uno hace de entrevistador y otra vez de entrevistado. Si no, también puedes buscar gente en foros como Reddit que busca compañeros para practicar, aunque sinceramente, yo nunca lo hice por vergüenza xD.
Clave 8: Fíjate en los patrones
Hay miles de ejercicios que te pueden caer, pero todos tienen ciertos patrones o técnicas para resolverlos de forma eficiente: sliding window, two pointers, BFS/DFS, backtracking, etc. Cuando empiezas a reconocer estos patrones, muchos problemas dejan de parecer tan distintos entre sí. No memorices ejercicios concretos, céntrate en entender bien estos enfoques y cuándo aplicarlos.
En resumen: mucho tiempo, pero buen retorno
No te voy a mentir. Preparar estas entrevistas por primera vez es un dolor de cabeza. Se necesita invertir mucho tiempo y pasar por entrevistas que son estresantes.
Pero también tiene su lado positivo. Una vez lo haces, las siguientes veces es bastante sencillo y rápido volver a prepararlas (normalmente yo repaso una semana y empiezo a aplicar). Además, es un proceso muy estructurado y sabes lo que te espera, a diferencia de otras entrevistas técnicas donde pueden preguntarte cualquier cosa.
Esta forma de evaluar candidatos sigue siendo la preferida por empresas estadounidenses o extranjeras en general, por lo fáciles que son de hacer y escalar. Y el sueldo que ofrecen suele ser razón suficiente como para que, en mi opinión, compense prepararlas!
Y si te interesa preparar este tipo de entrevistas de forma más guiada, recuerda echarle un vistazo a mi curso Algoritmos, Estructuras de Datos y Entrevistas de Programación, donde cubro toda la teoría, el CV y más de 50 ejercicios reales.
Sudores frios solo de recordar alguna de mis entrevisas. Recuerdas alguna especialmente dura?
Para nada ha sido una chapa Dani, interesantisimo! Vengo de grado superior y llevo 2 añitos en el sector, tu contenido me da la vida te lo prometo!!