Atlasingeniería

Carrera profesional y entrevistasEntrevistasTema 5

Ejercicios para entregar y programar en vivo

Son dos formatos con reglas opuestas. En el ejercicio para entregar te juzgan el criterio y las decisiones; en el vivo, cómo trabajás bajo observación. Optimizar para el formato equivocado es el error más común.

Un ejercicio para hacer en casa y una sesión de programación en vivo parecen la misma prueba con distinto horario. No lo son. En el primero nadie te ve trabajar, así que lo único que habla es el resultado y lo que escribas sobre él. En el segundo el resultado importa menos que el proceso, porque el proceso es justamente lo que se está mirando.

Quien entrega un ejercicio como si fuera código de producción y después programa en vivo en silencio buscando la solución perfecta, está optimizando para el formato contrario en los dos casos.

El ejercicio para entregar

Cómo encararlo

  1. Respetá el tiempo sugerido y decilo. Si dice cuatro horas, entregá lo que entra en cuatro horas y escribí qué falta. Entregar veinte horas de trabajo no impresiona: sugiere que no sabés acotar y compite injustamente con quien respetó la consigna.
  2. Que funcione con un comando. Instrucciones probadas desde cero. Si no arranca, no importa lo que haya adentro.
  3. Tests de lo que importa, aunque sean pocos. La lógica central, no el andamiaje.
  4. Escribí las decisiones en el README. Es lo que más se lee y lo que más diferencia.
  5. Decí qué harías con más tiempo. Autenticación, manejo de errores, límites de tasa, observabilidad. Reconocer lo que falta demuestra que sabés qué necesitaría en serio.

Antes de seguir, predecí

El ejercicio dice «no más de cuatro horas» y a las cuatro horas te falta una funcionalidad. ¿Qué hacés?

Programar en vivo

Lo que no funcionaLo que funciona
Al empezarEscribir código enseguidaRepetir el enunciado y preguntar lo que falta
Mientras pensásSilencio largo«Estoy evaluando dos formas, te cuento»
Al trabarteInsistir en silencioDecir dónde estás y qué descartaste
Con el entornoPelear con una herramienta que no conocésUsar lo que mejor manejás y avisar
Si no recordás algoFrenar«No me acuerdo la firma exacta; la escribo así y la verifico»
Nadie escribe su mejor código observado y con reloj. Eso está contemplado en la evaluación; el proceso, no.

Lo que se prepara antes

Buena parte de los problemas en estas instancias son logísticos y se evitan en quince minutos:

Antes de la entrevista

  1. Probá la herramienta que van a usar. Editor compartido, videollamada, compartir pantalla. Perder diez minutos en configuración con el reloj corriendo pone nervioso a cualquiera.
  2. Tené tu entorno listo y limpio. Proyecto vacío, tests corriendo, atajos que conozcas. Y cerrá lo que no querés compartir por accidente.
  3. Practicá en voz alta. Resolver un ejercicio explicando en voz alta a nadie es raro y es exactamente la habilidad que se evalúa. Nadie lo hace bien la primera vez.
  4. Preparate para lo básico sin ayudas. Recorrer una lista, manipular cadenas, agrupar con un diccionario, ordenar con un criterio. Si eso fluye, la cabeza queda libre para el problema.

Dos formatos, dos estrategias

Escenario · 1 decisión como mínimo

Te dan un ejercicio para hacer en casa: «unas cuatro horas»

El enunciado pide una API con tres endpoints y persistencia. Sugieren cuatro horas. Vos sabés que en doce lo dejarías impecable. ¿Qué hacés?

Las mismas cuatro horas y el mismo ejercicio. Lo que cambia es para qué está hecho cada formato.

Cierre

Autoevaluación

¿Lo entendiste?

El ejercicio sugiere cuatro horas y te falta algo. ¿Qué conviene?
¿Por qué la sobre-ingeniería descarta?
¿Qué es lo más importante en una sesión de programación en vivo?
¿Se puede buscar en internet durante una entrevista en vivo?
¿Qué conviene practicar antes de una entrevista en vivo?