Coding Interview University: one engineer's ordered reading list, and the quarter it drops
A complete computer science study plan to become a software engineer.
At a glance
- What is it?
- This repository is a multi-month computer science study plan for becoming a software engineer, written as an ordered Markdown list rather than a codebase. Its own author says it covers about 75% of a CS program, and that it targets software engineering, not frontend or full-stack work.
- Who is it for?
- Use it as a reading order if you already write loops and have months of study time, and expect to repair the links as you go. Do not use it for frontend or full-stack coverage, and do not expect a graded practice set, because the repository is a document rather than a course.
- Can I use it commercially?
- Yes, with credit. CC-BY-SA-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Probably not. The repository last received commits 13 months ago, on August 28, 2025.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Nothing at the top level is installable, and the order is the product
The repository holds a README, a LICENSE.txt, a .gitignore, a .github directory, and three supporting locations: extras/, programming-language-resources.md and translations/. There is no package manifest and no build script, so there is nothing to clone and run.
The topics of study run in a fixed sequence. Algorithmic complexity and Big-O come first, then data structures (arrays, linked lists, stack, queue, hash table), then binary search and bitwise operations, then trees, sorting, graphs, and a long closing block the author labels Even More Knowledge.
That closing block is where the cost climbs. It holds recursion, dynamic programming, design patterns, combinatorics and probability, NP, NP-Complete and approximation algorithms, how computers process a program, caches, processes and threads, testing, string searching and manipulations, tries, floating point numbers, Unicode, endianness and networking.
The README does not attach an exercise or a solution to any of those topics, and the repository ships no test to run. Whatever you build while working through the list, you grade yourself.
The author states the 75% cut himself, and points frontend readers elsewhere
The plan does not pretend to be a computer science degree. The author says a university program contains a lot to learn but that knowing about 75% is good enough for an interview, and that this list is what he covers on that basis.
The scope line sits in the same paragraph. This is a study plan for software engineering, not frontend engineering or full-stack development, and the README redirects anyone on those paths to roadmap.sh. For a candidate aiming at a backend or infrastructure role, the 75% cut is a reasonable bargain. For someone targeting a frontend job, following the list spends months on endianness and networking while the material their interviews will assess never appears.
What the 75% figure is not is a derivation. No interview dataset, no per-company breakdown, nothing showing which quarter was cut or on whose authority. The author's own outcome is a single data point: he says he was hired as a Software Development Engineer at Amazon after going through the plan.
The entry requirement is a loop you have already written
Three things are listed as required before you start, and only the first is technical: a little experience with coding covering variables, loops, methods and functions, plus patience, plus time.
That first line is a real filter. Someone who has never written a loop is not slightly underprepared, they are outside the target audience, and the document offers them no ramp. Set it against the author's own account of studying 8-12 hours a day for several months, and the implied budget is a full-time one.
The README softens this twice, telling the reader they will not need to study as much as he did and that he wasted a lot of time on things he did not need to know. That is a fair warning about scope, not about hours. Nothing in the document accounts for covering the same material in four hours a day beside a full-time job, and the prerequisites give a reader no way to estimate a timeline before committing to one.
The list thins out exactly where the theory gets deep, and repeats BFS and DFS
Some entries are named at the level of concept rather than implementation, and the plan is candid about it. Balanced search trees appear in the trees section as a general concept, not details. Traversals get their own line: preorder, inorder, postorder, BFS, DFS.
The sorting section names five algorithms and stops: selection, insertion, heapsort, quicksort, mergesort. The graphs section splits into directed and undirected, gives both representations, adjacency matrix and adjacency list, and then names the same two traversals again.
That repetition is worth catching. A reader working in order meets BFS and DFS once under trees and again under graphs, and nothing says whether the second pass goes deeper or simply repeats. Treating each heading as new material costs you the topic twice. Noticing the repeat and skipping it is a call you have to make alone, with no confirmation in the document.
The job-hunting half sits above the optional divider, not below it
The document splits itself with a horizontal rule reading that everything below this point is optional, and the divider is placed right after the Getting the Job material. Above it sit four sections: Update Your Resume, Find a Job, Interview Process and General Interview Prep, and Be thinking of for when the interview comes.
The optional half holds Additional Books and a block titled System Design, Scalability, Data Handling, conditioned on having 4+ years experience. A candidate with three years of industry work is told, by the plan's own wording, that system design is not for them yet.
So the emphasis runs opposite to what the title suggests. This is a technical fundamentals plan with a hiring appendix, not a hiring plan. A Note About Video Resources and What you Won't See Covered are also section names in the table of contents, which tells you the author treated the omissions as a known property of the list rather than an oversight.
Sixteen translations are separate files, and nothing marks which ones are current
Sixteen translations ship as complete documents under translations/, each with a language-specific filename such as README-cn.md for Simplified Chinese and README-tw.md for Traditional Chinese. Fourteen more exist only as open GitHub issues, among them French, Korean, Turkish, Arabic and Ukrainian.
Keeping translations as separate documents instead of sections of the main README is a deliberate structure, and it has a predictable cost. When the main list gains a topic or a book, the other fifteen files do not gain it, and nothing in the repository records which translations have caught up. A reader working from a French copy could not tell from the file itself that it had fallen behind.
For a reader whose language is one of the fourteen, the practical result is that the plan is English-only. Discovering that is easy, since the README's table of contents carries the mapping. Staying current is the part that is not.
CC-BY-SA-4.0 makes any fork you adapt a share-alike work
The licence is CC-BY-SA-4.0 and the file is LICENSE.txt. For a document you only read, the obligation is attribution. For one you reuse, share-alike is the term that binds: a fork that adapts the study plan is a derivative work and carries the same licence forward.
That matters for a specific audience. If you intend to turn this list into a paid course, an internal onboarding curriculum at a company, or a translated PDF to hand out, you are now making a licensing decision, and the share-alike term is what constrains how you can distribute the result. The underlying ideas are not covered; the text and its arrangement are. For anyone building on the file rather than linking to it, that distinction is the whole decision.
Last push 2025-08-28, no releases, and no signal when a link dies
The last push was on 2025-08-28 and there are no GitHub releases. No tag to pin, no changelog, no version marker, so the only stable reference is the commit you happened to read.
That matters most for a document whose content is almost entirely outbound links to books, videos and practice sites. Nothing in the repository records when any given link was last confirmed working, and with no release there is no earlier version to diff against when one dies. A reader working through slowly will eventually hit a resource that has moved, and the recovery path is finding the replacement yourself rather than filing a report against a broken file.
Adopt it accordingly: as a checklist with an expiry date, not a curriculum with a version. Record the commit you started from, expect to substitute your own practice material, and assume every link needs verifying before you spend an evening on it.
Editorial conclusion
Use it as a reading order if you already write loops and have months of study time, and expect to repair the links as you go. Do not use it for frontend or full-stack coverage, and do not expect a graded practice set, because the repository is a document rather than a course. Before you plan your weeks around it, open the table of contents and check the 4+ years experience condition attached to the system design section, because that single gate decides whether the optional half of the plan applies to you at all.
Frequently asked questions
How do I study for a coding interview?
Coding Interview University is a multi-month study plan for becoming a software engineer at a large company, and it asks for three things up front: a little coding experience with variables, loops and methods or functions, patience, and time. The author says he studied 8-12 hours a day for several months while following it, and advises readers to study less than he did because he wasted time on material he did not need.
What is asked in a coding interview?
The plan's topic list is its answer: algorithmic complexity and Big-O, arrays, linked lists, stack, queue, hash tables, binary search, bitwise operations, trees and binary search trees, heaps, five sorting algorithms, directed and undirected graphs with both adjacency representations, then recursion, dynamic programming, design patterns, combinatorics and probability, caches, processes and threads, testing, tries, Unicode, endianness and networking.
How are coding interviews done?
The plan's Getting the Job section covers Update Your Resume, Find a Job, Interview Process and General Interview Prep, plus what to be thinking of when the interview comes and what questions to have for the interviewer. Everything after that point is marked optional in the README, including a System Design, Scalability, Data Handling block gated on having 4+ years experience.
Community notes