Research a company before an interview by finding three things: what its product does, what the advertised role is meant to improve, and what you still need to ask. Put each finding next to its source and connect the strongest ones to your own experience. You should leave with a brief you can use in conversation, not a pile of facts to recite.
Short answer: Read the job posting and company product pages, try the product or its public documentation, check one independent account, and prepare two relevant experience stories plus three questions. Label uncertain conclusions as questions. If the interview is soon, a focused half hour can still produce a useful brief.
The most useful company research ends in a better question or a more relevant answer. A fact you cannot use is just another note to forget.
Start with the hiring problem, not the company timeline
Open the job posting before the About page. Highlight the work the person will do, the outcomes they will own, and the constraints they will face. Separate those from the list of technologies and adjectives. A posting that says "improve account recovery for enterprise customers" tells you more about the likely work than a generic list of programming languages. If a responsibility appears in the opening and again in the day-to-day section, give it particular attention.
Then write a one-sentence provisional hiring problem: "They may need someone who can make account recovery safer without making legitimate customers wait too long." The word may matters. You have an interpretation of a public document, not inside knowledge. Treating a plausible theory about the team as a fact about its priorities is the research failure to avoid.
The National Careers Service interview advice recommends reading the job description, researching the company site, and preparing examples from your experience. Those are connected tasks. The posting identifies what to investigate; the company material gives context; your examples show what you could contribute.
| What the posting says | What you can reasonably infer | What you must ask |
|---|---|---|
| "Own the customer import flow" | Imports matter to this role | Which part fails most often today? |
| "Partner with support and security" | Several teams influence the work | Who decides when convenience and risk conflict? |
| "Improve reliability of scheduled jobs" | Background work is in scope | How is failure detected and recovered now? |
The middle column is a prompt, not a script. Select a past example and a question that can confirm or correct your reading. For a general role, start with the top two responsibilities. For a specialized role, add the technical or regulatory constraint that would change how the work is done.
Observe the product without diagnosing it from outside
Use the product if access is available. Complete one normal user task, then one task at the edge of that flow: edit a saved item, undo a mistake, recover from an error, or find an explanation for a confusing setting. If it is a developer tool, try one documented request or read the quickstart. If it is enterprise or internal software you cannot access, work from public documentation, a demo, a help center, and customer-facing examples.
While you use it, note who the customer is, what task they are trying to complete, and what you actually observed. "The import page asked me to confirm the file format" is an observation. "The engineering team has a validation problem" is an unsupported diagnosis. A visible rough edge may reflect a deliberate policy or a configuration you could not see.
Write down the customer's job in ordinary language: who is trying to do what, under which constraint, and what happens when it fails. A scheduling product might help clinic staff assign appointments while preserving patient access and staff availability. That description gives you a starting point for a question about conflicting constraints. It does not imply any particular system architecture or business performance.
If something felt rough, raise it as curiosity, not a verdict. "How do you handle edits after a schedule is shared?" invites an explanation. "Your edit flow is broken" assumes you have seen every use case. If you could not try the product, say that plainly; do not claim first-hand experience from a demo.
Check what each source can actually tell you
Company pages are the right source for what the company says it offers, which customers it names publicly, and the roles it advertises. They are weaker evidence for what working there feels like. Independent reporting may help with a major event, but a headline can omit the team context. Reviews can surface questions to ask, while one anonymous account is not a reliable diagnosis of an entire workplace.
The University of Pennsylvania career guidance recommends combining the job ad and employer website with news, professional contacts, and conversations with people who know the organization. That mix is useful because each source answers a different question. A public product page can explain the offering; a current employee can describe how a team actually works; neither can prove every claim the other makes.
For a public company, an investor page or official filing can clarify its business lines and stated risks. For a private company, you may only have the company site, recent announcements, customer material, and the recruiter. Do not force certainty from thin evidence. In any country, the availability of reliable corporate records varies, and a funding headline or employee count can age quickly. If you cannot verify a number and its date, leave it out of your answer.
Treat a series of job openings with the same care. Multiple postings might mean expansion, replacement hiring, or simply a broad search. Ask "Is this a new position or an existing seat?" rather than announcing that the team is growing fast. The question gets you the information you wanted without pretending the public evidence settled it.
Run four checks on every note you plan to use:
- Source: Where did I see it, and when was it published or last updated?
- Scope: Is it about this company, product, and team, or only the wider industry?
- Status: Is it a verified fact, my observation, an inference, or a question?
- Use: Which answer or question becomes better because I know it?
If a note fails the fourth check, it probably does not deserve a place on your final brief. If it fails the first two, do not say it as a fact.
Use the team's public work as context
If the interview invitation names the people you will meet, look at their roles and public professional work. You can ask the recruiter who will attend if the invitation does not say. A recent team article, talk, or public project may suggest an area worth discussing. It does not tell you what questions that person will ask.
Professional context can help you choose a relevant story. If you will meet someone responsible for a data platform, prepare an example involving data decisions if you have one. Keep another story ready; the interviewer may be assessing a different skill. Do not build an answer around assumptions about a person's priorities.
A team article can show how its authors explain a particular decision. It cannot prove that every team makes decisions that way. Ask what has changed since it was written. If there is no public team material, use the job description and make your question about the current work instead.
Keep the boundary professional. A public talk or work article can support a work question. A person's family, hobbies, or private circumstances do not belong in your preparation. You do not need to mention every profile you read.
Reference a public detail only when it moves the conversation forward. "I read your team's explanation of the migration. What changed after the first month?" asks for insight you could not get from the article. Reciting its headline adds little.
Choose the experience that answers the hiring problem
With the product and team understood, map the central responsibility to a project you can explain under follow-up. Identify your contribution, the constraint, a decision you made, and what happened afterward. If you cannot distinguish your work from the team's work, repair the story before the interview.
| Role clue | Evidence to prepare | Boundary to check |
|---|---|---|
| Improve a customer workflow | A change you made after observing users | Which observation was yours? |
| Work across support and engineering | A decision made with another team | Who owned the final decision? |
| Handle reliability problems | A failure you diagnosed and addressed | What did you verify afterward? |
The Harvard FAS interviewing guidance advises candidates to use employer research to connect their skills and experience to the job requirements. That is more useful than proving you visited the website. A researched detail should lead into something you actually did or a question whose answer will change your view of the role.
Prepare two stories. One should address the main responsibility in the posting. The second should address a different constraint, such as working across teams, handling a failure, or deciding what not to build. For each, prepare the tradeoff and the limit of your own involvement. Then you have material even if the interviewer frames the question differently from what you expected.
For example, a company document describing approval steps in an enterprise workflow might remind you of a project where you made permission changes auditable. Your answer can say that the published workflow caught your attention, then explain your relevant work. It should not claim that the employer has the same failure mode you once faced. That leap sounds knowledgeable for a sentence and collapses when the interviewer asks how you know.
Worked example: Nia's appointment scheduling brief
Consider this explicitly hypothetical interview. Nia is applying for a product engineering role at an unnamed company that sells appointment scheduling software to clinics. All product details, role text, and candidate experiences in this example are invented to show the method. They make no claim about a real company or a real patient system.
The hypothetical posting says the hire will improve rescheduling, work with support, and help reduce failed appointment changes. A public demo shows that a clinic worker can move an appointment and send a confirmation. Nia cannot log in to the staff interface. Her first draft says, "The scheduling system probably has race conditions and too many failed transactions." She has no basis for either diagnosis. A better brief separates what she found from what she suspects:
| Item | Nia's note | How she will use it |
|---|---|---|
| Posting fact | Rescheduling and support collaboration are named responsibilities | Choose a relevant cross-team story |
| Demo observation | A confirmation follows a changed appointment | Ask what happens if confirmation fails |
| Inference | A change may involve both staff and patient availability | Keep it as a hypothesis, not a claim |
| Unanswered question | What counts as a successful reschedule? | Ask the hiring manager for the team's measure |
Nia's owned example comes from a hypothetical school booking project. She built a change-history view for room bookings after staff kept receiving conflicting email updates. She did not design the whole booking platform. Her contribution was to record who changed a reservation, show the previous and current times, and let support staff identify which message corresponded to the latest change. Her team later found fewer ambiguous support cases in the project sample, but she has no reliable before-and-after count, so she does not invent one.
Her answer to "Why this role?" becomes specific without pretending to know the clinic company's internals:
"Your posting puts rescheduling and support collaboration together, which caught my attention. In a school booking project, I owned the change-history view that helped staff sort out conflicting reservation updates. I liked working through the question of which change was current and what support needed to see. I have only seen your public demo, so I would like to learn where rescheduling is hardest for your team today."
Each piece has a boundary: a public fact about the hypothetical role, Nia's contribution in the invented scenario, and an open question. If the interviewer says the real problem is policy rather than message ordering, Nia can adjust. Her preparation starts a conversation instead of trapping her in a false premise.
The distinctive research move is the claim boundary. Nia refuses to turn a visible confirmation screen into an assertion about failure rates or system design. She still extracts a useful question and a defensible past example. That is a stronger result than filling a page with unverified technical guesses.
Prepare questions that can change your decision
Bring three questions, each with a purpose. One should clarify the work, one should reveal how the team makes a difficult decision, and one should test a condition that matters to you. Examples include "Which outcome would tell you this hire is succeeding?", "Who decides when a customer request conflicts with a security requirement?", and "How does the team handle urgent work when planned work is already committed?"
Choose the person who can answer each question. A recruiter can explain the interview process, location expectations, compensation range, and contract terms. An engineer can describe a normal change, a failure, or a review practice. A hiring manager can explain the reason for the opening, priorities, and how success is judged. These are practical starting points; if your interviewer raises a topic, you can discuss it with them.
Do not ask a question whose answer is plainly on the page you just read. Turn the page into context instead: "I saw that rescheduling is a named responsibility. Which part of it needs the most attention now?" The second sentence asks for information you could not get from public material. If a question is answered earlier in the conversation, acknowledge the answer and use a different one.
Pay attention to whether the interviewer can give concrete examples. A vague answer is not automatically a warning sign; they may not know that area or may be unable to discuss it. Repeated uncertainty about the role's scope, decision rights, or success criteria is worth following up before you accept an offer. Your research should help you evaluate the opportunity as well as present yourself.
Build a brief you can use under interview pressure
Keep the final note to one screen or one page. Put the role and interviewers at the top, then the product's customer and task, the two strongest sourced observations, your two evidence stories, and three questions. Add the source link and date beside any time-sensitive claim. Avoid a dense chronology of founders, funding rounds, and announcements unless one of them genuinely affects this role.
The timing can be simple. For a first conversation, begin with the posting and company material, then spend the remaining time on your own stories and questions. For a later conversation, fill the specific gaps the first one exposed. If you have only ten minutes, identify the product, the main responsibility, one evidence story, and one question. The goal is usable preparation, not exhaustive reading.
Read the brief aloud once. If you cannot explain the company in plain language without repeating its slogan, revisit the product material. If your answer includes a confident claim you cannot source, change it to a question. If every note is about the employer and none is about your contribution, add an evidence story. Research is complete when the brief can support a real exchange.
The main avoidable errors are easy to recognize in the note itself:
- A fact without a source: verify it or remove it.
- A theory stated as a diagnosis: turn it into a question.
- Three stories about the same skill: replace one with evidence for a different constraint.
- Questions that repeat public copy: ask what has changed or how a decision works in practice.
- Notes only about impressing the employer: add the conditions you need to assess for yourself.
FAQ
How much company research is enough before a first interview?
Enough to explain what the company offers, identify the main work in the posting, connect one of your experiences, and ask a question the public pages cannot answer. A first conversation seldom needs a detailed financial or organizational history. Add depth when a later conversation makes a specific area relevant.
What if the company is small and has almost no public information?
Use the posting, its website, any public customer material, and the recruiter's invitation. Write down what remains unknown, then ask the recruiter for a product overview or the team's main priority. State the limit of what you could verify instead of filling the gap with guesses.
Should I mention a problem I noticed while using the product?
Yes, if you describe your observation precisely and ask about the tradeoff. Say what you tried and what happened. Avoid diagnosing a root cause or declaring a feature broken from a single attempt. The interviewer may know a constraint you could not see.
Can I use an employee review as evidence about the team?
Use it as a source of questions, not a verdict. Check its date, location, and whether it concerns the team you would join. Ask about the underlying issue, such as decision making or on-call expectations, without citing an anonymous complaint as established fact.
What should I research about my interviewers?
Look at their roles and public professional work, such as a team article or talk, if it helps you choose a relevant question. Avoid personal details. You do not need to reference every profile to show preparation.
How do I answer "What do you know about us?" without reciting the website?
Give a short description of the customer and the problem the product addresses, connect one verified detail to the advertised work, and name the part you want to understand better. That gives the interviewer something to confirm or correct.
What if I find conflicting information about the company?
Check dates and whether the sources discuss the same product, region, or team. Prefer a current primary source for a current company claim. If the conflict matters to your decision, ask about it without implying you have established which source is right.
Put the research to work
- Use reading a job description to separate the role's core work from generic requirements.
- Shape a specific motivation answer with why you want this job.
- Choose sharper closing questions with questions to ask your interviewer.
- Check your own fit with interview warning signs.