Place Review REST API ("PlaceRate") — Backend Take-Home
Source: Derived from Resources/Coding Task.pdf — a real backend hiring take-home assignment (a startup that explicitly prefers Django + a relational database, reads submissions manually, and treats them as production pull requests).
Skills Required
- Language: Python (the source strongly prefers Django; any language/framework is technically allowed, but the teaching brief assumes Django).
- Web framework: Django + Django REST Framework (DRF) — viewsets, serializers, routers. (Flask/FastAPI/Express are acceptable substitutes if you are not doing the Django track.)
- REST API design: resource modeling, correct HTTP verbs and status codes, request/response JSON contracts, pagination, query-parameter-driven search.
- Relational databases: PostgreSQL or SQLite, schema design, foreign keys,
UNIQUE constraints, composite unique constraints, indexing for search and sorting. - ORM: Django ORM querysets,
annotate() + Avg() for average ratings, Case/When ordering, filter/Q objects for partial + exact name matching, avoiding N+1 queries via select_related/prefetch_related. - Authentication & authorization: login-required access on every endpoint (token auth / session auth / JWT). No public access to anything.
- Validation: enforcing rating bounds (1–5), unique phone number per user, unique (name, address) per place, input sanitization, meaningful error responses.
- Business logic: "find-or-create place on review" semantics, average-rating computation, custom review ordering (current user's review first, then newest-first).
- Data seeding: a management command / script that populates the DB with realistic random sample data (e.g., Faker).
- Testing: unit and API tests (pytest / Django
TestCase / DRF APITestCase) — expected at a "production PR" bar. - Tooling & hygiene: virtualenv/poetry,
requirements.txt, migrations, .gitignore, a clear README with run instructions, packaging as a tar/zip under 1 MB without the virtualenv. - Soft skills: stating and documenting assumptions, writing readable/reviewable code, self-review rigor (the bar is "code as if you're sending a production pull request").
Background a Student Needs
You should be comfortable building a small CRUD-style web backend before attempting this. Concretely: you understand HTTP and REST basics (verbs, status codes, JSON), you can define database models with relationships and constraints, you can write and run migrations, and you know how authentication works (login required, tokens or sessions). Familiarity with Django and Django REST Framework — models, serializers, views/viewsets, querysets, and the annotate/aggregation API — will let you finish this confidently. You should also know how to write tests and a runnable README, since the evaluation explicitly grades code quality, not just whether it works.
Task Summary
Build a REST API (no UI — a separate frontend will consume it) for a mobile app where logged-in users review any kind of place: shops, doctors, restaurants, etc. Users register with a name and phone number, leave 1–5 star reviews with text, and the act of reviewing auto-creates the place if it does not already exist. Other users can search places by name (exact matches first, then substring matches) and/or minimum average rating, and drill into a place to see its full details and all reviews — with the current user's own review pinned to the top.
The Task
Constraints & assumptions (from the brief)
- You are building only the REST API endpoints; the UI is built by someone else.
- The app must run with just a web server and a database — no other servers, background workers, or third-party services (local or remote).
- A relational database is strongly preferred over non-relational. Django is preferred but any language/framework is allowed.
- If anything is ambiguous, make a reasonable assumption and document it in your submission.
Entities
User
- Has a
name and a phone number. - Registers with name + phone number.
- Phone number is unique — only one user per phone number.
- Authentication is mandatory: a user must be logged in to do anything. There is no public access to any endpoint.
Place
- Has a
name and an address. - The combination of
(name, address) is unique — only one place per name+address pair.
Review
- Has a
rating (integer 1–5), text, a reference to the user who left it, and a timestamp (when it was left).
Features / endpoints
- User registration — register a new user with name + phone number, enforcing phone uniqueness.
- Authentication — login so that all subsequent requests are authenticated; reject unauthenticated requests everywhere.
- Add review — a user submits a place
name, address, and rating (plus review text). If a place with that name (and address) already exists, attach the review to it; otherwise create the place and attach the review. (Document how you resolve the name-vs-address matching ambiguity.) - Search places — search by
name and/or minimum average rating across the global database:- If a minimum rating is given, only return places whose average rating meets or exceeds it.
- If a name is given, return full and partial matches: exact-name matches first, then places that contain the name as a substring.
- Each search result shows the place name and its average rating.
- Place details — selecting a search result returns the place's full detail:
name, address, average rating, and all reviews. Each review shows the name of the user who wrote it.- Ordering rule: if the current user has reviewed this place, their review appears first; all remaining reviews follow, sorted newest first.
Deliverables
- Source code (Django/DRF or chosen stack) implementing all of the above.
- A data population script / management command that seeds the DB with a decent amount of realistic random sample data.
- A README with clear, exact instructions to install dependencies, run migrations, seed data, and start the server.
- Packaged as a tar/zip under 1 MB, excluding the virtualenv/environment folder.
Evaluation notes
- The bar is high and code is read manually, "as if you are sending a pull request for a production feature." Merely working is not sufficient — readability, structure, validation, query efficiency, tests, and documented assumptions all count.
- Tests, clean serializers/views, sensible constraints and indexes, and avoiding N+1 queries are the kinds of things that distinguish a strong submission.
Alternate Tasks (Mini-Project Variations)
- Beginner — Single-Resource Review API. Build a stripped-down version with just two models,
Place and Review, and no authentication. Expose endpoints to create a place, add a 1–5 review to a place, list all places, and fetch one place with its average rating and reviews. This is the ideal first rung: it isolates the core skills of model design, serializers, foreign-key relationships, and computing an average with the ORM, without the complexity of auth or fuzzy search. It teaches a student the fundamental REST CRUD loop and how aggregation (Avg) turns child rows into a parent-level metric. - Intermediate — Authenticated Review API with Token Login. Take the beginner version and add the full user layer from the source brief: registration with a unique phone number, token-based login, and a hard rule that every endpoint requires authentication. Add the "find-or-create place when reviewing" logic and a constraint that a user can only leave one review per place (or may edit their existing one). This variation teaches authentication, permission classes, uniqueness constraints, and idempotent business logic — the difference between a toy API and one that respects identity and data integrity, which is exactly what the hiring bar checks for.
- Advanced — Full Faithful Build with Ranked Search and Pinned Reviews. Implement the complete original assignment, but push on the two hardest correctness details and grade yourself on them: (a) search ordering that returns exact name matches before substring matches and filters by minimum average rating in a single efficient query, and (b) place-detail review ordering that pins the current user's review to the top followed by everyone else's newest-first. Add database indexes for the search/sort paths, a Faker-based seed command, and a real test suite covering edge cases (duplicate phone, rating out of range, no matches, tie-breaking). This is advanced because the value is entirely in query correctness, efficiency (no N+1), and the production-PR rigor the company explicitly rewards.
- Intermediate → Advanced (MERN twist) — Full-Stack Place Reviews with React + Node. Re-implement the same domain as a MERN-style full-stack app: an Express + (PostgreSQL/Prisma, or MongoDB) backend exposing the same review/search/details endpoints, plus a React frontend that lets a logged-in user register, search places, view a place's detail page with reviews, and submit a new review. This twist teaches a student how the "UI built by someone else" half actually consumes a REST API: JWT auth flow from the browser, handling loading/error states, controlled forms, and rendering the pinned-review-first ordering on the client. It bridges backend contract design and frontend consumption — a complete employable skill set.
- Advanced (Agentic AI twist) — AI Review Assistant over the Review API. Keep (or reuse) the backend from variation 3 and build an agentic AI layer on top of it. Expose the search, place-detail, and add-review operations as tools to an LLM agent, then let a user chat naturally: "find me a highly-rated dentist near downtown," "summarize the reviews for Café Aroma," or "leave a 4-star review for that place saying the service was slow but the food was great." The agent must call the right API tools, ground its answers only in real review data (no hallucinated places or ratings), and confirm before writing data. This teaches tool/function calling, retrieval-grounded responses, guardrails around state-changing actions, and how a clean REST API becomes the action surface for an AI agent — directly relevant to the Agentic AI track.
Reference Links