Why research changes the interview
Company research is not about flattering the interviewer with trivia. It changes how you answer and what you ask. When you understand the product, the stage of the company, and the problems the team is working on, your answers connect to their reality instead of staying generic. You can frame your experience in terms they care about, and you can ask questions that sound like a future colleague rather than an outsider.
It also protects you. An interview runs in both directions, and the same research that helps you impress them helps you decide whether the role is worth taking. A good hour before the call is one of the highest-return things you can do in a job search.
Start with the product, and actually use it
Before anything else, use the product. Sign up, click around, hit the limits of the free tier. If it is a consumer app, become a user for a day. If it is a developer tool, read the quickstart and try the basic flow. If it is internal or enterprise software you cannot access, read the docs, watch a demo video, and study the marketing site to understand who it is for.
While you use it, take notes on three things: what you liked, what felt rough, and who you think the customer is. These notes become specific talking points. "I tried the onboarding and the import step was smooth, but I noticed there is no way to undo a bulk action, which made me curious how you think about destructive operations" is a sentence no generic candidate can produce. It proves you did the work and it opens a real conversation.
Understand the stage and the business
Knowing the company stage tells you what the job will actually feel like. A ten-person seed-stage startup and a public company with ten thousand employees hire for very different things, even under the same job title.
Find out, roughly:
- How big is the company and how fast is it growing.
- How is it funded, and how does it make money.
- Is it a startup finding its market, a scale-up growing hard, or an established business optimising.
- Who are the main competitors, and how does it describe its difference.
You can get most of this from the company site, a few news articles, the careers page, and public funding or filing information. You do not need a finance degree. You need a sentence like "you are a Series B company growing the engineering team quickly, so I expect a lot of ownership and not much process yet, which is what I am looking for." That single line shows judgement about fit.
Research the team and the people
Find out who you will meet. Recruiters will usually tell you the names and roles of your interviewers if you ask, and it is a fair question. Read their public profiles and recent posts. You are not looking for personal details, you are looking for context: what they work on, what they have written about, how long they have been there.
This does two things. It calms nerves, because the interview feels less like meeting strangers. And it lets you tailor. If you are meeting the engineer who leads the data platform, you can be ready to talk about data work and to ask informed questions about their stack. If you are meeting a founder, expect more questions about motivation and fit than about syntax.
Also look at the engineering culture signals. Does the team have a public blog, open-source projects, or conference talks. Those tell you what they value and give you genuine material. Reading one engineering blog post from the team is often the single best-value piece of research, because it shows you how they think and gives you something specific to reference.
Map the role to your evidence
With the product and team understood, reread the job description and map each main requirement to a story or project from your own experience. This is preparation for the interview itself. If the description stresses "experience scaling systems," have a concrete example ready. If it stresses "comfort with ambiguity in an early-stage team," pick the story that shows that.
Write a short grid for yourself.
They want | My evidence
Scaling read-heavy systems | Cache + fanout work on the feed service
Working across product | Shipped the billing change with PM and design
Comfort with ambiguity | Owned the migration with no clear spec
Now your answers will land on their actual needs instead of being a generic recital of your CV.
Prepare questions that show you did the work
The questions you ask at the end are part of the evaluation. Weak questions like "what is the culture like" signal that you did no research. Strong questions come straight out of what you found.
A few patterns that work:
- A product question from using it: "I noticed the export feature is fairly new. How did that come about, and what is next for it."
- A team question: "I read your post on moving to a monorepo. How has that played out a year on."
- A role question: "What would the first ninety days look like for whoever takes this, and what would success look like at six months."
- A direction question: "Where do you see the biggest engineering challenge in the next year."
Keep two or three ready and adapt to the conversation. Asking nothing, or asking only about salary and holidays, leaves a flat final impression even after a strong interview.
Keep it to an hour, and write it down
Research has diminishing returns. An hour of focused work covers the product, the stage, the people, and a few good questions. Beyond that you are usually procrastinating. Put your findings in a short note you can reread ten minutes before the call: one line on the product, one on the stage, the names and roles of your interviewers, your evidence grid, and your three questions. That note turns a vague sense of being prepared into something you can actually use under pressure, and it doubles as a record to help you decide if the offer comes.
Continue your prep
Pair this with role-specific question sets and sample answer outlines: