5 Consejos para destacar en la prueba técnica

Cada vez más empresas utilizan pruebas técnicas como parte de su proceso de selección. Una de las más habituales es enviarte el enunciado de un problema de negocio (generalmente relacionado con su actividad) para que lo resuelvas en casa. Tu ejercicio será posteriormente evaluado por tus potenciales colegas de trabajo de forma asíncrona, sin tener contacto contigo. En otras palabras, tu carta de presentación en esta parte del proceso es tu código, por lo tanto, debe transmitir todas tus capacidades.

He estado en ambos lados del muro: He sido candidata y he sido revisora, y esto me ha ayudado a aprender varios trucos y normas de “etiqueta” que me gustaría transmitirte a través de los siguientes consejos:

 

Haz preguntas

Lee con detenimiento el ejercicio y si hay algo que no te queda claro pregúntalo. Una de las capacidades más útiles en programación es la empatía. ¡Programar no cosiste en picar código! En nuestro trabajo es muy importante que entendamos bien el contexto de nuestras tareas, el vocabulario de nuestro sector, las necesidades del cliente. Por lo tanto, no dejes de hacer una pregunta porque pienses que vas a quedar mal, al contrario, vas a dar una imagen muy profesional al mostrar tu compromiso con la entrega de valor.

 

Preocúpate por el enfoque, no por terminarlo

No necesito que termines el ejercicio. No voy a ponerlo en producción ni a venderlo. Lo que necesito es saber cómo programas. Por lo tanto, preocúpate más por cosas como, por ejemplo, tu historial de commits.

Los commits son una buena representación de tu metodología. Sólo leyendo el nombre de tus commits podría conjeturar si has escrito los tests antes que el código, si has dado pasos pequeños, qué importancia tiene para ti la fase de refactor, cuánto tiempo has tenido los tests en rojo e incluso tu capacidad para expresarte y tu nivel de inglés.

Lo cierto es que las aplicaciones nunca están terminadas. El código es un ser vivo que muta constantemente a lo largo del tiempo, por lo tanto es irrelevante si te has creado un “Facebook” de una sentada en una noche. Eso sólo demuestra que tenías tiempo para hacerlo. Lo realmente importante es si tu código es legible por otras personas, si eres capaz de transmitir tus conocimientos, si encajas con nuestra cultura ágil.

Piensa: si tuvieras que irte de vacaciones y dejar este código en manos de otra persona, ¿sería fácil para esta persona trabajar con él? Si la respuesta es sí, no importará que no esté terminado.

Escribe un código limpio

Seguramente estoy dejando de hacer otras cosas para revisar tu ejercicio. Tengo poco tiempo: No me obligues a perderlo descifrando tu código.

Hay muchos trucos y recursos que pueden enseñarte a escribir un código legible y expresivo: Leer mucho para adquirir vocabulario, aprender a detectar los olores de código y a refactorizarlos, programar en parejas…

Mejorar en esta habilidad te será muy útil para comunicarte con tus compañeras y compañeros de trabajo, e incluso con tu yo del futuro. Y también será útil, como hemos visto, para la empresa, ya que un código limpio es un código escalable.

Truco: Si necesitas explicarte a través de comentarios por todo el código, algo no va bien. El código debería autodocumentarse a través de la semántica y de los tests.

 

Cuida tu README

El README es el documento en el que se define en qué consiste un proyecto y cómo interactuar con él. Y es lo primero que voy a buscar. Intenta incluir en él toda la información que creas que voy a necesitar:

  • El enunciado del problema: no des por hecho que me lo sé. Puede que hiciera este ejercicio hace meses o años, o tal vez nunca, y ahora está perdido en el laberinto de documentación laboral de la empresa. No me hagas ir a donde quiera que tengamos los enunciados a buscar el tuyo.
  • Cómo levantar la aplicación y ejecutar los tests: En definitiva, cómo utilizar tu programa. No asumas que tengo el mismo entorno que tú instalado en mi ordenador, ponme links a recursos si debo descargarme alguno, concreta versiones, lista requisitos, dime cuál es el comportamiento esperado.
  • Notas: Si quieres decirme algo que no puedes expresar a través del código, puedes reservar una sección del Readme para “Observaciones”. Por ejemplo, si tenías en mente hacer algunas cosas pero no te ha dado tiempo, o no has podido tomar alguna decisión porque preferirías debatirlo con alguien, escribe una lista de “To-Do” explicando qué, por qué y cómo.
    Por otro lado, es importante que cuides las formas. No te tomes confianzas. No soy tu “coleguita de birras”, soy una profesional que está juzgando tu trabajo, por cierto, con un código de conducta bajo el brazo. Dame sólo la información necesaria, de una forma concisa.
    Y sobretodo no utilices el Readme para quejarte de algo o de alguien, para disculparte, o para explicarme tu situación personal. Estas son cosas que debes hablar con tu persona de contacto de la empresa, que es quien debe valorarlo. Si tu situación personal te ha impedido que dediques más tiempo al ejercicio, lo dicho, escribe en la lista de “To-Do” lo que habrías hecho si hubieras podido.

Haznos la vida fácil

En general, lo que se agradece es que tu ejercicio sea fácil de revisar: Fácil de entender y fácil de operar. En este aspecto, mi mayor consejo es que virtualizes tu entorno de pruebas.

Como he comentado seguramente la persona que te lo está revisando tiene poco tiempo y muchos ejercicios en la cola de espera, y es muy incómodo tener que instalarse el entorno concreto que requiera cada ejercicio.

Por eso agradezco mucho cuando una aplicación está Dockerizada, ya que trae todo el entorno preconfigurado, con las versiones necesarias, etc. Ayúdame a centrarme en tu código.

 

¡Espero que estos consejos te sirvan de utilidad en futuras oportunidades laborales! Ten en cuenta que están basados en experiencias y opiniones personales, por lo tanto, no los sigas al pie de la letra. Los ejemplos que he puesto sirven para procesos de selección en los que se valora ante todo la excelencia técnica y el seguimiento de las buenas prácticas, sin embargo puede que no te sirvan si aspiras a un puesto de Data Science o desarrollo de videojuegos, por ejemplo. Investiga siempre qué es lo que se espera de tí y cuáles son los valores de la empresa.

¿Conoces algún otro truco o consejo para superar las pruebas técnicas?

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑