Open-source project
yangshun/tech-interview-handbook avatar
yangshun/tech-interview-handbook

Tech Interview Handbook: system design is still a stub, and three links are affiliate URLs

GitHub describes it as Curated coding interview preparation materials for busy software engineers. The repository metadata lists TypeScript as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

143,047 stars16,852 forksTypeScriptMIT

At a glance

What is it?
Tech Interview Handbook is a curated preparation library rather than a link dump, built around coding practice sets, cheatsheets, a resume guide and behavioral questions. Its two soft spots are visible in the source: system design content is stated as unfinished and forwards to paid courses, and the outbound course recommendations carry affiliate parameters in their addresses without any disclosure in the text.
Who is it for?
Use the handbook for the parts that are actually written: the practice question set, the cheatsheets, the resume guide, the behavioral questions, and the framing around each phase of a loop. Skip it for system design, where the handbook says the work is still in progress and points you at two paid courses instead, and treat front end preparation as a separate site with its own cadence.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 54 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

System design is a stub that forwards you to two paid courses

One chapter of the interview loop is openly unfinished, and the handbook says so rather than leaving you to infer it. The file states the authors are still working on system design content, and in the meantime recommends ByteByteGo's System Design Interview course and Design Gurus' Grokking the System Design Interview course, described as among the most useful resources for getting started on that kind of preparation. So the coverage is one sentence and two outbound links, and both destinations are courses you pay for. The consequence is a hole in the middle of the phase list, and the phase list is the first thing a newcomer reads: apply, pass the interviews, negotiate. Plan from the sentence and skip the section listing and you will reach a system design round with a study plan that contains no system design in it.

Front end content was moved to its own site and left a link behind

The handbook used to reach further, and the seam is still visible. Front end related content has been moved to a separate website, the Front End Interview Handbook, and what stays here is a pointer in the list of resources plus a short section telling you where it went. Consolidating is a reasonable call, since a front end track and a general software engineering track diverge quickly, but the documentation does not say when the move happened, whether the two sites share an editorial rhythm, or whether anything is kept in step. The consequence for anyone assembling one plan is that you now track two subscriptions, two sets of addresses and two update cadences, and the half that was moved out of this repository is the half you have the least information about.

Three of the outbound course links carry affiliate parameters in the address

The recommendation surface and the earning surface are the same links, and the file does not say so. The Grokking the Coding Interview links from Design Gurus carry an aff=kJSIoU parameter, the AlgoMonster links go through a shareasale.com redirect with tracking identifiers in the query string, and the ByteByteGo recommendation carries an fpr parameter naming this handbook. There is no advertising note, no partner labelling, and the same Design Gurus course appears twice in the file, once in a banner above the questions and again in the courses section. Nothing suggests the recommendations are wrong for a given reader. The consequence is narrower and purely factual: when you are about to pay for a course, look at the address first, because a recommendation and a commission are indistinguishable in the prose, and the affiliate marker is only visible if you look where it is actually stored.

The workspace contains a portal app that the documentation never names

The root package.json is a private workspace defined by two globs, packages/* and apps/*, and its scripts describe two front ends rather than one:

json
"dev": "vp run --filter @tih/website... dev",
"dev:portal": "vp run --filter @tih/portal... dev"

The documentation describes one of them. A Docusaurus website was created to provide a better reading experience, and the handbook sends you to techinterviewhandbook.org. The other is @tih/portal, which has its own dev command and appears nowhere in the prose. So the repository carries a second application with a separate start script and no account of what it serves. For a contributor that is a gap rather than a curiosity, because the recursive build flag means a build reaches across the whole workspace either way, and for a reader it means the site you read is one of at least two things this monorepo produces.

Node 25.8.1 and pnpm 10.32.1 are pinned to the patch, and the build tool resolves from a catalog

The engines block leaves unusually little open:

json
"engines": {
  "node": "25.8.1",
  "pnpm": "10.32.1"
}

No caret, no range, no greater-than clause, and the same pnpm release is repeated in the packageManager field. The single devDependency is vite-plus with its version written as catalog:, so the resolved version lives in the workspace catalog rather than in this file. The command vocabulary built on top is small: build runs a cached recursive build, ci runs a check, then a test, then that same build, and clean empties the cache. The consequence for anyone running it locally is that the manifest asks for an exact patch on both tools with no range to fall back on, and the one build tool in the project is versioned somewhere the file you are reading cannot show you.

The differentiator is curation against link lists, resting on the Blind 75 lineage

The handbook argues its own case in a section asking how it is different, and the argument deserves a hearing. It acknowledges there are many books like Cracking the Coding Interview and other interview related repositories on GitHub, then makes two claims: that existing interview repositories contain mainly links to external resources whereas this one holds curated content written for direct consumption, and that existing resources focus mainly on algorithm questions while lacking coverage of domain specific and non technical questions. The lineage supports the first claim, since the author also wrote Blind 75, and the handbook offers Grind 75 as its next evolution. The consequence is that the second claim is the one to test, because domain specific coverage is a choice about which domains rather than a promise about yours, and no index is offered that would let you check before spending an evening.

Condensed is an editorial policy, so a missing topic is a cut, not a bug

The voice of the handbook is a stated constraint, and it explains the shape of the gaps elsewhere. The file says the information here is condensed, that the key to succeeding in technical interviews is consistent practice, and that the author does not want to bore you with too many words, so the promise is the minimum you need to navigate the process, after which you practise on your own. That is a defensible position and it keeps the thing short. It also means an absent topic is an editorial cut rather than an oversight, which is the trap for anyone auditing it: you cannot infer coverage from what is missing, and nothing distinguishes a deliberate exclusion from a section that has not been written yet. The last push to the repository was 2026-08-07, so read the summary as one editor's snapshot on that date rather than a maintained syllabus.

The handbook says there are no formal contributing guidelines, and CONTRIBUTING.md is in the tree

The final section begins by saying there are no formal contributing guidelines and is cut off there, while the tree beside it holds CONTRIBUTING.md, AGENTS.md, CODE_OF_CONDUCT.md, a .github directory and an .editorconfig. The repository also publishes no GitHub releases, so there is no tag to pin if you fork it, and the site is served from the main branch. For a project this size the mismatch costs little and the missing tags cost less, but both point the same way: the README is written as a reading experience rather than as an operations manual, and the operational detail lives in files it barely mentions. Read CONTRIBUTING.md and AGENTS.md before sending a pull request, and treat the README's account of the process as unreliable in both directions, since it understates what exists.

Editorial conclusion

Use the handbook for the parts that are actually written: the practice question set, the cheatsheets, the resume guide, the behavioral questions, and the framing around each phase of a loop. Skip it for system design, where the handbook says the work is still in progress and points you at two paid courses instead, and treat front end preparation as a separate site with its own cadence. Read an address before you click a course link, since three of the recommendations carry affiliate parameters, and if you came to contribute, read AGENTS.md and CONTRIBUTING.md rather than relying on the README's claim that there are no formal guidelines.

Frequently asked questions

Is blind 75 enough for faang?

The handbook's premise is that not everyone has time to do a few hundred LeetCode questions, and its author is also the author of Blind 75. It points to Grind 75 as the next evolution of Blind 75 and to a separate best practice question set for coding interviews.

What is the 30-60-90 rule in an interview?

The repository file does not define a 30-60-90 rule anywhere. What it does point to for interview preparation is a coding interview study plan, a how to prepare guide, and a cheatsheet of do's and don'ts.

What are the 5 C's of interviewing?

The repository file never names a 5 C's framework. It says the content covers all phases of a technical interview, from applying for a job to passing the interviews to offer negotiation, and it links to behavioral questions asked by the top tech companies.

What is L1, L2, L3, and L4 engineer?

The repository file does not define engineering levels. Its stated audience is anyone new to technical interviews, seasoned engineers who have not been on the other side of the table in a while, and anyone who wants to get better at technical interviewing.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/yangshun-tech-interview-handbook.svg)](https://hysenlabs.com/projects/yangshun-tech-interview-handbook)