alexeygrigorev/data-science-interviews: A CC-BY Question Bank That Ships With Answers

The problem is not finding questions, it is finding written answers

Question lists for data science interviews are easy to find and mostly interchangeable. What is scarce is a set of questions where someone has committed to an answer in text, in public, under a licence that permits reuse. That is the gap this repository fills. The README states the premise directly: the answers are given by the community. So the unit of value here is the answer paragraph, not the question line. The intended reader is someone preparing for a data science interview who wants to compare their own reasoning against a written explanation, and secondarily an instructor or writer who needs question-and-answer material they can legally adapt. The repository is written in HTML according to the metadata, though the content files referenced in the README are Markdown, which tells you the HTML is likely a rendering or site layer rather than the source of truth. Anyone expecting a curated, editorially reviewed textbook will be disappointed, and the README does not claim otherwise.

theory.md, technical.md and contrib: how the material is split

The README lists two main files. theory.md covers linear models, trees, neural networks and others, which is the conceptual half of a typical interview loop. technical.md covers SQL, Python and coding, which is the applied half. A third location, the contrib folder, holds contributed questions, with contrib/probability.md named as the example, and the README invites readers to add more there. There is also awesome.md, described as a collection of other data science interview questions and resources, and contributors.md, which the README points to as the list of contributors. That is the whole visible architecture: flat Markdown files, one topic per file, plus a folder for outside contributions. There is no build step described, no question schema, no metadata block per question, and no index file that maps a question to a difficulty level. If you want to filter by topic you filter by which file you open. That is a deliberate simplicity, and it is also the reason the repository cannot tell you what you are weak at.

The contribution path is a pull request, and that is the whole review process

The README gives three instructions, all of the same shape. If you know how to answer a question, create a pull request with the answer. If an answer already exists but you can improve it, create a pull request with an improvement suggestion. If you see a mistake, create a pull request with a fix. Nothing else is described: no issue template, no style guide for answer length, no requirement to cite a source, no statement about who merges and against what standard. For a reader, the practical consequence is that two answers in the same file can disagree, and the repository offers no mechanism to mark which one is current. For a contributor, the barrier is low, which is exactly why the corpus grows. The README also routes readers to the author's Twitter and LinkedIn accounts for updates, and to DataTalks.Club for discussion. Those are the only channels the README names for staying informed, and none of them is a changelog inside the repository.

Getting the files onto your machine

There is no package, no install command and no CLI in the supplied material. You get the content the same way you get any repository: clone it and open the Markdown files. The default branch is master, so the clone URL takes that branch by default. The README gives no setup instructions beyond pointing at the files, so treat the repository as a document collection rather than a tool. The homepage field in the metadata points to alexeygrigorev.com/data-science-interviews/, which is where the rendered version lives if you would rather read than clone. Two Markdown files, theory.md and technical.md, plus contrib/probability.md, are the entry points named in the README. Everything else in the repository, including the logo image referenced at the top of the README, is supporting material. If you were hoping for a config key to tune or an environment variable to set, there is none to report, and inventing one would be dishonest.

Community answers drift, and nothing in the repository flags stale ones

The failure mode follows from the contribution model. An answer about a library API, a SQL dialect detail or a default hyperparameter can be correct when written and wrong a year later, and the README describes no mechanism for flagging that. The only correction path stated is the same as the creation path: a pull request. That means the freshness of any given answer depends on whether a reader noticed the problem and bothered to submit a fix. A second limitation is scope. The README lists theory and technical as the two live categories and marks the rest as more to come, so the coverage is uneven by design. Probability questions live under contrib rather than in the main files, which means the boundary between core and contributed material is organisational, not editorial. If your interview loop leans on experimentation design, causal inference or data modelling, check the actual files before assuming the topic is covered, because the README does not enumerate the questions.

Compared with a question-only list, the difference is who wrote the answer

The obvious alternative is one of the many bare question lists that circulate for interview prep, including the ones collected in this repository's own awesome.md. The difference in approach is straightforward. A question-only list leaves you to produce and validate your own answer, which is closer to the interview itself but gives you nothing to check against. This repository commits to answer text, which means you can compare your reasoning with someone else's and spot the gap. The trade is that you inherit the author's assumptions, and with many authors you inherit many sets of assumptions. A second alternative is a commercial prep platform, which typically adds grading, progress tracking and versioned content. Those features are absent here, and the README does not present the repository as competing with them. Choosing between the two comes down to whether you want a corpus you can read, fork and quote, or a system that tells you whether you got the answer right.

CC-BY-4.0, attribution and the maintenance you inherit

The README states the work is licensed under a Creative Commons Attribution 4.0 International License, and the licence badge in the README links to creativecommons.org/licenses/by/4.0/. Attribution is the operative condition: if you reuse the answers, you carry an obligation to credit the work, and the README points to contributors.md as the list of contributors, which is where that credit would come from. This is not legal advice, and anyone republishing at scale should read the licence text rather than this summary. On maintenance, the repository shows no releases in the metadata supplied, which fits a document collection: there is nothing to version and nothing to upgrade. Your ongoing cost is editorial, not technical. Every time a library or a SQL engine changes behaviour, some answer in theory.md or technical.md may need a pull request, and no one is obliged to send it. Budget for reading answers as claims to verify, and check the last push date before you treat a file as current.

Editorial conclusion

Adopt this repository if you want a permissively licensed question-and-answer corpus you can quote or adapt with attribution, and if you are willing to read every answer critically because the README states the answers come from the community rather than from a review process. Do not adopt it as a graded practice platform: there is no scoring, no difficulty ordering and no test runner in the material supplied. Before you rely on any single answer, open the file that contains it, check the surrounding question, and confirm the answer still matches the library and version you use in production.

Official sources

1. alexeygrigorev/data-science-interviews on GitHub
2. Issues
3. License: CC-BY-4.0
4. Project website
5. README