Back to Developer

Coding Challenges

Real take-home assignments shared by the community — practice prompts with their requirements and evaluation criteria.

React TypeScript Autocomplete Component

Build a fully functional autocomplete component in React with TypeScript from scratch — no third-party libraries allowed. The component must fetch/filter data asynchronously, highlight matching text, handle edge cases for a polished UX, and use only functional components with hooks.

Requirements

  • No third-party libraries — only pure React and native DOM APIs
  • Use TypeScript with proper interfaces and types
  • Data filtering function must be asynchronous (simulating a REST call), even if using mock data
  • Basic but decent CSS styling (no fancy effects required)
  • Handle all edge cases for a perfect user experience (keyboard navigation, empty states, blur handling, race conditions, etc.)
  • Highlight the matching portion of text in suggestions
  • No external state management — only native React state (useState, useReducer, useContext)
  • Use only functional components with hooks
  • Add comments explaining any shortcuts or hacks, noting what would change for production
  • Include a README.md explaining how to run the project
  • Bonus: load data using a real API call to an external resource

Evaluation criteria

  • Correct TypeScript usage with well-defined interfaces
  • Async data handling with proper loading/error states
  • UX polish: keyboard support, accessibility, debouncing
  • Clean code structure and meaningful comments
  • Text highlighting implementation
  • Edge case coverage

Deliverables

  • Zipped GitHub repository (including .git folder)
  • Working autocomplete component
  • README.md with setup instructions
  • questions.md file with answers to Part 2 theory questions
frontendreacttypescripthookscss

Source: Deel - Frontend Test.pdf

Word Finder — Full-stack Developer Challenge

Build a web application that accepts a character matrix (up to 64×64) and a word list, searches for each word horizontally (left to right) and vertically (top to bottom) in the matrix, and returns the top 10 most-found words. Duplicate entries in the word list count only once.

Requirements

  • Backend (C# preferred; Java/Python/ASP.NET accepted for junior roles): expose an API endpoint that receives the character matrix and word list and returns the matched words ranked by frequency.
  • Backend must implement input validation and return appropriate HTTP error responses for malformed input and internal errors.
  • Frontend (React preferred): provide UI inputs for the character matrix and the word list.
  • Frontend must call the backend API and display the found words to the user.
  • Frontend must handle API failures gracefully and display a meaningful error message.
  • Matrix is limited to 64 rows × 64 columns.
  • Words repeated in the input word list must be deduplicated before counting.
  • Include a README with setup and run instructions.

Evaluation criteria

  • Code quality: project structure, cleanliness, security, reliability, and readability.
  • Functionality: correct word search logic, adherence to all specified requirements.
  • User interface: aesthetics, user-friendliness, and responsiveness.
  • Documentation: clear README and inline comments where appropriate.
  • Extra effort: unit tests, benchmarks, additional features, or UI improvements.

Deliverables

  • Source code submitted via a public Git repository (GitHub, GitLab, etc.) or a ZIP archive.
  • README file with all instructions needed to run the project locally.
fullstackalgorithmrest-apireactcsharp

Source: Full-stack_20Developer.pdf

Full Stack Notification Management System

Build a basic notification management system for authenticated users. Each user must be able to create, update, delete, and list their own notifications, and each notification must be dispatched through the specified channel upon creation.

Requirements

  • User registration with email and password.
  • User login that returns an access token; all endpoints must require a valid token.
  • Create a notification (fields: title, content, channel).
  • Update an existing notification.
  • Delete a notification.
  • List all notifications belonging to the authenticated user.
  • On creation, automatically dispatch the notification through the chosen channel (Email, SMS, or Push Notification), each with its own specific logic: Email — validate recipient format, generate a template, log the send; SMS — limit content to 160 characters, log number and send date; Push Notification — validate device token, format the payload, log send status.
  • The channel dispatch architecture must allow adding a new channel without modifying existing channel logic.
  • Use a relational database (PostgreSQL, MySQL, SQLite, etc.).
  • Expose a RESTful API using any backend technology of your choice.
  • Optionally add a simple frontend to consume the endpoints.
  • Apply best practices in code quality, architecture, security, and documentation.

Evaluation criteria

  • Clarity and organisation of the code.
  • Architecture chosen to handle the different notification channels and their dispatch logic.
  • Correct implementation of authentication and authorisation.
  • Scalability and maintainability of the system.
  • Appropriate use of the relational database.

Deliverables

  • Source code repository.
  • README with installation and execution instructions.
  • README section with a brief description of the technical decisions made.
fullstackrestauthstrategy-patternrelational-dbjwt

Source: FullStack_Challenge_Notificaciones.pdf

REST API with Dynamic Percentage Calculation

Build a Spring Boot REST API (Java 21) that sums two numbers, applies a dynamically fetched percentage from an external service, caches the result, retries on failure, logs all calls asynchronously, and enforces a rate limit of 3 requests per minute.

Requirements

  • Implement a POST/GET endpoint that receives num1 and num2, fetches a percentage from a (mockable) external service, and returns (num1 + num2) * (1 + percentage/100).
  • Cache the fetched percentage in memory for 30 minutes; on external-service failure use the cached value; if no cached value exists return an appropriate HTTP error.
  • Retry the external service call up to 3 times before falling back to cache or returning an error.
  • Implement an endpoint to retrieve a paginated call history (timestamp, endpoint, parameters, response or error) stored in PostgreSQL.
  • Write call history asynchronously; a logging failure must not affect the main endpoint response.
  • Enforce a rate limit of 3 RPM; return HTTP 429 Too Many Requests with a descriptive message when exceeded.
  • Handle all 4XX and 5XX errors globally with descriptive messages.
  • Run PostgreSQL and the API in Docker containers orchestrated with docker-compose.yml.
  • Publish the Docker image to a public Docker Hub repository.
  • Document the API with Swagger or a Postman collection.
  • Cover functionality with unit tests including error scenarios (external service failure, RPM exceeded).
  • Design for multi-replica deployment; use a distributed cache (e.g., Redis) if needed.

Evaluation criteria

  • Correctness of the calculation and cache/retry logic
  • Asynchronous logging implementation and fault isolation
  • Rate limiting accuracy and proper HTTP status codes
  • Code quality, separation of concerns, and test coverage
  • Docker and docker-compose setup usability
  • API documentation completeness
  • README clarity: setup, run, and test instructions
  • Bonus: use of Spring WebFlux / reactive programming and technical decision justification in README

Deliverables

  • Public GitHub repository with full source code
  • README.md with project description, local setup instructions, and API usage details
  • docker-compose.yml to start API and PostgreSQL
  • Docker Hub image link or docker-compose reference
  • Swagger UI or Postman collection
backendjava21spring-bootrestpostgresqldockerredisrate-limitingcaching

Source: TENPO challenge java spring boot.pdf

Repair Order Management System — React SPA

Build a single-page application in React for a vehicle repair-shop network. The app has two role-based views — Workshop (mechanic) and Client — each protected by a simulated login. All state is managed in the frontend using mocks and persisted in localStorage. Business rules, order lifecycle transitions, and financial calculations must be implemented entirely in the frontend domain layer.

Requirements

  • Implement a simulated role-based login (Workshop / Client) that protects internal routes; unauthenticated direct access must redirect to login.
  • Model the domain entities: Customer, Vehicle, RepairOrder (with orderId, status, subtotalEstimated, authorizedAmount, realTotal, authorizations, services, events, errors, source), Service/Repair, Component, Authorization, and Event.
  • Enforce the full order status machine: CREATED → DIAGNOSED → AUTHORIZED → IN_PROGRESS → COMPLETED → DELIVERED, plus CANCELLED from any permitted state.
  • Restrict service and component edits to CREATED and DIAGNOSED states; generate NOT_ALLOWED_AFTER_AUTHORIZATION for later attempts.
  • On authorization (DIAGNOSED → AUTHORIZED): require at least one service, compute authorizedAmount = subtotalEstimated × 1.16 (2 decimal places); emit NO_SERVICES if no valid services exist.
  • Implement the 110% cost-overrun rule: if realTotal > authorizedAmount × 1.10 move order to WAITING_FOR_APPROVAL and emit REQUIRES_REAUTH; equality allows the flow to continue.
  • Support re-authorization from WAITING_FOR_APPROVAL: record a new Authorization, update authorizedAmount, append a reauthorization Event, and return the order to AUTHORIZED.
  • Workshop view: order list (filterable by status, searchable by orderId or client), order detail (services, components, financial summary, event history, business errors, state-action buttons), and new-order creation form.
  • Client view: own-orders list with action indicators, order detail in plain language, accept/reject repair proposal, accept re-authorization, submit a new repair request (source=CLIENTE).
  • Seed sample data with varied statuses on first load if localStorage is empty; persist every mutation to localStorage; hydrate correctly on page refresh.
  • Implement mobile-first responsive design; tables must collapse or adapt on small screens.
  • Separate business logic from UI: domain layer (pure functions/classes), state layer (hooks/reducers), persistence layer (localStorage adapters), presentation layer (components).

Evaluation criteria

  • Correctness and completeness of all business rules and state transitions (40%).
  • Code quality: separation of concerns, SOLID principles, domain-driven module structure — orders, clients, auth, shared (40%).
  • Unit tests covering state transitions, financial calculations, cost-overrun logic, and protected-route behaviour (10%).
  • Error handling and traceability: clear business-error recording, non-breaking error states, readable event history for both roles (10%).

Deliverables

  • Full source code of the React SPA.
  • Unit tests for domain logic and route guards.
  • README with setup/run instructions and an explanation of the architectural design.
  • (Optional) UML diagram or architecture description.
frontendreactspalocalstoragestate-machinerole-based-authresponsive

Source: Technical Evaluation.pdf