Career Checkpoint

After 62 days you have three released projects, and most people write "built RAG chatbot using LangChain" on a resume and stop there. Hiring teams skim for proof: numbers, what broke, what you decided. Today you turn R1–R3 into evidence while the numbers are fresh, and freshers start the slow part of interview prep (data structures and algorithms) now.

At a Glance

• Time: ~2 h core (+ optional Go Deeper) · Depth: intro
• Prerequisites: Day 62: Capstone R3, Part 2: Durable, Evaluated, Shippable, plus your skills_audit.md from Day 1: The AI Engineer: Role, Skills & How to Use This Course
• You'll build: four text files in your Atlas repo: skills_audit_v2.md, resume_bullets.md, application_plan.md and dsa_schedule.md
• Stops at: interview prep (Days 97–98). No STAR stories, negotiation, system design or portfolio polish today.
• Fast path: Already keep an up-to-date resume? Read §From Project to Bullet and §Two Tracks, Two Resumes, then do Exercise 3 (about 30 min).
• Cost: $0. No API calls and no code today.
• New terms: requirement map, evidence bullet, application cadence, DSA schedule

You Have More Than a Certificate

A certificate says you sat through something. A release with measured numbers in its README says you can ship. You have three, and each proves a different skill.

Open the three READMEs side by side. Every number you use today comes from them. If a README is missing a number, measure it now; a gap is cheaper to fix today than in an interview.

Freshers often feel behind at this point because the job postings look long. Name the progress first: if you scored the agents and evals groups near zero on Day 1, you have since shipped an evaluated agent.

A Code Review of Your Career

The plain version of today: take stock, translate what you built into the words a hiring manager scans for, and set a pace you can keep. Each step produces the input for the next.

The Day 1 vs Day 63 diff is the heart of the review. For each group, write one line on what moved and why, pointing at a file in your repo; those lines become your bullets later.

Re-Score the Audit

Copy skills_audit.md to skills_audit_v2.md, fill in its D63 column, and leave the D1 column untouched; keep the original file beside it as the frozen baseline. The D100 column waits for your last re-score. The audit is unchanged: the same 20 items in 8 groups, each scored 0–5 with the Day 1 anchors, for a maximum of 100.

One honest rule: score what you can do without notes. If you needed to reread Day 54 to remember how a checkpointer resumes a run, that item is a 3, not a 4. For every 4 or 5, write the file that proves it in the evidence column. A score you can't point at is a score you can't defend.

Read the total with the Day 1 bands: 0–30 means you are early in the material, 31–65 means you can build with guidance, and 66–100 means you can build and debug on your own. A middle-band total is normal here, with safety and production still ahead.

Expect uneven gains:

Flat safety and production rows are expected; they become "currently learning" lines in your plan.

What Employers Ask For, Mapped to What You Built

On Day 1 you saw the course's job signal. It came from 320 public AI-engineer, applied-AI and forward-deployed-engineer postings (a forward-deployed engineer builds AI solutions with a customer, often on site), counted on 2026-11-06. The sample leans heavily toward AI vendors, and a keyword appearing in a posting doesn't say how much the job uses it. Read it as a signal (as of 2026-11-06) and verify it against postings in your own market.

This time, put your evidence next to each row:

The top row matters most, and every release has a measured eval in its README. "I built a chatbot" is common; "here is how I know it got better" is your strongest sentence.

Map a Real Posting

A requirement map is a table that lists each line of a job description (JD) and, next to it, the specific file or README line that proves it, plus a status. The statuses are plain:

• Strong: a release shows it, with a number.
• Partial: you've built it in a lesson, but not in a release, or without a number.
• Gap: not covered yet. Say which later day closes it.

Here is a worked example on a sample JD. It is invented for this lesson; don't treat it as a real company's posting.

SAMPLE JD (invented): Applied AI Engineer
- Build and ship LLM features in Python
- Design evals and use them to drive changes
- Build agents that use tools and recover from failure
- Retrieval: search quality, ranking, citations
- Instrument LLM systems (tracing, cost)
- Ship to production behind an API; on-call rotation
- Nice to have: guardrails / prompt-injection defenses, multi-agent systems, TypeScript

Most Gap rows are ahead of you in the course, so they read as "in progress", not "missing". A switching engineer may already be Strong on "production API, on-call" from work history, not Atlas.

Do this for three real postings you would apply to (Exercise 2). After three, a pattern shows up: the same two or three Gap rows repeat. Those are your top-3 gaps, and they go into the plan.

From Project to Bullet

Most weak bullets list tools: "Built a RAG chatbot using FAISS". A strong bullet follows one formula, like a good commit message:

verb + what you built + stack + a number + the effect

Compare weak and better versions for each release. Every number below is an EXAMPLE. Replace it with a figure from your own README, or drop the number.

One rule decides which numbers survive: claim only what you can defend. In an interview, "how did you measure that?" is the first follow-up. For every number you should be able to say the dataset, how many cases, what the baseline was and what you changed. If you can't, cut the number.

Two Tracks, Two Resumes

The facts are the same for everyone; the order and framing differ, following your Day 1 track.

Two resume tops, for invented people:

SWITCHING (EXAMPLE)
Backend engineer, 6 years (payments, Python). Shipped three AI projects in 2026: a typed extractor,
a cited RAG assistant with access control, and a durable issue-investigation agent gated by evals.

FIRST ROLE (EXAMPLE)
BSc Computer Science, 2026. Projects: Atlas (an AI assistant for an open-source library):
extractor, RAG assistant with a live demo, and an eval-gated agent. Practising DSA daily in Python.

For LinkedIn, write three lines: what you build, one proof with a number, what role you want. Pin your R3 repo and the R2 demo. Polishing the portfolio itself belongs to Day 99: Building Your Portfolio.

When to Start Applying

Waiting until you feel ready is a mistake; so is applying everywhere with one resume. Use this rubric as a guideline, not a rule:

• three releases, each with README numbers;
• one deployed demo (R2's URL counts);
• one failure per release that you can explain: what broke, how you found it, what you changed.

A light start means researching roles, asking for referrals and sending 3 to 5 applications a week, editing the top three bullets for each posting. Switching engineers start now, as Day 1 suggested. Freshers keep Day 1's plan of applying in earnest from about R4, and use the weeks until then for the light version. Search for "AI engineer", "applied AI engineer", "forward-deployed engineer" and "LLM application engineer".

Freshers: Start the DSA Plan Now

Data structures and algorithms (DSA) rounds are common in first-role loops, and the skill compounds slowly, which is why Day 98: Practical Interviews: Coding, Take-Homes & DSA assumes you have started. (You will likely reach Day 98 before week 12; Day 98 continues from wherever you are.) Day 1 pencilled in 30 minutes a weekday; now that the schedule is concrete, budget 45 minutes, five days a week, for two problems per session, in Python, with a weekly review of the ones you missed. Work through topics in this order:

Week 1 by day (classic problems on any practice site). Save both tables as dsa_schedule.md:

Experienced engineers: you likely have the fundamentals, so a two-week refresh is enough. Week 1: arrays and hash maps, two pointers, stack, binary search. Week 2: trees, BFS and DFS, heap, graphs, two DP problems. Here is Two Sum solved by hand, which shows the hash-map pattern behind the whole first topic:

nums = [2, 7, 11, 15], target = 9, seen = {}
2:  need 9 - 2 = 7, not in seen  -> store seen[2] = 0
7:  need 9 - 7 = 2, found in seen -> answer is [0, 1]

One pass: a dictionary lookup replaces the second loop.

Your 30-Day Application Plan

Each week has four lanes. Save your version as application_plan.md:

Track every application in a sheet with these columns: company, role, link, date applied, source (referral or cold), bullets tailored, status, next action and date, and "what the posting asked that I lacked", which feeds your next gap list.

In production

• Keep your four files in the Atlas repo, so the history shows progress.
• Date your README numbers, and re-measure after any release that changes behaviour.
• Ship one write-up per release; Day 99 shows how.
• Avoid tool-chasing: a new framework rarely moves your odds as much as one more measured result.
• Re-score the audit again on Day 100 and compare it with today.

Go Deeper (optional)

Common Pitfalls

• Inflated re-score. Symptom: a total of 85 and no files behind it. Cause: no evidence required. Fix: score without notes, and link a file for every 4 or 5.
• Tool lists instead of outcomes. Symptom: "used LangChain, FAISS". Cause: no number or decision. Fix: verb + number + effect.
• Numbers you can't defend. Symptom: you freeze at "how did you measure that?" Cause: copied the example numbers. Fix: use your own README figures, or drop the number.
• Waiting, or spraying. Symptom: zero applications, or 100 identical ones. Cause: waiting for certainty, or no tailoring. Fix: 3 to 5 a week, with the top three bullets edited for each posting.
• Skipping DSA until invitations arrive. Symptom: a coding round in two weeks and no practice. Cause: it takes months. Fix: schedule 45 minutes each weekday, starting now.
• Copying the sample JD mapping. Symptom: your map matches this lesson line for line. Fix: map three postings you would actually apply to.

Key Takeaways

• Your three READMEs are evidence, and every number you use on a resume comes from them.
• Re-score the same 20-item audit without notes, write one line per group on what moved, and link a file for every 4 or 5.
• Map real postings to your work as Strong, Partial or Gap; repeated Gaps are your top-3 plan.
• A bullet is verb + what + stack + number + effect, and you must be able to defend every number.
• Start applying lightly once the rubric holds; freshers also start a DSA schedule today.

References & Further Reading

• LLM evals FAQ (Hamel Husain): why evals are the most requested skill and how practitioners approach them.
• AGENTS.md: the convention behind the coding-agent evidence in Day 60.
• CS50's Introduction to Programming with Python: a free course if your Python needs strengthening before DSA practice.
• The Python Tutorial: lists, dictionaries and sets are the tools of the first DSA topic. Day 98 links a full DSA roadmap.