FREE WORKBOOK 02 · Technical students preparing applications or interviews

Turn a technical project into an interview story.

Explain the problem, your own engineering decisions and the evidence behind your result without hiding behind a list of tools.

YOUR OUTPUTA concise project explanation, an evidence-backed résumé draft and a list of follow-up questions to practice.

Original teaching material · Read and download without registering.

Use a decision story, not a stack inventory.

Start with the user or system problem. Explain what you personally built, why you chose that approach, how you tested it and what remains weak. Keep teammates' work separate from your contribution.

Adapt the explanation to the work in the role description. A software discussion may focus on reliability and design; an AI discussion may focus on evaluation; a deployment discussion may focus on integration constraints. Changing the emphasis does not justify changing the facts.

Problem: who needed something, and what was failing?
Ownership: what did you implement yourself?
Decision: which alternatives did you consider, and why did you choose one?
Evidence: what did you test, against which baseline, and with what result?
Limits: where does the approach fail, and what would you improve next?

An illustrative source-linked FAQ prototype.

The prototype and all numbers below are fictional teaching examples. They are not results from Meta, Google, an employer interview or a real candidate. Use your own measured evidence in applications.

WORKED EXAMPLE · TEACHING ONLY

A short technical explanation

Problem: answers in a small FAQ prototype were difficult to check against the source documents.

My work: I built document chunking, retrieval, source links and an explicit cannot-answer state. I did not train a foundation model.

Decision: I used retrieval over the small source set so an answer could point back to its evidence. I compared two chunk sizes rather than adding more tools immediately.

Evaluation: I authored 20 teaching questions and manually labeled the supporting passages. In this fictional example, 14 answers were source-supported and six were not.

Failure analysis: I inspected retrieval misses and unsupported answers separately. The small authored set does not establish performance on real users' questions.

Next step: expand the held-out questions and test whether source links are useful to someone unfamiliar with the documents.

Rewrite a vague bullet into a checkable claim.

Vague: Built an accurate AI chatbot using a modern stack.

A more useful draft specifies the actual artifact, your contribution and the evaluation. Quantified wording belongs on a résumé only after you can reproduce the figures.

Practice the questions behind the story.

Prepare to explain a single example in detail rather than memorizing a polished script. Walk through the actual code or artifact when useful, and be explicit about what you would need to look up.

What would a simpler non-AI version have done?
Why did you choose this baseline and these test cases?
Which failure did your first demo hide?
What did you personally change after inspecting a failure?
What would you measure before calling this ready for users?
What security, privacy or operating-cost constraint affected your design?

MAKE IT YOUR OWN

Your preparation checklist.

Checks are saved only in this browser on this device. They are not uploaded or synced to your account.

0 of 8 checked · a preparation aid, not an eligibility result.

I can explain the problem without naming the technology first.I distinguish my contribution from teammates' and libraries' work.I can explain one trade-off and a simpler alternative.I describe the evaluation set and baseline accurately.Every number in my explanation comes from my own recorded result.I can walk through one failure and the change it led to.I do not present a small project evaluation as production performance.I connect the story to the actual work in a target role.

Your worksheet includes

Project and my role:
User or system problem:
What I personally built:
Alternative I considered:
Trade-off and reason for my choice:
Evaluation data and baseline:
Measured result and where it is recorded:
One failure and my response:
Limitations:
Next experiment:
Résumé bullet using only verified facts:
Interview follow-up I need to practice:

Download the editable text and fill it in yourself. These pages do not generate a résumé, submit an application or verify a claim for you.

USE THIS WITH A REAL ROLE

Browse the relevant records, inspect the official posting and decide what deserves your attention. Opening the list does not save a role or select a company review.

Explore software engineering internship records Create a free account to save target roles

Your worksheet stays free. Account-saved targets are separate from the checks stored in this browser. No company-review allowance is used by this workbook.