career.json / fictional walkthrough

A career you can actually review

Meet Jules Elm: a software engineer who grew into technical leadership, with useful older work, shared achievements and a few claims that need a second look.

Entirely fictional. People, employers, sources, answers and decisions are authored examples. The pages use the real review and recall tools; they do not measure model extraction accuracy or represent a real person’s approval.

Who is Jules?

Jules works at the intersection of software architecture, service operations and engineering development. The current remit is 18 engineers through three managers. The recurring contribution is helping teams adopt workable approaches, while leaving implementation credit with the people who did the work.

  1. 2010–2014 · Software Engineer · Fictional Civic AtlasData imports, recovery tools and learning how operators use software.
  2. 2014–2017 · Senior Software Engineer · Fictional North Quay SystemsShared observability and incident practice across service teams.
  3. 2018–June 2022 · Staff Engineer · Fictional Fieldwork LtdDeployment practice, service architecture and influence without line authority.
  4. July 2022–present · Head of Engineering · Fictional Fieldwork LtdA promotion at the same employer: planning capacity, developing managers and making technical tradeoffs explicit.

The sources do not establish revenue impact, enterprise-wide transformation or an outage-reduction percentage. A useful career record keeps those limits alongside the achievements.

Follow the review

Start anywhere. Each page is a separate snapshot, so your experiments with one review do not change the others. 9 achievements can be saved while other questions remain open.

1. Inspect the proposal

Four roles, twelve proposed achievements and four sources. Look for shared ownership, duplicate accounts and unsupported numbers.

2. See a partial save

Nine achievements are accepted. Corrections, the uncertain metric and strengths questions remain pending.

3. Review corrected wording

Compare the coaching correction and combined dashboard account with the earlier sources. New wording needs a new decision.

5. Add new work later

A quick migration note becomes a proposed achievement after a follow-up account. The launch has not happened yet.

6. Read the current career pack

Eleven accepted achievements across sixteen years. Private material and an open coaching question remain visible in this private reading view.

Six things worth reviewing critically

Try the initial proposal before opening the scripted outcomes. Expand supporting excerpts in each review card when you need more context. The review uses five items per batch; you can jump, defer or pause.

Peer review ownership

The initial proposal credits Jules with designing the entire review format and coaching every engineer.

See the scripted review outcome

The manager review and Jules’s clarification identify Mara and Theo as the format designers. Jules sponsored the pilot and coached three managers.

Two accounts of one dashboard

The resume uses two names for the March 2016 dashboard. Both appear as proposed achievements.

See the scripted review outcome

The correction keeps one achievement, attaches both accounts and preserves the five-service adoption detail. It does not double-count delivery.

A tempting 35% claim

Project notes mention a 35% improvement, but the baseline and measurement period are missing.

See the scripted review outcome

The claim stays unresolved and outside every accepted pack. The original source and pending question remain available.

Sensitive work

The supplier review demonstrates useful technical judgment, but includes employer-sensitive context.

See the scripted review outcome

It is accepted as accurate and explicitly kept private. Accuracy and external-use permission are separate decisions.

Strength versus overstatement

Practical adoption appears repeatedly; enterprise-scale transformation is also proposed.

See the scripted review outcome

Jules confirms the narrower interpretation in a recorded answer. The enterprise claim remains a correction request; a leadership title does not establish it.

A note is not a finished outcome

Jules records migration planning in August 2026.

See the scripted review outcome

Capture leaves the accepted pack unchanged. Later review accepts planning and agreement, without inventing a successful launch or reduced incidents.

Use the same career record in different situations

These excerpts come from actual deterministic searches of the final accepted pack. They are private preparation examples, not completed resumes.

Prepare an annual review

“What did I contribute to developing other engineers?”

Built an engineering practice

Contribution: Sponsored the peer design-review pilot and coached three engineering managers; Mara Vale and Theo Reed designed the format, and the managers shared hiring responsibility.

Recorded result: The engineering group adopted peer design reviews.

Original supporting excerpts
In February 2025 I hired and coached engineers while introducing peer design reviews. The engineering group adopted peer design reviews.
Jules sponsored the peer design-review pilot and coached three engineering managers. Engineers Mara Vale and Theo Reed designed the review format together. Hiring was shared with the managers. The engineering group adopted peer design reviews; we have not collected feedback about which coaching was most useful.
I sponsored the peer design-review pilot and coached three managers. Mara and Theo designed the format, and the managers shared hiring responsibility. Please keep that division of work explicit. I still cannot say which part of my coaching helped most.

Prepare for a Staff Engineer interview

“Show the service-separation decision and who delivered it.”

Agreed a gradual service separation

Contribution: Mapped failure boundaries with both groups and authored a staged separation proposal.

Recorded result: The teams chose a staged separation and retained a rollback path; product teams implemented the changes.

Original supporting excerpts
2021-02: Product and operations disagreed about replacing a shared service in one release. Make the migration tradeoffs explicit and agree a sequence the teams could support. Mapped failure boundaries with both groups and authored a staged separation proposal. The teams chose a staged separation and retained a rollback path; product teams implemented the changes.

Update the latest review

“What can I accurately say about the customer-data migration?”

Agreed a phased customer-data migration

Contribution: Facilitated the planning discussion and wrote a rollback decision guide; operations ran the rehearsal.

Recorded result: Product owners agreed to migrate in phases. The migration had not yet run.

Original supporting excerpts
Helped operations and product agree a phased customer-data migration. I wrote the rollback decision guide; operations ran the rehearsal. Capture this for my next review.
August 2026: product wanted a single customer-data migration while operations wanted a rehearsed fallback. Jules facilitated the planning discussion and wrote a rollback decision guide. Operations ran the rehearsal, and product owners agreed to migrate in phases. The migration had not yet run; no claim about a successful launch, time saved or reduced incidents is established.

For a leadership resume, Jules could ask to emphasize manager coaching and adoption planning. For an architecture role, the service-separation and deployment examples may matter more. External permissions still need review: this example only explicitly allows the shared talk and its Staff Engineer role externally.

See the source material

What stays unfinished?

The 35% estimate is still pending. The value of Jules’s coaching needs feedback from the engineers. Cross-team tradeoffs remain a proposed strength; the enterprise-scale wording needs correction. Sensitive supplier work stays private. None of these prevents Jules from retrieving the accepted record.