I used to spend three hours researching a company before every interview. Org charts, Glassdoor reviews, the founder's old podcast appearances, the whole thing. By the interview, my head was full of trivia and empty of anything I could actually use to answer a question.

The research that helps you in an interview is narrow. You're not preparing a book report. You're trying to do two things: ask better questions, and frame your own experience so it lands.

Here's how I'd spend 45 minutes today.

Start with the product, not the company

Go to the homepage. Pretend you're a customer. What problem does this thing solve, and for whom? Write that down in one sentence, in your own words. If you can't, the rest of the research is going to slide off you.

Then look at the pricing page if there is one. Pricing tells you who they think their customer is — self-serve indie hackers and enterprise procurement read very different pricing pages. If you're interviewing for a sales or marketing role this is non-optional. If you're an engineer, it still tells you the shape of the business behind the code.

A hidden upside: most candidates skip this step. "What was the buyer profile like for the mid-tier plan?" lands very differently from "I read on Glassdoor that culture is good."

Read what they wrote, not what was written about them

Thirty minutes on the company's own blog, careers page, and any recent product announcement. The careers page is where companies put the version of themselves they want you to believe. Compare it to what you see in the product. If there's a gap, that's an interesting question to bring up.

If the company has a public engineering blog, podcast, or post-mortem culture, read one piece. One. Pick the most recent technical post or the most recent founder's letter. Have an opinion on it. Not a fawning opinion — a real reaction. "I thought your post on X was interesting because it contradicts what most teams do, and I had a question about Y" is a memorable opening when the interviewer asks if you have questions.

Find one recent piece of news

Not a press release. A real piece of news from the last six months: a funding round, a product launch, a leadership change, a layoff, a new market. The key word is recent. Bringing up something from 2021 in a 2026 interview is worse than bringing up nothing.

Google News, the company's LinkedIn page, and Crunchbase cover almost everything between them. Twenty minutes is plenty.

What to do with the news: connect it to the role you're interviewing for. If they just raised a Series B and they're hiring you for product, you have an obvious thing to ask about — what's changing in the product roadmap because of it. If they just had layoffs, you don't ignore that, but you don't lead with it either. The right move is to acknowledge it neutrally if it comes up and otherwise keep the conversation forward-looking.

Look up the people you'll meet

Five minutes per interviewer on LinkedIn. Two questions you're trying to answer:

1. What did they do before this role, and how long have they been here?
2. Is there anything in their background that overlaps with yours?

That's it. You're not building a dossier. You're looking for the one piece of common ground or context that makes the conversation feel less like a job interview and more like a normal first meeting between two people in the same field.

If you can't find a LinkedIn profile, check the company's about page. If they're not public anywhere, just skip it. Some interviewers like their privacy and you don't need to mention you looked.

Check Glassdoor and Blind, but with caution

Glassdoor reviews skew angry. Blind threads skew specific and often bitter. Both are useful for one thing: spotting consistent patterns. If five separate reviews mention the same broken process, that's signal. If one review says management is terrible and the other forty are fine, that's noise.

Don't bring Glassdoor reviews into the interview. Asking "I read on Glassdoor that..." is a way to make sure you don't get the offer. Use the patterns you spot to inform what you ask, not as evidence to confront people with.

Prepare three questions you actually want answered

This is the only deliverable that matters. By the end of the 45 minutes you should have three real questions, not generic ones. Generic questions sound like:

• What's the company culture like?
• What does success look like in this role?
• What are the next steps?

Real questions sound like:

• The careers page emphasizes async work but I noticed most of your engineering blog posts have multiple authors. How does collaboration actually happen day to day?
• The Series B announcement mentioned expansion into Germany. Is this team going to be involved in that, and if so when?
• I saw the API docs were rewritten this year. What was wrong with the old ones, and what did you learn from the migration?

You don't need three of these. Two is fine. One good question lands harder than five rehearsed ones.

What to skip

A short list of research that feels productive but isn't:

• Memorizing the leadership team's bios. Nobody asks.
• Reading every press release going back five years.
• Writing out a summary document you'll never look at again.
• Quizzing yourself on the company's mission statement.

If you're building your CV alongside your interview prep, Postulit can keep your application material aligned with the role you're interviewing for so you're not retelling a different story in the room than the one on the page.

Forty-five minutes is enough. The interview is mostly about how you think and how you fit, and neither of those gets better with a sixth hour of background reading.