Kiosk - Lead Developer Case Study

This exercise is a technical case study for a Lead Developer position.
It is inspired by a real feature of our ESG/CSRD reporting product.

How to run the project

You may run the project using Docker:

docker build -t kiosk .
docker run -d -p 3000:3000 kiosk:latest

Linting and testing

To check linting and typing:

npx eslint
npx prettier --write .
npx tsc

To run tests:

npx vitest

Architecture

The project architecture is intentionally kept simple and explicit:

• Components focus on rendering and are split into small, reusable units;
• Stores are responsible for state management;
• Services encapsulate business logic and data processing;
• The app layer owns routing, API routes, and the homepage.

This separation helps keep concerns isolated and makes the codebase easier to reason about and extend.

Technical choices

The JS stack required for this project is not my primary ecosystem. I therefore approached this exercise focusing on architecture, data flow, functionality and code maintainability rather than focusing on exhaustivity.

This influenced some trade-offs which I've documented below along with the improvements I would prioritize in a production context.

• Next.js was chosen for its robust routing and layout system, as well as its clear server/client separation. Core logic is implemented using standard React patterns without relying on framework-specific abstractions where unnecessary.
• Zustand is used for state management as a lightweight alternative to Redux. For the scope of this case study, Redux would have introduced unnecessary complexity and boilerplate.
• The DSN parser provided by La Societe Nouvelle was reused with minor adaptations (notably to extract additional values) instead of reinventing the wheel. This decision saved time but required relaxing TypeScript constraints in that file. For a production system, this parser would deserve a thorough refactor with stricter typing and validation.
• Not all responses are automatically computed from the DSN file. Given the limited time frame, priority was given to core flows rather than exhaustive coverage.
• Testing was intentionally kept minimal and focused on the most complex component and the state store. In a production context, I would work on broader coverage (incuding integration and edge-case testing).
• Styling is handled with Tailwind CSS, which integrates well with Next.js and allows for rapid iteration with minimal configuration.
• Exporting data as JSON was preferred over Word to keep the export logic simple and focused on the data itself rather than document formatting, which felt secondary for this exercise.
• The logic used to generate responses from the uploaded DSN could be more flexible and business-driven. This is partly due to limited domain knowledge, I would be happy to delve into it deeper.
• For simplicity, the application is currently fixed to French.

AI was used as a pair-programming buddy when I could not find the solution to an issue using the good old StackOverflow. It also helped me with CSS and typing, helping improve development speed without replacing design or architectural decisions (or actual code writing).

Future improvements

• More tests! Increase test coverage, + integration tests and more exploration of edge case scenarios;
• Refactor the DSN parsing logic to improve typing robustness and better handle imperfect or partial data;
• Rework the response generation logic to better reflect business rules and improve flexibility;
• Add a button letting the user select their preferred language;
• Make the export a .docx document instead of JSON;
• Better styling and a more pleasant UI (but I will admit this is not my strong suit).