Volver a Desarrollador

Desafíos de Código

Desafíos take-home reales compartidos por la comunidad — enunciados de práctica con sus requisitos y criterios de evaluación.

Componente Autocomplete en React TypeScript

Construir un componente de autocompletado completamente funcional en React con TypeScript desde cero — sin bibliotecas de terceros. El componente debe obtener/filtrar datos de forma asíncrona, resaltar el texto coincidente, manejar casos límite para una UX pulida y usar solo componentes funcionales con hooks.

Requisitos

  • Sin bibliotecas de terceros — solo React puro y APIs nativas del DOM
  • Usar TypeScript con interfaces y tipos adecuados
  • La función de filtrado de datos debe ser asíncrona (simulando una llamada REST), incluso si se usan datos mock
  • Estilo CSS básico pero decente (no se requieren efectos sofisticados)
  • Manejar todos los casos límite para una experiencia de usuario perfecta (navegación por teclado, estados vacíos, manejo de blur, condiciones de carrera, etc.)
  • Resaltar la porción coincidente del texto en las sugerencias
  • Sin gestión de estado externa — solo estado nativo de React (useState, useReducer, useContext)
  • Usar solo componentes funcionales con hooks
  • Agregar comentarios explicando atajos o hacks, indicando qué cambiaría para producción
  • Incluir un README.md explicando cómo ejecutar el proyecto
  • Bonus: cargar datos usando una llamada API real a un recurso externo

Criterios de evaluación

  • Uso correcto de TypeScript con interfaces bien definidas
  • Manejo de datos asíncronos con estados de carga/error apropiados
  • Pulido de UX: soporte de teclado, accesibilidad, debouncing
  • Estructura de código limpia y comentarios significativos
  • Implementación del resaltado de texto
  • Cobertura de casos límite

Entregables

  • Repositorio GitHub comprimido (incluyendo carpeta .git)
  • Componente de autocompletado funcional
  • README.md con instrucciones de configuración
  • Archivo questions.md con respuestas a las preguntas teóricas de la Parte 2
frontendreacttypescripthookscss

Fuente: Deel - Frontend Test.pdf

Buscador de Palabras — Desafío para Desarrollador Full-stack

Construye una aplicación web que acepte una matriz de caracteres (hasta 64×64) y una lista de palabras, busque cada palabra horizontal (de izquierda a derecha) y verticalmente (de arriba a abajo) en la matriz, y devuelva las 10 palabras encontradas con mayor frecuencia. Las entradas duplicadas en la lista de palabras se cuentan solo una vez.

Requisitos

  • Backend (C# preferido; Java/Python/ASP.NET aceptados para posiciones junior): exponer un endpoint de API que reciba la matriz de caracteres y la lista de palabras y devuelva las palabras encontradas ordenadas por frecuencia.
  • El backend debe implementar validación de entrada y devolver respuestas HTTP de error apropiadas para entradas mal formadas y errores internos.
  • Frontend (React preferido): proporcionar inputs de UI para la matriz de caracteres y la lista de palabras.
  • El frontend debe llamar al API del backend y mostrar las palabras encontradas al usuario.
  • El frontend debe manejar los fallos del API de forma elegante y mostrar un mensaje de error significativo.
  • La matriz está limitada a 64 filas × 64 columnas.
  • Las palabras repetidas en la lista de palabras de entrada deben deduplicarse antes de contar.
  • Incluir un README con instrucciones de configuración y ejecución.

Criterios de evaluación

  • Calidad de código: estructura del proyecto, limpieza, seguridad, fiabilidad y legibilidad.
  • Funcionalidad: lógica correcta de búsqueda de palabras, cumplimiento de todos los requisitos especificados.
  • Interfaz de usuario: estética, facilidad de uso y responsividad.
  • Documentación: README claro y comentarios en el código donde corresponda.
  • Esfuerzo extra: pruebas unitarias, benchmarks, funcionalidades adicionales o mejoras de UI.

Entregables

  • Código fuente enviado a través de un repositorio Git público (GitHub, GitLab, etc.) o un archivo ZIP.
  • Archivo README con todas las instrucciones necesarias para ejecutar el proyecto localmente.
fullstackalgorithmrest-apireactcsharp

Fuente: Full-stack_20Developer.pdf

Sistema Full Stack de Gestión de Notificaciones

Desarrollar un sistema básico de gestión de notificaciones para usuarios autenticados. Cada usuario debe poder crear, modificar, eliminar y consultar sus propias notificaciones, y cada notificación debe ser despachada por el canal especificado en el momento de su creación.

Requisitos

  • Registro de usuario con email y contraseña.
  • Inicio de sesión que devuelva un token de acceso; todos los endpoints deben requerir token válido.
  • Crear una notificación (campos: título, contenido, canal).
  • Modificar una notificación existente.
  • Eliminar una notificación.
  • Consultar todas las notificaciones propias del usuario autenticado.
  • Al crear una notificación, ejecutar automáticamente el envío por el canal elegido (Email, SMS o Push Notification), cada uno con su lógica específica: Email — validar formato del destinatario, generar un template, registrar el envío; SMS — limitar contenido a 160 caracteres, registrar número y fecha de envío; Push Notification — validar token de dispositivo, formatear el payload, registrar el estado del envío.
  • La arquitectura de despacho de canales debe permitir agregar un nuevo canal sin modificar la lógica de los canales existentes.
  • Usar base de datos relacional (PostgreSQL, MySQL, SQLite, etc.).
  • Exponer una API RESTful con la tecnología de backend que se prefiera.
  • Opcionalmente agregar un frontend simple para consumir los endpoints.
  • Aplicar buenas prácticas de código, arquitectura, seguridad y documentación.

Criterios de evaluación

  • Claridad y organización del código.
  • Arquitectura elegida para manejar los distintos canales de notificación y sus lógicas.
  • Correcta implementación de la autenticación y autorización.
  • Escalabilidad y mantenibilidad del sistema.
  • Uso adecuado de la base de datos.

Entregables

  • Repositorio con el código fuente.
  • README con instrucciones de instalación y ejecución.
  • Sección del README con una breve descripción de las decisiones técnicas tomadas.
fullstackrestauthstrategy-patternrelational-dbjwt

Fuente: FullStack_Challenge_Notificaciones.pdf

API REST con Cálculo de Porcentaje Dinámico

Construir una API REST en Spring Boot (Java 21) que sume dos números, aplique un porcentaje obtenido dinámicamente de un servicio externo, cachee el resultado, reintente ante fallos, registre todas las llamadas de forma asíncrona y aplique un límite de 3 requests por minuto.

Requisitos

  • Implementar un endpoint que reciba num1 y num2, obtenga un porcentaje de un servicio externo (mockeable) y retorne (num1 + num2) * (1 + porcentaje/100).
  • Cachear el porcentaje en memoria durante 30 minutos; ante fallo del servicio externo usar el valor cacheado; si no hay valor en caché retornar un error HTTP adecuado.
  • Reintentar la llamada al servicio externo hasta 3 veces antes de usar el caché o retornar un error.
  • Implementar un endpoint para consultar un historial paginado de llamadas (timestamp, endpoint, parámetros, respuesta o error) almacenado en PostgreSQL.
  • Registrar las llamadas de forma asíncrona; un fallo en el registro no debe afectar la respuesta principal.
  • Aplicar un límite de 3 RPM; retornar HTTP 429 Too Many Requests con mensaje descriptivo al superarlo.
  • Manejar globalmente todos los errores 4XX y 5XX con mensajes descriptivos.
  • Ejecutar PostgreSQL y la API en contenedores Docker orquestados con docker-compose.yml.
  • Publicar la imagen Docker en un repositorio público de Docker Hub.
  • Documentar la API con Swagger o una colección de Postman.
  • Cubrir la funcionalidad con tests unitarios incluyendo escenarios de error (fallo del servicio externo, RPM excedido).
  • Diseñar para despliegue multi-réplica; usar caché distribuido (por ejemplo, Redis) si es necesario.

Criterios de evaluación

  • Corrección del cálculo y la lógica de caché/reintentos
  • Implementación del registro asíncrono y aislamiento de fallos
  • Precisión del rate limiting y códigos de estado HTTP correctos
  • Calidad del código, separación de responsabilidades y cobertura de tests
  • Usabilidad de la configuración Docker y docker-compose
  • Completitud de la documentación de la API
  • Claridad del README: instrucciones de configuración, ejecución y prueba
  • Bonus: uso de Spring WebFlux / programación reactiva y justificación de decisiones técnicas en el README

Entregables

  • Repositorio público en GitHub con el código fuente completo
  • README.md con descripción del proyecto, instrucciones de configuración local y detalles de uso de la API
  • docker-compose.yml para iniciar la API y PostgreSQL
  • Enlace a la imagen en Docker Hub o referencia al docker-compose
  • Swagger UI o colección de Postman
backendjava21spring-bootrestpostgresqldockerredisrate-limitingcaching

Fuente: TENPO challenge java spring boot.pdf

Sistema de Gestión de Órdenes de Reparación — SPA React

Construir una aplicación de página única en React para una red de talleres automotrices. La app tiene dos vistas basadas en rol — Taller (mecánico) y Cliente — cada una protegida por un login simulado. Todo el estado se gestiona en el frontend usando mocks y se persiste en localStorage. Las reglas de negocio, las transiciones del ciclo de vida de las órdenes y los cálculos financieros deben implementarse completamente en la capa de dominio del frontend.

Requisitos

  • Implementar un login simulado basado en rol (Taller / Cliente) que proteja las rutas internas; el acceso directo sin autenticación debe redirigir al login.
  • Modelar las entidades del dominio: Customer, Vehicle, RepairOrder (con orderId, status, subtotalEstimated, authorizedAmount, realTotal, authorizations, services, events, errors, source), Service/Repair, Component, Authorization y Event.
  • Aplicar la máquina de estados completa: CREATED → DIAGNOSED → AUTHORIZED → IN_PROGRESS → COMPLETED → DELIVERED, más CANCELLED desde cualquier estado permitido.
  • Restringir la edición de servicios y refacciones a los estados CREATED y DIAGNOSED; generar NOT_ALLOWED_AFTER_AUTHORIZATION para intentos posteriores.
  • En la autorización (DIAGNOSED → AUTHORIZED): requerir al menos un servicio, calcular authorizedAmount = subtotalEstimado × 1.16 (2 decimales); emitir NO_SERVICES si no hay servicios válidos.
  • Implementar la regla de sobrecosto del 110 %: si realTotal > authorizedAmount × 1.10 mover la orden a WAITING_FOR_APPROVAL y emitir REQUIRES_REAUTH; la igualdad permite continuar el flujo.
  • Soportar reautorización desde WAITING_FOR_APPROVAL: registrar una nueva Autorización, actualizar authorizedAmount, agregar un Evento de reautorización y regresar la orden a AUTHORIZED.
  • Vista Taller: listado de órdenes (filtrable por estado, buscable por orderId o cliente), detalle de orden (servicios, refacciones, resumen financiero, historial de eventos, errores de negocio, botones de acción por estado) y formulario de alta de nueva orden.
  • Vista Cliente: listado de propias órdenes con indicadores de acción, detalle en lenguaje claro, aceptar/rechazar propuesta, aceptar reautorización, solicitar nueva reparación (origin=CLIENTE).
  • Sembrar datos de ejemplo con estados variados en la primera carga si localStorage está vacío; persistir cada mutación en localStorage; hidratar correctamente al recargar la página.
  • Implementar diseño responsive mobile-first; las tablas deben colapsar o adaptarse en pantallas pequeñas.
  • Separar la lógica de negocio de la UI: capa de dominio (funciones/clases puras), capa de estado (hooks/reducers), capa de persistencia (adaptadores localStorage), capa de presentación (componentes).

Criterios de evaluación

  • Corrección y completitud de todas las reglas de negocio y transiciones de estado (40 %).
  • Calidad del código: separación de responsabilidades, principios SOLID, estructura modular por dominio — orders, clients, auth, shared (40 %).
  • Pruebas unitarias que cubran transiciones de estado, cálculos financieros, lógica de sobrecosto y comportamiento de rutas protegidas (10 %).
  • Manejo de errores y trazabilidad: registro claro de errores de negocio, estados de error no bloqueantes, historial de eventos legible para ambos roles (10 %).

Entregables

  • Código fuente completo de la SPA en React.
  • Pruebas unitarias de lógica de dominio y guardias de rutas.
  • README con instrucciones de configuración/ejecución y explicación del diseño arquitectónico.
  • (Opcional) Diagrama UML o descripción de arquitectura.
frontendreactspalocalstoragestate-machinerole-based-authresponsive

Fuente: Technical Evaluation.pdf