Cómo planear una prueba técnica frontend

Resolver una prueba técnica frontend exige más que escribir código: requiere entender el proyecto base, traducir los issues en tareas concretas y planear la solución antes de tocar el editor. Si estás aplicando a un puesto de desarrollo y te enfrentas a un reto técnico tipo Shoppy, este recorrido te muestra cómo abordarlo con criterio profesional.

¿Qué debes revisar antes de empezar una prueba técnica?

Antes de escribir una sola línea, necesitas dos cosas: comprender el proyecto y entender qué te están pidiendo.

La empresa Shoppy entrega un repositorio con cuatro issues que funcionan como objetivos generales: maquetar las vistas de usuario, crear un navbar dinámico, implementar protección de rutas y manejar la sesión del usuario. Esos issues son el norte, pero rara vez vienen detallados al milímetro.

Tu trabajo es desglosarlos. Clona el repositorio, navega el código y revisa la documentación que viene en la cajita de recursos. Solo así vas a saber qué piezas ya existen y cuáles tienes que construir desde cero.

¿Qué es un issue en una prueba técnica? Es una tarea u objetivo que la empresa deja en el repositorio para que tú lo resuelvas. Suele describir el qué, no el cómo, así que tú defines la estrategia.

¿Cómo identificar los detalles que marcan la diferencia?

Una prueba técnica se gana en los detalles. Aquí es donde demuestras que eres detallista y que piensas como desarrollador profesional.

En el proyecto base de Shoppy, por ejemplo, el botón sign out llevaba a una página en blanco y la ruta estaba mal escrita: decía algo parecido a decantar en lugar de sign in. Ese tipo de bugs pequeños son oro para ti, porque arreglarlos suma puntos sin que nadie te los haya pedido.

Otros comportamientos que debes mapear desde el inicio:

• Si el usuario ya se logueó antes, sus datos de email y password aparecen prellenados en el formulario.
• Cuando el usuario está autenticado, puede filtrar productos por categorías como clothes o electronics y entrar a my orders o my account.
• Si no está logueado, el navbar cambia y los clics en secciones protegidas no permiten el acceso.
• Si no tiene cuenta, aparece un botón secundario que lo lleva al flujo de registro.

Tomar nota de cada una de estas reglas te da el verdadero backlog de la prueba.

¿Cómo funciona la sesión con local storage?

La autenticación en este proyecto se maneja con local storage, y entender esa lógica es clave para resolver el reto.

Al inspeccionar el navegador en la pestaña application, encuentras dos keys importantes: una llamada sign out con valor true, que indica que el usuario está fuera de la aplicación, y otra llamada account que guarda los datos del usuario.

Si eliminas manualmente la key de account y recargas, la app debe entender que no hay usuario y deshabilitar el botón de login. Cuando el usuario se registra con datos nuevos, por ejemplo tef@platzi.com con password 123123, esa información tiene que persistir nuevamente en local storage.

¿Qué es local storage y para qué sirve en autenticación? Es un almacenamiento del navegador que guarda datos como pares clave-valor. Sirve para mantener la sesión del usuario entre recargas sin depender del servidor.

¿Por qué planear es más importante que codear?

Uno de los errores más comunes entre desarrolladores es creer que lo más importante es escribir código. No lo es. Lo más importante es planear bien, establecer una solución y después llegar a ella con el código.

En este reto, aunque la empresa dejó solo cuatro issues, la solución real se desglosó en 10 pull requests. Cada pull request representa un paso pequeño y verificable hacia el resultado final. Esa granularidad ayuda a revisar el trabajo, a mantener el código limpio y a que tus commits cuenten una historia clara.

Buenas prácticas que evalúan en una prueba técnica:

• Código limpio y legible.
• Commits bien escritos que describan el cambio.
• Un README que explique cómo correr y entender el proyecto.
• Pull requests pequeños y enfocados.

¿Cómo gestionar el tiempo en dos días de prueba técnica?

Normalmente una prueba técnica te da dos días. Es trabajo bajo presión, así que la planeación también incluye estimar tiempos por tarea.

Una vez tengas el paso a paso desglosado, asigna una duración aproximada a cada bloque: dos horas para maquetar, tres horas para la lógica de sesión, una hora para el navbar dinámico, y así sucesivamente. Sumar esos tiempos te dice si llegas o si necesitas recortar alcance.

Y aquí va el reto para ti: arriésgate a diseñar tu propia solución. ¿Cómo harías para que la aplicación distinga entre un usuario logueado, deslogueado, con cuenta y sin cuenta? ¿Cómo conectarías ese estado con el navbar y con la protección de rutas? Cuéntame en los comentarios tu paso a paso antes de ver la solución completa en los siguientes materiales.