How to Prepare Your Project

You've picked your project. Now, set aside an hour, open up a doc, and go through this lesson. By the end, you'll have your slide content prepared, plus answers ready for the follow-up questions before they're even asked.

There are four core sections your project deep-dive must have (in order):

1. Impact
2. Requirements
3. High-level system design
4. Zoom in

Impact

The impact your project made is what gets interviewers invested. If they're interested in your project, they'll naturally want to find out more about how it was built. This turns the round into a genuine conversation between engineers about a cool project one of them happens to have built.

This slide needs to answer two questions.

1. What was the business problem?

State the problem you were solving and who you were solving it for. Don't state the task because the task misses the "so what."

• Wrong "Build a data pipeline" (task)
• Correct "Sales couldn't see deal risk until it was too late to intervene" (problem)

Answer: Who had the problem, and what was it costing them (time, money, errors, churn)?

2. What was the outcome?

State what changed because of this project. If you have a number, use it as evidence inside this answer. If you don't have a clean metric, the qualitative consequence still counts.

Answer: Because of this, [stakeholder] could now ___ (backed by [metric], if you have one).

Requirements

Real projects usually have more functional and non-functional requirements than you could reasonably present. Your task is to identify the main ones that most shaped the key decisions you're about to walk through.

• Functional requirements. The main things the system had to do. Pick the ones tied to the decisions you'll go deep on later, not an exhaustive list of everything it did.
• Non-functional requirements. The main performance constraints (scale, latency, security, cost, reliability) that drove your technical choices.

You should have 1-3 of each. Keep it short and simple so the discussion can remain focused.

High-level system design

Pull out or create a system design diagram for the project. Include the specific technology used.

Components

1. Support agent — asks a question with a customer ticket open.
2. Assist panel — embedded in the existing ticket view.
3. Orchestrator — builds the prompt, calls retrieval and the model, enforces citations.
4. Semantic cache — checked before retrieval, written after generation. Cuts latency and cost on near-duplicate questions.
5. Vector index — chunk embeddings plus source metadata.
6. Claude on Bedrock — answers from retrieved context only.
7. Traces and feedback — written asynchronously so logging never blocks the response. This is what makes retrieval quality measurable.
8. Sources — help center articles and resolved tickets.
9. Chunk and embed job — nightly reindex, offline by design so the request path never waits on embedding.

Prepare your walkthrough

From the diagram, make sure you can explain the happy flow i.e., how a request or task moves end to end through the design.

Also make sure you can point to which components fulfill the functional and non-functional requirements from the previous slide, and explain how. This is what makes the walkthrough easy for interviewers to follow.

While you're walking through the happy flow and components, this is also the moment to signpost where you're planning to zoom in on. Naming it upfront gives you some control over the direction of the conversation, rather than leaving it fully open to the interviewer. That said, they may still redirect you toward a different area if they want to assess a specific expertise.

Prepare for follow-up questions

Interviewers like to ask why a specific component (and technology) was chosen. Doing this exercise ahead of time preps you for those follow-ups.

Take note of every component in the diagram and answer these questions:

1. What's the purpose of this component? Could we do without it? What were the alternatives?
2. Why was that specific technology used, and which requirement was it satisfying? Were there better alternatives?
3. Did it play out as planned in production, or did changes need to be made?

This section takes real time and thought. It may even mean reaching out to colleagues or ex-colleagues who worked on the project with you. But it's worth the effort.

Interviewers who run these rounds say these are the questions that catch candidates off guard and break their composure. If you've thought it through beforehand, you'll impress them with a calm and thoughtful answer.

Zoom in

Choose the right area to zoom in on. A good choice anticipates what interviewers will naturally want to dig into, and if you've prepared for it in advance (even with slides), the round will feel exceptionally smooth.

Pick using this order:

1. Does the role you are interviewing for have a stated technical specialization in the job description? That's your area.
2. If the role is ambiguous, which part of the system was most complex or highest-risk?

Once you've picked your area, the conversation here is less structured than the sections above. It's more of a back-and-forth with the interviewers.

The way to prepare is to think through the questions below ahead of time. It's easy to forget details like this, especially if the project isn't your current one:

• What made this part complex? What needed discussion and consideration?
• How did you implement it? What other options were on the table, and why did yours make the cut?
• What differed between the plan and what happened in production? What didn't you plan for?
• How would you improve it today? Bonus: how would it look if you solved it in this company?

If answering any of these makes you want a diagram, table, or other visual aid, add it as a slide.

The conversation itself will be free-flowing, but if you've thought through the questions above, you'll already have the talking points in your head.

Wrapping up

Congratulations on making it through!

You should now have a sizable doc of notes (it’s for your eyes only).

Now open your favorite presentation tool and pull the relevant pieces onto slides. Recommended structure:

• Slide 1: Impact
• Slide 2: Requirements
• Slide 3: High-level system design diagram
• Slide 4-5: Zoom in visual aid (if needed)

We'll leave the styling to you (or to AI). The slides just need to be tidy and easy to follow. You won't get extra points for polish.

That's it for the deliverables. The next lesson covers practice and presentation tips.