What you'll learn: how to describe enterprise integration work as measurable achievements you can defend in an interview, write FDE and architect variants of one CV, present a learning project honestly, and what never to write.
At a glance
Figure 1. From a raw task to a claim you can defend
How to read this: every bullet passes the diamond, and the loop through "rewrite" runs until the claim is either backed or removed.
- A strong bullet has an action, a system, your role, a scope and a measured result.
- Describe the role you really had: led, built, contributed, supported.
- Keep one set of facts and vary only the emphasis per role.
- Label a learning project as a learning project.
- Never state a number you cannot reproduce or explain.
Scenario
Composite scenario, not a real company. A backend engineer applies for a customer-facing AI role. The CV lists "worked on APIs and integrations for several enterprise clients" and "AI experience". Asked which API, how many consumers, what changed afterwards and what the AI experience was, the engineer can answer the first three in conversation but none is on the page. The "AI experience" was a weekend tutorial. All numbers here are illustrative.
What you will be able to do
- Rewrite five experience lines as measurable, defensible achievements.
- Produce an FDE variant and an architect variant of one CV from the same facts.
- Describe a learning project (the capstone) without implying production experience.
- Apply an evidence test to every line before it goes out.
Prerequisites
The baseline lesson, whose skills map tells you which experience to lead with, and the AI Architect overview for the architect variant.
Core ideas
The bullet formula
| Part | Question it answers | Weak example | Stronger example (illustrative) |
|---|---|---|---|
| Action | What did you do? | "Worked on integrations" | "Built a REST integration" |
| System | What was it? | "for clients" | "between an order system and a partner portal" |
| Role | What was yours? | (missing) | "as the lead developer in a team of four" |
| Result | What changed, measured? | (missing) | "cutting order sync from 12 hours to 5" |
Add scope (volume, number of consumers) where you can. Leave out any part you cannot state truthfully: three honest parts beat five invented ones.
In the interview: "Tell me about that number." A good answer says how it was measured, over what period, and which part was yours and which the team's.
One history, three variants
| Section | FDE variant | Architect variant | Applied AI variant |
|---|---|---|---|
| Headline | Builds and delivers integrations with customers | Designs and reviews integration architectures | Builds and evaluates AI features |
| First bullets | Customer-facing delivery, fast prototypes | Decisions, trade-offs, review outcomes | Quality, tests, reliability, cost |
| Project section | Capstone with a demo and an evaluation | Capstone with the integration design note | Capstone with the evaluation report |
| Skills order | Python, APIs, customer discovery, testing | Architecture views, security, governance | Python, evaluation, observability |
Nothing in the table changes a fact. It changes which true facts come first.
The evidence test
Before a line stays, answer three questions. Can you explain how it works at whiteboard level? Can you say what you personally did? Can you show something that supports it: a repository, a design note, a public write-up, a metric you may legally share?
Never write experience you do not have, inflate a role, or name a client or share material you are not allowed to. If a claim fails the test, rewrite it as what you really did or drop it. A line you cannot defend puts the others in doubt.
Presenting the capstone
The capstone is a learning project with fictional data. Say so in one line: "Learning project: a Python service that turns vague requests into cited recommendations, with an evaluation harness; fictional data." Then state what it demonstrates (offline tests, tested access control, evaluation numbers from a run), not what it does for a business.
Worked example
Assumptions: a fictional engineer; every number is illustrative and stands for the reader's own measured value.
| Before | After |
|---|---|
| "Worked on integrations for clients" | "Led development of a REST integration between an order system and a partner portal in a team of four; cut order sync time from 12 hours to 5" |
| "Improved reliability" | "Added timeouts and idempotency keys to a payment callback; duplicate postings fell from 4.0 percent of callbacks to 1.5 percent" |
| "AI experience" | "Learning project: built a retrieval service with an evaluation harness on fictional data" |
Arithmetic: 12 hours to 5 is 7 fewer hours, 7 divided by 12, about 58 percent. From 4.0 to 1.5 percent is 2.5 percentage points, or 2.5 divided by 4.0, about 62.5 percent relative. Say which you mean. The third line makes no production claim, which is the point.
Practice task
Use the template and fill it in with your own history.
EXPERIENCE LINE (one per task)
Action: ____
System: ____ (generic description, no client name)
My role: led / built / contributed / supported
Scope: ____ (volume, consumers, duration)
Result: ____ before -> ____ after, measured by ____ over ____
Evidence: I can show ____ / I can explain ____
Variant: FDE / Architect / Applied AI (which variants include it)- Write five lines with the template, using only facts you can defend.
- Order them for the FDE variant, then reorder them for the architect variant.
- Write the one-line description of the capstone.
Exercise
Explain it back. In three sentences, answer "walk me through the most important result on your CV". A good answer:
- names the system and your role in it;
- gives the measure with its before and after and how it was taken;
- says what you would do differently now.
Done when you have five template lines, two orderings of them, a one-line capstone description, and a spoken three-sentence answer for your strongest line.
Hint 1: I have no numbers
Use counts you can know: consumers served, endpoints, environments, incidents handled, duration. Scope is a legitimate result when the change is not measurable.
Hint 2: the numbers belong to my employer
Describe the change in relative terms ("roughly halved") if you may, or leave the figure out and keep the system and role.
Common mistakes
- Claiming production AI experience from a tutorial or the capstone.
- Writing team results as personal results.
- Using one CV for every role.
- Including a number you cannot reproduce under questioning.
Knowledge check
1. What are the parts of a strong achievement bullet?
An action, the system, your role, the scope and a measured result. Each part answers a question an interviewer will ask next.
2. How do the FDE and architect variants of a CV differ?
The facts are identical. The FDE variant leads with customer-facing delivery and prototypes, the architect variant with decisions and review outcomes. Changing emphasis is honest; changing facts is not.
3. A line has no measurable result. What do you do?
State the scope you can support, such as consumers, volume or duration, or rewrite it as the exact work done. If nothing can be shown or explained, drop it.
4. Why label the capstone as a learning project?
It uses fictional data and a mock provider, so it shows skill, not production experience. The label is accurate and invites the right question: what it demonstrates and how you tested it.
5. Why distinguish a 62.5 percent relative reduction from 2.5 percentage points?
One is a share of the original rate (2.5 divided by 4.0), the other the difference between two rates (4.0 minus 1.5). Both describe the same change, so say which you mean; otherwise a reader may mistake one for the other.
You can now
- Write a bullet with action, system, role, scope and result.
- Order the same facts for an FDE and an architect variant.
- Describe the capstone as a learning project.
- Apply the evidence test to every line.
Further reading
- Building effective agents (Anthropic): workflows against agents, a precise vocabulary for your own work.
- OWASP Top 10 for LLM Applications: the 2025 list of LLM application risks, as of 2026-11-02.
Last verified: 2026-11-02