Build something small that actually runs.
A practical task in four parts — AI development, database, ML and web development. About 90 minutes. We'd rather see something rough that works than something polished that doesn't.
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
Four parts. About 90 minutes.
If you hit 90 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. Finishing two parts well beats rushing four.
A grounded 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. Every answer must name the document (and section) it came from — an answer without its source counts as wrong.
| 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 |
| Overseas buyer pays 50% upfront on a 3-Bed Executive — price after discounts, and what's due at booking? | Discount stacking + payment plan, across two documents |
| 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 three. A confident wrong answer costs us a sale. "I don't have that, ask the marketing manager" costs us nothing. Hint for the arithmetic: language models are bad at it — decide where the maths should actually happen.
Schema & queries for a messy CRM
leads.csv is the dump of a messy CRM (~9,000 leads). Treat it that way:
- Design a minimal SQL schema you'd store this in properly —
schema.sql. One table is fine if you can defend it. - Write three queries in
queries.sql: conversion rate by lead source (200+ leads only, best first); a query that finds the duplicate leads and keeps exactly one canonical row per pair with a deterministic winner rule (plus a comment on preventing them at schema level); and conversion rate by city after normalizing the messy spellings (ISB, Rwp, khi, UPPERCASE) inside the query itself.
Any SQL dialect. Runnable is best, but clearly written counts.
Lead scoring, honest baseline
Same leads.csv, outcome column converted:
- Decide what you'd clean, drop or fix — and write those decisions down. A few bullets in your README is enough.
- Train a baseline model that scores likelihood to convert. No tuning — a notebook or script is fine.
- Split by time, not randomly — train on older leads, test on newer — and say why that matters here. We'll ask about your split on the call.
- Report one metric against a no-skill baseline, and translate it: if the team can only call the top 100 scored leads, how many convert?
The data is real-world shaped: missing values, duplicates, inconsistent spellings, and columns of varying usefulness. Part of the test is noticing which columns you should and shouldn't use.
One page that ties it together
A minimal web interface where a salesperson can do both:
- ask the document assistant a question and see the answer with its source, and
- enter a lead's details and see its score.
Bare HTML served by anything — Flask, FastAPI, Express, Streamlit. No styling points. It should run on our machine from your README.
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, source citation, refusal, the conflict — and where you put the arithmetic.
Keys, types, the dedup winner rule, and the normalization.
What you dropped and why, the time split, and an honest number tied to the business.
Wiring, not looks. Bare HTML is completely fine.
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 90 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 Friday 16 October, 11:59 PM PKT. The form closes automatically at the deadline.
Submissions are closed
The deadline (Friday 16 October, 11:59 PM PKT) has passed. If you believe this is an error, WhatsApp 0308 77 77 275.