Solved-Problems GitHub Portfolio as Prep vs Transfer-Focused Timed Mocks
A common prep habit is keeping a solved-problems GitHub portfolio: a repo where every problem you solve gets committed, often organized by topic, with a README, notes on the approach, and complexity in a comment. The green squares fill up and the repo grows. The other habit is transfer-focused timed mocks: fresh problems you have not seen, a timer set to your real round length, narration out loud, a forced freeze-and-recover, a dry-run before you say "done," and a short postmortem.
Both can be part of good prep. They do different jobs. The useful question is narrower: when does building a solutions portfolio actually help—and when do transfer-focused timed mocks do more for how you perform?
This is a workflow comparison, not a judgment of anyone's repo. Many engineers keep well-organized solution repos and learn a lot from them. Nothing here is a claim about how any recruiter or company views such repos. What stays stable is the difference between a record of problems you solved and the ability to solve a new one, out loud, on the clock.
At a glance
| Category | Solved-problems GitHub portfolio | Transfer-focused timed mocks (Luna side panel optional) |
|---|---|---|
| What you get | A searchable record of your solutions | Reps on unseen problems under realistic conditions |
| Measures | Volume and consistency | Pacing, narration, and recovery |
| Effort | Steady, satisfying to maintain | Higher, uncomfortable at first |
| Visibility | Public or private repo | Private postmortems |
| Best for | Review, reflection, consistent habit | Getting ready for the live round |
| Main tradeoff | Committing is not performing | Does not leave a tidy artifact |
What a solved-problems GitHub portfolio looks like
A typical portfolio workflow:
- You solve a problem, often after looking at hints or a discussion.
- You clean up the code and commit it to a folder by topic.
- You add a short note: the pattern, the complexity, maybe a tricky edge case.
- You update the README count or progress table.
- You move to the next problem.
Honest strengths. Writing down the pattern and complexity in your own words is a real learning step—it forces you to explain why the solution works. A well-organized repo makes review easy: before an interview you can skim your notes on sliding window or graph traversal in minutes. Committing every day can build a steady habit, and seeing progress can keep motivation up during a long search. For students and early-career candidates, the act of writing clean, tested code for each problem is also good practice in its own right.
Honest limits. A portfolio tracks problems you have already solved, often with help, and often without a clock. It is easy to optimize for the count—more commits, more folders—instead of for transfer to new problems. Polishing the code after the fact can hide how long it took and how much help you needed. And the repo does not practice narration, pacing, or recovery from a stall, which is what most live rounds actually test. Recruiters and interviewers will usually judge you on the round, not on the repo.
When a solutions portfolio wins: you are early in prep and want a consistent habit; you learn best by writing explanations; you want an easy way to review patterns before a round; or you are a student building good coding habits alongside study.
What transfer-focused timed mocks look like
Mocks check whether what is in the repo transfers to a problem you have not seen.
- Pick a fresh problem that is not in your repo and not one you recognize.
- Set a timer to your real round length.
- Restate the problem out loud and say a two-line plan before coding.
- Narrate while you code.
- If you stall, pause, breathe, and say what you would try next.
- Dry-run three cases before you say "done."
- Write a one-sentence postmortem that decides the next session's focus.
Optional companion: Luna Interview is a Chrome extension framed as a practice / calm side panel—not a substitute for knowing the material, and never an "undetectable" live cheat. Keep it beside the pad while you own the plan, the code, and the narration.
Honest strengths. Timed mocks practice what the round measures: working through an unseen problem, at a steady pace, while explaining your thinking. They show which patterns in your repo you really understand and which you only recognize. The postmortem keeps practice focused on your real weak spots instead of on the next folder to fill. And repeating the same format each week makes the live round feel familiar.
Honest tradeoffs. Mocks take scheduled time and can feel discouraging at first, especially if your repo is large and your first timed session goes badly. They do not leave a tidy artifact to show for the effort. And without some review of patterns, mocks can turn into repeated struggling with no new learning—which is where the repo helps.
When transfer-focused mocks win: your repo is large but live rounds still go poorly; you recognize patterns but cannot start an unseen problem; feedback says you were slow, quiet, or froze; or the interview is within a few weeks.
Decision table for candidate situations
| Your situation | Prefer a solutions portfolio | Prefer transfer-focused timed mocks |
|---|---|---|
| Just starting prep, need a habit | Strong fit | Add one mock a week |
| Repo has hundreds of problems, rounds still go badly | Pause adding | Strong fit |
| Review night before the interview | Strong fit—skim your notes | One short warm-up mock |
| Interview in under a week | Review only | Primary lane—one mock a day |
| Feedback: "solution was fine, communication unclear" | Light | Strong fit—narrate every session |
| You learn by writing explanations | Strong fit | Use notes in postmortems |
| Chasing commit streaks over learning | Pause | Strong fit |
A fair practical method (combine both in one week)
Do not measure prep by commit count. Use the repo for review and reflection, and use timed mocks to test transfer.
Repo sessions (short): After each mock, commit the problem with three lines: the pattern, the complexity, and what you would do differently next time. Note honestly whether you solved it within the time, with help, or after the timer.
Mock sessions: Two or three a week on problems not in your repo. Timer at your real round length, restate out loud, two-line plan, narration, three dry-run cases, one-sentence postmortem. Keep a calm practice side panel beside the pad if you use Luna. Score only: plan said before coding, dry-run done before time ran out, recovered out loud from at least one stall.
End of week: Search your repo notes for the patterns you stalled on in mocks. Re-read those notes, then pick next week's mock problems from those patterns—still unseen ones.
Common mistakes / when NOT to use each
Skip portfolio growth when you are adding solutions you mostly copied, polishing code instead of solving new problems, or treating the count as a measure of readiness. Also be careful posting solutions publicly if a platform's terms or a company's assessment rules ask you not to.
Skip mock theater when you pick problems already in your repo, pause the timer to look things up, or skip the postmortem. Also skip any practice-tool framing that promises stealth help in a real employer interview—that is the wrong goal and the wrong integrity bar.
For both: solutions and AI are for study and postmortems, not mid-session rescue if you are training transfer. The skill is your approach to a problem you have not seen, explained out loud.
Soft close
If your bottleneck is turning a repo full of solved problems into calm, repeatable performance on new ones—narrating your plan, recovering from a stall, finishing with a dry-run—Luna Interview is a Chrome side panel built for that practice loop, not for cheating or replacing study. Soft trial path: https://lunainterview.xyz/
Keep a solutions portfolio to review what you have learned. Use transfer-focused timed mocks to get ready for what you have not seen. The offer goes to the candidate who can solve the next problem, not just list the last hundred.
Rehearse with an AI interview copilot, then browse commonly reported interview questions.