Small timebox
The design had to be understandable and complete within the scope of a short technical assessment.
Case Study · International Engineering Assessment
Fullstack Calculator
A deliberately small full-stack assessment where the real engineering work was deciding what not to build, separating responsibilities, validating behavior and using AI without outsourcing judgment.
2–4htechnical assessment scope
1REST calculation endpoint
4required operations
3CI jobs across backend, frontend and integration
01 / Context
Context
The project was built for a Junior Software Engineer technical assessment. The visible requirement was simple: a calculator with a React interface and a Go API. The engineering goal was broader: produce a solution that was correct, readable, testable and easy to explain inside a deliberately small timebox.
02 / The real challenge
The real challenge
A calculator is easy to overengineer because almost any architectural pattern can be justified in theory. The harder decision was to keep only the structure that improved correctness and testability while resisting frameworks, abstractions and features that did not solve a requirement.
03 / Constraints that shaped the solution
Constraints that shaped the solution
Full-stack boundary
Frontend and backend needed a clean contract without adding infrastructure that the exercise did not require.
Quality evidence
The result needed tests, type checking, builds and integration verification rather than relying on manual demonstration.
AI-assisted workflow
AI was allowed, but generated suggestions still had to be reviewed, adapted and validated before inclusion.
04 / Small architecture, explicit boundaries
Small architecture, explicit boundaries
Each layer has one obvious responsibility. The design stays intentionally boring in the best sense: there is little hidden behavior and every boundary can be tested independently.
React UI
Local component state owns inputs, operation selection, loading state and user feedback.
Frontend API client
A small TypeScript module isolates the POST request and maps API or network failures into user-facing errors.
Go HTTP layer
The handler owns routing, strict JSON decoding, validation, status codes and response serialization.
Calculator domain
Pure calculation rules live outside HTTP and expose explicit domain errors for invalid operations and results.
Development proxy
The frontend calls a relative /api path while Vite proxies requests to the Go server during development.
Quality pipeline
GitHub Actions verifies backend, frontend and the complete development path before changes are considered healthy.
05 / Deliberate trade-offs
Deliberate trade-offs
The strongest decisions in the project are the missing dependencies and abstractions.
One endpoint
POST /api/calculate handles every required operation through one explicit request contract.
Go standard library
net/http and encoding/json are enough for a single endpoint, so a backend framework would add weight without value.
React local state
One form does not need a global state-management library.
No Docker
Go and Node already provide a direct local setup; containers would solve a problem the assessment did not have.
Required scope only
Optional calculator features were intentionally excluded so effort stayed on correctness and engineering quality.
No coverage theater
Coverage commands exist, but the design favors meaningful behavioral confidence over chasing an arbitrary percentage.
06 / TESTING
Testing strategy
The backend tests the calculation domain independently from HTTP, including all four operations, division by zero, unsupported operations and non-finite values. HTTP tests then verify successful requests, malformed or incomplete payloads, unknown fields and method handling. On the frontend, Testing Library and Vitest exercise user behavior, validation before network calls, successful results, backend errors and network failures.
07 / CI
CI validates the system at three levels
The pipeline mirrors the architecture instead of collapsing everything into one generic build job.
Backend
Checks Go formatting, runs tests with coverage output and builds the server.
Frontend
Installs dependencies, runs strict TypeScript checking, behavioral tests, coverage and the production build.
Integration
Starts both development servers, verifies the Go endpoint directly, then repeats the request through Vite's /api proxy and expects 6 × 7 = 42.
08 / AI-ASSISTED DEVELOPMENT
AI-assisted, human-controlled
AI was used across planning, architecture, implementation, testing, documentation and review. Meaningful prompts are preserved in the public repository. The important rule was ownership: suggestions were not accepted because they came from an AI tool; they were reviewed against the requirements, adapted where necessary and then validated by tests and builds.
09 / What the repository proves
What the repository proves
The result is intentionally more valuable as engineering evidence than as a calculator.
Inspectable engineering
Architecture, source code, tests, technical design, CI and AI prompt history can all be reviewed directly.
Explicit contracts
TypeScript strict checking, strict JSON decoding and typed domain errors reduce ambiguous behavior across the stack.
Testable boundaries
Domain logic, HTTP concerns, API communication and UI behavior can be reasoned about independently.
Automated validation
The repository does not depend on a one-time demo: GitHub Actions rebuilds and revalidates the solution on changes.
10 / LESSONS
What this project reinforced
- Good engineering in a small system is mostly restraint: every abstraction should earn its place.
- Separating domain logic from transport logic makes both testing and explanation dramatically easier.
- An integration smoke test can catch wiring problems that isolated backend and frontend test suites cannot see.
- AI-assisted development is strongest when prompts, constraints, review and automated validation form one workflow.
Engineering stack
Gonet/httpReact 18TypeScriptViteVitestTesting LibraryGitHub ActionsAI-Assisted Development