What should a candidate's pre-interview company research cover before a recruiter screen?
answer
- Three kinds of source, not three browser tabs
- How they build, what they sell, how they are funded
- The product itself counts as a source
- One page, written the day before
- Every finding owes you a hook or a question
basics
~20 sThree kinds of source: how the company builds (its public engineering writing), what it sells (the product itself), and how it is funded or performing. Capture the findings on one page as hooks and questions, not as memorised facts.
solid answer
~40 sI read three sources and write one page. First, public engineering writing — blog posts, talks, public docs — because that shows how they build and which problems they chose to write about. Second, the product itself: I sign up or read the docs and note one concrete observation, like how a data import handles a malformed file. Third, how they are funded or performing — the funding stage or the annual report's narrative — because that tells me the constraint engineering is under. Then I write two hooks I could genuinely say about them and four questions I could only ask having done this reading. The whole thing fits a 45-minute block; past that, returns fall off fast.
go deeper
Be ready to name three concrete sources you would read and to say what each one told you. Having actually opened the product, even the free tier, separates you from most first-job candidates.
Explain why each source type exists: engineering writing shows how they build, the product shows what they ship, funding or financial information shows the constraint the team is under. Show the page you wrote, not the tabs you opened.
Demonstrate that you filter. Say which findings you discarded because any candidate could have said them, and how you decided a 45-minute block was enough for this stage of the process rather than reading everything available.
Own the tradeoff between depth and breadth when several processes run at once. Be able to say where research stops paying — the point where more reading produces facts rather than better questions — and how you defend that boundary on your own calendar.
## Why research is graded, not admired Almost nobody is asked *did you research us?* directly. What happens instead is that a recruiter asks something ordinary early in the screen, and listens for whether your answer could have been given about any employer in the sector. Research is scored on **specificity**, not on volume. Ten facts you can recite are worth less than one observation nobody could make without having looked. That reframes the goal. You are not collecting knowledge about the company; you are manufacturing two things you can use in conversation — **hooks** (something specific and true you can point at) and **questions** (things you can only ask because you read something). Everything else is overhead. ## The three source types **1. How they build — public engineering writing.** Blog posts, conference talks, public technical documentation, open changelogs. The value is less the technology named than the *problem they chose to write about*: teams write up the thing that hurt. A write-up about reprocessing a data pipeline after a bad upstream feed tells you they own messy inputs and care about recovery. **2. What they sell — the product itself.** Sign up for the free tier, read the API docs, click through the onboarding. For a data product, useful observations are concrete and small: how an import behaves on a malformed file, whether rejections are shown per record or as one failure, what the export shape looks like, what the public status page says has recently gone wrong. One such observation outperforms a page of marketing summary. **3. How they are funded or performing.** For a private company: the funding stage and who they say they sell to. For a public one: the segment narrative and headcount direction in the annual report. This does not make you an analyst; it tells you the *constraint* engineering is working under — land new customers, cut cost per unit, meet a compliance bar, or hold reliability while volume climbs. A fourth, weaker category is third-party commentary: anonymous employee reviews and self-reported pay entries. These are self-selected samples that skew toward extremes, and pay norms vary enormously by market, level and local rules — where a company or a posting publishes a range, treat it as a starting point rather than a fact you can quote back. Use this material to *generate a question*, never to form a verdict before you have spoken to anyone. ## The one-page research sheet The artefact that makes this usable is a single page with three columns — source, what I found, what it turns into: | Source | Finding | Turns into | |---|---|---| | Engineering writing | A claim: they moved nightly batch ingestion to an event-driven pipeline | A question | | Product | An observation: the import screen reports rejections per record, not per file | A hook | | Funding or performance | A fact: the last raise was pitched around serving regulated customers | A question | From that sheet, an example question is: *Your engineering blog described moving to event-driven ingestion — what did that cost you in debugging?* It is short, it is impossible to ask without having read the post, and it invites the other person to talk about real work. ## The 45-minute block Timebox it. Three sources read, two hooks and four questions written, inside one 45-minute block, done the day before rather than in the ten minutes before the call. The timebox matters for two reasons: research expands to fill whatever time you give it, and reading you did not convert into a hook or a question is reading you will not use. ## The failure mode The most common weak version is reciting the About page back at the interviewer as evidence of homework. Mission wording is public, generic and written by people who are not on the team; repeating it proves only that you can read a landing page, and it generates no question at all. The test to apply to every line on your sheet is simple: *could a candidate who spent zero minutes on this company have said it?* If yes, it is not research — cut it and go read something the marketing team did not write. A smaller variant is the opposite: heavy, undirected reading with nothing written down, so nothing surfaces under pressure. The page is not bureaucracy; it is what makes the reading retrievable in a live conversation.
- How would you use the product itself as a research source for a data company?By using it rather than reading about it. I sign up or open the public docs and look for one concrete behaviour: how an import handles a malformed file, whether rejections are reported per record or per batch, what the export shape looks like, what the status page says recently broke. One specific observation like that is worth more in conversation than a summary of the marketing site, because nobody who skipped the research could have made it.
- How much weight do you put on anonymous employee reviews of a company?Low weight, and only as question fuel. Reviews are a self-selected sample that skews to people with strong feelings in either direction, and they rarely say which team or which period they describe. If a theme repeats across several, I turn it into a neutral question for someone who works there now rather than treating it as settled. The same caution applies to self-reported pay entries, which vary by market and level and are not a benchmark I would quote as fact.
- What would you do if the funding or financial information you found is out of date?Treat it as directional and say so if it comes up. I use it to infer the constraint the team is under, not to make claims about the business. If the most recent public information is old, that itself is a reasonable thing to ask a recruiter about — where the company is in its funding or growth cycle now — rather than guessing on the call and being corrected.
saying these in an interview costs you the question
- Reciting the About page back as evidence of homework
- Naming the product repeatedly without ever having opened it
- Notes full of facts with no question attached to any of them
- Treating anonymous employee reviews as established fact
- Doing the reading during the call itself, visibly
- Volume of tabs read mistaken for depth of preparation