The honest version of this guide is short. There is a 12-week path from "I use Copilot at work" to "I can pass a panel-graded interview on the AI-assisted engineering rubric." It is not a fast path, and it is not a hard one. It is a deliberate one. Most engineers who get stuck do not get stuck on the material. They get stuck on the order. Skip frame and defend in week three, and the practice in weeks eight through twelve will not stick. Spend month one on tooling instead of workflow, and month three's interview prep will land on the wrong rubric. The plan below is the order we have watched work, against the rubric the hiring panels actually use.
Why this matters
Three years ago, the practice plan for a senior interview was a known quantity. Algorithm patterns. System design templates. A behavioural narrative. The structure was stable and the public material was good. That plan does not work in 2026, not because the topics disappeared but because the weights changed. Correctness is now the floor, not the discriminator. Defensibility is the discriminator. AI-rejection rate is graded. Replay clarity is graded. The behavioural answer matters less; the live defence of a code decision matters more.
This guide is the practice plan rebuilt against the v2.6 rubric. It is opinionated. It is sequenced. It assumes you already write working code. It does not assume you already know how to defend a decision to a reviewer who was not in the room.
If you have not read the complete guide to AI-assisted software engineering, read it first. The career plan below is downstream of the topology in that post. Reading them out of order works; the plan just makes more sense with the topology in mind.
What does the path actually look like?
The shape of the path is three phases. Each phase has a single goal and a single measurable milestone. The milestones are not aspirational; they are the gating criteria for moving to the next phase. Engineers who skip ahead without the milestone tend to repeat the next phase and lose a month. Engineers who stick to the milestone tend to clear all three.
The milestones are deliberately concrete. "Frame takes under ten minutes" is checkable; "feels confident about framing" is not. "Three replays at 3.5 or higher on calibrated peer review" is checkable; "have built a portfolio" is not. Engineers who hit checkable milestones tend to pass the loop; engineers who hit aspirational milestones tend to take longer.
The 12 weeks are calendar weeks, not effort weeks. Most engineers run this on top of a full-time job, with six to ten hours per week of dedicated practice. Going faster than this is possible but rare; we have seen engineers compress to nine weeks with a sabbatical or a transition period, and we have seen engineers stretch to sixteen weeks with parental leave or competing commitments. The phases stay in order at every cadence.
The most common reason engineers stall is that they skip the workflow milestone and start building portfolio replays before frame and defend are reflex. Portfolio replays built without the workflow read as polished diffs with weak defence notes. Reviewers grade them on what is visible, which is the weakness. Engineers in this position usually need to repeat weeks three and four with a tighter focus on the defend stage before re-entering the evidence phase. The lost two weeks are recoverable; the lost portfolio cycle is not, because the replays are dated and dated weak work undermines the strong work the engineer produces later.
What should you learn first?
The temptation in week one is to start with tools. Set up the new agent. Try the new model. Build the new keymap. Resist it. The tool is not the practice. The practice is the workflow. The workflow runs on top of any tool, and engineers who built the practice first move tools without losing skill. Engineers who built the tool first lose half the practice every time the model deprecates.
The foundational sequence below is the five steps we walk every engineer through in week one. They map one-to-one onto the workflow stages. They are designed to be learnable inside the first calendar week, not mastered. Mastery is the work of weeks two through four.
How to
Learn to frame in writing
Before any non-trivial PR, write three to seven sentences: what problem this solves, the constraints, the alternatives you considered, the criteria for done. The frame is for you and for the reviewer. Expect it to feel slow in week one. Frames take three minutes by week three.
Learn to draft inside the frame
Use the model to draft. Reject suggestions that drift from the frame, even if they are technically correct for a different problem. AI-rejection rate is graded. The skill is recognising when a plausible answer is the wrong answer.
Learn to verify the boundaries
Run an explicit boundary pass before merge. Auth, schema, external API, and any invariant the codebase relies on. The model will not raise the boundary. You have to look. Skipping verify is the single largest cause of silent regressions.
Learn to defend each load-bearing decision
Write down, in two or three sentences per major decision, why this option was chosen over the alternatives you named in the frame. The defence is evidence for the reviewer. Without it, the rubric scores defensibility from absence — and absence scores low.
Learn to produce a replay
Assemble the frame, the rejected suggestions, the verify checks, and the defence notes alongside the diff. This bundle is the replay. It is what the reviewer reads. Engineers who treat the diff as the deliverable score lower on replay clarity than engineers who treat the replay as the deliverable.
Practice the update under pushback
Once a week, ask a peer or a reviewer to push back on one defence. Notice whether you can update the position when the pushback is good or hold it when the pushback is weak. This is the single most under-prepared-for behaviour at the senior bar.
The sequence is six steps because we have added a sixth — update under pushback — that does not map directly to a workflow stage. We added it because it is the behaviour that separates the engineers who pass the loop from the engineers who almost pass. It is also the behaviour that is hardest to practise without a structured peer. Start it in week three and repeat it weekly through week twelve.
The patterns that make each step tractable are covered in AI pair programming patterns that work. The mental models for reading drafts you did not type are in three mental models for reading AI code.
How do you build evidence for the rubric?
Evidence is the artifact that lets a hiring panel grade you without an interview. The traditional version of this was a GitHub profile. The 2026 version is a replay portfolio — three to five complete replays that each demonstrate strength on a specific rubric dimension. Panels who can see your replays can pre-grade your work; engineers with strong portfolios skip the take-home stage at most of our partner organisations.
The portfolio is not a writeup. It is the actual replay — the frame, the rejected suggestions, the verify checks, the defence notes, and the diff — laid out the way a reviewer reads. Replays are graded on the same rubric as live sessions. The difference is that you control the framing.
| Evidence type | Rubric dimension demonstrated | What the reviewer looks for | Most common reason it fails |
|---|---|---|---|
| Debugging replay | Correctness + regression cost | A faulty trace, your reasoning, the fix, the regression check, the post-fix invariant. | Replay shows the fix but not the reasoning that produced it. |
| Refactor replay | Spec fidelity + defensibility | The original frame, the named alternatives, the discriminating criterion, the rejection of an AI suggestion that drifted. | No alternatives named; the chosen option appears without contrast. |
| Security replay | Regression cost + AI-rejection rate | Boundary identification before the diff; an explicit reject of a model suggestion that touched the boundary unsafely. | Boundary mentioned in the defence but not in the verify pass. |
| Feature build replay | Replay clarity + defensibility | End-to-end frame, draft, verify, defend, replay. The reviewer can grade every dimension from this single replay. | Too many decisions at once; reviewer cannot tell which decision was load-bearing. |
| Take-home replay | All six dimensions | The full workflow applied to a fresh problem, completed in the time budget. The replay is the deliverable. | Engineer optimised for code quality and skipped the defence stage. |
Three replays is the floor. Five is the comfortable bar. We have seen engineers ship strong portfolios with as few as three high-quality replays and weak portfolios with as many as ten low-quality ones. Quality matters more than quantity. The panel reviewer does not have time to grade ten replays; they pick the two strongest and grade those.
Peer calibration is the cheapest way to know whether your portfolio is strong. Trade replays with one peer running the same plan; grade each other against the rubric. The scoring is noisier than panel scoring but the trend is reliable enough to gate your phase. A peer score of 3.5 or higher across three replays is the milestone for week eight.
The take-home dimension is covered in detail in take-home assignments 2026 standout guide. The defensibility dimension is in defensibility, the skill AI can't replace.
What does the 12-week plan look like, week by week?
The week-by-week plan below is the schedule we hand engineers entering the platform on the career track. It is six to ten hours per week of practice, spread across three to five sessions. The tracked metric in the sparkline column is the engineer's defensibility score on the five-question self-review, normalised to a 100-point scale. Starting scores cluster around 40; ending scores cluster around 78 to 82. The shape of the climb is more reliable than the absolute numbers.
| Week | Phase | Focus | Deliverable | Defensibility trend |
|---|---|---|---|---|
| 1 | Workflow | Learn frame and replay stages on a small PR. | One framed PR with a written replay. | |
| 2 | Workflow | Add verify and defend stages; run all five. | Two PRs with the full workflow. | |
| 3 | Workflow | Start update-under-pushback drill with a peer. | One peer pushback session, recorded. | |
| 4 | Workflow | Run workflow on a non-trivial change. | Frame and defend each under ten minutes. | |
| 5 | Evidence | First portfolio replay: debugging. | One graded replay. | |
| 6 | Evidence | Second portfolio replay: refactor; repeat pushback drill. | Two graded replays; peer score 3.0+. | |
| 7 | Evidence | Third portfolio replay: feature build. | Three graded replays. | |
| 8 | Evidence | Calibration peer review of full portfolio. | Three replays at 3.5+ peer score. | |
| 9 | Loop prep | First mock panel session; pushback drill at session pace. | One mock panel session, scored. | |
| 10 | Loop prep | Second mock panel; system design with rubric anchors. | Second mock; rubric breakdown. | |
| 11 | Loop prep | Third mock with fresh reviewer; behavioural sweep. | Third mock; behavioural narrative. | |
| 12 | Loop prep | Two mocks back-to-back with no shared reviewers. | Pass both. You are loop-ready. |
The plan assumes you are already writing code at work and already using a model. If you are not, add a week-zero stage to set up the tool and write your first framed PR. Engineers transitioning from a non-coding role should expect to add four to six weeks of foundational coding practice before week one of the plan; the path is the same shape but the runway is longer.
How do you prepare for the interview loop?
The largest mistake we see in interview preparation is allocating time the wrong way. Engineers who have spent a decade preparing for algorithm interviews tend to default to algorithm drills, because the muscle memory is there. The rubric has moved. The drills have to move with it. The chart below is the time allocation we recommend across the loop-preparation phase, weighted by rubric impact.
Two notes on this allocation. First, coding drills get less time than most engineers expect — twelve hours over four weeks. This is intentional. You are already a working engineer; the floor on coding correctness is high. The discriminator is not the floor. Cutting coding drill time is not negligence; it is the redirection of time to the dimensions that move the score.
Second, mock panel sessions get sixteen hours — four to five sessions across the four weeks. Each session is roughly 90 minutes of session plus 30 minutes of structured debrief. The debrief is where most of the learning happens. Engineers who skip the debrief in favour of running more sessions tend to repeat the same mistakes across all of them; engineers who debrief carefully and run fewer sessions tend to climb faster.
The system design dimension under AI assistance is the topic of system design interviews, 5 patterns AI can't solve. The interview practice framework is in how to practice the AI-era interview. The cross-company shape of the interview loops is in Google vs Stripe vs Meta vs AWS interviews 2026.
Engineers who debrief carefully and run fewer sessions climb faster than engineers who run more sessions and skip the debrief. The mock is the data; the debrief is the learning.
What separates 'ready' from 'almost ready'?
We have graded a large enough number of mock sessions to see the cluster of behaviours that separate "ready" from "almost ready." The radar chart below shows the average skill emphasis for engineers we graded as ready versus engineers we graded as almost ready in 2026 H1. The two distributions overlap on coding correctness, system design, and behavioural narrative. They diverge on three dimensions: update-under-pushback, replay framing, and pre-written defence.
Update under pushback is the single largest gap. Almost-ready engineers hold their original position when the reviewer raises a good point. Ready engineers update the position and explain why the update is correct. The behaviour is teachable; it takes about three weeks of weekly pushback drills to internalise. Engineers who skip the drill rarely close this gap from reading.
Replay framing is the second largest gap. Almost-ready engineers' replays bury the load-bearing decisions inside long annotations. Ready engineers' replays surface them in the first sixty seconds — the title, the summary, the first decision-point. Reviewers read the first sixty seconds with attention; the rest with skim. The framing decides which decisions get the attention.
Pre-written defence is the third gap. Almost-ready engineers improvise the defence in the session. Ready engineers wrote it down during the defend stage of the workflow and re-read it before the session. The improvised defence sounds less rehearsed, which engineers think is a feature; the reviewer hears it as less considered, which is the bug. Pre-written defence does not mean memorised; it means thought through once before the session.
If your portfolio replays score above 3.5 on peer calibration but your mock sessions score lower, the gap is almost certainly in one of these three. Engineers in this position should not run more mock sessions; they should add a structured pushback drill, rewrite their top two replays for first-sixty-second framing, and write defence notes in the workflow rather than the interview.
The behaviour we see least often in "ready" engineers but want to flag for completeness: tool fluency does not predict readiness. Engineers who switch models weekly tend to score the same on the rubric as engineers who have settled on one model for a year. The pattern is consistent across cohorts. Tool fluency is real but it is not the discriminator. Engineers who optimise for tool fluency at the expense of workflow practice cluster in the "almost ready" group, not the "ready" one. The framework for choosing a tool once the skill is clear is in choosing an AI coding tool, 2026 framework.
The leveling shift for senior engineers is covered in from L4 to L5 leveling in the AI era. The senior-bar definition is in what senior engineer means in 2026.
How do you stay ready after you land the role?
The skill does not stay built. Engineers who pass the loop and stop practising regress over six to nine months — defensibility scores drift down, AI-rejection rate slides, replay clarity erodes. The drift is not catastrophic and it is not immediate, which is why most engineers miss it. By the time you notice — usually during a promotion review or an interview for the next role — the regression is six months old.
The maintenance loop is the same cadence as the build loop, scaled down. It is roughly 90 minutes of practice per week, sustained indefinitely. The shape is below.
Weekly self-review is the five-question defensibility drill on one of your own PRs. Pick one PR. Answer the five questions in writing. Compare your answers to what you would have written six months ago. The trend matters more than the absolute score. Engineers who run this weekly see the defensibility regression early enough to correct it; engineers who skip it for a quarter or more see the regression on a hiring panel.
Monthly replay study is reading one panel-graded replay from somebody else's session. The platform publishes anonymised graded replays for this purpose. The study is not for content; it is for calibration. Reading other engineers' replays at the bar you are trying to maintain keeps your own framing aligned. Most engineers who drift do so because their internal calibration drifts; the monthly study is the cheapest way to anchor it.
Quarterly rubric refresh is reading the current rubric version end to end. The rubric updates roughly twice a year. The updates are usually small — anchor refinements, weight adjustments, the occasional new dimension — but they accumulate. Engineers who do not refresh score against the old rubric and lose points on dimensions they did not know had changed. The refresh takes about 45 minutes per quarter. Pair it with reading the most recent panel-reviewer calibration notes; together they take an hour, and they catch the kind of slow drift that does not show up on the weekly self-review.
A useful supplementary practice for engineers in the maintenance loop is mentoring a peer through the 12-week build plan. Teaching the workflow forces you to articulate why each stage exists, and articulating it surfaces the parts of your own practice that have gone implicit. Engineers who mentor at least one peer per year retain their defensibility scores at a higher level than engineers who do not. The mentoring is not for the mentee; it is for you.
The leveling-up pattern after the role lands is the subject of from L4 to L5 leveling in the AI era. The on-call dimension and how to maintain the workflow under production pressure is in read production stack trace field guide.
The skill does not stay built. It stays built if you keep building it.
The 2026 study on which rubric dimensions best predict offer outcomes, behind the time-allocation recommendations in this guide.
From Codritium Research
Interview-Fit Signal, 2026
Does a Codritium platform score predict outcomes in FAANG-class interview loops? Tracking 318 candidates through 1,440 interview rounds at Google, Stripe, Meta, AWS, and 14 other employers.
Common questions
How long does this realistically take?
Twelve weeks is the median for working engineers running six to ten hours per week of dedicated practice. The fastest credible path we have seen is nine weeks during a transition period; the longest is sixteen weeks with competing commitments. Engineers who try to compress below nine weeks usually skip the workflow phase and fail the loop on defensibility. Engineers who stretch past sixteen weeks usually keep adding tooling instead of practising.
Do I need a degree?
No. The rubric does not grade credentials. It grades work. Engineers without a CS degree pass the loop at roughly the same rate as engineers with one, controlled for years of working experience. What matters is whether your replays demonstrate the rubric dimensions. The degree is a signal hiring panels can ignore once they have a strong portfolio.
Can I become an AI engineer without prior coding experience?
Yes, but the runway is longer. The 12-week plan assumes you can already write working code in at least one language. Engineers transitioning from non-coding roles should plan for four to six months of foundational coding practice before week one of the plan. The workflow itself is the same; the floor for entering it is different.
What if my employer doesn't let me use AI tools?
Run the workflow on personal projects until you have a portfolio. The plan does not require employer permission. Three to five replays on open-source contributions or side projects produce evidence the same way that work PRs do. The only thing that does not transfer is the on-call dimension; that one needs production context, which usually means a different employer.
How important is open-source contribution?
Helpful but not required. A single high-quality open-source contribution with a strong replay carries more signal than ten low-effort merges. The portfolio is graded on replay quality, not commit count. If your work PRs are not portable, open-source is the cheapest substrate for building the portfolio.
What if I fail an interview loop?
Most failures cluster on one of the three gaps in the 'ready vs almost ready' radar above. The debrief from a failed loop usually tells you which. Do not run another loop within the same week. Spend three to four weeks on the specific gap, run two mock sessions to verify the gap has closed, then run the next loop. Engineers who run loops back-to-back without debriefing tend to repeat the same failure.
Is there a 'too late' age?
No. We have onboarded engineers in their fifties and sixties to the rubric and the workflow without issue. The skill is not about being early to the model; it is about being deliberate about the workflow. Senior engineers who have spent decades developing judgement tend to take to the defensibility dimension faster than juniors, because they have practiced the underlying skill in a non-AI form for longer.
How do I know I am ready before paying for an interview?
Pass two mock panel sessions back-to-back with no shared reviewers, scored against the v2.6 rubric, with a final score at or above the senior bar. If you cannot run mocks with calibrated reviewers, the platform replay grading is the cheapest substitute. Three calibrated replay scores at 3.8 or higher approximate the same readiness signal as two passed mock sessions.
Where to go next
- Interview fit signal, 2026 — the study behind the time-allocation recommendations
- The complete guide to AI-assisted software engineering, 2026 — the topology this career plan sits inside
- How to practice the AI-era interview — the structured practice plan companion
- Defensibility, the skill AI can't replace — the deep-dive on the highest-weighted rubric dimension
- What panel reviewers actually look for — the read flow and signal hierarchy
- Take-home assignments 2026 standout guide — the take-home dimension of the loop
- Google vs Stripe vs Meta vs AWS interviews 2026 — the cross-company shape of the loops
- From L4 to L5 leveling in the AI era — the staying-ready dimension after the role lands
- Codritium platform challenges — practice tasks calibrated to the rubric
- Codritium replay — the tool the portfolio is built in