What should you actually research before an interview?
Ninety minutes, spent where it changes what you say
· 5 min read · Interview Preparation
Most interview research is theatre. People memorize the founding year, skim the values page, read forty Glassdoor reviews, and arrive knowing a pile of facts that never once come up.
Meanwhile the questions that actually get asked — why do you want to work here, what do you think of the product, what would you do first — get answered with something that could apply to any company in the sector.
Useful research has one property: it changes something you say. If a fact can't alter a single sentence of your answers, learning it was entertainment. Here's where ninety minutes actually goes.
Use the product — 30 minutes
The single highest-return half hour available to you, and the one most candidates skip.
Sign up. Click everything. If it's B2B or you can't access it, watch a demo, read the docs, get a trial. Then form one specific opinion — something you liked and something that confused you.
"I went through your onboarding on Tuesday and I got stuck at the workspace step — I wasn't sure whether to invite my team before or after importing" is worth more than everything else on this list combined. It proves interest that can't be faked, and it puts you and the interviewer on the same side of the table, discussing their product instead of auditing you.
How they make money — 10 minutes
Who pays, how much, and for what. Subscription or usage or ads or services. Enterprise contracts or self-serve. One customer paying a lot, or many paying a little.
A startling number of candidates reach final rounds unable to explain the business model of the company they're joining. It matters because it determines what your job would really be — the same title does very different work at a self-serve product company and at one selling six-figure annual contracts.
What's happened in the last six months — 15 minutes
Funding, layoffs, launches, acquisitions, leadership changes, a bad news cycle. Search news rather than the company's own blog, and read the most recent things first.
This tells you the pressure the team is under, which is usually the real reason the role exists. A company six months past a raise is hiring to grow. A company six months past a layoff is hiring to cover. Those are different jobs with different interview answers, and nobody will tell you which one you're in.
Decode the job description — 10 minutes
Read it again, not as a list of requirements but as evidence. Why does this role exist now? Is it new or a backfill? Which responsibilities are described in unusual detail — that's usually where the pain is. What's conspicuously missing?
A job description is a document written by people with a problem. Ten minutes reading it as a symptom rather than a checklist will give you better questions than an hour on the company website.
Your interviewers — 10 minutes
Names, roles, tenure, background. Not to flatter anyone — mentioning you read their LinkedIn is uniformly awkward — but to calibrate.
Someone two months into the company will talk about it differently than a founding employee. An interviewer from an infrastructure background will probe different things than one who came up through product. You're working out what this person is likely to care about, so you can lead with the part of your experience that matters to them.
The team's public work — 15 minutes
Engineering blog, public repos, conference talks, API docs, changelog. For non-technical roles: case studies, marketing site, public decks, recent campaigns.
This is where you find out what they actually do, as opposed to what the recruiter said. It surfaces the real stack, the real standards, and the problems they were interested enough in to write about — which are excellent things to ask about, because someone on the panel probably wrote it.
Turn research into three things
Facts alone don't help. Before you close the tabs, your ninety minutes should have produced exactly three artifacts:
- One specific question that could only be asked by someone who did this work. Not "what's the culture like" — something about a real decision they made.
- One point of view about the product or market, held lightly. You're not there to critique them, but having an actual opinion separates you from everyone who says "the space is exciting."
- One connection between something you found and something you've done. "You moved billing in-house last year — I ran that migration at my last company and it was harder than anyone expected."
If you have those three, the research worked. If you have twelve facts and none of these, you did homework instead of preparation.
Then don't perform it
The failure mode on the other side is the candidate who recites. Listing what you found reads as anxiety, not enthusiasm, and it eats time you need for your own answers.
Research should surface once or twice, naturally, where it's relevant — and mostly it should just make your answers more specific without anyone noticing why. Nobody needs to know you spent an evening in their changelog.
If you only have twenty minutes
It happens. Prioritize brutally:
- 10 min — use the product, even superficially
- 5 min — how they make money
- 5 min — most recent news item, and who you're meeting
That's enough for one real question and one real opinion, which is most of the value. The rest is polish.
Want this done for the specific role? labor.quest analyzes the job description alongside your CV and builds the prep plan — including the questions worth asking and the gaps worth addressing — for that company and that round.
All posts