Senior Engineering Interview Handbook / Chapter 972
Appendix H - Company Research Template
A printable company research worksheet for separating fact from inference, choosing evidence and practice, testing role hypotheses in conversation, and carrying unresolved risk into an offer decision.
Page tools
Build the page that will change your next conversation
Use this worksheet for one role at one company. Its purpose is not to preserve everything you can discover. It is to decide what to prepare, what to ask, and which uncertainty could change your interest in the job.
Keep the live brief to one page. Store links and supporting notes in the evidence ledger that follows it. If a detail changes no project choice, practice topic, question, logistical check, or career decision, it does not belong on the live page.
Begin with public professional material and information the company sends you. Do not collect private details about interviewers, retain material you are not entitled to keep, or infer private architecture from a technology name. Date anything likely to change: the role description, interview process, product priority, leadership, policy, or team assignment.
The live brief
Write this page before you feel ready. Its blank spaces will tell you where more browsing is unlikely to help and a conversation must take over.
COMPANY / ROLE
Company:
Role, level, and location:
Team, if known:
Brief updated:
Next conversation:
WORKING ROLE THESIS
This appears to be a role where...
The strongest evidence I can bring is...
The most consequential thing I still do not know is...
PRODUCT AND PRESSURE
Primary user and buyer:
Critical workflow:
What failure costs the user:
Business or strategic pressure that may shape the work:
LIKELY ENGINEERING CONSTRAINTS
Public interfaces or system boundaries:
Constraints suggested by the evidence:
What I must not pretend to know:
WHY THIS HIRE EXISTS
New headcount, backfill, or unknown:
Problem waiting for the new person:
What useful six-month progress might look like:
OPERATING ENVIRONMENT
Practices visible in public material or interviews:
What happens under incident, deadline, or disagreement:
Authority the role owns, must influence, or still needs clarified:
PREPARATION CHOICES
Projects or stories to recover:
Technical domains to practise:
Behavioral evidence to rehearse:
Round, tool, policy, or logistics gaps to confirm:
OPEN QUESTIONS, IN PRIORITY ORDER
1.
2.
3.
4.
5.
DECISION RISK
The most plausible way this role disappoints me is...
I could accept that risk if...
I would reconsider the role if...
The thesis is a selection rule, not an introduction to memorize. Revise it when a recruiter explains why the role opened, when a manager names a different first problem, or when a peer account contradicts the advertised operating model.
Keep a dated evidence ledger
The brief contains conclusions. The ledger keeps those conclusions honest. Use one block for each clue consequential enough to affect the page.
Evidence block
Date observed: __________________________________________________________
Source and link or conversation: ________________________________________
Fact — what the source states or what you directly heard:
Inference — what that fact may imply about the work:
Question — what would confirm, correct, or bound the inference:
Action if true — the story, practice, follow-up, or decision it changes:
Freshness or confidence limit: __________________________________________
Repeat the block only when the action differs. Five clues that all say “this company uses distributed systems” are not five pieces of preparation.
Let product pressure choose the technical questions
Start with the user’s work, not the company’s stack. Identify the critical journey and what an unavailable, late, incorrect, insecure, or confusing result would cost. Then trace the public boundaries around that journey: APIs, SDKs, integrations, migration guides, trust material, status reports, or engineering talks.
User trying to: _________________________________________________________
Failure with the greatest consequence: __________________________________
Public boundary where that failure might emerge: ________________________
Constraint worth practising: ___________________________________________
Question that avoids claiming private knowledge:
“They use Kubernetes” rarely changes preparation. “Their public integration docs describe retries but leave customer recovery unclear” can lead to a useful reliability question and a relevant design drill. The technology is a clue; the constraint does the teaching work.
Find the job behind the posting
A title cannot tell you whether the team needs feature delivery, migration, service ownership, reliability recovery, platform adoption, or broader technical direction. Public material may suggest an answer, but the recruiter or hiring manager usually has to supply it.
What changed to make this hire important now?
What would the new person be expected to improve first?
Which decisions would they own? Which require influence or sponsorship?
What work already consumes the team’s calendar?
Do not repair a vague answer on the company’s behalf. Keep it as an unresolved question. Continued vagueness about team placement, success, authority, or operating load is itself information about the offer.
Choose evidence and practice
For each likely need, name one piece of your own evidence before adding a new study topic. A role may deserve less preparation, or no application, when its deciding work requires experience you cannot honestly demonstrate in this campaign.
Likely need one
Evidence for the need: __________________________________________________
Project or story that matches: __________________________________________
What the story genuinely proves: ________________________________________
Gap to practise or disclose: ____________________________________________
Likely need two
Evidence for the need: __________________________________________________
Project or story that matches: __________________________________________
What the story genuinely proves: ________________________________________
Gap to practise or disclose: ____________________________________________
Likely need three
Evidence for the need: __________________________________________________
Project or story that matches: __________________________________________
What the story genuinely proves: ________________________________________
Gap to practise or disclose: ____________________________________________
Now choose at most two technical domains for targeted practice. Practise the transferable constraints—correctness, latency, failure, privacy, cost, operability, migration—not an imagined version of the company’s private system.
Map the interview without trusting old reports
Record process details when the company confirms them. Candidate reports and forums may suggest questions, but formats and policies change.
Known rounds and duration: ______________________________________________
Interviewer roles, when provided: _______________________________________
Coding environment and language options: ________________________________
Documentation, notes, and AI-tool policy: _______________________________
Project presentation or portfolio expectations: _________________________
Time zone, breaks, accessibility needs, and backup contact:
Public professional context about an interviewer can help you avoid entering their domain cold or prepare one question about the work. It should not be used to manufacture familiarity or tailor an answer to a person’s presumed preferences.
Ask questions that can alter the page
Prioritize by decision value, not by audience coverage. A recruiter can clarify process, level, placement, and written constraints. A hiring manager can name the first problem, success criteria, authority, and trade-offs. A peer can describe daily work, incidents, ownership boundaries, and what has actually improved. A leader can explain strategy and who resolves conflicts across teams.
Upgrade broad questions by locating a mechanism:
Instead of: What is the culture like?
Ask: What changed after the last difficult delivery or incident?
Instead of: How much ownership would I have?
Ask: Which decisions would I own, and who resolves a conflict with a
team whose roadmap depends on mine?
Instead of: Is there much technical debt?
Ask: Which recurring work displaces planned delivery, and how does it
receive time on the roadmap?
Before each conversation, choose three questions. Beside each one, write what different answers would change. If no plausible answer affects your preparation or your decision, the question may be interesting but is not a priority.
Update the brief after every conversation
Do this while the language and uncertainty are still fresh.
What did I learn directly? ______________________________________________
Which inference was confirmed, corrected, or made less certain?
What changes in my project, story, or practice selection?
Which contradiction now deserves follow-up? ____________________________
What did I hear about authority, load, or behavior under pressure?
What is the next highest-value question? _______________________________
Preserve disagreement between sources until you understand it. A manager, a peer, and a product partner may describe different positions inside the same system. The useful question is often whether those accounts fit together well enough for the role to succeed.
Close the sources and test the brief
Put the ledger away. In five minutes, use only the live page to:
- state the likely job and its largest uncertainty;
- explain the product pressure without reciting company language;
- choose the two projects or stories that best fit the evidence;
- name the technical practice that the evidence justifies;
- ask the question most likely to change your preparation;
- name the risk most likely to change your decision.
If you cannot do this, shorten the page. If a claim sounds like private knowledge, restore its inference label. If none of your preparation choices changed, stop collecting facts and ask what problem the hire is meant to solve.
The brief is ready when it can orient you quickly, survive correction, and carry one unresolved risk all the way to a decision. It should make you sharper in the interview without making you sound rehearsed.