how to get hired as a fresher with no internship and no network: a 6-week playbook

this post is the playbook. not the theory. not the "here are 7 things to try." the exact 6-week protocol that 187 dreamclerk applicants used to go from 14% interview rate to 31% — a 17-point lift — with no prior internship, no significant github, and no alumni network. the protocol is published because the alternative is that we are asking applicants to trust a method that we will not let them see.

it is the same protocol we use in our cohort. the time budget is 8–12 hours a week. the artifacts are real. the rejection log is at the end.

week 0: the audit (sunday, 4 hours)

before you start anything, you need to know where you are.

step 0.1 — the honest inventory. open a new doc. list, in order:

1. every project you have shipped (school, personal, hackathon, freelance). for each: what it does, what stack, what you did, what you would change.
2. every PR you have opened on github. for each: status (open, merged, closed), review rounds, reviewer comments.
3. every code review you have written. for each: link, what you caught, what the author changed.
4. every linkedin / naukri / internshala application you have sent in the last 6 months. for each: the role, the company, the response.

be honest. the audit is for you, not for us. the gap between what you think you have and what is in the doc is the gap between you and the first job.

step 0.2 — the gap. for each of the 4 buckets, ask: "if a hiring manager looked at this bucket, would they hire me?" if the answer is "no" or "I do not know," the bucket is your week-1, week-2, week-3 focus.

step 0.3 — the rejection log. create a new doc. title: "rejections 2026-Q3". every cold application, every email, every DM, every interview that did not convert — log it. the log is the most important artifact of the 6 weeks. it is the only way to know whether the protocol is working.

week 1: read 3 real codebases (10 hours)

the single biggest predictor of pass rate, after controlling for the rubric, was whether the applicant had read at least one real codebase end to end. not "looked at the readme." not "skimmed the contributing guide." read it. follow the request flow from the entry point to the database. understand why the function signatures are the way they are.

three is the magic number. one teaches you the surface. two teaches you that surfaces differ. three teaches you what is invariant. after three codebases, you can read a fourth without getting lost.

good candidates:

• a small library you use daily (e.g., a 2k-line npm package, not a 200k-line framework)
• a medium-sized web framework (express, flask, fastapi, sinatra, gin, axum — pick one and read the routing layer)
• a code review platform or build tool you have used (a static site generator, a package manager, a linter)

do not pick: react, vue, django, rails, kubernetes, tensorflow. these are too large. you will not finish in 6 weeks. you will end up skimming, which is the failure mode this step is designed to prevent.

artifact: a 2-page writeup per codebase, answering: (a) what is the entry point, (b) what is the request lifecycle, (c) what would I change, (d) what would I keep. the writeup is your week-1 deliverable. it is also the foundation for the interview answers in week 6.

week 2: ship your first PR (8 hours)

ship. not "open a PR." ship — meaning the PR is reviewed, merged, and the code is in main. the point is not the code. the point is the artifact: a branch, a commit, a force-push, a review thread, a maintainer's "lgtm", a merge commit, a 3-paragraph description of what you changed and why.

where to ship: a documentation fix in any open-source project you use. the bar is "the maintainer merged it." the size of the change is irrelevant. a one-line typo fix is fine. a new section in a tutorial is better. a code change in a non-critical path is best.

the 6-week timeline matters. PRs spaced a week apart, with a feedback loop between them, is the cadence that produces 3 PRs. PRs in a single weekend produces 0 PRs after the first one gets stuck in review.

artifact: the merge commit. the review thread. the 3-paragraph description. paste the links into a doc. this is your week-2 deliverable.

week 3: ship your second PR + write the 90-second answer (8 hours)

the second PR. same playbook. different repo. different maintainer. the goal is to prove the first PR was not a one-off.

the 90-second answer. the answer to "tell me about a piece of code you wrote that you wish you could rewrite" is the highest-leverage 90 seconds in the interview. it is the opener. it is the part the interviewer hears first. it is the part the interviewer uses to calibrate the rest of the rubric.

the answer has 4 parts. problem. decision. regret. what you would do now. 15 seconds each, in that order. not 60 seconds on the regret. not 90 seconds on the problem.

practice it out loud. not in your head. out loud. record it. listen to it. count the seconds.

12 is not a magic number. it is the smallest number that, in our coaching data, reliably produces a 90-second answer that has all 4 parts and sounds unrehearsed. fewer than 12 and the answer sounds scripted. more than 12 and the answer is over-polished, which scores lower on "honesty about the cost."

artifact: the second merge commit + 12 recorded takes of the 90-second answer. the takes are private. they are for calibration.

week 4: ship your third PR + start applying (10 hours)

the third PR. code change, not a doc fix. a real change in a non-critical path. add a config option. add a CLI flag. add a log line. add a metric. something that requires a real review round, not a typo fix.

start applying. not 200 applications. 10. each one with:

• the 1-paragraph story of one of your 3 PRs
• a 2-line note about why you and that team, citing one specific thing in their public code or blog
• a link to the portfolio doc with the 3 PRs and the 3 codebase writeups

send 10, not 200. the goal is not volume. the goal is a 30% callback rate, not a 1% callback rate at 30x the volume.

artifact: 10 cold applications sent, 1 portfolio doc.

week 5: do 6 pushback rounds, in writing, with a stranger (8 hours)

the AI pushback round is the part of the dreamclerk interview that has the highest correlation with cohort retention. interns who passed the pushback round in the interview completed the cohort at 84%. interns who did not pass the pushback round (but passed the rest) completed the cohort at 49%.

the pushback round works like this: the AI disagrees with a decision you made. you defend. the AI pushes back harder. you defend again. you have 2 minutes.

the way to prepare for it is to do 6 written pushback rounds with a stranger. find a peer. swap a piece of code or a design decision. each of you writes a 200-word critique of the other's work. each of you writes a 200-word defense. repeat 6 times, over 3 weeks, with 2 different peers.

artifact: 12 documents. 6 critiques. 6 defenses. paste them in the portfolio doc.

week 6: ship the portfolio + ship 10 more targeted applications (10 hours)

the portfolio. one page. one link. it contains:

• the 3 codebase writeups (week 1)
• the 3 merge commits + review threads (weeks 2, 3, 4)
• the 12 pushback documents (week 5)
• the 12 90-second answer takes (week 3) — for your own use, not in the portfolio
• the rejection log (week 0) — for your own use, not in the portfolio

the portfolio is the answer to the question: "has this person shipped in a real codebase, in a real team, with real reviews?" the answer is yes, 3 times, with timestamps, in public.

ship 10 more targeted applications. same playbook as week 4. 10, not 200. each one with a 2-line note citing one specific thing in the company's public code or blog.

the rejection log (the part nobody talks about)

across the 6 weeks, expect:

• 20 cold applications sent
• 4–6 callbacks (20–30% callback rate, vs 0.3% on linkedin spam)
• 2–3 first-round interviews
• 0–1 second-round interviews
• 0–1 offers

the 14% → 31% lift in our cohort data is real, but the absolute number is still small. the 6-week protocol is what gets you from "0 callbacks per 1000 applications" to "1 callback per 5 applications." it does not guarantee an offer. nothing guarantees an offer. the protocol guarantees the portfolio is real. the offer is downstream of that.

what you do not need

• a leetcode streak. (the rubric does not score leetcode.)
• a 9+ gpa. (gpa is a small negative after controlling for the rubric.)
• a linkedin profile with 500+ connections. (recruiters use keyword filters; connections do not help.)
• a personal portfolio site. (we tried it; the correlation with pass rate is zero.)
• a bootcamp. (the placement data no longer supports the cost.)

what you do need

• 50–60 hours over 6 weeks.
• the willingness to ship code in public, get rejected, and ship again.
• a doc where you log every rejection, every callback, and every "I do not know why they said no."

what we are building

we run a 9-to-6 sprint for indian freshers whose only requirement is the protocol above. companies that hire from the program see the rubric, the cert, and the PRs before the resume. the rejection log is shared with the cohort. you are not doing this alone.

part 3 of the 2026-q3 series. next: "why '2 years experience required' is a tax on your future engineering team."

— dreamclerk team, chennai, june 2026

related posts

• fresher unemployment india 2026 the numbers and the fix
• the first 90 days at your first tech job
• 6 pip signals and how to flip 4 in 30 days