supportix.md

🧩 Live Coding Challenge — Support Ticket Desk

---

🕐 Duration

30–60 minutes (live session)

🎯 Objective

Build a simple support ticket system with basic login, role-based access, and ticket management features.

You don’t need to use a database — in-memory data is enough.

Focus on logic, code structure, and correctness, not UI polish.

---

📘 Background

We want to simulate a simple internal system for handling support tickets.

• A User can log in, post a ticket and see only their own tickets.
• An Admin can log in and see all tickets.
• Admins can also mark a ticket as resolved.

---

⚙️ Requirements

1. Data Models (in-memory only)

You can hardcode these arrays:

// Example data
users = [
  { id: "u1", email: "[email protected]", ...},
  { id: "u2", email: "[email protected]", ... },
];

tickets = [
  { id: "t1", userId: "u1", ...},
  { id: "t2", userId: "u1", ...},
];

You don’t need any external DB — just store them in memory.

---

2. Endpoints

POST /login

Authenticate a user by email and password.

• Request body:

  { "email": "[email protected]", "password": "user123" }
  

• Response on success:

  { ... }
  

• On failure: return 401 Unauthorized

You can just store tokens in memory (e.g. { token: userId }).

---

GET /tickets

Return a list of tickets depending on the user’s role.

• Requires header:

  Authorization: Bearer <token>

• If role = "USER" → return only tickets created by that user.

• If role = "ADMIN" → return all tickets.

Example response:

[
  {
    "id": "t1",
    "subject": "POS down",
    "message": "Printer not working",
...
  }
]

---

POST /tickets/:id/resolve

Only admins can resolve tickets.

• Change the ticket’s status to "RESOLVED".
• Return { "ok": true } on success.
• Return 403 if user is not admin.
• Return 404 if ticket not found.

---

✅ Expected Deliverables (during the live session)

By the end of the interview, the candidate should ideally have:

1. Working backend (/login, /tickets, /tickets/:id/resolve)
2. Basic auth and role logic
3. Optional frontend to test the flow
4. Ability to explain their code structure and decisions