E187 - ADS - Parte 5: Tips para entrevistas técnicas

Resumen

El episodio 187 de enCoders (ADS, parte 5) reúne tips para entrevistas técnicas tipo LeetCode, aplicables también a entrevistas técnicas en general. El método propuesto es hablar en voz alta, repetir el problema con palabras propias, hacer preguntas aclaratorias, verificar supuestos (orden, duplicados, negativos, rangos) y dibujar un ejemplo trivial. Después se propone una solución de fuerza bruta como checkpoint y se optimiza buscando cuellos de botella, trabajo innecesario y trabajo duplicado. Solo entonces se escribe código, que se verifica con casos de borde y puntos de alto riesgo. Los invitados cuentan cómo filtran currículums y evalúan candidatos. Su conclusión es que importa más el proceso de razonamiento y la comunicación que acertar la respuesta. La actitud sola no basta. Al cierre se comenta cómo la IA cambia la programación y se recomienda practicar entrevistas y hacer un proyecto real.

Capítulos

• 00:00
  IntroEpisodio 187, quinta parte de algoritmos y estructuras de datos, centrada en tips para entrevistas tipo LeetCode. Algunos tips aplican a entrevistas técnicas más amplias.
• 00:30
  Libro recomendado y preparaciónSe recomienda *Cracking the Coding Interview* y los videos de su autora. No hace falta leer el libro completo. Un resumen basta para conocer las estrategias típicas, como BFS.
• 01:53
  Hablar en voz alta y aclararHay que hablar en voz alta, reformular el problema y hacer preguntas aclaratorias. Si no se pregunta, se puede resolver algo que no se pidió. El ejemplo es "mejorar la retención de clientes": quien salta a un modelo de propensión sin preguntar plazo, presupuesto o plataforma lo hace mal.
• 05:01
  Supuestos y restricciones claveConviene verificar si los datos están ordenados, si hay duplicados, negativos, decimales o complejos, y los rangos de entrada y salida. Con números distintos se puede descartar un valor ya identificado. También hay que definir inputs y outputs de todo el sistema. Si algo no está definido, se presiona para definirlo.
• 09:01
  Dibujar para entenderDibujar da intuición y permite transmitirla al entrevistador. El ejemplo es el caballo en un tablero de ajedrez: primero un movimiento, luego dos con otro color. Se recomienda una pizarra virtual compartiendo pantalla en lugar de escribir en un archivo de texto.
• 13:36
  IA en entrevistas técnicasAl dibujar se detectan patrones y transformaciones útiles para el pseudocódigo. Sobre usar IA, depende de la empresa: si no lo dicen explícitamente, hay que preguntar. En problemas tipo LeetCode no tiene sentido. En proyectos para la casa puede aceptarse si se justifica cada decisión. Se prefiere preguntar "¿puedo usar IA?" a "¿puedo hacer vibe coding?".
• 17:44
  Primera solución y checkpointsSe propone primero una solución de fuerza bruta, explicada rápido, que sirve de checkpoint. Ir directo a la óptima puede dejar el problema sin resolver. En la vida real también conviene que primero funcione y luego se optimice. Hasta aquí no se ha escrito código.
• 21:13
  Optimización y cuellos de botellaSe miran tres aspectos: cuellos de botella, trabajo innecesario y trabajo duplicado. El profiling mide tiempo y memoria por sección. Ejemplos: pandas vs Polars, full outer join vs inner join, loops anidados y condiciones de término. Otro ejemplo es Two Sum con two pointers en vez de copiar el arreglo. Se discute si optimizar problemas pequeños y por qué conviene conocer las soluciones estándar, con el ejemplo del álgebra lineal.
• 34:41
  Comunicación y mentalidadSe evalúa el método y la comunicación, no solo la actitud. Un razonamiento coherente aunque erróneo vale más que uno que no se sabe explicar. Se busca a alguien que cuestione y no ejecute sin pensar. Se rechaza la frase "denme una oportunidad". Se dan consejos a un estudiante de ingeniería: los videos de 3Blue1Brown para álgebra lineal, teoría y luego ejercicios, y mucha práctica en programación.
• 47:34
  CV y filtros rápidosSe descarta de inmediato a quien no coincide con el perfil, por ejemplo un perfil de data analyst para un puesto de data scientist. También los CV de más de dos o tres páginas. Un CV de una página es perfectamente válido.
• 49:23
  Poner librerías en el CV?Listar muchas librerías, como pandas, es mala señal si no se domina de verdad. Sugieren no ponerlas si no se conocen bien.
• 50:24
  Junior vs senior y rotaciónLos perfiles de 0 a 3 años rotan más, por eso se buscan más juniors. Los puestos altos se cubren a menudo con ascensos internos. Un equipo puede ser solo senior si tiene presupuesto.
• 52:47
  Fit y comunicación en entrevistaLa entrevista de fit se evalúa con una rúbrica, no con "vibes": orden al expresarse y capacidad de explicar el impacto del proyecto. Es el primer filtro porque las pruebas técnicas son más largas. Leer el CV punto por punto no se considera buena entrevista.
• 55:08
  MemesPausa de memes. Los triggers manuales y la depuración local son útiles. Un CI/CD de 15 minutos a una hora se puede evitar montando la infraestructura local con un script. Sobre LeetCode: los problemas fáciles pueden costar horas al principio. Luego se responden preguntas de la comunidad sobre máster y Poetry vs uv.
• 01:01:23
  Evitar trabajo duplicadoPara contar letras en un string se hace una sola pasada con un diccionario, en vez de una pasada por letra. Gasta más espacio, pero reduce el tiempo. También se menciona la programación dinámica con caché de resultados.
• 01:04:04
  Tradeoff espacio tiempoA veces conviene reducir espacio a costa de tiempo. Si la RAM es insuficiente, se procesa por bloques en serie, cada uno con toda la memoria, en vez de en paralelo.
• 01:06:10
  Pruebas técnicas largasUna persona cambió su evaluación porque los LLM resuelven las pruebas cortas: ahora son más abiertas. Las entrevistas en vivo suelen durar una hora. Las largas son tareas para la casa, por ejemplo un PDF con una semana de plazo.
• 01:08:44
  Evaluar el proceso mentalInteresa más cómo resuelve problemas nuevos que lo que sabe. Un error con razonamiento sólido es fácil de corregir. Se cuenta una anécdota de un proceso de selección donde destacó quien llegó con un análisis, aunque fuera malo. Se menciona la pregunta "¿te contratarías a ti mismo?", que debe justificarse.
• 01:15:10
  Casos prácticos y portafolioEl caso práctico es un filtro potente y se usa hacia el final. Se valora que el candidato justifique sus decisiones y no dependa de GPT. Un portafolio de GitHub con un solo commit indica que no se sabe usar Git.
• 01:17:11
  Foto en el currículumAnécdota de una persona que puso en el CV una foto cuidada, que le sacó su hermana tras muchos intentos. Cree que ayudó a que la llamaran, aunque lo atribuye a una combinación de factores.
• 01:19:42
  Cómo codear en entrevistaSe empieza a codear solo después de entender el problema, tener la intuición y un plan con pseudocódigo. Se verifican la correctitud con inputs y outputs de ejemplo, la legibilidad, la mantenibilidad y la performance. Se comparan la complejidad de la solución bruta y la optimizada.
• 01:21:46
  Testing edge cases y riesgosHay que probar con cero, vacío, negativos y listas anidadas. Un solo edge case fallido no suele descartar, pero varios sí. Si falta tiempo, se puede asumir una función simple y común, avisando al entrevistador. Se hace un walkthrough paso a paso y se revisan los puntos de alto riesgo: índices, bucles, recursión y caso base.
• 01:30:43
  CierreSe recomienda probar casos propios, comunicar bien y revisar el documento en GitHub. Próximos temas: binary search y programación dinámica. Se comenta cómo la IA cambia la necesidad de programar con exactitud y el efecto de los nervios. Se aconseja encontrar un proyecto real para empresas pequeñas. El siguiente episodio es Arquitectura de software, parte 2.

Palabras clave