Founding Platform Engineer: Sales Dinner Planning Assistant

Finch helps companies grow their go-to-market by turning relationship-building into a repeatable system. It starts with small in-person events such as sales dinners. Finch handles the planning, details and follow-through, so customers can focus on the relationships, not the logistics.

Finch is AI-native: product builders, some of them non-technical, ship features with AI agents. The platform engineer's job is to make that safe. As Finch's founder puts it: "We're not trying to review all the code that gets written. We do need to ensure it does what we want and doesn't cause regressions or breakages."

Your task: build a thin, working proof of concept of Finch's Sales Dinner Planning Assistant. It is a chat agent that guides a non-technical event planner, step by step, from "I want to host a dinner" to a venue shortlist and a guest list. It must be grounded in real data and protected by checks that run.

The customer: Northwind Analytics (fictional). Their VP of Sales wants a sales dinner in Seattle on Thursday, November 12, 2026:

• 12 guests from accounts with an open sales opportunity, plus 2 Northwind hosts (14 seats);
• a quiet private room;
• a budget of $120 per head or less.

The person chatting with the assistant is Northwind's sales-ops coordinator. She is busy, not technical, and has never planned a dinner like this.

Your data: two upstream sources, served locally by a script we provide. Download finch_mock_server.py and start it with python3 finch_mock_server.py. It needs Python 3.8+, has no dependencies, and doesn't need the internet. It serves:

• Northwind's CRM: a JSON API. GET http://localhost:8787/v1/crm/contacts?owner=northwind. Results are paginated: follow next_cursor until it is null.
• A venue directory: a website, not an API. GET http://localhost:8787/venues?city=seattle returns an HTML page that links to one HTML page per venue. There is no JSON. Capacity, price, noise level and status are written by the venues themselves, in whatever form they chose.

Pull both sources into a local store of your choice (SQLite, Postgres, JSON files or similar), then build the agent on top. Treat both as third-party sources you don't control. Expect what real upstream sources do: the CRM API can fail and repeat itself, and the venue pages are written for people, not programs. Don't edit the mock server or copy values out of it by hand.

What "good" looks like: the planner has a conversation and ends up with a shortlist and a guest list she can trust. The agent leads her through the steps instead of waiting for her to know what to ask. It is honest when the data can't give her exactly what she asked for. And you can show, with something that runs, that the agent obeys Finch's rules.

Constraints to Consider

• Hard rules must be enforced by something that runs. Finch must never invite a contact marked do_not_contact, never invite a competitor, and never recommend a venue that is closed or can't seat the full party. A single violation in front of a customer is a trust failure. "The prompt tells the model not to" is not enforcement. Show how you know the rules hold.
• Upstream data you don't control. The venue site will change its pages, and the next CRM pull will have new quirks. Fix data problems in your ingestion code. When a page doesn't clearly answer a question that a hard rule depends on, decide what your system does, and say so.
• A non-technical builder extends this next week. Maya, Finch's customer-success lead turned product builder, will add features with her own AI coding agent. She won't read your code. She needs to know what she can safely change, what she must not touch, and how to tell whether her change broke something.
• Runs locally; no paid service required to check it. Anyone should be able to run your project and your rule checks with one command, with only the mock server running. Use any language, framework and LLM (hosted or local; Finch prefers local models where they're good enough). Keep keys in environment variables, never in files you submit. Your deterministic rule checks must pass without an LLM key and without internet access.
• Thirty minutes to build. This is a proof of concept, not production. Choose what to cut and tell us what you cut and why. A working, guarded thin slice beats a broad, unverified one. A terminal chat is fine; don't spend time on UI.

AI Usage Guidance

We expect you to use AI tools. We evaluate how you use them, not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.

The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.

Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you, and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.

Speak naturally. Communication is assessed on clarity of technical ideas and logical structure, not verbal polish, accent, or filler words. Because this role works with both engineers and non-technical teammates, we also look at how clearly you explain things to someone who isn't an engineer.

Submission

Upload each deliverable as a separate file directly on the Provn platform: your code files, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV). Please don't upload ZIP files or repository links.

Accommodations: if you need a reasonable accommodation, for example extra time or an alternative to on-camera video, request it before you start. Add a short note to your submission saying an accommodation was provided.