The 72-Hour Company Research System

An interview invitation arrives for Friday. Most candidates spend the next three days on more problem-solving practice and a rehearsed "tell me about yourself". Then the interviewer asks, "Why do you want to work here?", "What do you know about what our team does?", or opens with a problem from their own domain, and the generic preparation shows.

Company-specific preparation does not replace problem-solving. It sits beside it, and it changes the conversation: you recognise the domain of their problem, you mention a decision their team wrote about, you ask a question nobody else asks. This article is a system for getting there in about three days.

• A 72-hour timeline from invitation to interview.
• What to ask the recruiter before you prepare.
• How to build a research notebook with grounded AI tools.
• Less obvious public sources that show how a company's engineers think.
• Where to draw the line when researching interviewers.

Adjust to the time you actually have, but keep the three phases.

Problem-solving practice continues throughout, but the research phase makes it targeted.

Recruiters want you to be prepared; a well-prepared candidate makes their job easier. A short, polite message can save you hours:

Hi [Name], thank you for scheduling my interview for [role] on [date].To prepare well, could you share:1. How many rounds there will be, and the format of each (coding, design,   behavioral, HR)?2. Whether coding will be on a shared editor or a whiteboard tool, and which   languages are allowed?3. Which team or area the role is in, if known?4. Anything you'd recommend I review beforehand?Thank you, [Name]

Many recruiters answer some or all of these. Write the answers into your notebook.

Gather the material in one place and use an AI tool that answers from your sources, with citations, rather than from its general memory. Two common setups, as of October 2026:

• A source-grounded notebook tool, such as NotebookLM, where you add documents, links and pasted text as sources, and its answers cite the passages they used.
• A project or workspace in a general assistant (for example Projects in Claude or ChatGPT), where you upload files and set instructions to answer from them first.

Either works. The point is grounding: an assistant asked about a company from memory may mix up products, invent architecture or describe the company as it was years ago.

Keep personal data out: do not upload your offer letters, other candidates' details or anything marked confidential. For review sites, add your own notes summarising reports rather than copying whole pages.

This workspace is for preparing for an interview at [company] for [role].Rules:- Answer from the uploaded sources first and cite which source each point comes from.- If something is not in the sources, say "not in my sources" before adding  general knowledge, and label general knowledge clearly.- Never invent facts about the company, its systems or its people.- When I ask for likely interview topics, base them on the job description and  candidate reports, and say how many sources support each.

1. Based on the engineering posts, what are the three hardest technical problems   this company says it has solved? For each: the decision, the alternatives   they considered, and why they chose it. Cite the posts.2. From the candidate reports, what do interviewers here most often ask about,   beyond problem-solving? Count how many reports mention each.3. Write 10 questions an engineer who wrote these posts might ask an entry-level   candidate, each tied to a specific post.4. What does this company appear to value in engineers, as shown in the posts   and values page? Quote the evidence.5. Which parts of my project ([one-line description]) connect to problems in   these sources? Be honest if the connection is weak.

How to check: open the cited passage for anything you plan to say in the interview. If an answer has no citation, or the citation does not support it, do not use it.

Most candidates read the company's homepage and one review site. Engineers' real thinking is often elsewhere:

• Conference talks. Indian product engineers speak at conferences and meet-ups (for example events run by HasGeek, language conferences, cloud and data meet-ups). Search video sites for the company name with "engineering" or "talk".
• The company's GitHub organisation. Public repositories, their README files, open issues and pull request discussions show their stack, standards and how they review code.
• Product changelogs and release notes. What they shipped recently, and so what teams are busy with.
• Old discussion threads. A full-text search of Hacker News (hn.algolia.com) or Reddit for the company name can surface engineers discussing technical decisions years ago, and the company's own posts in monthly hiring threads.
• Developer documentation and status pages. Well-documented parts of a product are usually the parts they care most about; a public status page shows what can break.
• For listed companies, annual reports and investor presentations. They describe priorities in plain business terms, which helps your "why this company" answer.

If you know who will interview you (from the invitation or the recruiter), a little research on their professional, public work helps you ask good questions:

• their role and team, from their LinkedIn profile;
• posts they wrote on the engineering blog, talks they gave, public code they contributed.

Use it to understand what they work on and perhaps to ask one informed question at the end ("I read your post on migrating the notification service; how has it held up?").

Do not go further. Looking through personal social media, family details or anything private is intrusive, and mentioning it would be alarming. Do not open the interview by reciting their history. Interest in their work is welcome; surveillance is not.

Rohit has a Friday interview at a mid-sized logistics software company for a junior backend role.

• Tuesday (72 to 48 hours): he emails the recruiter, who replies that there are three rounds: a coding round on a shared editor (Java allowed), a "design and project discussion" and a hiring manager conversation. He builds a notebook with the job description, six engineering posts, two talk transcripts, the API documentation, three news items and his notes from seven candidate reports.
• Wednesday (48 to 24 hours): the notebook shows posts about route optimisation and event-driven tracking, and reports that mention questions on queues and on the candidate's own project. He practises graph problems (BFS and shortest paths) and prepares to explain his order-tracking project in depth.
• Thursday (24 hours): a mock coding interview, then he writes his one-page brief and "why this company" answer from cited material (article 29).
• Friday: a 20-minute warm-up and a read of the brief.

In the design round, the interviewer asks how he would track thousands of delivery partners' locations. Because he read their tracking post, he starts with the right questions instead of a blank stare.

• Only generic practice in the days before an interview.
• Not asking the recruiter about the format.
• Asking AI about the company from memory instead of grounding it in sources.
• Repeating notebook claims without checking the citation.
• Over-researching interviewers into their personal lives.
• Cramming research the night before instead of reviewing a brief.

• Next: Read the JD, the Engineering Blog and the Product Like an Insider goes deeper into the three most useful sources.
• For working with AI over your own documents, see Give AI the Right Context: Source Material and Long Documents.
• For a research workflow that keeps track of sources, see An AI-Assisted Research Workflow: Primary Sources and Citation Checking.