# GrainX Tech Challenge

**Estimated time:** 3–5 hours. It's up to you, but won't recommend spending more time on this.
**Submission:** Share a GitHub repository (private with access granted to user ShahadIshraq) with a short written README explaining your decisions.

---

## Context

GrainX is building a digital grain marketplace that connects growers, buyers, and traders across Australia. The platform needs to be fast, reliable, and simple to use — both on the web and mobile.

This challenge is a small slice of that product. You'll build a minimal **Grain Listings** feature: growers can post grain they have available for sale, and buyers can browse and express interest.

---

## What You're Building

A simple full-stack app with the following:

### Backend

A REST API with these endpoints:

- `GET /listings` — return a paginated list of grain listings
- `POST /listings` — create a new listing
- `GET /listings/:id` — return a single listing
- `POST /listings/:id/enquiries` — submit an enquiry on a listing (buyer interest)

**A listing should have at minimum:**
- Grain type (e.g. wheat, barley, canola)
- Volume (tonnes)
- Price per tonne
- Location (free text is fine)
- Status (`available` or `sold`)
- Created timestamp

**An enquiry should have at minimum:**
- Buyer name or contact
- Message / offer note
- Timestamp

You don't need authentication. Keep it simple.

---

### Frontend

A minimal web UI (or React Native screen, see note below) that:

- Displays the list of grain listings
- Allows a user to create a new listing via a form
- Allows a user to click into a listing and submit an enquiry

The UI doesn't need to be beautiful, but it should be functional and not embarrassing. Think: clean, usable, communicates the data clearly.

---

## Tech Stack

Use the stack that matches your role:

**Backend applicants:** Python, Django, Django REST Framework, PostgreSQL. Use Docker to run it locally.

**Frontend applicants:** React.js (Next.js preferred), TypeScript. You can use a mock JSON file or a simple Express/Next API route as a backend stand-in — you don't need a full database.

> Both roles: we expect minimal but working functionality on the other side of the stack. A backend candidate should have *something* rendering in a browser. A frontend candidate should show some understanding of the API contract they'd be consuming. The quality bar is much higher on your primary role.

---

## About Using AI Tools

We expect you to use AI tools — Cursor, Copilot, Claude, ChatGPT, whatever you prefer. We use them on this team every day.

**What we're evaluating is not whether you used AI. It's whether you understand what was built.**

In your README, we ask that you be honest about how you used AI assistance and reflect on the following:

1. **What did you design yourself vs. delegate to AI?** Walk us through the key decisions you made.
2. **What would you do differently** if this were a real production feature with real users?
3. **Where did the AI get it wrong, or where did you push back / change its output?** We're looking for evidence that you reviewed and understood the code, not just accepted it.
4. **One thing you'd add next** if you had another hour — and briefly, how you'd approach it.

These reflections matter as much as the code. A candidate who ships clean AI-assisted code and can clearly articulate the tradeoffs will do better than someone who writes everything manually but can't explain their choices.

---

## What We're Looking For

### Backend candidates

- Clean API design — sensible endpoints, status codes, and response shapes
- Django and DRF used idiomatically (serializers, viewsets or APIViews, proper model design)
- Database model that's thoughtfully designed (field choices, types, constraints)
- Dockerised setup that runs with a single command
- Basic test coverage (even a couple of API tests shows the right instinct)
- Code that reads like a professional wrote and reviewed it

### Frontend candidates

- Component structure that makes sense — not everything in one file
- TypeScript used properly, not just as a JavaScript alias
- State managed cleanly (local state or Zustand, appropriate for scope)
- A UI that's responsive and usable on mobile widths
- Attention to UX details: loading states, empty states, basic form validation
- Code that reads like a professional wrote and reviewed it

---

## Submission Checklist

- [ ] GitHub repo link (private with access to user `ShahadIshraq`) — send the link to hi@shahadishraq.com
- [ ] README with: setup instructions + AI usage reflection (the 4 questions above)
- [ ] App runs locally without manual setup steps beyond `docker compose up` (backend) or `npm install && npm run dev` (frontend)

---

## A Note on Scope

Don't over-engineer this. We're not looking for a production system. We're looking for clean, considered work that shows you understand what you're building and why. A well-structured minimal submission beats a bloated one that's hard to read.

Good luck — we're looking forward to seeing what you build.