AI Engineer

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1Scope the user and the job5 minSo that's who it's for and the job it does. Next, what a good answer looks like.
2. 2What good means and how to measure it5 minThat's how we'll know it works. Now let me sketch the path one request takes.
3. 3Sketch the request path5 minThat's the whole path, end to end. I'd like to go into retrieval and the prompt next.
4. 4Retrieval, tools and prompts10 minThat's what the model sees and what it's allowed to do. Next, how we'd test it.
5. 5Evals and failure cases8 minThat's the test plan and the ways it fails. Now cost, speed and safety.
6. 6Cost, latency, fallbacks and injection8 minThose are the numbers and the guards. Let me sum up.
7. 7Wrap up4 minTo sum up, here's what I'd build first and the biggest risk.

How people lose this round

• I'd start with the biggest model and a vector database.Tools before the user and the job. Nothing after it has a reason the interviewer can check.
• We'll know it works when users are happy with it.That's a hope with no measure. Name a test set and the two or three numbers you'd track before you build.
• The system prompt tells it to ignore instructions in documents, so injection is handled.A prompt is a request the model may not follow. Limit what the model can do, and treat every outside text as untrusted.
• I'd put the user's question at the top of the prompt.The question changes on every request, so nothing after it can be reused. Fixed instructions go first, where the server can cache them.
• If the model is down, we show an error.Plan the fallback out loud: a second model, the source links, or a hand-off to a person.

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1The situation in one line15 secThat's the situation. Here's what I did.
2. 2What you did60 secThat was my part. Here's how it turned out.
3. 3The result, with a number30 secThat's the result. And here's what I'd change.
4. 4What you'd change15 secThat's what I'd do differently. Happy to go into any part.

How people lose this round

• We decided, we built it, and we fixed it.They're hiring you. With "we" all the way through, they can't tell what you did.
• I can't think of a real failure.Everyone has one. It sounds like you don't notice your mistakes, or won't own them.
• In the end, they saw I was right.A story you win outright sounds one-sided. Show what you took from the other side.
• So to give you some background, the company had three teams...Long setup uses up your time and their attention. One line of situation, then what you did.
• It worked out, so it was the right call.A good result can come from luck. Say why the decision made sense with what you knew then.

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1The problem2 minThat's the problem and why it mattered. Here's the main choice I made.
2. 2Your choice and its alternative3 minThat's what I chose and what I turned down. Now what broke.
3. 3What broke2 minThat's what went wrong and how I found it. Here's where it ended up.
4. 4The result2 minThat's the result, against where we started. Last, what I'd do next.
5. 5What's next1 minThat's what I'd do next. Happy to go further on any part.

How people lose this round

• The stack was Python, Postgres, Airflow and Docker.A list of tools isn't a decision. Say what you chose, what you turned down, and why.
• Nothing really went wrong.Every real project breaks somewhere. It sounds like you didn't build much of it, or didn't watch it run.
• We got 95 percent accuracy.Without the baseline or how rare the positives are, the number means nothing. Say what the simple approach scored.
• I tried logistic regression, then trees, then a neural net.A list of tries isn't a story. Say what each one taught you and why you moved on.
• The team built it, and I helped out.Too modest to score. Name the parts that were yours.