Tillbaka till Utvecklare

Kodutmaningar

Riktiga take-home-uppgifter delade av communityn — övningsuppgifter med krav och bedömningskriterier.

React TypeScript Autocomplete-komponent

Bygg en fullt fungerande autocomplete-komponent i React med TypeScript från grunden — inga tredjepartsbibliotek tillåtna. Komponenten måste hämta/filtrera data asynkront, markera matchande text, hantera edge cases för en polerad UX och använda enbart funktionella komponenter med hooks.

Krav

  • Inga tredjepartsbibliotek — bara ren React och inbyggda DOM-API:er
  • Använd TypeScript med korrekta interfaces och typer
  • Datafiltreringsfunktionen måste vara asynkron (simulera ett REST-anrop), även vid användning av mockdata
  • Grundläggande men snygg CSS-styling (inga avancerade effekter krävs)
  • Hantera alla edge cases för en perfekt användarupplevelse (tangentbordsnavigering, tomma tillstånd, blur-hantering, race conditions, etc.)
  • Markera den matchande delen av texten i förslagen
  • Ingen extern state management — bara inbyggt React-state (useState, useReducer, useContext)
  • Använd enbart funktionella komponenter med hooks
  • Lägg till kommentarer som förklarar genvägar eller hack och anger vad som skulle ändras för produktion
  • Inkludera en README.md som förklarar hur projektet körs
  • Bonus: ladda data med ett riktigt API-anrop till en extern resurs

Bedömningskriterier

  • Korrekt TypeScript-användning med väldefinierade interfaces
  • Asynkron datahantering med korrekta laddnings-/feltillstånd
  • UX-polish: tangentbordsstöd, tillgänglighet, debouncing
  • Ren kodstruktur och meningsfulla kommentarer
  • Implementation av textmarkering
  • Täckning av edge cases

Leverabler

  • Zippad GitHub-repository (inklusive .git-mappen)
  • Fungerande autocomplete-komponent
  • README.md med installationsinstruktioner
  • questions.md-fil med svar på del 2:s teorifrågor
frontendreacttypescripthookscss

Källa: Deel - Frontend Test.pdf

Ordsökare — Full-stack Utvecklar-utmaning

Bygg en webbapplikation som tar emot en teckenmatris (upp till 64×64) och en ordlista, söker efter varje ord horisontellt (vänster till höger) och vertikalt (uppifrån och ned) i matrisen, och returnerar de 10 mest funna orden. Dubblettinlägg i ordlistan räknas bara en gång.

Krav

  • Backend (C# föredraget; Java/Python/ASP.NET accepteras för juniorroller): exponera ett API-endpoint som tar emot teckenmatrisen och ordlistan och returnerar matchade ord rankade efter frekvens.
  • Backend måste implementera indatavalidering och returnera lämpliga HTTP-felsvar för felformaterad indata och interna fel.
  • Frontend (React föredraget): tillhandahåll UI-inmatningar för teckenmatrisen och ordlistan.
  • Frontend måste anropa backend-API:et och visa de hittade orden för användaren.
  • Frontend måste hantera API-fel på ett elegant sätt och visa ett meningsfullt felmeddelande.
  • Matrisen är begränsad till 64 rader × 64 kolumner.
  • Ord som upprepas i indataordlistan måste avdupliceras innan räkning.
  • Inkludera en README med installations- och körningsinstruktioner.

Bedömningskriterier

  • Kodkvalitet: projektstruktur, renhet, säkerhet, tillförlitlighet och läsbarhet.
  • Funktionalitet: korrekt ordsökningslogik, efterlevnad av alla specificerade krav.
  • Användargränssnitt: estetik, användarvänlighet och responsivitet.
  • Dokumentation: tydlig README och inline-kommentarer där det är lämpligt.
  • Extra insats: enhetstester, benchmarks, ytterligare funktioner eller UI-förbättringar.

Leverabler

  • Källkod inlämnad via ett offentligt Git-förvar (GitHub, GitLab, etc.) eller ett ZIP-arkiv.
  • README-fil med alla instruktioner som behövs för att köra projektet lokalt.
fullstackalgorithmrest-apireactcsharp

Källa: Full-stack_20Developer.pdf

Full Stack-system för Notifieringshantering

Bygg ett grundläggande notifieringshanteringssystem för autentiserade användare. Varje användare ska kunna skapa, uppdatera, ta bort och lista sina egna notifieringar, och varje notifiering ska dispatchas via angiven kanal vid skapandet.

Krav

  • Användarregistrering med e-post och lösenord.
  • Inloggning som returnerar en åtkomsttoken; alla endpoints måste kräva giltig token.
  • Skapa en notifiering (fält: titel, innehåll, kanal).
  • Uppdatera en befintlig notifiering.
  • Ta bort en notifiering.
  • Lista alla notifieringar som tillhör den autentiserade användaren.
  • Vid skapandet, automatiskt dispatcha notifieringen via vald kanal (Email, SMS eller Push Notification), var och en med sin specifika logik: Email — validera mottagarens format, generera en template, logga sändningen; SMS — begränsa innehållet till 160 tecken, logga nummer och sändningsdatum; Push Notification — validera enhetstoken, formatera payload, logga sändningsstatus.
  • Kanalens dispatch-arkitektur måste tillåta att en ny kanal läggs till utan att befintlig kanallogik ändras.
  • Använd en relationsdatabas (PostgreSQL, MySQL, SQLite, etc.).
  • Exponera ett RESTful API med valfri backend-teknik.
  • Lägg eventuellt till ett enkelt frontend för att konsumera endpoints.
  • Tillämpa bästa praxis gällande kodkvalitet, arkitektur, säkerhet och dokumentation.

Bedömningskriterier

  • Tydlighet och organisation i koden.
  • Vald arkitektur för att hantera de olika notifieringskanalerna och deras dispatch-logik.
  • Korrekt implementering av autentisering och auktorisering.
  • Systemets skalbarhet och underhållbarhet.
  • Ändamålsenlig användning av relationsdatabasen.

Leverabler

  • Källkodsrepository.
  • README med installations- och körningsinstruktioner.
  • README-avsnitt med en kort beskrivning av de tekniska beslut som fattats.
fullstackrestauthstrategy-patternrelational-dbjwt

Källa: FullStack_Challenge_Notificaciones.pdf

REST API med Dynamisk Procentberäkning

Bygg ett Spring Boot REST API (Java 21) som summerar två tal, applicerar en dynamiskt hämtad procentsats från en extern tjänst, cachar resultatet, gör retries vid fel, loggar alla anrop asynkront och tillämpar en hastighetsgräns på 3 requests per minut.

Krav

  • Implementera ett endpoint som tar emot num1 och num2, hämtar en procentsats från en (mockbar) extern tjänst och returnerar (num1 + num2) * (1 + procentsats/100).
  • Cacha den hämtade procentsatsen i minnet i 30 minuter; vid fel i den externa tjänsten används det cachade värdet; om inget cachat värde finns returneras ett lämpligt HTTP-fel.
  • Försök anropa den externa tjänsten upp till 3 gånger innan fallback till cache eller felavkastning.
  • Implementera ett endpoint för att hämta en paginerad anropshistorik (tidsstämpel, endpoint, parametrar, svar eller fel) lagrad i PostgreSQL.
  • Logga anrop asynkront; ett loggningsfel får inte påverka huvudendpointens svar.
  • Tillämpa en gräns på 3 RPM; returnera HTTP 429 Too Many Requests med ett beskrivande meddelande när gränsen överskrids.
  • Hantera alla 4XX- och 5XX-fel globalt med beskrivande meddelanden.
  • Kör PostgreSQL och API:et i Docker-containers orkestrerade med docker-compose.yml.
  • Publicera Docker-imagen till ett publikt Docker Hub-repository.
  • Dokumentera API:et med Swagger eller en Postman-samling.
  • Täck funktionaliteten med enhetstester inklusive felscenarier (extern tjänst misslyckas, RPM överskrids).
  • Designa för multi-replika-driftsättning; använd distribuerat cache (t.ex. Redis) vid behov.

Bedömningskriterier

  • Korrekthet i beräkning och cache/retry-logik
  • Implementation av asynkron loggning och felisolering
  • Noggrannhet i rate limiting och korrekta HTTP-statuskoder
  • Kodkvalitet, separation av ansvar och testtäckning
  • Användbarhet av Docker- och docker-compose-konfigurationen
  • Fullständighet i API-dokumentationen
  • Tydlighet i README: installations-, körnings- och testinstruktioner
  • Bonus: användning av Spring WebFlux / reaktiv programmering och motivering av tekniska beslut i README

Leverabler

  • Publikt GitHub-repository med fullständig källkod
  • README.md med projektbeskrivning, instruktioner för lokal installation och API-användningsdetaljer
  • docker-compose.yml för att starta API och PostgreSQL
  • Docker Hub-imagelänk eller docker-compose-referens
  • Swagger UI eller Postman-samling
backendjava21spring-bootrestpostgresqldockerredisrate-limitingcaching

Källa: TENPO challenge java spring boot.pdf

Reparationsorderhanteringssystem — React SPA

Bygg en single-page application i React för ett nätverk av bilverkstäder. Appen har två rollbaserade vyer — Verkstad (mekaniker) och Kund — vardera skyddade av en simulerad inloggning. Allt tillstånd hanteras i frontend med mocks och persisteras i localStorage. Affärsregler, orderlivscykelovergångar och finansiella beräkningar måste implementeras helt i frontend-domänlagret.

Krav

  • Implementera en simulerad rollbaserad inloggning (Verkstad / Kund) som skyddar interna rutter; direkt åtkomst utan autentisering ska omdirigera till inloggning.
  • Modellera domänentiteterna: Customer, Vehicle, RepairOrder (med orderId, status, subtotalEstimated, authorizedAmount, realTotal, authorizations, services, events, errors, source), Service/Repair, Component, Authorization och Event.
  • Tillämpa den fullständiga tillståndsmaskinen: CREATED → DIAGNOSED → AUTHORIZED → IN_PROGRESS → COMPLETED → DELIVERED, plus CANCELLED från valfritt tillåtet tillstånd.
  • Begränsa redigering av tjänster och komponenter till tillstånden CREATED och DIAGNOSED; generera NOT_ALLOWED_AFTER_AUTHORIZATION vid senare försök.
  • Vid auktorisering (DIAGNOSED → AUTHORIZED): kräv minst en tjänst, beräkna authorizedAmount = subtotalEstimated × 1.16 (2 decimaler); emittera NO_SERVICES om inga giltiga tjänster finns.
  • Implementera 110%-kostnadsöverskridningsregeln: om realTotal > authorizedAmount × 1.10 flytta ordern till WAITING_FOR_APPROVAL och emittera REQUIRES_REAUTH; likhet tillåter flödet att fortsätta.
  • Stödja omauktorisering från WAITING_FOR_APPROVAL: registrera en ny Authorization, uppdatera authorizedAmount, lägg till en omauktoriserings-Event och returnera ordern till AUTHORIZED.
  • Verkstadsvy: orderlista (filtrerbar efter status, sökbar på orderId eller kund), orderdetalj (tjänster, komponenter, ekonomisk sammanfattning, händelsehistorik, affärsfel, åtgärdsknappar per tillstånd) och formulär för att skapa ny order.
  • Kundvy: lista över egna ordrar med åtgärdsindikatorer, orderdetalj på klarspråk, acceptera/avvisa förslag, acceptera omauktorisering, begära ny reparation (source=CLIENTE).
  • Seed exempeldata med varierade tillstånd vid första laddning om localStorage är tomt; persistera varje mutation till localStorage; hydrera korrekt vid sidomladdning.
  • Implementera mobile-first responsiv design; tabeller ska kollapsa eller anpassas på små skärmar.
  • Separera affärslogik från UI: domänlager (rena funktioner/klasser), tillståndslager (hooks/reducers), persistenslager (localStorage-adaptrar), presentationslager (komponenter).

Bedömningskriterier

  • Korrekthet och fullständighet hos alla affärsregler och tillståndsövergångar (40 %).
  • Kodkvalitet: ansvarsseparation, SOLID-principer, domändriven modulstruktur — orders, clients, auth, shared (40 %).
  • Enhetstester som täcker tillståndsövergångar, finansiella beräkningar, kostnadsöverskridningslogik och skyddade rutters beteende (10 %).
  • Felhantering och spårbarhet: tydlig registrering av affärsfel, icke-blockerande feltillstånd, läsbar händelsehistorik för båda rollerna (10 %).

Leverabler

  • Fullständig källkod för React SPA:n.
  • Enhetstester för domänlogik och routeguards.
  • README med installations-/körningsinstruktioner och förklaring av arkitekturdesignen.
  • (Valfritt) UML-diagram eller arkitekturbeskrivning.
frontendreactspalocalstoragestate-machinerole-based-authresponsive

Källa: Technical Evaluation.pdf