How to study a company's codebase before a technical interview
Written by GitDiagram. Checked on (sources).
If the company has public GitHub repositories, learn the shape of the product rather than its code: the main parts, how a request or job flows through them, what the team is working on now, and how they review changes. An architecture diagram gives you the first two in minutes (replace hub with diagram in the repository's URL); recent pull requests, issues and the contributing guide give you the rest. Then prepare two or three specific questions from what you saw.
How to prepare
- Find the main repository. Start from the company's GitHub organization and its pinned repositories; the product's main repository usually has the most stars and recent activity.
- Get the map. Open its diagram and overview. Aim to explain, in three sentences, what the main parts are and how a typical request or job moves through them.
- Read what the team is changing now. Recently merged pull requests (search
is:pr is:merged) and open issues show current priorities, the review style and how much testing is expected. - Run it if you can. Follow the README or contributing guide to start it locally. Whatever was hard to set up is a fair thing to mention.
- Prepare questions, and be honest about depth. Turn what you saw into questions ("how do these two parts share work?"). Say you studied the public repository; don't claim to know internals you haven't seen.
Example: n8n
n8n's diagram (made 2026-11-05) has 25 parts in 5 groups (Workflow authoring, Execution and AI, Integrations and services, Operations and governance, Apps and clients) and 17 connections. The main path is short enough to say out loud: someone designs a workflow in the visual editor (packages/frontend/editor-ui/src), the execution engine (packages/@n8n/engine) runs it, and the engine executes integration nodes (packages/nodes-base/nodes) against connected services.
The map also points at a good question. The agent runtime (packages/@n8n/agents) connects to model adapters, tools, memory, guardrails and streaming, but the diagram shows no connection between it and the execution engine, because the sampled files did not show one. "How does the agent runtime relate to the workflow engine?" is a specific, informed question to bring.
Other tools that help
DeepWiki writes a longer explanation of popular public repositories, with a chat for follow-up questions. GitHub's code navigation lets you read without cloning. If the company's code is private, its engineering blog, conference talks and public API docs are the next best map.
GitDiagram's diagram is made by an AI model from the file tree, the README and up to 12 source files. It is a map of the important parts, at most 34 of them, not a complete dependency graph: it can simplify or leave things out, every linked path is checked against the real repository, and it shows the repository as it was when the diagram was made (Regenerate makes a fresh one).
Questions
I have a technical interview at a company with public GitHub repos. How can I understand their architecture quickly?
Open an architecture diagram of their main repository, learn the main parts and the main path, skim recently merged pull requests and open issues, and prepare a few specific questions from what you saw.
Sources
Checked on . Products change: if something here is out of date, open an issue.