For a long time my company research was a memory exercise. Founding year. Funding rounds. The three words in their mission statement.
I would walk in loaded with facts and then find no natural place to use any of them. Worse, when I did force one in, it landed like a party trick. I noticed you were founded in 2016. Yes. And?
What changed is that I stopped collecting facts and started collecting questions.
The goal is not to prove you researched
Interviewers are not scoring your recall. They are trying to answer two things:
- Does this person understand what we actually do?
- Have they thought about whether they want to do it? Trivia answers neither. A good question answers both at once, because you cannot ask a specific question about a company without demonstrating that you understood it.
The hour I actually spend
Roughly this split:
| Time | What |
|---|---|
| 15 min | The product — used, not read about |
| 15 min | The job description, reread properly |
| 15 min | Recent news, releases, engineering blog |
| 10 min | The people interviewing me |
| 5 min | Writing questions |
Use the product
If it is a consumer app, install it. If it is a website, click through the flow. If it is B2B and locked behind a demo, read the pricing page, the docs, and the changelog.
Fifteen minutes of actual use gives you more usable material than an hour of reading about the company. You will have an opinion, and opinions are what conversations are made of.
You do not need to critique it in the room. You need to be able to say "I was going through the onboarding and noticed…" — which immediately places you as someone who engaged rather than applied.
Reread the job description
You read it before applying. Read it again now, slowly.
Job descriptions are usually written by the hiring manager, and they leak. A line like "comfortable with ambiguity" is rarely decorative. Neither is "you will work closely with the design team" or "we are rebuilding our data pipeline."
Mark anything that sounds like a real problem rather than boilerplate. Those are the things the team is worried about.
Read the last three months, not the origin story
Recent beats historic:
- Product releases and changelogs
- The engineering or company blog
- Funding news, or for public companies, the last earnings summary
- Recent job postings — twelve open backend roles tells you where the pressure is The founding story is on the About page and it is not going to come up.
Look up the interviewers
Five minutes each. What they work on, how long they have been there, what they did before.
Someone who joined three months ago and someone who has been there six years give you very different questions to ask. The former can tell you what onboarding was really like. The latter can tell you what changed.
What I have stopped doing
- Memorising the mission statement. Reciting it back is transparently a memory trick.
- Exhaustive competitor analysis. Knowing the main competitor is enough. A market map is not.
- Reading every Glassdoor review. Reviews skew toward the angry and the freshly departed. I read them for repeated specifics — "reorgs every six months," named twice, is a signal. Generic "bad management" is noise.
- Preparing facts I have no plan to use. If I cannot see where a fact would fit, I drop it.
Converting research into questions
This is the whole point. Take each thing you found and turn it into something you would genuinely like to know.
Found: They shipped a big redesign last quarter. Question: How did the redesign land? Is the team still cleaning up after it, or has it settled?
Found: The JD mentions rebuilding the data pipeline. Question: Where is the pipeline rebuild right now — still designing, or already migrating?
Found: Twelve open backend roles. Question: Is the team growing into new work, or catching up on existing work?
Each of these does three jobs. It shows you looked. It gets you information you actually need. And it moves the interview from interrogation toward conversation, which is a far better room to be in.
I aim for five and expect to ask two or three. The rest get answered along the way. That is fine — it is a stock, not a script.
Where the research goes wrong
The failure mode is using research to perform enthusiasm.
If you have to manufacture excitement about a company, the research will not fix that, and interviewers are reasonably good at detecting it. It is entirely acceptable to be interested in the work rather than in love with the brand. "This is the kind of problem I want to spend two years on" is a stronger and more believable answer than anything involving the word "passionate."
Fitting it in
This slots into a wider set of things I do before an interview — the stories, the setup, the questions. The full checklist is here.
And once you are in the room with all this material, the constraint becomes delivery: saying the useful thing in ninety seconds instead of four minutes. That is a separate skill.