Luzia is a personal assistant used by millions of people daily, mainly through WhatsApp and our own
app, across Brazil, Mexico, Colombia, Argentina, the US and Spain. We work with large volumes of
anonymized data, so data confidentiality and fast response times matter to us.
This exercise is a small slice of the kind of problem we work on. We care less about how much you
build and more about how you think — the design decisions you make and the tradeoffs you can
defend.
The task
Build a small chat service with an assistant that can use a tool.
A user sends a message. The assistant replies — and when it's helpful, it can use a tool
(for example: fetching a gif, doing a calculation, or a simple lookup) and weave the result into its
answer. The reply should stream back progressively rather than appearing all at once, and the
user should be able to tell when a tool is being used. Include a minimal UI to interact with it.
Use a real LLM or a mock one — your choice. If you wire up a real model, keep it configurable
(and don't commit any keys); if you'd rather not, a deterministic stand-in is perfectly fine. Either way,
your automated tests should run offline, with no live calls or paid keys.
How you structure all of this is up to you. There's no prescribed
architecture, framework, or file layout — choosing them well is part of what we're evaluating.
What it needs to do
A backend that handles the conversation and the tool interaction.
The assistant decides when a tool is useful and incorporates its result into the reply.
Responses stream to the client progressively, with some indication when a tool is running.
A minimal frontend — bare-bones is fine — where you can type a message and watch the reply stream in.
Automated tests that run offline (no live external calls, no paid keys).
A short README (how to run + test) and a brief writeup of the decisions you made.
In your writeup, also think about
A paragraph or a few bullets each is plenty — we'll go deeper in the follow-up:
How would you keep responses fast when expensive operations (e.g. image or video generation) spike under load?
How would you handle a long-running task so it doesn't block the user's chat?
How would you store and scale conversation data for millions of users?
How would you choose between a cheaper and a more capable model — and how would you know quality held up?
What we care about
Clear thinking — a clean design you can explain and defend, scoped sensibly to the time-box.
Code that's easy to follow and test — well-separated concerns; sound async handling; clear types.
Robustness — the tool and streaming interaction behaves sensibly, including when things go sideways.
Honesty — a writeup that's clear about tradeoffs and what you'd do with more time.
Readable, incremental commits over one giant "final" commit.
Use any tools you like, including AI assistants — we do too. Just be ready to
explain your choices.
Deliverables & submission
A git repository (link or zip) that runs with the documented commands, with tests green.
A README and a short writeup (a page is plenty) covering your design, tradeoffs, and the questions above.
Reply to this email with the link when you're done. Aim for within one week; tell us if you need more.
Follow-up is a short walkthrough: you'll run it, we'll read the code together, and
we'll talk through how you'd take it further.