how to pass a coding interview with no experience
no internships. no github. no leetcode streak. here is the 4-step protocol we built to prep dreamclerk applicants in 6 weeks — and what the data says about it.
a coding interview is a 60–90 minute interaction with one person, sometimes two, who is trying to predict whether you can do the job. the prediction is wrong about 30% of the time. that is not a typo: in the studies we have seen (linked at the end), the predictive validity of a single 60-minute coding interview for on-the-job performance is roughly r=0.30, with a confidence interval of about ±0.15. the interview is a noisy signal.
the noisiness is your friend if you have no experience. it means the interviewer is not as certain as they look. it means a specific kind of preparation can move the needle a lot. it means you can out-prepare a candidate with more raw experience by being more deliberate about the 4 things that move the rubric score.
this post is the 4-step protocol we built to prep dreamclerk applicants who had no prior internship, no significant github, and no leetcode streak. it works in 6 weeks. it is the same protocol we use in cohort 1 and cohort 2. it is published because the alternative is that we are asking applicants to trust a method that we will not let them see.
step 1: pick 3 real codebases and read them
the single biggest predictor of cohort-1 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 codebase 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. you can answer "what does this codebase do, and why is it shaped that way" without sounding like you are reciting a tutorial.
good candidates for the three:
- 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.
step 2: ship 3 pull requests, in 3 different repos, in 6 weeks
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.
the artifact is what you talk about in the interview. the artifact is the only thing that survives the interview. the artifact is what the AI pushback round is testing.
in our cohort data, applicants who had shipped 3+ PRs passed the interview at 51%. applicants who had shipped 1–2 PRs passed at 38%. applicants who had shipped 0 PRs passed at 27%. the gap is large. the gap is not noise. the gap is the whole game.
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.
- a small feature in a project you actively use. add a config option. add a CLI flag. add a log line. add a metric.
- a code review of someone else's PR. write the review even if the maintainer never sees it. the review is the artifact. put it in a gist. link to it in the interview.
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.
step 3: write the 90-second answer, out loud, 12 times
the 90-second 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. do it 12 times across 6 weeks. by the 12th take, you will not be reciting — you will be explaining. the difference is the whole interview.
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."
step 4: do 6 pushback rounds, in writing, with a stranger
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.
the artifact is the 12 documents. in the interview, you reference them: "i did a pushback round on a peer-review last month where i defended a decision to use a hash index over a btree. the criticism was that btree would have been safer for range scans. my defense was…" you have done this 6 times. you have the language. you have the rhythm. the AI pushback round is just pushback round 7.
what the data says
we tracked 187 dreamclerk applicants across cohort 1 and cohort 2 who had no prior internship, no significant github, and no leetcode streak at the time of application. the cohort-1 to cohort-2 pass rate for this subgroup went from 14% to 31%. the 17-point lift is large. we attribute it to the protocol. the protocol is the only thing that changed in the application.
the protocol is not free. 6 weeks of focused work, 8–12 hours a week, is the budget. it is more work than a leetcode streak, but the artifact is a piece of code, not a streak count.
what this is not
this is not a substitute for a degree. this is not a substitute for an internship. this is not a substitute for a portfolio. it is a way to prep for a specific kind of interview in a specific kind of time budget. if you have more time, prep for longer. if you have a portfolio, refer to it. if you have an internship, talk about it. the protocol is for the case where you have 6 weeks and no signal.
references
- the rubric used in this protocol: /blog/inside-our-bias-audit
- the cohort data: /faq (the "is there a real job at the end" answer)
- the apply link: <a href="#" data-open-modal>apply to dreamclerk</a>
— dreamclerk team, chennai, may 2026