Project defence drills
Rashmi put a chatbot project on the first line of her resume. The panel in Amravati liked it and asked for one change. Make it answer only from last year's policy files, they said. She opened her own repository and could not find where the files were loaded. The code was clean, and it was not hers. The room stayed polite for six more minutes. Nobody asked about the other two projects on the page.
- This is the one round where a chatbot cannot sit beside you. Nobody is reading your code here; somebody is watching you change it.
- It is also how this course grades you. Your projects are scored by defence, so the drill in this module is the drill you are marked on.
- The hard work is already done. You built the churn model and the RAG assistant, so this module teaches you how to talk about them.
A project defence — ten to twenty minutes on something you built, with the interviewer free to go anywhere — is the deep-dive round. There is no question list. She reads your resume line or your repository, picks one thread, and pulls it. Where she pulls next is decided by what you said last.
This module carries a plain ruling from the course. A model can write code that looks like yours, and no tool can tell the two apart with any reliability. Hidden test cases do not fix that either, because a test in your hand is a test a model can read. So the course grades projects by defence, since explaining and changing your own work live is the part no chatbot can do for you. The interview does the same thing, for the same reason.
That answers the fair question a student asks. Why not let AI write the project? Because the defence is the assessment, and the defence is also the interview. Code you cannot explain earns you nothing on either side of that sentence.
An interviewer is checking four things, and every probe you hear is one of them in different words. Do you understand what you built? Did you make the decisions, or copy them? Do you know its limits, and can you change it while I watch? The figure shows what each check sounds like and what a passing answer carries.
Open with a walkthrough — a ninety-second tour of one project in four parts. The parts are problem, approach, result, limit, in that order. Ninety seconds is short on purpose, because a five-minute tour reads as a rehearsed speech. Then stop talking and let her choose the next step. That pause is the offer, and a good interviewer always takes it.
After the pause you answer depth on demand. She names one part of your ninety seconds, and you give two more minutes on that part alone. She goes deeper, then deeper again, the way module 6.4 drilled. The tour is wide and shallow; every answer after it is narrow and deep.
Write the reason down on the day you decide it. A decision log — a dated list of what you chose, what you rejected and why — costs two minutes per entry. Six weeks later you will remember the choice and forget the reason, which is the exact half an interviewer asks for. Module 4.4 already made you log every run, and module 1.8 made you keep honest comparison tables. The decision log is the sentence you write beside those rows.
Some facts about your own work must arrive with no pause at all. A numbers card — one page of the figures you must know cold — holds the dataset size, the baseline, your metric and its value, and what you compared against. It also holds latency and cost if the thing is served, plus the one change you would make next. Not knowing somebody else's number is normal. Not knowing your own reads as a project you did not run.
The hardest part is live modification — the interviewer changes one constraint and you reason through the change in your own code. What if the data doubled, or the label arrived sixty days late? What if this feature disappeared next month? She does not want the change built in the room. She wants the file, the function, the number that moves, and the risk you would watch.
Name your weak spots before she finds them. This limits-first habit scores higher than defending a weakness after it is exposed, and it costs you nothing you were keeping. A candidate who says "it misses 13 churners of 39, and here is why that is the number I would attack next" sounds like an owner. A candidate who argues that 13 misses are fine sounds like a risk.
Here is the contrast this module exists for. One student lists a project that runs and cannot be touched, so the first change request ends the round. Another lists a smaller project and opens the file, names the function and prices the change in front of you. The second project is weaker on paper and wins the offer.
"Did you build this yourself?" is a normal question now, and it needs a real answer. Evasion fails, because the follow-up always lands on a line you cannot explain. Over-claiming fails harder, since "I wrote every line" collapses the moment she asks about one you did not. The professional answer has three parts: what you used AI for, what you decided yourself, and what you verified. Using a model to learn faster is fine and common; handing it your understanding is the loss.
Prepare one defence dossier per project — a single page holding the walkthrough, the numbers card, the decisions, the limits and your modification answers. It takes about an hour and it is reusable for every company you meet. Two defended projects beat six listed ones, every time. Cut any resume line you cannot hold for ten minutes of questions, because one weak line puts every other line in doubt.
Six worked artefacts, not code. Read the block, then read the notes under it. Every one of them is built on projects you already own: the churn model from Phase 1 and Phase 4, and the RAG assistant from Phase 3.
Piece 1 — the ninety-second walkthrough, delivered well. The interviewer says one line: "take me through something you built."
# PIECE 1 - THE 90-SECOND WALKTHROUGH. Churn project. Annotated.
Q: Take me through one project you built.
A: [PROBLEM - about 20 seconds]
A grocery-delivery company in Ludhiana lost customers quietly. The
business only learnt about it when a customer stopped ordering, and
by then nothing could be done. I built a model that flags a
customer as likely to leave while a voucher can still reach them.
[1] Two sentences of business, one of what he built. No tool names
yet. The interviewer now knows WHY the code exists.
[APPROACH - about 30 seconds]
500 customers, six features - three raw columns and three I built,
including days since last order and a salary-week ordering ratio.
Stratified 75/25 split. A scaler and a logistic regression sealed
inside one scikit-learn Pipeline, so the scaler refits inside every
fold and never sees a test row.
[2] Decisions, not a library list. "Sealed inside one Pipeline"
and "never sees a test row" are the leakage answer, given
before anybody asked for it.
[RESULT - about 25 seconds]
Accuracy 0.824 against a do-nothing baseline of 0.688, and recall
0.667 - it catches 26 of the 39 churners in the test set. I served
it with FastAPI at p50 12 ms and p95 19 ms, and I run a daily
PSI check on every feature to catch drift.
[3] BASELINE FIRST, then the score. A score with no baseline beside
it is not a result, it is a number.
[LIMIT - about 15 seconds]
The honest limit is that it still misses 13 churners of 39, and the
table is a seeded world, not a real company's data. So what I trust
is the shape of the trade-off, not the third decimal of 0.824.
[4] The weakness, volunteered. This is the limits-first habit, and
it steers the next question towards ground he has prepared.
Happy to go deeper anywhere - the feature work, the threshold, or
the drift monitor.
[5] The handover. He stops at 90 seconds and lets her choose. A
candidate who talks for five minutes has answered a question
nobody asked and used the depth time on the tour.
TOTAL: 92 seconds. Four parts. One offer to go deeper.
The order is the whole trick, because problem-first tells the interviewer why anything that follows matters. Line [2] shows the difference between naming decisions and naming tools: "sealed inside one Pipeline so the scaler never sees a test row" is a decision with a reason, while "I used scikit-learn" is a fact about the world. Line [3] puts the baseline before the score, which is the single cheapest signal of a person who has read module 1.1 and believed it. Line [4] volunteers the miss count, and volunteering it is what makes the rest of the tour believable. Line [5] is the part students skip: ninety seconds and a full stop, because the depth is where the marks are, and you cannot reach it if you are still talking at minute five.
Piece 2 — the same project under depth probing. Five follow-ups, each one level deeper, until an honest edge:
# PIECE 2 - THE DEPTH LADDER ON YOUR OWN PROJECT. Five rungs.
RUNG 1 Q: Why logistic regression and not gradient boosting?
A: Two reasons. I ran both, and boosting scored 0.816 against
logistic's 0.824 on this table - inside the noise, so the
simpler model wins on my own module 1.8 rule. And the
retention team has to be told WHY a customer was flagged;
six coefficients can be read out, a boosted ensemble
cannot without extra work.
-> Comfortable ground. He compared, and he can say the score
of the model he did NOT ship. That second half is rare.
RUNG 2 Q: Recall 0.667 at the default gate. Did you move it?
A: Yes. I swept the threshold from 0.2 to 0.7. At 0.35 recall
went to 0.77 and precision fell from 0.72 to 0.58, so I
caught 30 of 39 instead of 26 and sent about 12 extra
vouchers. At 50 rupees a voucher that is 600 rupees to
save four customers, so I shipped 0.35 and wrote the
reason in the decision log.
-> He converted the trade into rupees and named where the
reason is written down. Rung 2 is where memorised answers
usually stop.
RUNG 3 Q: Your Phase-1 notes say the baseline was 0.74. Your repo
says 0.688. Which one is wrong?
A: Neither. The baseline is a property of the class balance,
not of my model. The early table had 26 churners in 100
test rows, so doing nothing scored 0.74. The Ludhiana
table has 39 churners in 125 test rows, so doing nothing
scores 0.688. Same rule, different mix, so the number a
model must beat moved.
-> This is the trap rung. A candidate who copied the write-up
has two numbers and no explanation. He has one idea.
RUNG 4 Q: Your PSI monitor flagged orders_last_90d at 0.31 one week.
What did you actually do?
A: I did not retrain that day. PSI says the inputs moved, not
that the model is wrong, and my labels arrive about 60 days
late, so the freshest recall I could score was two months
old. I raised a ticket rather than a page, checked whether
any other feature moved - none did - and found a rival app
had changed ordering habits. My retrain trigger needs PSI
at or above 0.2 sustained, or rolling recall under the 0.60
gate for two weeks. Only the first had fired.
-> Rung 4 asks for judgement under uncertainty. He separated
"inputs changed" from "model is wrong", which is the whole
of module 4.8 in one sentence.
RUNG 5 Q: How would you tell real drift apart from a seasonal dip,
statistically?
A: That is my edge, and I will tell you exactly where it ends.
I know PSI is blind to season, because it compares one
window against a fixed training window and has no memory of
last year. With 500 seeded customers and no multi-year
history, I could not test any seasonal correction. What I
would do is hold out the same calendar weeks from earlier
years as a comparison window, and read up on seasonal
decomposition before I claimed anything stronger. Today I
handle it by asking the business whether the week was
unusual, which is a human check, not a statistical one.
-> THE EDGE, handled well. Named the limit, said why his data
could not settle it, gave a route, and named the stopgap he
actually uses. The ladder was designed to end here.
INTERVIEWER'S NOTE: "Knows his own numbers and the numbers of the
model he rejected. Found his ceiling at rung 5, above the fresher
bar. Recommend."
Five rungs is a normal ladder and reaching the top of yours is the goal, not the accident. Rung 1 rewards a habit rather than a fact: he can quote the score of the model he did not ship, which proves the comparison happened. Rung 3 is the rung to study, because two different baselines in two documents look like a lie until you can explain that a baseline belongs to the data, not to the model. Rung 4 is judgement, and the answer works because he says what he did not do and why the trigger had not fired. Rung 5 is the honest edge from module 6.4, with one addition worth copying: he names the human stopgap he uses today, so the edge is a boundary and not a hole.
Piece 3 — the live-modification drill. The interviewer stops asking about the past and changes the world:
# PIECE 3 - LIVE MODIFICATION. Three changes, one open repository.
CHANGE 1 - "Your 500 customers become 100,000 tomorrow. What breaks?"
A: Say what does NOT change first: the features, the target, the
split discipline and the metric all survive, so config.py and
src/features.py are untouched.
What DOES change:
- train.py fits in memory today at 500 rows. At 100,000 rows a
logistic regression is still fine on a laptop - it is one pass
over a small matrix - so the model is not my first worry.
- data.py currently regenerates a seeded world and writes a csv.
At 100,000 rows I would stop regenerating and read from the
warehouse, so that function becomes a query with a date filter.
- The one-hot encoder on city is safe at 5 cities. At national
scale that becomes hundreds of pincodes, which is module 1.6's
wide-matrix problem, so I would switch to frequency encoding.
- The real change is the label mix. 39 churners in 125 test rows
is a small positive count, and my recall of 0.667 has a wide
error bar around it. With 100,000 rows that number gets
trustworthy for the first time, so I would rerun the threshold
sweep before shipping anything.
The risk I would watch: the seeded world is uniform and a real
100,000 rows will not be. My scaler statistics would move.
CHANGE 2 - "days_since_last_order is being removed from the source
system next month. Show me what you do."
A: That is my strongest feature, so I will price the loss first
rather than pretend the model survives untouched.
- It is built in src/features.py from order_date and
SNAPSHOT_DATE, so the removal is upstream of me: order_date
itself is going, not my derived column.
- Step one is measurement, not repair. I refit without it and
report the new recall beside 0.667. If it drops from 26 of 39
to something near the 0.688 baseline, then the model WAS that
feature and rebuilding is honest work, not tuning.
- Step two is a replacement built from what remains. Order counts
per week give me a recency shape without a date column, so
orders_last_90d minus orders_last_30d becomes a slowdown
signal.
- Step three is the write-up. A model that lost its best feature
needs a new baseline, a new threshold sweep and a note in the
decision log saying the two versions are not comparable.
What I would NOT do: keep the old score on the dashboard. That is
how a team keeps trusting a model that has quietly changed.
CHANGE 3 - "The churn label now arrives 6 months late, not 60 days."
A: Nothing in the training code changes. Everything in monitoring
does, and so does what I am allowed to claim.
- monitor/outcomes.py scores rolling recall against the 0.60 gate.
At 6 months late, the freshest recall I can compute describes a
model version that may already be retired, so that alert loses
most of its value.
- My retrain trigger set has three rules and one of them just
died. So PSI drift and the calendar rule carry the weight, and I
would lower the sustained-PSI window rather than the threshold.
- I would add a fast proxy label. "No order in 45 days" is not
churn, but it correlates with it, and I can measure that
correlation once on history. Then I monitor the proxy weekly and
confirm with the real label twice a year.
- The honest cost: a proxy is a different target. If I ever report
recall on the proxy I must say so, or I am quietly moving the
goalposts, which is the failure module 6.5 warns about.
Three moves repeat in all three answers, and they are what you rehearse. Say what does not change, name the file and the function that does, then price the risk. Change 1 rewards arithmetic over panic: a hundred thousand rows is small, and saying so is stronger than naming five tools you would add. Change 2 is the hardest kind, because the interviewer removed his best feature, and the professional response is to measure the loss before designing the repair. Change 3 shows the habit that separates a fresher from a hire — a proxy label is allowed, and calling proxy recall "recall" is not.
Piece 4 — the numbers card, filled in for both spine projects. Print this and keep it current, because every figure here can be asked with no warning:
# PIECE 4 - THE NUMBERS CARD. One per project. Know these cold.
=== PROJECT A: CHURN MODEL (Phase 1 + Phase 4) =====================
DATA 500 customers, 6 features (3 raw, 3 engineered)
375 train / 125 test, stratified, seed 42
39 churners in the test set = 31% positives
BASELINE 0.688 accuracy by predicting "stays" for everyone
(86 stayers of 125). Catches 0 churners.
METRIC Recall, because a missed churner costs a customer and a
false alarm costs a 50-rupee voucher.
MY NUMBER accuracy 0.824, recall 0.667, caught 26 of 39
at the shipped 0.35 threshold: recall 0.77, 30 of 39
COMPARED do-nothing baseline 0.688 | decision tree 0.81
AGAINST gradient boosting 0.816 | logistic 0.824 (shipped)
SERVING FastAPI, one container, p50 12 ms, p95 19 ms,
error rate 0.16% over a replayed week
MONITORING PSI per feature daily (alert at 0.2), rolling recall
against a 0.60 gate, labels about 60 days late
ONE CHANGE Real data. The seeded world has clean columns and no
missing values, and every number above inherits that.
=== PROJECT B: RAG ASSISTANT (Phase 3) =============================
DATA One HR policy document, 14 paragraphs, about 7,000
characters, chunked by paragraph
Embeddings: nomic-embed-text, run locally with Ollama
Generator: llama3.2:1b, also local
RETRIEVAL Top 3 chunks by cosine similarity
BASELINE The same generator with NO retrieval, answering from
memory: it invented a notice period that is not in the
document. That is the comparison that justifies RAG.
METRIC Two, measured separately: retrieval hit rate and
groundedness. Mixing them hides which stage is broken.
MY NUMBER hit rate 10 of 12 golden cases; groundedness judged by
an LLM-as-judge with a strict rubric, audited against my
own labels on all 12
EVAL SET cases.jsonl - 12 cases: golden, edge, and 1 adversarial
case whose only passing answer is a refusal
COST Zero rupees. Everything runs offline on my laptop, which
is also why I cannot quote a production latency.
ONE CHANGE 12 cases is too small to trust a 1-case swing. The next
version needs 50, and a holdout I never tune against.
RULE: if a line on this card takes you more than three seconds, you
do not know it yet. Numbers about somebody else's system may be
looked up. Numbers about your own may not.
Two cards, one shape, and the shape is the point. The baseline line is compulsory on both, and notice that project B's baseline is not a number at all — it is the same generator with retrieval switched off, which is the honest way to show that retrieval earned its place. The "compared against" row is where most students go quiet, because comparing costs runs and remembering the losers costs a decision log; an interviewer who hears three model scores knows the comparison happened. Project B's cost line is a limit stated as a fact, since running offline means no production latency to quote, and saying that is better than inventing one. The last rule is the drill: three seconds, or it is not yours yet.
Piece 5 — "did you build this yourself?" answered three ways. Same student, same project, three different rounds:
# PIECE 5 - THE AI-ASSISTANCE QUESTION. Two failures, one pass.
Q: Did you build this yourself, or did you use AI?
--- ANSWER A: EVASIVE (fails) ---
A: I mean, everyone uses tools now. It is all standard code anyway.
[1] Answers a question about ethics with a question about fashion.
She asked what YOU did.
[2] "Standard code" is the tell. If it is standard, explain it.
Q: Fine. Walk me through the function that builds the features.
A: It is a fairly standard feature engineering step, it makes the
columns the model needs...
[3] Two probes and there is nothing under it. The interviewer now
doubts the whole resume, not this one project. That is the
real cost: doubt spreads sideways.
--- ANSWER B: OVER-CLAIMING (fails harder) ---
A: No AI at all. I wrote every line myself from scratch.
[1] A large, checkable claim, offered for free.
Q: Good. Why did you pass class_weight to LogisticRegression there?
A: For... better accuracy, mainly.
[2] Wrong, and now the earlier claim is a lie rather than a gap.
class_weight trades accuracy for recall; it usually LOWERS
accuracy. He copied the line and claimed authorship of it.
Q: And the pinned scikit-learn version in requirements?
A: I think that came with the template.
[3] The claim collapses in his own words. Version A left doubt;
version B left proof. Over-claiming is the worse failure.
--- ANSWER C: THE PROFESSIONAL ANSWER (passes) ---
A: Yes, I used it, and I can tell you exactly where.
[1] Direct, first sentence, no defensiveness.
WHAT I USED IT FOR: boilerplate and explanation. It wrote my first
FastAPI request model and my Dockerfile skeleton, and I asked it
to explain a scikit-learn error about feature names twice.
[2] Specific. Named the files. Vague honesty reads like evasion.
WHAT I DECIDED MYSELF: the target definition and its 90-day
window, the six features, recall over accuracy, the 0.35
threshold after the rupee sweep, and the choice to ship logistic
regression over boosting at 0.824 against 0.816.
[3] The decision list IS the project. This is the part that came
from his decision log, written on the day, not remembered.
WHAT I VERIFIED: I rewrote the generated Dockerfile after it
installed packages before copying requirements, which broke the
layer cache. And I checked the FastAPI model against a bad
request myself, because the generated version accepted a negative
income without complaint.
[4] The strongest part. He caught the tool being wrong, twice,
with specifics. Nobody who did not do the work can say this.
Q: Good. Change the threshold logic to read from config - where?
A: config.py holds SEED and TEST_SIZE today, so THRESHOLD goes
there, train.py reads it when it writes the sweep table, and
predict.py reads it at scoring time. Two files import it, and the
test in tests/test_predict.py pins 0.35, so that assertion moves
too.
[5] And there is the actual proof. The disclosure was words; this
is the demonstration. Order matters - she asked AFTER the
honest answer, not instead of it.
INTERVIEWER'S NOTE on C: "Used AI the way we use it. Knows what he
decided. Caught two generated mistakes. No concerns."
Answer C passes because it is more specific than either failure, not because it is more humble. The three parts do different work: what you used it for shows you are normal, what you decided shows the project is yours, and what you verified shows you were the senior party in that conversation. Line [4] is the one that changes the room, since catching a generated Dockerfile ordering bug is a thing only a person who ran the build can report. Line [5] is the reason the whole module exists — she followed the honest answer with a change request, and the change request is the real test. Notice that answer B fails harder than answer A, because a doubt costs you one project and a disproved claim costs you the page.
Piece 6 — the defence dossier, filled in. One page per project, written once, updated when the project changes:
# PIECE 6 - DEFENCE DOSSIER. Project: churn model. Updated 12 Aug.
1. THE 90-SECOND WALKTHROUGH (write it, then time yourself)
Problem : a Ludhiana grocery-delivery firm learnt about churn
only after the customer had gone.
Approach : 500 customers, 6 features, stratified 75/25 split,
scaler + logistic regression sealed in one Pipeline.
Result : 0.824 accuracy vs 0.688 baseline, recall 0.667,
26 of 39 caught; served on FastAPI, p95 19 ms.
Limit : misses 13 of 39; seeded data, not a real table.
Measured spoken length: 92 seconds.
2. NUMBERS CARD -> see piece 4, kept current
3. DECISION LOG (the WHY, written on the day)
14 Jun Target = no order in 90 days. Rejected "closed account"
because the firm has no account closure flow.
16 Jun Recall over accuracy. Miss costs a customer worth about
3,000 rupees a year; false alarm costs a 50-rupee
voucher. Ratio decided the metric, not the textbook.
18 Jun Six features. Rejected pincode one-hot: 900 columns for
20,000 rows, module 1.6's wide-matrix problem.
21 Jun Logistic over boosting. 0.824 vs 0.816 is inside noise,
and the retention team must be told why a customer was
flagged. Module 1.8's tie-break rule.
24 Jun Threshold 0.35 from the rupee sweep, not from F1.
02 Aug Did not retrain on the PSI 0.31 week. Trigger needs
sustained drift or two weeks under the recall gate.
4. THREE LIMITS I NAME BEFORE ANYBODY ASKS
a. Seeded data. Clean columns, no missing values, one region.
Every number I quote inherits that.
b. 13 of 39 churners still missed at the shipped threshold.
c. Labels arrive about 60 days late, so today's monitoring is
an early warning, never a verdict.
5. THREE MODIFICATIONS I HAVE ALREADY REASONED THROUGH
a. Data 200x bigger -> piece 3, change 1
b. Best feature removed -> piece 3, change 2
c. Labels 6 months late -> piece 3, change 3
6. THE AI-ASSISTANCE ANSWER (three parts, rehearsed)
Used for : FastAPI request model, Dockerfile skeleton, two error
explanations.
Decided : target and window, features, metric, threshold, model.
Verified : rewrote the Dockerfile layer order; caught the request
model accepting a negative income.
7. THE FILE MAP (so I can open the right file in 5 seconds)
config.py SEED, TEST_SIZE, SNAPSHOT_DATE, feature list
src/data.py loads or regenerates customers.csv
src/features.py the three engineered columns
src/pipeline.py scaler + model, sealed
train.py fit, score, save joblib
app/main.py FastAPI, /predict and /health
monitor/drift.py PSI per feature
8. WHAT I WOULD BUILD NEXT, AND WHY
Real data from one partner store, 3 months. Every limit above is
a data limit, so more modelling is the wrong next move.
The dossier is an hour of work and it is the difference between remembering your project and defending it. Section 3 is the section students skip and the section interviewers live in, because each line answers a "why" question that arrives months after you decided it — and each line was written on the day, when the reason was still in your head. Section 4 is the limits-first habit turned into a list, so the weaknesses come out of your mouth before they come out of hers. Section 7 looks trivial and saves rounds: when the interviewer says "show me where that happens", opening the right file in five seconds is itself evidence. Section 8 answers the question that closes most defences, and the strong answer names data, not another model.
Work in a folder called defence with four files: dossier.md for the one-page dossier per project, numbers.md for your cards, decisions.md for the log you should have been keeping since Phase 1, and drills.md for graded attempts. Grade every attempt on the ten-mark rubric below, including when you are grading yourself and would rather not.
The ten-mark defence rubric, two marks per area: (1) walkthrough — four parts in order, under two minutes, ends with an offer to go deeper; (2) numbers — dataset size, baseline, metric and value, and one comparison, all with no pause; (3) decisions — at least three choices defended with the reason and the rejected option; (4) limits — three weaknesses named before being asked, one of them about the data; (5) live modification — names the file, the function, the number that moves and the risk, without asking for time.
Build the defence dossier for your strongest project. Pick the project you would put on line one of your resume — for most of you that is the churn repo from Phase 4 or the RAG assistant from Phase 3. Write dossier.md with all eight sections from piece 6, filled with your own numbers and file names, not the lesson's. Rebuild the decision log honestly: open your git history, your MLflow runs and your old notes, and write one dated line per decision with the option you rejected and the reason. Mark any decision whose reason you can no longer reconstruct as REASON LOST and keep it in the file, because that list is what the habit is for. Then write your numbers card in numbers.md, close every file, and have somebody read the card out to you as questions while you answer from memory with a stopwatch running. Check: dossier.md holds all eight sections for one project, with real file paths from your own repository in section 7; the decision log has at least six dated entries, each naming the rejected option and the reason, with every unreconstructable entry marked REASON LOST and counted; section 4 lists three limits and at least one is about the data itself; section 5 names three modification scenarios that are specific to your project, not copied from piece 3; and your stopwatch run records how many of the card's lines you answered inside three seconds, with the failures listed for tomorrow.
The live-modification drill, run inside your own code. Open your project with the files visible and a timer at ten minutes per scenario. Run six changes against it: the data grows 200 times; your strongest feature disappears; the label arrives four times later than it does today; the model must answer in 20 ms instead of 200; the business asks for an explanation with every prediction; and one you invent that would genuinely hurt your design. For each, write in drills.md what does not change, the file and function that do, the number you expect to move and in which direction, and the risk you would watch. Then actually make one of the six changes in code, run it, and record whether the number moved the way you predicted. Finish by writing the AI-assistance answer for this project in three parts — used for, decided, verified — with specific file names in each part, and read it aloud twice. Check: all six scenarios are written up with the four required elements, and the "what does not change" line comes first in every one; at least four scenarios name a real file and function from your repository; one scenario is implemented in code with the before and after numbers recorded, and you state in one sentence whether your prediction was right and what you learnt if it was not; your three-part AI answer names at least two specific files and one thing you verified or corrected in generated code; and you mark the scenario you found hardest with two sentences on why.
The pair defence, fifteen minutes each way, graded on the rubric. Pair with a classmate who has not seen your project. You present the ninety-second walkthrough, then your partner probes for fifteen minutes using the depth ladder from piece 2: never sideways, always one level deeper than your last answer, and at minute nine they must throw one live-modification change. Their rules are strict — no helping, no filling your silences, and every claim you make about a number gets checked against your own repository on screen. They score you out of ten as it happens and write one line of evidence for every mark refused. Then swap chairs and do the same to them with a different project. Finish with fifteen minutes comparing the two transcripts, and each of you records the exact question where you first went vague. Check: drills.md holds both rounds with the questions asked at every rung and the minute the modification landed; both defences are scored out of ten with written evidence for every refused mark; every number a defender quoted is marked verified or unverified against the repository on screen, and any unverified one is added to the numbers card as homework; each of you quotes the exact sentence where you first went vague and writes the answer you should have given; and you both name which chair taught you more and why, in three sentences.
Working alone? Use the solo substitute defined in project P1: record a full fifteen-minute self-defence against the ten-mark rubric — walkthrough first, ladder questions you set for yourself in advance, one live modification at minute nine — then grade the recording line by line with written evidence for every mark you refuse.
Three defence failures, all common and all fatal in ways students do not expect. Each has a War Room entry with the full diagnosis path:
- WR-163 — the project that was not theirs. A tutorial-shaped project on a resume collapsed on the second follow-up and the offer was withdrawn; the fix is the ten-minute rule for every resume line, plus the rebuild-it-yourself remedy that turns a borrowed project into a defensible one.
- WR-164 — the numbers nobody remembered. A candidate could not state their own dataset size or baseline, and a real project started to read as an invented one; the fix is the numbers card, kept current, and the three-second drill that proves you own it.
- WR-165 — the defensive candidate. A real weakness was pointed out and the candidate argued for four minutes instead of naming it; the fix is limits-first framing and the "you are right, and here is what I would do" move.
A project defence is ten to twenty minutes on something you built, and it exists because AI-written code cannot be detected while an owner can always be questioned. Four checks run underneath every probe: do you understand it, did you decide it, do you know its limits, and can you change it live. Open with a ninety-second walkthrough of problem, approach, result and limit, then stop and answer depth on demand. Keep a decision log written on the day and a numbers card you can recite in three seconds, because your own dataset size, baseline and metric may never be looked up. Name your limits before anybody finds them, answer the AI-assistance question in three honest parts, and list no project you cannot defend for ten minutes.
- IT services and GCC panels in India now open the deep-dive round with a change request rather than a description request. A candidate who cannot edit their own repository on a shared screen is read as somebody who did not write it, whatever the resume says.
- Analytics teams at banks and NBFCs treat the numbers card as the whole interview. Dataset size, base rate, baseline and the cost of each mistake are the daily language of a risk team, so a fresher who has them ready sounds like a colleague.
- Product and startup teams hiring for GenAI work ask about AI assistance openly, because everybody on the team uses it. The three-part answer is the normal professional reply there, and evasion is the only thing that reads as a problem.
Answer these aloud before opening the gate assessment. Each question names its kind.
type=interpretation— A candidate gives a fluent five-minute tour of a project, then cannot say what the do-nothing baseline was. The panel note reads "good communicator, could not confirm ownership". Interpret what the note is really about, and name the two habits from this module whose absence produced it.type=scenario-judgement— Halfway through your defence the interviewer says "this feature would not exist in production, would it?" and she is right. Give your ruling on what you say next, the exact first sentence you use, and justify it against what the round is measuring.type=trade-off— Compare listing six projects on your resume against listing two you have dossiers for. Give one concrete gain and one concrete cost of each, then name the single situation that would flip your choice.type=debug— A student's practice defences score well until the modification question, where they always ask for a minute and then describe the change in general words. Diagnose the underlying cause from that pattern alone, and give the one change to their preparation that fixes it.type=output-prediction— A candidate answers the AI-assistance question with "no AI at all, every line is mine", and the interviewer's eyes go to a line the candidate cannot explain. Predict the interviewer's next two questions, what the candidate's answers will sound like, and what the note at the end of the round will say.
Explain to a friend from a non-technical degree why a company asks you to change your own project in front of them, rather than reading the code you sent. Use an everyday comparison, such as a tailor who is asked to alter a shirt he claims he stitched, and can find the seam in one second. Then tell your friend the four parts of your ninety-second walkthrough and the three parts of the honest answer about using AI. Use at most 4 sentences and no word your friend would need to look up.