Mockinaut: a Python course delivered as Jupyter notebooks

A repository named for a mock interview tool that opens as a Python textbook

The mismatch between the label and the contents is the first thing to notice about Mockinaut. The repository description reads AI automated mock inteview tool, and the topics are python, roadmap and tutorial. What the README actually documents is a course on the Python language, written in Russian, under the title Core of planet Python. It introduces itself as a small textbook on the basics of the language, written because the author saw a gap between the volume of content promised by programming courses and what junior job postings actually require.

The mock interview idea is present, but as content rather than as software. The repository contains a directory named python-backend-interview, a file named interview_questions_draft.txt, and two annex notebooks, 16_annex_1_interview_questions.ipynb and 17_annex_2_leetcode_questions.ipynb. The README describes the pull-quote blocks inside the chapters as inserts that hold the answer to an interview question, for example a definition of Python as an interpreted language with dynamic strict typing and automatic memory management. So the interview framing is a teaching device inside a textbook, not an interface you can call.

The README also points to a separate repository, github.com/amaargiru/pycore, as the place where the guide lives with its freshest corrections, and invites readers to fork and rewrite it freely. That points to a relationship between the two repositories that the README does not spell out, and it is worth checking before you decide which copy you track.

One notebook per chapter, from data structures to DevOps

The teaching content is a sequence of Jupyter notebooks with numeric prefixes that map out a study order. The list runs from 00_intro.ipynb through the data structures, data management and data flows chapters, into 04_oop.ipynb, 05_under_the_hood.ipynb, 06_multithreading_multiprocessing.ipynb, 07_common_practice.ipynb and 08_algorithms.ipynb, then 09_database.ipynb, 10_net.ipynb, 11_architecture.ipynb, 12_admin_devops.ipynb and 13_data_science.ipynb, closing with 15_outro.ipynb and the two annexes. The numbering skips 14, and the README does not explain the gap.

The notebook format is deliberate. The README says the textbook is written in Jupyter Notebook precisely so that you can interactively edit and run the code, adding new entities or clarifying confusing points on the spot. That is a different learning contract from a static tutorial site, and it is the strongest argument for the format: you can run the cell, change it, and see the result immediately.

The navigation aid matches that. Instead of a flat table of contents, the guide presents one as a diagram with a left-to-right, top-to-bottom path. Green items are for beginners, grey items are for when accumulated experience or curiosity pulls you deeper, and orange items are the ones needing deeper study, with the advice to at least understand their general scope and pros and cons and keep them in reserve. The repository also holds supporting images such as gitflow.svg, garbage.svg and coupling_vs_cohesion.svg, plus a compose_readme.bat script, a todo.md and an examples directory with part1 and part2 subfolders.

The README declares the guide a draft and asks for corrections

Unusual candour is the defining tone of this README. It opens by warning that the guide is in draft status, that the deeper you read the more inconsistencies, clumsy phrasing and errors you will find, and that somewhere around the middle of the guide you land in a stretch of disconnected notes and scribbles. It asks readers not to judge too harshly and says the text is being corrected slowly, drifting toward greater readability.

Later, the author repeats the point with a claim that there is a 100 percent chance of errors and inaccuracies of every calibration, and invites pull requests and forks on GitHub, saying any suggestions and additions are warmly welcomed. That framing changes what the project is. It is not a finished reference, and treating it as one would be a mistake. It is a work in progress that happens to cover a wide arc, and its value depends on the reader supplying the corrections.

The author is also candid about scope discipline, saying the narrative can look unbalanced because topics that interest him get more detailed coverage at the expense of overall completeness, and that on the other hand he does not want to rewrite the Python documentation by tediously listing data structure methods. The practical reading is that the chapters explain why a construct matters and when to reach for it, while the reference detail stays in the official documentation at docs.python.org, which the README recommends reading diagonally first and then drilling into section by section.

Interview inserts and a LeetCode reading suggestion

Two practical devices sit inside the prose. The first is the set of blockquoted inserts that carry interview answers, which the README describes as inserts meant to fix the facts in place. The example given defines Python as an interpreted, mostly interpreted language with dynamic strict typing and automatic memory management, and notes that implementations exist that compile the source, for example cython, but that working with Python generally goes through the interpreter.

The second device is external to the notebooks. The README recommends leetcode.com for learning basic syntax at full intensity, and gives a concrete procedure: filter the problem set by the Easy difficulty level, then add a secondary sort on the Acceptance column. The result, in the author's phrase, is not the competitive-programming platform's snarling face but a primer with a smoothly rising difficulty curve.

That recommendation sits slightly at odds with the book's own arc. The chapters are organised as a conceptual curriculum, from structures through object orientation to architecture and administration, while LeetCode problems are organised by technique and by the platform's own difficulty tags. Treat the two as different passes over the same language rather than as one sequence. The interview annex notebook, 16_annex_1_interview_questions.ipynb, and the LeetCode annex, 17_annex_2_leetcode_questions.ipynb, are the bridge between those passes inside the repository itself.

Reading the list chapter in a notebook cell

The README gives no installation steps, because this is a set of notebooks rather than an installable package. It says the text with the latest corrections is available on GitHub, and it invites forking and rewriting. So the practical route is to open the repository, read the notebooks in order in a Jupyter environment, and edit the cells as you go. The first notebook, 00_intro.ipynb, holds the introduction and the diagram-based table of contents.

The first code chapter, 01_data_structures.ipynb, opens with the list. The README describes the list as an ordered mutable collection of objects of arbitrary type, and points at the CPython source for listobject.c to explain that the internal structure is a dynamic array of pointers, so lists hold references to objects rather than the objects themselves, which is what allows a single list to mix types.

A notebook cell from that opening looks like this:

a: list[int] = [10, 20]
b: list[int] = [30, 40]
print(a, b)

a += b
print(f'Add: {a}')

The surrounding cell also demonstrates append to add a value at the end, insert to place a value at a chosen index, reverse, the difference between sorted, which returns a new list, and sort, which modifies the list in place and returns nothing, and finally clear. The notebook prints the resulting lists and their contents after each operation, so you can step through them one line at a time. The typed annotations on the two lists are worth noting, since they show the annotation syntax the guide uses throughout rather than treating it as decoration.

A custom licence and an authorship that spans several projects

Mockinaut is licensed under a custom licence that GitHub cannot classify, and the licence text lives in a file named license at the root of the repository. That is a meaningful difference from the MIT or Apache terms most tooling libraries use, and it is the kind of thing to read before you copy chapters into an internal wiki, translate them for colleagues, or use them in a paid course. The README itself is generous about reuse, saying readers are free to supplement and rework it as much as they like, but the licence file is the document that governs, and the README is not a substitute for it.

The repository also carries signs of a wider toolchain. There is a python-backend-interview directory alongside the course, a compose_readme.bat script for assembling the README, and a set of stray working files such as 1.bin, 1.json, f.txt and a test_contextlib_connect.db used by the database chapter. The last push was on 2026-06-10 and there are no tagged releases, so there is no version to pin and no upgrade path beyond following the main branch.

None of that makes the guide unusable, and the churn is normal for a personal teaching repository. It does mean the right way to depend on it is to fork it and treat your fork as the artefact you maintain, rather than to track a moving upstream and expect the same file names to keep their contents.

Editorial conclusion

Mockinaut fits a Russian-speaking learner who wants a patient, example-led walk from lists to architecture, and it fits poorly for a team that needs English documentation, a stable API, or a mock interview engine it can call from code. Before adopting it as an internal reference, read the license file at the root, since the repository carries a custom licence that GitHub cannot classify, and check that the notebooks match the Python version your team runs, because the chapters are written as a course rather than as a versioned manual.

Frequently asked questions

Official sources

1. amaargiru/Mockinaut on GitHub
2. Issues
3. README