El proceso de entrevista

Puedes escribir la solución óptima y aun así no pasar. También puedes no terminar de codear y pasar. Eso confunde a mucha gente, y la explicación es simple: no te evalúan por el código final, te evalúan por cómo llegaste a él.

Las fases de un proceso típico

Varía entre empresas, pero el esqueleto se repite:

1. Filtro de reclutamiento (20 a 30 minutos). Conversación, tu experiencia, qué buscas. Rara vez hay código.
2. Screening técnico (45 a 60 minutos). Uno o dos problemas de algoritmos en un editor compartido, casi siempre con alguien mirando. Aquí es donde entra todo lo de este curso.
3. Onsite o rondas finales (3 a 5 entrevistas en uno o dos días). Dos o tres de algoritmos, una de diseño de sistemas si el puesto es senior, y una de comportamiento.
4. Decisión. Un comité o el hiring manager lee las notas de todos los entrevistadores. Casi nunca decide una sola persona.

Ese último punto importa más de lo que parece: el entrevistador no decide, escribe. Tu objetivo real es darle material para que escriba algo bueno. Un entrevistador que no entendió tu razonamiento no puede defenderlo aunque tu código funcione.

Los 45 minutos por dentro

Un reparto que funciona:

El error de tiempos más caro es empezar a codear en el minuto 5. Sin haber acordado el enfoque, cualquier código es una apuesta, y reescribirlo a mitad de camino cuesta más que los diez minutos que te ahorraste.

Qué evalúan de verdad

Cuatro cosas, y solo una es el código:

Comprensión del problema. ¿Preguntaste lo que faltaba antes de asumirlo? Los enunciados de entrevista son ambiguos a propósito. ¿Puede haber duplicados? ¿Cabe en memoria? ¿Los valores pueden ser negativos? ¿Qué devuelvo si la entrada está vacía? Preguntar suma; asumir en silencio resta, aunque aciertes.

Razonamiento. ¿Cómo llegaste al enfoque? Decir "esto se parece a dos punteros porque el array está ordenado y busco un par" vale mucho más que escribir el código correcto en silencio.

Ejecución. ¿El código hace lo que dijiste? ¿Se lee? ¿Los nombres significan algo? Nadie espera código perfecto en un editor sin autocompletado, pero sí que sea coherente con lo que explicaste.

Comunicación. ¿Se te puede seguir? ¿Aceptas una pista o te aferras a tu idea? ¿Reconoces cuando algo no funciona?

Entre dos candidatos con el mismo código, pasa el que explicó mejor. Casi siempre.

Pensar en voz alta

Es lo que más separa a quien pasa de quien no, y lo que menos se practica.

Cuando te quedas callado, el entrevistador no sabe si estás razonando, trabado o perdido. Y si no lo sabe, no puede ayudarte, así que se limita a esperar y a anotar que no hubo comunicación.

Qué decir mientras piensas:

• La idea ingenua primero. "Lo obvio sería probar todos los pares, O(n²). Vamos a ver si se puede mejor." Eso demuestra que entendiste el problema y te da un punto de partida.
• Por qué descartas algo. "Pensé en ventana deslizante, pero como hay negativos el invariante se rompe."
• Cuando no sabes. "No se me ocurre cómo evitar el ordenamiento. Déjame pensar en qué estructura me daría el mínimo rápido." Eso no es debilidad; es exactamente lo que hace un ingeniero.

Lo que no conviene: quedarte en silencio tres minutos, o narrar la sintaxis ("ahora abro un for") en vez del razonamiento.

Las preguntas de aclaración que casi siempre aplican

Sirven en la mayoría de problemas y te compran tiempo para pensar:

• ¿Qué tamaño puede tener la entrada? Define qué complejidad hace falta.
• ¿Puede venir vacía, o con un solo elemento?
• ¿Hay valores repetidos? ¿Negativos? ¿Ceros?
• ¿Los datos vienen ordenados?
• ¿Puedo modificar la entrada?
• Si hay varias respuestas válidas, ¿devuelvo cualquiera o una en particular?
• ¿Qué hago con una entrada inválida: excepción, valor nulo, no puede pasar?

Probar sin ejecutar

En muchas entrevistas el editor no corre nada. Tienes que recorrer tu código a mano.

Elige un ejemplo pequeño, tres o cuatro elementos, y sigue el código línea por línea anotando el valor de cada variable. Es lento y se siente torpe, pero encuentra los off-by-one antes de que los encuentre el entrevistador, y demuestra rigor.

Después menciona los casos límite aunque no los pruebes: vacío, un elemento, todos iguales, el objetivo no está, el máximo al principio, el máximo al final.

Cuando te quedas en blanco

Pasa, y no es el final. Lo que se evalúa es qué haces después.

1. Vuelve al ejemplo. Resuélvelo a mano y observa qué pasos diste tú. Muchas veces el algoritmo está ahí.
2. Prueba con la fuerza bruta. Una solución lenta escrita y funcionando vale más que una óptima que no existe. Y desde ella se optimiza.
3. Di dónde estás trabado. "Sé que necesito recordar los prefijos que ya vi, pero no doy con la estructura." Un entrevistador que oye eso suele dar la pista. Uno que ve silencio, no.
4. Acepta las pistas. Están para eso. Rechazarlas para "hacerlo solo" es de las peores señales que puedes dar.

Después de codear

Cuando termines, no digas "listo" y esperes. Cierra tú:

• Recorre un ejemplo de principio a fin.
• Di la complejidad de tiempo y de espacio, y por qué.
• Menciona qué mejorarías con más tiempo.
• Nombra los casos límite que cubriste.

Ese cierre de dos minutos cambia lo que el entrevistador escribe en sus notas.

Lo que este curso cubre y lo que no

Este curso te prepara para las rondas de algoritmos: reconocer el patrón, escribirlo bien, justificar la complejidad. Es la parte más entrenable del proceso y la que más gente reprueba.

No cubre diseño de sistemas (aparece en puestos senior y es otra disciplina), ni las entrevistas de comportamiento, ni diseño de bajo nivel. Si tu proceso las incluye, prepáralas aparte.