Build something small that actually runs.
A 30–45 minute practical task. We'd rather see something rough that works than something polished that doesn't. Any stack, AI tools allowed.
The situation
Two things eat our sales team's day.
- Staff answer the same questions about price, payment plans and booking policy over and over, usually by flipping through PDFs. They get it wrong often enough to matter.
- We get far more leads than the team can call. Nobody knows which to call first, so they work down the list by date and the good leads go cold.
This task is a small slice of both. Everything you need is in the task pack: three real MGC documents and a leads dataset (9,160 rows).
The task
Two parts. Keep it under 45 minutes.
If you hit 45 minutes, stop and submit what you have — with a note on what you'd do next. That's a completely acceptable submission and we've hired on them before.
A document assistant
Three MGC documents: a brochure, a price list with payment plans, and a booking policy FAQ. Build something a salesperson can ask questions of in plain language and get an answer grounded in those documents, with the source shown. A script, a notebook, a tiny page — the form doesn't matter. The behaviour does.
| Question | Why it's here |
|---|---|
| Base price of a 2-bed in Block B? | Straight lookup |
| Total for a Margalla-facing corner unit, floor 15, 2-bed Block B? | Base price plus stacked premiums |
| What's the transfer fee? | The two documents disagree. Handle it. |
| Rental yield on a 1-bed? | Not in the documents. Don't invent one. |
| Who is the anchor tenant? | Explicitly unconfirmed. Say so. |
The last three matter more than the first two. A confident wrong answer costs us a sale. "I don't have that, ask the marketing manager" costs us nothing.
Lead data, honest baseline
leads.csv has ~9,000 historical leads with an outcome column, converted. Do a fast, honest pass:
- Look at the data. Decide what you'd clean, drop or fix — and write those decisions down. A few bullets in your README is enough.
- Train a quick baseline model that scores likelihood to convert. No tuning, no endpoint — a notebook or script is fine.
- Report one metric and say why you chose it. The class balance should inform that choice.
The data is real-world shaped: missing values, duplicates, inconsistent city spellings, and columns of varying usefulness. Part of the test is noticing which columns you should and shouldn't use.
How we judge it
We read it, run it, then talk to you about it.
From your README, on our machine, without back-and-forth.
Grounding, refusal, and how you handled the conflict.
What you dropped and why, and an honest number you can defend.
Structure over style. Every line is fair game on the call.
What we're not looking at: visual design, test coverage, deployment, auth. Don't spend your 45 minutes there.
Ground rules
Use AI tools. Seriously.
Claude, Copilot, ChatGPT — whatever you normally use. We do too, and pretending otherwise would tell us nothing about how you actually work.
The one thing that matters: you must be able to explain every line you submit. Shortlisted candidates get a 30-minute call where we open your repo and ask why you did things. That's the real interview. Code you can't explain is worse than code you didn't write.
Questions about the task itself: 0308 77 77 275. Asking a clarifying question is not a mark against you.
Submission
Submit your work
Push to a public GitHub repo and drop the link here before Tuesday 2 September, 12:00 PM PKT. The form closes automatically at the deadline.
Submissions are closed
The deadline (Tuesday 2 September, 12:00 PM PKT) has passed. If you believe this is an error, WhatsApp 0308 77 77 275.