Resolver un problema mientras alguien te mira
En una entrevista de programación se evalúa mucho menos la solución de lo que se cree y mucho más cómo llegás a ella. Quien te entrevista está imaginando cómo sería trabajar con vos, y para eso necesita escucharte pensar.
Dos personas resuelven el mismo ejercicio. La primera escribe en silencio quince minutos y llega a la solución óptima. La segunda pregunta por los casos borde, propone una solución simple, dice por qué es lenta, mejora una parte y llega a algo casi óptimo hablando todo el tiempo.
La segunda suele pasar y la primera no siempre. No es injusticia: la entrevista no evalúa si sabés el truco, evalúa cómo trabajarías con el equipo, y de alguien que resuelve en silencio no se sabe nada más que el resultado.
El procedimiento que conviene seguir siempre
Los seis pasos
- Repetí el problema con tus palabras. Treinta segundos que evitan resolver algo distinto de lo que te pidieron, que es el error más caro y más común.
- Preguntá lo que falta. ¿Puede haber repetidos? ¿Qué tan grande es la entrada? ¿Qué devuelvo si está vacía? Preguntar no es no saber: es lo que hace alguien con experiencia.
- Escribí dos o tres ejemplos a mano, incluido un caso borde. Muchas veces la solución aparece mirándolos.
- Decí una solución simple primero, aunque sea ineficiente. «Lo más directo sería probar todos los pares, que es cuadrático.» Ahora tenés algo funcionando de referencia y ya demostraste que entendés el problema.
- Mejorala en voz alta. Qué se repite, qué se puede recordar, qué estructura ayuda.
- Recién ahí, escribí el código. Y probalo a mano con tus ejemplos.
Pensar en voz alta, sin narrar todo
| Narración que no ayuda | Narración que ayuda |
|---|---|
| «Ahora voy a declarar una variable i» | «Voy a recorrer una vez guardando lo que ya vi, para no repetir la búsqueda» |
| Silencio largo | «Estoy pensando si conviene ordenar primero; dame diez segundos» |
| «Esto está mal, lo borro» | «Esto no maneja el caso de la lista vacía, lo arreglo» |
| «No sé» | «No recuerdo la sintaxis exacta; la idea es agrupar por clave, lo escribo así y lo verifico» |
Antes de seguir, predecí
Hablar de complejidad sin recitar
Casi siempre se pregunta, y conviene responder con criterio y no con una etiqueta:
| Respuesta pobre | Respuesta con criterio |
|---|---|
| «Es O(n²)» | «Es cuadrático porque por cada elemento recorro el resto; con un conjunto auxiliar bajo a lineal a cambio de memoria» |
| «No sé la complejidad» | «Tiene dos recorridos anidados, así que crece con el cuadrado; puedo calcularlo bien si querés» |
| «Es eficiente» | «Para mil elementos cualquiera de las dos anda; si son millones, la diferencia importa» |
Los primeros cinco minutos
Escenario · 1 decisión como mínimo
«Dado un arreglo de números, devolvé los dos que suman un valor dado»
Te dan el enunciado y una pantalla en blanco. Se te ocurre enseguida la solución de dos ciclos anidados, y también sospechás que hay una mejor. ¿Qué hacés primero?
Pasan cinco minutos sin que digas nada. El entrevistador pregunta en qué estás pensando.
DesenlaceQue te tengan que preguntar ya es la señal. No es una regla arbitraria: en el trabajo real nadie te va a poder ayudar si no sabe dónde estás, y eso es exactamente lo que se está evaluando.
Escribís la versión con tabla hash. A mitad de camino te das cuenta de que no manejaste el caso de números repetidos.
DesenlaceAhora estás corrigiendo bajo presión algo que se resolvía preguntando al principio. Saltar a la solución óptima sin pasar por la simple deja sin red: cuando aparece un problema, no hay una versión que funcione a la cual volver.
Preguntás si puede haber repetidos, qué tan grande es la entrada y qué devolver si no hay solución. Te contestan: puede haber repetidos, la entrada es grande, y si no hay solución devolver vacío. ¿Qué sigue?
Escribís la solución. Anda. El entrevistador pregunta qué pasa si el arreglo tiene dos veces el mismo número y el objetivo es su doble.
DesenlacePreguntaste bien al principio y después no usaste la respuesta. Escribir el ejemplo borde antes del código es lo que hace que esa pregunta no te agarre.
Con los ejemplos escritos, ¿con qué solución arrancás?
La escribís y anda. Quedan quince minutos.
DesenlaceBuen resultado. Si te hubieras trabado, en cambio, no había ninguna versión funcionando a la cual volver, y esos son los casos donde una entrevista que iba bien se cae en dos minutos.
La versión cuadrática anda y pasa tus ejemplos. ¿Y ahora?
El entrevistador pregunta si se puede hacer mejor.
DesenlacePreguntaron lo que vos mismo habías dejado abierto. Si señalás el costo, hay que seguir: «es cuadrática, y se puede bajar guardando lo visto en una tabla».
Escribís la versión lineal, la probás con los ejemplos de antes —incluido el de los repetidos— y explicás por qué ahora es O(n) en tiempo y O(n) en memoria.
DesenlacePreguntas, ejemplos, versión simple, mejora y prueba: quedó a la vista cómo trabajás, que es lo que se estaba evaluando. Y el caso de los repetidos, que era la trampa del ejercicio, lo habías cerrado en el primer minuto.
Ninguna decisión acá es sobre el algoritmo. Todas son sobre qué se ve de cómo trabajás.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica