Resume, GitHub, LinkedIn, portfolio
Suchitra applied to a logistics firm in Bidar. Her resume listed forty one tools across three lines. The interviewer read the list, picked one name from it, and asked a single question. She had used that tool once, in a weekend tutorial. The room went quiet, and the panel stopped asking about tools at all. Her churn model was real, measured and hers to defend. It sat near the bottom of page two, and nobody reached it. One weak line had priced the whole page.
- You built real work in this course. This module is the one page that decides whether anybody ever looks at it.
- Every claim you write down can be checked in ten minutes by a person in a chair. Writing lines you can hold is a skill, and it is trainable.
- The tools are already yours. Career Studio in this app builds tailored resumes from your profile and tracks what you sent, so today you learn the judgement behind the button.
Your resume is one page that argues for one thing: give this person an interview. Keep it to one page, because a fresher's second page is nearly always filler. Inside each section, order items reverse-chronological — newest first, oldest last. For AI roles, projects sit above coursework, since a project is evidence and a course is a plan. Your degree stays on the page, lower down, where it belongs.
Every line on that page takes one shape. An action-what-result bullet — a line that names what you did, what you did it to, and the number that moved — is the whole craft. "Worked on a churn model" is a duty, and duties are what a job title already implies. "Built a churn model on 500 customers and caught 26 of 39 churners, against a 0.688 baseline" is evidence. The number is not decoration, because it is the part a reader cannot get from anybody else.
You already own the numbers this asks for. The churn model scored 0.824 against a 0.688 do-nothing baseline, caught 26 of 39 churners, and served at p95 19 ms. The retrieval assistant scored a hit rate of 10 of 12 on a 12-case eval harness, and a drift check caught a PSI of 0.31. These are small, honest, checkable numbers, and they beat any adjective you could write in their place.
One rule governs the page. Never list a skill you cannot defend for ten minutes, which is module 6.6's rule applied to paper. A panel picks one line from your list, and the answer to that line prices every other line on it. WR-163 is what that costs when the line was somebody else's work.
Some resume advice travels as fact and has no source behind it. You will hear that a recruiter spends six seconds on a page, or that a fixed share of resumes are thrown out by software before a human sees them. Our research pass looked for evidence behind those numbers and found none we could stand behind, so we will not repeat them. Treat them as folklore, and ask anybody who quotes them where the figure came from. What we can defend is the mechanics: one page, a plain layout, a file that opens, and words that are true.
Tailoring is a tailoring pass — one edit of your own true lines to match a single job description. Read the task verbs, the way module 6.1 taught you to read an advert. Where their words are also true of you, use their words: if the post says retrieval and your notes say RAG, write both. Move the bullets that match their tasks to the top of the section. Add nothing you have not done, because a tailoring pass promotes truth and never invents it.
Now cut. The objective line goes, since "seeking a challenging role" says nothing about you. Hobbies go, unless one is real evidence for this job. The photo, the birth date and the marital status go: they are not needed for these roles, they eat space, and they invite bias that gains you nothing. The forty item skills list goes too, because nobody believes it and one weak entry drags the rest down with it.
Your GitHub profile is where a reader checks whether the page was true. Three things decide that check. The README must explain the project in about thirty seconds: the problem, what you built, the result with its number, how to run it, and the limits. The commit history must look like work, so many small commits over days beat one dump commit named "final". And the package versions must be pinned, so the thing runs on a machine that is not yours.
A reviewer does not read your code first; he runs it. The clone test — a stranger copies your repo into a fresh folder, follows your README only, and runs the project — is module 4.1's ritual. It is also what actually happens on the other side. A project that does not run is worse than no project, because it turns a claim into a failed claim while the reader watches. Run that test on yourself before you send any link.
GitHub shows a small set of repos at the top of your profile. A pinned repository — a repo you choose to display in that top row — is a claim about what you want read first. Three strong projects that run beat twelve forked tutorials, every time. The other nine add no weight, and they dilute the three that had some.
LinkedIn is a searchable surface, not a trophy shelf. Put the work you can do in the headline, write the about section in plain sentences, and add your projects with links. Then be honest about what actually moves things: polish alone reaches nobody, while the people you talk to do. Comments on real work and messages to real people turn a profile into a conversation.
A portfolio site earns its cost in two cases: your work is visual, or you want one link that holds everything. Otherwise a clean GitHub profile with a good README does the same job for free. A half built site with a broken demo costs you more than no site at all. Build the site last, after three repos pass the clone test.
The last piece is the outreach message — a short note to somebody inside a company, asking for one small thing. Keep it short and specific, and show that you read something of theirs first. One ask, never five, and no attachment nobody agreed to receive. Career Studio can hold the drafts and the replies for you; the words in them are still your work.
Six worked artefacts, and no code to run. Every one is built from work you already own: the churn model from Phase 1 and Phase 4, and the retrieval assistant from Phase 3. The student in these pieces is Suchitra from the scene, rebuilding the page that failed her.
Piece 1 — one bullet, rewritten three times. Same work each time. Only the writing changes:
# PIECE 1 - ONE BULLET, THREE REWRITES. What changed, named.
V0 (what most freshers write)
"Worked on a machine learning project on customer churn using
Python and various libraries."
PROBLEM 1: "worked on" is a duty, not an act. A team member who
attended meetings can write this line honestly.
PROBLEM 2: "various libraries" hides everything a reader wants.
PROBLEM 3: no object and no result. Nothing here can be checked,
so nothing here can be believed or disbelieved.
V1 (add the ACTION and the WHAT)
"Built a customer churn model on 500 customers with 6 features,
3 of them engineered, using scikit-learn."
CHANGED: verb is now BUILT. The object is named and sized.
STILL MISSING: the result. A reader knows what you touched and
not whether it worked.
V2 (add the MEASURED RESULT)
"Built a customer churn model on 500 customers with 6 features
(3 engineered) reaching 0.824 accuracy."
CHANGED: a number arrived, and the line is now checkable.
STILL WEAK: 0.824 alone is a number, not a result. Guessing
"stays" for everyone already scores 0.688 here, so
most of that 0.824 was free.
V3 (add the COMPARISON, and the decision behind it)
"Built a customer churn model on 500 customers with 6 features
(3 engineered): 0.824 accuracy against a 0.688 do-nothing
baseline, and chose recall over accuracy after pricing the two
errors - caught 26 of 39 churners in the test set."
CHANGED: baseline beside the score, and a decision with a reason.
WHY IT IS THE STRONGEST: it survives the ten-minute test. Every
clause opens a question she can answer for minutes - why those
6 features, why recall, why 26 and not 39.
RULE OF THUMB: if a bullet cannot be followed by "and here is why",
it is still a duty. V3 invites four such questions on purpose.
The path from V0 to V3 is the same path every bullet on your page must walk, and each step adds exactly one thing. V1 adds the verb and the object, which is where most students stop, because it already looks technical. V2 adds a number and makes the line checkable, which is the first point at which a reader can disagree with you. V3 adds the baseline and the decision, and that is what turns a number into a result — 0.824 means nothing until 0.688 sits beside it. Notice that no claim grew across the four versions; only the evidence did.
Piece 2 — the one-page fresher resume, filled in. Projects above coursework, no photo, no objective line:
# PIECE 2 - ONE PAGE. Fresher, no job experience, real projects.
SUCHITRA R.
Bidar, Karnataka | +91 9xxxx xxxxx | suchitra.r@email.com
github.com/suchitra-r | linkedin.com/in/suchitra-r
====================================================================
PROJECTS [top of page: the evidence]
Customer churn model and prediction API github.com/suchitra-r/churn-repo
Python, pandas, scikit-learn, FastAPI, Docker
- Built a churn model for a grocery delivery firm on 500 customers
and 6 features (3 engineered): 0.824 accuracy against a 0.688
do-nothing baseline.
- Chose recall over accuracy after pricing both errors in rupees;
caught 26 of 39 churners, and 30 of 39 at a 0.35 threshold.
- Served the model with FastAPI in one container: p50 12 ms and
p95 19 ms over a replayed week of requests.
- Added a daily drift check on every feature; it caught a PSI of
0.31 on orders_last_90d, and I raised a ticket rather than
retraining on inputs alone.
Policy question assistant (retrieval) github.com/suchitra-r/policy-rag
Python, Ollama, embeddings, LLM-as-judge eval
- Built a retrieval assistant over a 14-paragraph HR policy
document, chunked by paragraph, top 3 chunks by similarity.
- Wrote a 12-case eval harness (golden, edge, and one adversarial
case whose only pass is a refusal): hit rate 10 of 12.
- Measured the no-retrieval baseline first: the same model invented
a notice period absent from the document. That is the comparison
that justified the retrieval step.
EDUCATION
B.E. Computer Science and Engineering, <college name>, Bidar 2026
CGPA 8.1 / 10
Coursework that this page uses: probability, linear algebra,
databases, operating systems.
SKILLS [only what I can be questioned on for 10 min]
Python, pandas, NumPy, scikit-learn, SQL, FastAPI, Docker, git,
retrieval evaluation, prompt design
Touched once, still learning: PyTorch, GitHub Actions, AWS
ACTIVITY
Wrote a 900-word note on why my drift alert did not trigger a
retrain (link). Ran a git session for 30 juniors at college.
====================================================================
NOT ON THIS PAGE, AND WHY:
objective line - says nothing a reader cannot infer
photo, DOB, marital status - not needed, eats space, invites bias
40-item skills list - one weak entry prices the whole list
"excellent communication skills" - an adjective with no evidence
second page - there is nothing on it worth the reader's time
One page, and the order is the argument. Projects come first because they are the only part of a fresher page that cannot be assumed from the degree, and the two projects together use about half the sheet. The "Touched once, still learning" line is the piece students find frightening and interviewers find rare — it makes the main skills line believable by showing where the honest edge sits. The activity block is small on purpose: two lines of real evidence, not a list of workshops attended. The block at the bottom is not part of the resume; it is her record of every cut, so that no removed item quietly returns next month.
Piece 3 — the README that a reviewer can read in thirty seconds, beside the one it replaced. Same repository, two weeks apart:
# PIECE 3 - README BEFORE AND AFTER. Same repo, same code.
--- BEFORE (the default) -------------------------------------------
# churn-repo
Churn prediction project.
## Installation
pip install -r requirements.txt
## Usage
python train.py
[1] Title repeats the folder name and adds nothing.
[2] No problem statement, so a reader cannot tell why it exists.
[3] No result. The one thing a reviewer wants is missing.
[4] "pip install -r requirements.txt" - into which Python? No
venv step, no version, so it may install into anything.
[5] Nothing about the data. train.py will look for a csv that is
not in the repo, and the reviewer will meet an error.
--- AFTER (passes the 30-second test) ------------------------------
# Customer churn model + prediction API
Predicts which grocery-delivery customers will stop ordering, while
a voucher can still reach them. Trained on 500 customers, 6 features.
## Result
| model | accuracy | recall | churners caught |
|----------------------|----------|--------|-----------------|
| do-nothing baseline | 0.688 | 0.000 | 0 of 39 |
| logistic regression | 0.824 | 0.667 | 26 of 39 |
| at threshold 0.35 | 0.795 | 0.770 | 30 of 39 |
Served with FastAPI: p50 12 ms, p95 19 ms on a replayed week.
## Run it in 5 minutes (tested on a fresh machine, 12 Aug)
git clone https://github.com/suchitra-r/churn-repo.git
cd churn-repo
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt # 4 pinned packages
python train.py # regenerates data, prints scores
Expected last line:
accuracy 0.824 recall 0.667 caught 26/39
No data download needed: train.py rebuilds the seeded table from
config.SEED, so your numbers match mine to three decimals.
## What this does NOT do
Data is seeded, not a real company's table. Labels in the real
setting arrive about 60 days late, so live recall is never current.
Misses 13 of 39 churners at the default threshold.
## Files
config.py knobs | src/features.py the 3 engineered columns |
train.py fit+score | app/main.py the API | monitor/drift.py PSI
The AFTER version answers, in order, the four questions a reviewer holds: what problem, what result, how do I run it, and where does it break. The results table does the work of a paragraph, and it puts the baseline row first so the 0.824 is read correctly. The run block is the part that decides everything — it names the venv step, pins the package count, and prints the exact line the reviewer should expect, so a mismatch is visible in one second. The limits section costs you nothing, because the reviewer will find the seeded data anyway; volunteering it is module 6.6's limits-first habit in written form. The date on the run block matters, since "tested on a fresh machine" ages, and a stale claim there is worse than no claim.
Piece 4 — the clone test, failing and then passing. This is what a reviewer's terminal looks like. He does not send you the log:
# PIECE 4 - THE CLONE TEST. Reviewer's terminal. Two attempts.
--- ATTEMPT 1: the repo as submitted (FAILS) -----------------------
$ git clone https://github.com/suchitra-r/churn-repo.git
$ cd churn-repo
$ pip install -r requirements.txt
Successfully installed pandas-2.2.3 scikit-learn-1.5.2 ...
$ python train.py
Traceback (most recent call last):
File "train.py", line 8, in <module>
df = pd.read_csv("/Users/suchitra/Desktop/data/customers.csv")
FileNotFoundError: [Errno 2] No such file or directory:
'/Users/suchitra/Desktop/data/customers.csv'
FAILURE 1: a hardcoded path from the author's own laptop.
FAILURE 2: no instruction anywhere about where data comes from.
FAILURE 3: requirements.txt had no versions, so the reviewer got
today's scikit-learn, not the one she tested against.
WHAT THE REVIEWER DOES NEXT: closes the tab. He does not debug a
stranger's repo, and he does not write to tell her. She learns
nothing, and the rejection has no reason attached to it.
--- THE FIX (three commits, about 40 minutes) ----------------------
1. Path comes from config, and data regenerates if missing:
DATA = Path(__file__).parent / "data" / "customers.csv"
if not DATA.exists(): build_seeded_world(config.SEED)
2. requirements.txt pinned to the 4 packages the code imports:
pandas==2.2.3 scikit-learn==1.5.2 fastapi==0.115.0
uvicorn==0.30.6
3. README gains the venv step and the expected output line.
--- ATTEMPT 2: same reviewer, fresh folder (PASSES) ----------------
$ git clone https://github.com/suchitra-r/churn-repo.git fresh-check
$ cd fresh-check
$ python3 -m venv .venv && source .venv/bin/activate
$ pip install -r requirements.txt
Successfully installed fastapi-0.115.0 pandas-2.2.3 ...
$ python train.py
data/customers.csv not found - rebuilding seeded world (seed 42)
accuracy 0.824 recall 0.667 caught 26/39
saved models/churn.joblib
ELAPSED: 3 minutes 40 seconds, README only, no questions asked.
The printed numbers match the README table to three decimals,
which is the moment the resume line becomes true for the reviewer.
Attempt 1 is the most common silent rejection in fresher hiring, and its cruelty is that no feedback comes back. Three small defects did it: a path that exists only on her laptop, no word about the data, and unpinned versions that quietly change the environment. The fix cost about forty minutes and no new features. Attempt 2 is the whole point of module 4.1 — the reviewer's terminal prints her numbers, on a machine she has never touched, from the README alone. Run this against yourself in a fresh folder before every submission; a repo that has never been cloned by anybody is a repo you have not tested.
Piece 5 — the outreach message, bad and good. Both were sent to the same engineer at the same company:
# PIECE 5 - OUTREACH. Two messages, one reply.
--- MESSAGE A: the copy-paste (no reply) ---------------------------
"Hello Sir/Madam, I hope you are doing well. I am a final year
B.E. student passionate about AI/ML with strong knowledge of
Python, Machine Learning, Deep Learning, NLP, Computer Vision and
Data Science. I am looking for opportunities in your esteemed
organisation. Kindly refer me. My resume is attached. Thanks and
regards."
[1] "Sir/Madam" - nothing here is about this person, so the
message could have been sent to anyone, and it was.
[2] Six fields claimed in one sentence. Nobody does six.
[3] The ask is the largest one available: refer me. To a
stranger, that is a request to spend their own credibility.
[4] An attachment nobody agreed to receive.
[5] Sent to 50 people the same evening with no edits. One of
them reported it, and the account was limited for a week.
That is WR-171.
--- MESSAGE B: the same student, one week later (replied) ----------
"Hi Ramesh - I read your post about moving your churn scoring from
a nightly batch to an API and the 40 ms budget you had to hold.
I built something much smaller in that shape: a churn model served
with FastAPI, p95 19 ms on one container, and a daily PSI check
that caught a 0.31 drift on one feature. Repo:
github.com/suchitra-r/churn-repo (runs in 5 minutes from the
README).
One question if you have a minute: when your labels arrive late,
what do you use to decide a retrain - drift, or a rolling metric?
Not asking for a referral. If the team opens a fresher role I will
apply through the careers page and mention I spoke with you."
[1] Names one specific thing he wrote, which proves homework in
the first line. This is the whole difference.
[2] Her own evidence, sized honestly: "much smaller in that
shape" claims nothing false.
[3] The link carries a promise about time, which is a courtesy.
[4] ONE question, and it is a real engineering question that he
can answer in two lines while waiting for a build.
[5] The ask is removed on purpose. A referral that arrives after
a conversation is worth more than one requested from a
stranger, and this line makes the message safe to answer.
REPLY (next morning): "We use both, but drift alone never triggers
a retrain - too many false alarms. Send me your CV, I will pass it
to the hiring manager."
Message B works because it is about him first and her second, and because it asks for something a busy person can give in ninety seconds. Line [1] does the heavy lifting: one specific reference to his own work cannot be mass sent, so it proves effort before any claim is made. Line [2] is the honest sizing that keeps her credible — a student project compared to a production system, with the difference stated by her rather than discovered by him. Line [5] is the move students resist and should copy: dropping the ask often produces the offer, because you have removed the reason to ignore you. The reply is not guaranteed; what is guaranteed is that message A never earns one.
Piece 6 — the tailoring pass, on one real advert. Same true bullets, reordered and reworded for one job:
# PIECE 6 - TAILORING PASS. One JD, one resume, nothing invented.
THE ADVERT (composite, not a real posting):
"Data Scientist - Fresher. Build and evaluate models for credit
and collections. Must be able to explain model decisions to
business teams. Exposure to model monitoring and retraining
triggers. Python, SQL, scikit-learn. Nice to have: exposure to
serving models behind APIs."
STEP 1 - PULL THEIR VOCABULARY (their words, in their order)
evaluate | explain model decisions to business | monitoring |
retraining triggers | Python | SQL | scikit-learn | serving
STEP 2 - MARK EACH ONE TRUE / PARTLY TRUE / NOT TRUE OF ME
evaluate ................ TRUE (baseline table, threshold sweep)
explain to business ..... TRUE (chose logistic so coefficients
could be read out to the team)
monitoring .............. TRUE (daily PSI, alert at 0.2)
retraining triggers ..... TRUE (three-rule trigger set)
Python / scikit-learn ... TRUE
SQL ..................... PARTLY (coursework + practice, no
project uses it) -> keep in
skills, claim nothing more
serving ................. TRUE (FastAPI, p95 19 ms)
credit / collections .... NOT TRUE -> say nothing. Churn is a
different problem, and calling it
"credit risk" would be a lie that
dies in the first follow-up.
STEP 3 - PROMOTE THE MATCHING TRUE BULLETS TO THE TOP
was: 1 model+baseline | 2 recall decision | 3 FastAPI | 4 drift
now: 1 model+baseline | 2 drift+trigger | 3 recall decision
| 4 FastAPI
WHY: their advert names monitoring and retraining triggers
before serving, so the bullet that answers it moves up one place.
STEP 4 - MIRROR THEIR WORDS WHERE THEY ARE ALREADY TRUE
before: "Added a daily drift check on every feature; caught a
PSI of 0.31 on orders_last_90d."
after: "Built model monitoring: a daily PSI drift check per
feature, with a written retraining trigger (sustained
PSI >= 0.2, or rolling recall under 0.60 for two
weeks). It caught a 0.31 move on orders_last_90d, and
I raised a ticket instead of retraining."
CHANGED: "drift check" -> "model monitoring" and "retraining
trigger", which are THEIR words and MY facts. The trigger rule
was already in the decision log; the advert only decided that it
deserved the space.
STEP 5 - THE LINE I DID NOT WRITE
"Experience with credit risk modelling and collections
strategy." <- FALSE. Cost of writing it: one question in the
round, and then every other line is re-read as a claim.
TIME: 12 minutes. Career Studio can generate this pass from your
profile; you still own step 2 and step 5, because only you know
what is true.
A tailoring pass is a promotion exercise, and step 2 is the only step that matters morally. Notice that nothing was added: every reworded line was already true and already in her decision log, and the advert only decided which true things deserved the top of the section. Step 4 is the legitimate half of keyword matching — using their vocabulary for facts you own is honest, while borrowing their vocabulary for facts you do not own is the failure in WR-169. Step 5 is the discipline that makes the rest safe, because a page with one false line is read as a page of claims. Twelve minutes per application is affordable; it is also why twenty applications beat two hundred, exactly as module 6.1 argued.
Work in a folder called portfolio with four files: resume.md for the page itself, cuts.md for what you removed and why, clone-test.md for the reviewer transcripts, and outreach.md for messages and replies. Draft in plain text and export to PDF at the end, because a layout fight in hour one is how students avoid the hard part.
The rule for every exercise below: no line enters any file unless you can be questioned on it for ten minutes. Write the number, then write the question you expect after it.
Rewrite your resume into one page where every bullet is an action-what-result line. Start by pasting your current resume — or your Career Studio profile output — into resume.md. Now rebuild it in the piece 2 order: contact, projects, education, skills, activity. Take every bullet through the V0 to V3 path from piece 1, and write all four versions in the file so the change is visible; the final page keeps only V3. Every project bullet must carry a real number from your own work, with its baseline or comparison beside it where one exists. Then run the defence check: for each line, write in one sentence the ten-minute question you expect, and mark the line KEEP or CUT depending on whether you could answer it. Move every cut into cuts.md with the reason. Finish by cutting the objective line, the photo, the birth date, the marital status and the skills list down to items you can defend, plus one honest "touched once, still learning" line. Check: resume.md is one page when exported, with projects above education; every project bullet shows its V0 to V3 history and ends in a V3 that names an action, an object and a measured result; at least three bullets carry a baseline or comparison beside the number; every surviving line has a written expected question and a KEEP mark; cuts.md lists at least five removed items with a reason each, including one skill you removed because you could not defend it for ten minutes; and no photo, date of birth, marital status or objective line survives anywhere.
Make one repo survive a stranger's clone test, and prove it with a transcript. Pick the project on line one of your new resume. First rewrite its README to the piece 3 shape: title that states the problem, a result table with the baseline row first, a run block with the venv step and the exact expected output line, a "what this does not do" section, and a one-line file map. Pin the packages your code actually imports, with versions. Now test it the way a reviewer does: clone your own repo into a brand-new folder under a different name, build a fresh virtual environment, and follow only the README — no memory, no fixes from your own shell. Record the full terminal transcript in clone-test.md, including failures. Fix each failure, commit, and run it again from a newly cloned folder. Then hand the repository link to a classmate who has never seen it, with a stopwatch and a rule that you may not speak. Check: clone-test.md holds at least two full transcripts, one failing and one passing, with timestamps; the passing run reaches your project's expected output within five minutes from clone to result, using the README alone; the printed numbers match the README's result table to three decimals; every failure you hit is listed with the commit that fixed it, and at least one is a path, data or version problem; your classmate's run is recorded with their elapsed time and every question they had to ask, and each such question becomes a README edit; and your commit history for this repo shows the fixes as separate small commits, not one dump commit.
Run one tailoring pass and write three outreach messages that could not be sent to anybody else. Take one real fresher advert you would actually apply to, and run the five steps from piece 6 in resume.md: pull their vocabulary, mark each term TRUE, PARTLY TRUE or NOT TRUE of you, promote the matching true bullets, mirror their words only where the fact is already yours, and write down the one line you refused to write. Then pick three real people connected to that company or that kind of work, and write one message each in outreach.md, following piece 5: something specific of theirs you read, your own evidence sized honestly, one link with a time promise, one real question, and no attachment. Annotate every message with the line that proves homework. Finish with a folklore audit: write down three pieces of resume or job-hunt advice you have heard from seniors, coaching centres or social media, and for each one name the source, whether it can be checked, and what you will do about it. Check: the tailoring pass shows all five steps with at least six of their terms marked TRUE, PARTLY TRUE or NOT TRUE, and at least one term honestly marked NOT TRUE; the promoted order is written before and after with a one-line reason; you record the exact false line you refused to write; the three messages are under 120 words each, name a different specific thing in each, ask one question each, and none of them contains the word "esteemed" or a referral request in the first message; and your folklore audit names three claims with their source, marks at least one as unverifiable, and states what you will do instead of following it.
Three portfolio failures that cost freshers rounds they never learn about. Each has a War Room entry with the full diagnosis path:
- WR-169 — the skill list that backfired. A resume listed forty technologies, the interviewer picked the one the candidate had touched once, and the credibility of the whole list collapsed; the fix is a short defensible list with an honest "still learning" line, which is module 6.6's ten-minute rule applied to paper.
- WR-170 — the repo that did not run. A reviewer cloned a submitted project, met a hardcoded path and unpinned packages, and closed the tab without writing back; the fix is the clone-test ritual from module 4.1, run in a fresh folder before every submission.
- WR-171 — the copy-paste outreach. Fifty identical messages went out in one evening, none was answered, and one report to the platform limited the account; the fix is the short specific message that shows homework and asks one small thing.
A fresher resume is one page, ordered newest first, with projects above coursework for AI roles. Every bullet takes one shape: the action, what you did it to, and a measured result with its baseline beside it. List no skill you could not hold for ten minutes of questions, and cut the objective line, the photo, the birth date and the forty item list. Your GitHub is where the page is checked, so pin three projects that pass a clone test from a stranger's fresh folder. Tailor each application by promoting true lines into the advert's own words, and reach people with short, specific messages that ask one small thing.
- Analytics and risk teams at Indian banks and NBFCs read fresher resumes for the baseline beside the score. A candidate whose page says 0.824 against a 0.688 baseline is speaking the language of the team's own weekly review.
- Product and logistics startups often shortlist by cloning the repo the candidate linked. The clone test is not an exercise there; it is the first round, and nobody writes back about a failed one.
- GCC and services recruiters search LinkedIn with the words from their own advert. A headline and project section that carry those words honestly is how a fresher becomes findable without applying at all.
Answer these aloud before opening the gate assessment. Each question names its kind.
type=interpretation— A resume bullet reads "Worked with a team on an AI chatbot using LangChain and various vector databases." Read it the way a reviewer does, name every piece of information a reader cannot extract from it, and rewrite it twice: once as it would look if the student built the retrieval and evaluation, and once as it would look if the student only tested it.type=scenario-judgement— A senior tells you that recruiters spend six seconds on a resume, so you must add bold keywords everywhere. Give your ruling on the claim itself, say exactly what you would ask him, and then say which parts of his advice you would still follow and why.type=debug— A student's GitHub has twelve repositories, all green with commits, and no callbacks. Every repo has a one-line README and a single commit named "final project". Diagnose what a reviewer sees, name the three specific checks that fail, and give the smallest change that fixes the profile this week.type=trade-off— Compare a resume skills line with 40 technologies against one with 9 plus a "touched once, still learning" line. Give one concrete gain and one concrete cost of each, then name the single situation in which you would still write the longer one.type=output-prediction— A candidate's resume says "deployed a model to production with 95% accuracy" with no baseline, no dataset size and no link. Predict the first three questions the interviewer asks, what the candidate's answers will sound like if the number came from a tutorial, and what the panel note will say.
Explain to a friend in a non-technical degree why a resume line with a number beats a resume line with an adjective, using a shop as the comparison: "we sell good vegetables" against "we deliver in 20 minutes and take back anything you do not like". Then tell your friend the three parts of every line you now write, and the one rule about never listing something you cannot talk about for ten minutes. Use at most 4 sentences and no word your friend would need to look up. If your friend can say why a longer skills list can be weaker than a short one, you own this module.