- Prepare two or three projects in real detail rather than a broad list of everything you have touched.
- The exercises test delivery work: transform imperfect input, call an API safely, debug a failing integration, design for one customer's constraints.
- Answer the customer exercise by clarifying the goal and the acceptance check before proposing anything.
- Say "I do not know that number" instead of estimating, because an invented figure is the one thing an interviewer can check.
- Ask which parts of the process test coding, design and customer discovery, since employers order these stages differently.
Build an evidence set
For each project, prepare a short answer to:
- Who needed the result, and what constraint mattered?
- How did you learn what to build?
- What did you personally implement or decide?
- What alternatives did you reject, and why?
- How did you test, deploy, monitor and support it?
- What went wrong, and how did you respond?
- What changed for the user after delivery?
Make your own part clear when the result belonged to a team.
What each exercise is testing
| Exercise | What the interviewer is looking for |
|---|---|
| Coding | Readable code with the assumptions said out loud: validation, error handling, security, and how it would be operated |
| System design | Questions before boxes — users, data, latency, permissions, deployment environment — then a small design that meets the stated need |
| AI or data systems | The data path, evaluation method, access controls, failure handling, and how a customer can challenge an output |
| Customer problem | Clarifying the goal and the acceptance check, naming what you would leave out, ending with an owner and a next action |
Do not add distributed components to make a design look larger. "I would make it scalable" is not an answer. Say what can fail, what you would measure, and what you would change if the evidence differs.
Practise the customer conversation
Ask someone to give you an incomplete request. Spend a few minutes on the user's goal, the current process, the constraints, and how success will be judged. State what you would build first and what you would leave out. Explain one risk in plain language. End with the next action, the owner and the acceptance check.
Ask the employer in the same call which customers the role serves, what reaches production, how much travel is expected, where the role can work, and how responsibility is shared after launch. Those answers decide whether you want the job.