Has pasado el primer filtro y llega el correo: prueba técnica. Es el punto donde más gente buena se cae, y casi nunca por falta de nivel. Se cae por no saber cómo funciona el formato.
Hay tres tipos, y se preparan de forma distinta.
1. El cuestionario cronometrado
Veinte o treinta minutos, tipo test, con tiempo por pregunta. Suele mezclar lógica, series numéricas, fragmentos de código y algún fundamento teórico.
Qué se mide en realidad: que no te bloquees bajo presión y que tengas los fundamentos frescos. No están buscando genialidad; están descartando a quien no distingue una función asíncrona de una síncrona.
Cómo prepararte:
- Repasa lo básico de tu lenguaje principal: tipos, ámbito de las variables, asincronía, estructuras de datos.
- Practica series numéricas. Casi siempre son alternancias: un patrón para los pares y otro para los impares, o dos operaciones que se turnan.
- Cronométrate en casa una vez. La sensación de reloj corriendo cambia mucho.
Durante:
- Portátil, enchufado, sin notificaciones. Papel y boli al lado.
- No lo abras "para echar un vistazo": el cronómetro suele arrancar al entrar.
- Si te atascas, responde lo que creas y avanza. Una en blanco vale lo mismo que una fallada, y el tiempo perdido te cuesta dos más.
2. El ejercicio para casa
Te mandan un enunciado y unos días de plazo. Suele ser una aplicación pequeña o una función con casos límite.
Qué se mide en realidad: cómo escribes cuando nadie te mira. Orden, nombres, decisiones, y sobre todo si sabes explicar por qué hiciste lo que hiciste.
Lo que marca la diferencia:
- Un README corto. Cómo ejecutarlo, qué decisiones tomaste y qué dejarías para una segunda versión. Muchos candidatos no lo ponen; con eso ya destacas.
- Alguna prueba automatizada, aunque sean tres. Demuestra criterio más que cien líneas extra.
- Terminarlo. Es mejor un alcance pequeño y acabado que uno ambicioso a medias.
- Respetar el enunciado. Si piden que no uses una librería concreta, no la uses. Es parte de la prueba.
Lo que resta:
- Entregar tarde sin avisar. Si necesitas dos días más, pídelos: se concede casi siempre y da mejor imagen que entregar algo a medio hacer.
- Sobredimensionar. Cinco capas de abstracción para leer un fichero dice más de lo que crees, y no dice nada bueno.
3. La sesión en directo
Compartes pantalla y programas mientras alguien mira. Es el formato que más nervios da y el que más se puede entrenar.
Qué se mide en realidad: cómo piensas y cómo trabajarías con ellos. El resultado importa menos que el camino.
La regla que lo cambia todo: piensa en voz alta. Un silencio de tres minutos, aunque estés razonando bien, se interpreta como bloqueo.
Un guion que funciona:
- Repite el problema con tus palabras. «Entonces necesito una función que reciba X y devuelva Y, ¿correcto?»
- Pregunta por los casos límite antes de escribir. ¿Puede venir vacío? ¿Hay duplicados? ¿Tamaño máximo?
- Di tu plan antes de teclear. «Lo haría con un mapa para no recorrerlo dos veces.»
- Escribe la versión sencilla primero. Que funcione. Optimizar después.
- Repásalo en voz alta con un ejemplo concreto.
Y si te quedas en blanco, dilo: *«Se me está yendo la sintaxis exacta, pero la idea sería recorrerlo una vez guardando lo visto.»* Eso no resta. Fingir sí.
Después de la prueba
Escribe lo que te preguntaron. Se olvida en dos días y es el mejor material para la siguiente. Guárdalo junto a la candidatura.
Si suspendes, pide retorno. Un correo corto:
Gracias por la oportunidad. Si podéis compartir en qué se quedó corta la prueba, me sería muy útil para mejorar.
No siempre responden. Cuando lo hacen, vale oro.
Si no dicen nada en el plazo indicado, escribe una vez pasada una semana. Una sola vez.
Lo importante: la prueba técnica no mide lo que vales como profesional. Mide cómo rindes en ese formato concreto. Y eso, a diferencia del talento, se entrena en unas pocas tardes.