Estimated time: 3–4 hours
Deadline: You have 72 hours from receiving this link
Delivery: Fork this repo, push your solution, and send us the link
A startup built an MVP using an AI-powered tool (Lovable). The product got traction fast — it went from 10 to 10,000 users in 6 weeks. The codebase works, but it was never designed to handle real production traffic, real security requirements, or real scale.
Your job: step in as the backend engineer responsible for stabilizing, securing, and preparing this codebase for production. This is the exact type of work you'd be doing from day one on this team.
The code is intentionally broken in realistic ways — the kind of issues you'd actually find in AI-generated MVPs. There are no trick questions.
src/
routes/ → API endpoints (Express)
middleware/ → Auth, error handling, validation
models/ → DB access layer
services/ → Business logic
config/ → App configuration
migrations/ → SQL schema files
tests/ → Test files (mostly empty — that's intentional)
docs/ → Your written answers go here
scripts/ → Utility scripts
There are 4 exercises. Do them in order — each one builds context for the next.
| # | Exercise | Focus | Points |
|---|---|---|---|
| 1 | Code Review & Fixes | Security, correctness | 25 |
| 2 | Authentication System | Auth, JWT, sessions | 25 |
| 3 | Database & Performance | Schema, queries, indexes | 25 |
| 4 | Architecture & Scale | Async, queues, resilience | 25 |
Total: 100 points. Pass: 70+. Senior signal: 85+.
- Fork this repository (keep it private, add us as collaborators)
- Create a branch:
solution/your-name - Fix the code directly in the source files
- Add written explanations in
docs/your-analysis.md - Open a Pull Request from your branch to
mainwith a clear description
Your PR description matters. Treat it like a real PR you'd open at work.
- You can use any libraries you want — but justify new dependencies in your PR
- You can restructure files if you think it's better — explain why
- Google and docs are allowed. Copying full solutions from AI without understanding them is not — we'll discuss your decisions in the follow-up call
- If something is ambiguous, make a decision and document your assumption
Beyond correctness, we evaluate:
- Clarity of thinking — can you explain why, not just what
- Prioritization — can you identify what's critical vs what's nice-to-have
- Production mindset — do you think about rollout, monitoring, edge cases
- Code quality — naming, structure, error handling
If something is genuinely unclear, open a GitHub Issue in this repo. We'll respond within a few hours.
Good luck.