Everything between "I should start applying" and "I signed the offer."
The resume that gets the call, the rounds in the middle, the negotiation at the end — and 150 practice problems with the reasoning written out.
Most interview repos are a pile of solutions. Solutions are the easy part — a model can write every one of them in seconds. What actually decides offers is the stuff around them: whether your resume gets read, whether you can think out loud, whether you know what a round is measuring, and whether you negotiate at the end.
So this repo is organised around the interview, not around the problem list.
Where are you in the process right now?
| Right now | Read this |
|---|---|
| Not applied yet | The process, end to end → Resume |
| Applications are out | Study plans → The 18 patterns |
| Loop is next week | The coding round, minute by minute → Practise out loud |
| Interview is tomorrow | The 18 patterns — recognition beats recall |
| Offer in hand | Negotiation — do not accept on the call |
| Worried AI made this pointless | Interviewing when the machine can already solve it |
| Interviewing for Android | The Android / Kotlin interview |
Each stage filters for something different, and most people only prepare for one of them.
graph LR
A["<b>Resume screen</b><br/><br/>keywords · numbers<br/>a link that works"]
B["<b>Recruiter call</b><br/><br/>don't name<br/>a number first"]
C["<b>Technical screen</b><br/><br/>clarify, brute force,<br/>then optimise — out loud"]
D["<b>On-site loop</b><br/><br/>patterns · system design<br/>verify before they ask"]
E["<b>Behavioural</b><br/><br/>six STAR stories<br/>say I, not we"]
F["<b>Offer</b><br/><br/>counter once<br/>get it in writing"]
A --> B --> C --> D --> E --> F
style A fill:#ddf4ff,stroke:#54aeff,color:#0a3069
style B fill:#ddf4ff,stroke:#54aeff,color:#0a3069
style C fill:#fff8c5,stroke:#d4a72c,color:#4d2d00
style D fill:#fff8c5,stroke:#d4a72c,color:#4d2d00
style E fill:#dafbe1,stroke:#4ac26b,color:#003d16
style F fill:#ffeff7,stroke:#ff80c8,color:#5e103e
| Guide | What it covers |
|---|---|
| The process, end to end | Every stage, what it filters for, where people lose offers they should have won |
| Resume | The bullet formula, why ATS parsers reject good resumes, what to cut |
| Guide | What it covers |
|---|---|
| The 18 patterns | Recognise the shape of a problem in two minutes. The most useful page here. |
| The coding round, minute by minute | What to do with the 45 minutes, and what the rubric actually scores |
| Interviewing in the AI era | AI-allowed rounds, code-comprehension rounds, and how to answer "do you use AI?" |
| System design | The 45-minute shape, the concepts, and designing systems that use models |
| The Android / Kotlin interview | Coroutines, Compose stability, lifecycle, mobile system design |
| The behavioural round | Six stories that cover thirty questions |
| Guide | What it covers |
|---|---|
| Practise out loud | The highest-value habit almost nobody builds deliberately |
| Study plans | 1 week / 4 weeks / 3 months, including what to cut when time runs out |
| Negotiation | Don't name a number first. Don't accept on the call. What else is negotiable. |
| Resources | A short, opinionated list — books, platforms, mocks, comp data |
Practice is one input to interviewing, not the whole thing — but you do still have to do it.
The 150 problems from neetcode.io, grouped into 18 patterns, in Kotlin and JavaScript. Every solution explains why the approach works and names the trap, and every one runs its own assertions:
node tools/test.js # the JavaScript suite
node tools/test-kotlin.js # the Kotlin suiteOpen any file and you get the idea, the complexity, and the edge cases that break the naive version — written as tests you can run and break yourself:
// 424. Longest Repeating Character Replacement — Medium
// Time O(n) | Space O(1)
//
// Idea: a window is legal when (length - count of its most common character) <= k.
// `maxCount` is deliberately never decreased: the answer only grows, so a stale high
// value can never produce a longer-than-real result.193 problems across Kotlin, JavaScript, C++ and Java, cross-linked when a problem is solved in more than one. Generated from the repo, so it never goes stale.
| 🟩 Easy | 🟨 Medium | 🟥 Hard |
|---|---|---|
| 51 | 116 | 26 |
Data structures/ and algorithms/ hold the things built from nothing — linked lists, trees,
graphs, heaps, sorting, searching, Big-O demonstrations. Start here if you want to understand
why a hash map is O(1) before using one to solve Two Sum.
Reading solutions is the least useful thing you can do with them.
- Solve it yourself first, badly if necessary. The brute force counts.
- State the complexity out loud before checking. Being wrong here is the most useful signal you get.
- Find the bottleneck, then name the pattern that removes it. Rescanning → hash map. Recomputing → memoise. This step is the skill.
- Then open the solution here and compare reasoning, not syntax.
- Re-solve it from scratch in three days. Non-negotiable.
If you are doing this at a desk in silence, you are practising the wrong half — see Practise out loud.
PRs welcome. The 150 are solved in Kotlin and JavaScript, so Python, Java, Go, Swift and Rust ports are all open — and so is anything that improves the guides.
See CONTRIBUTING.md. The one rule: a solution must run and pass its own assertions. CI checks it.
Good first contributions:
- Port a pattern folder to your language
- Add a section to a guide from your own interview experience
- Improve an explanation that didn't click for you
- Fix a typo — genuinely, they all help
If this helped, a ⭐ helps someone else find it.
Something unclear, wrong, or missing — open an issue.
Built by Muntasir Mahmud Saif · LinkedIn · LeetCode