Interview refresher: TypeScript, JavaScript, Python

A guide for rebuilding fundamentals that have eroded under AI-assisted coding. It covers data structures, algorithms, language internals, performance and design patterns across TypeScript/JavaScript and Python, and it is built around one idea: the parts an assistant does well for you (typing out a known algorithm) are exactly the parts interviews now value least, and the parts it cannot do for you (choosing, justifying, adapting, debugging live) are the parts being tested harder.

22 chapters, ~30,700 lines, ~206,000 words, 842 code blocks. Everything runnable was executed; every benchmark number was measured on the machine this was written on; every type-level claim was compiled; every test suite was run.

Start here

graph TD
    Start["How much time do you have?"]
    Start -->|"20 minutes"| A["Cheat sheets (ch 14)<br/>trap list + phrasebook"]
    Start -->|"An hour"| B["Complexity ch 01 §9<br/>+ 3 drills from ch 13 §6"]
    Start -->|"A week"| C["Study plan (ch 15)<br/>sprint track"]
    Start -->|"Two months"| D["Study plan (ch 15)<br/>8-week plan"]
    Start -->|"Ongoing"| E["Study plan ch 15 §4<br/>maintenance loop"]

If you only take one thing from this guide: close the file and write the heap from scratch. The diagnosis is a retrieval failure, not a knowledge failure, and retrieval only improves by retrieving.

The files

Foundations

Data structures

Algorithms

Design

Testing

Book crosswalks

Practice

Reading orders

Rebuilding fundamentals (recommended). 01 -> the 20 drills in 13 §6 -> 05/06 as reference while drilling -> 07 -> 08 -> 09 -> 10 -> 02/04 for internals -> 03 -> 11/12 -> 14 for maintenance.

Interview in two weeks. 14 (all of it) -> 13 §1-3 -> 08 -> 10 -> 09 -> the starred drills daily -> one chapter’s interview-questions section each evening.

Senior/staff loop, where the internals questions live. 02 §6-8 (event loop, GC, V8) -> 04 §6-9 (GIL, memory, bytecode, perf) -> 03 (type system) -> 11/12 (SOLID, pattern judgement) -> 01 §11-12 (lower bounds, how to talk about complexity).

Language-specific brush-up. JS/TS: 02 -> 03 -> 05 -> 11 -> 16. Python: 04 -> 06 -> 12 -> 17.

If you own the two Effective books. Read 21 §4 first — the book’s first four chapters are where this guide is weakest and they fix real gaps in how you read type errors. Then 20 §5, then 20 §4 for the unit-vs-integration measurement. Use the matrices to skip the ~35% of each book this guide already covers at equal or greater depth.

Testing, from scratch. 18 §1-3 (what tests are for, the doubles) -> 16 or 17 for your language -> 18 §6-9 (testability, pure cores, mutation testing) -> 19 for the drills. If you only read one section, make it 18 §9.

How this guide is different from a tutorial

Everything runs. Not “should work” — was executed. Each data-structure and algorithm chapter ends with the actual test output, and where two algorithms solve the same problem they are checked against each other (Kahn vs DFS topological sort, Prim vs Kruskal, Tarjan vs Kosaraju, O(n^2) vs O(n log n) LIS on 50 random arrays). Type-level claims are verified by the compiler, including the negative ones — the @ts-expect-error markers fail the build if the error does not occur.

Benchmarks are measured, not quoted. Every number came from this machine (CPython 3.11.15, Node 22.22.2 / V8 12.4, a 2-core cloud container). A sample of what that produced:

Several of those contradict common advice, which is the point. The __slots__ result and the LOAD_GLOBAL result mean the folklore is stale on Python 3.11; the string-concatenation results mean the “always use join” rule is Python-specific and more subtle than usually stated.

Failures are documented. The first inline-cache benchmark showed no difference because a shared counter dominated the loop — that mistake is in 02 §8.2 along with how to design the benchmark correctly, because “a benchmark showing no difference is more often a broken benchmark than a disproved theory” is a more useful lesson than the number. Likewise the Bloom filter’s signed-32-bit bug, which produced actual false negatives, is documented in 05 §22.

Opinions are stated. The design-pattern chapters say which GoF patterns are dead weight in each language and why. The DP chapter says which optimizations to name and never implement. The Python chapter says Result types usually lose to exceptions there and explains why the same argument does not hold in TypeScript.

Environment

Facts that could have changed since training were checked against primary sources in August 2026: Python 3.14 (PEP 779 free-threading, PEP 734 interpreters, PEP 750 t-strings, heapq max variants), TypeScript 6.0/7.0 (the Go port), ES2025/ES2026 feature status plus a Node 22 feature-detection table, V8’s TimSort, and the Python wiki’s TimeComplexity tables.

Sources

• Python 3.14 release notes — free-threading, JIT, heapq max functions, GC changes

• Announcing TypeScript 7.0 Beta and TypeScript 6.0 ships as the final JS-based release

• Getting things sorted in V8 and Stable Array.prototype.sort — TimSort, run detection, stability

• Python wiki: TimeComplexity — the built-in complexity tables

• ECMAScript 2026 feature list — cross-checked against runtime feature detection on Node 22

• LeetCode 75 vs Blind 75 vs NeetCode 150 (2026) — list composition

• What actually changed in tech interviews in 2026 — format shifts. Practitioner observation, not published data; flagged as such in 13 §1

• Node.js test runner documentation — the feature/stability/version table in 16 §1, cross-checked against feature detection on Node 22. A secondary comparison article contradicted the official docs on two points; that disagreement is documented in 16 §17

• Brett Slatkin, Effective Python, 3rd ed. (Addison-Wesley, 2025) and Dan Vanderkam, Effective TypeScript, 2nd ed. (O’Reilly, 2024) — cross-referenced Item by Item in 20 and 21. Those chapters are an index and a gap-closure companion, not a substitute: claims are restated in my own words and every Item is cited by number so you can read the original. Two of Vanderkam’s Items are now stale against TypeScript 6.0.3, verified by compiling them; one of Slatkin’s disagrees with this guide, settled by measurement rather than assertion

A note on keeping it

Guides rot. Two habits keep this one useful:

1. Re-run the code. The scratch files that produced every test output and benchmark table are reproducible; when you upgrade Python or Node, re-run them. Several conclusions in here are version-specific (the __slots__ speed result, the LOAD_GLOBAL result, the Node 22 feature table) and will change.
2. Do the weekly loop. Study plan §4 — one blank-file drill, two mixed problems, one flashcard pass, one trap. Ninety minutes a week is enough to stop the erosion, which is a much better deal than another eight-week cram.

And the smallest habit with the biggest return, from that same section: when you accept a generated data structure, say why it is the right one and what its complexity is. Thirty seconds per acceptance, and it keeps the judgement attached to the typing.