How do you research an early-stage company that publishes no engineering writing at all?
answer
- No writing means the product is the writing
- Read every open role, not only yours
- Hiring is a roadmap published in public
- Use the recruiter as a live source
- Fewer hooks, and the questions carry the weight
basics
~20 sSubstitute observable artefacts for absent writing: the product itself, the shape of the open roles, public docs and changelogs, and what a recruiter can tell you before the loop. Expect fewer hooks and lean harder on questions.
solid answer
~40 sWhen there is nothing published, the product becomes the primary source. I use it and note concrete behaviour — how an import handles bad rows, what the docs cover and conspicuously do not, what the changelog or status page shows. Next I read every open role, not just mine: what a company hires for is its roadmap in public. Funding stage tells me the constraint they are under. Then I use the recruiter deliberately, asking what the team shipped recently and what problem this hire is meant to solve, and I use their answer as research for the later rounds. The output shifts: maybe one solid hook instead of two, and the four questions carry most of the weight.
go deeper
Know that a missing engineering blog is not a dead end. Open the product, read the documentation and read every open role before deciding there is nothing specific to say.
Explain the substitutions and what each yields: the product shows design decisions, open roles show the roadmap, funding stage shows the constraint, and a recruiter can supply what was never published.
Show that you adjust both the output and your confidence — fewer hooks, more questions, and claims hedged to match thinner evidence rather than asserted as if you had read a technical write-up.
Own what a company's silence itself tells you. Decide how much weight to put on an absent public technical record when judging engineering maturity, and be honest that it is often a resourcing choice rather than a signal about quality.
## When the usual first source does not exist A young company, or a company whose engineering work is not customer-facing, may have no technical blog, no talks and no open documentation. The instinct is to conclude there is nothing to research and fall back on the About page — which is exactly the failure this whole subject is trying to prevent. Reciting a startup's landing-page mission back at the person interviewing you is, if anything, more transparent than doing it to a large company, because at a small company the person across the table probably wrote the landing page. The method does not change; the sources do. You are still after two hooks and four questions out of one 45-minute block. You just gather them from artefacts rather than from prose. ## Source substitutions **The product as the primary artefact.** With no engineering writing, the product *is* the engineering writing. Sign up for whatever is free and push on it in the direction of your own expertise. For a data product: what happens to a file with a malformed row, is the rejection reported per record or per batch, is there an export that round-trips, does the documentation describe rate limits and retries, is there a public status history. Each of those is a design decision you can observe directly, and each one converts into a question about why it was made. **The full set of open roles.** Read every posting, not only yours. Hiring is a roadmap: a company posting for its first data-platform engineer alongside several support roles is telling you where the pain is. The words that repeat across postings — reliability, migration, onboarding, cost — tend to be the words being used inside the company right now. **Funding stage as a constraint reader.** Public funding information tells you less about what they build than about the pressure they are under. Early stage typically means shipping speed and finding customers dominates; later stage more often means scale, cost or reliability pressure. Frame this as an inference to be checked, never as an assertion about their finances. **The recruiter as a live source.** This is the substitution people underuse. Before a technical round, ask what the team shipped in the last few months, what problem this hire is meant to solve, and who the person would work with day to day. Recruiters answer these routinely, and the answer becomes research material for every later stage. Anything they cannot answer, they can often carry to the hiring team — a question travelling into the process is not a wasted question. **Adjacent public traces.** Public changelogs, release notes, developer docs, integration guides and support forums are all written by engineers even when no blog exists. ## What changes in the output Accept a different ratio. With no published technical writing, you may end the block with one solid hook rather than two, and the questions carry the weight. That is fine — and at a small company, questions are worth more anyway, because there is a good chance the person answering them personally made the decision you are asking about. Also adjust what you claim. With thinner evidence, hedge harder: describing what you observed in the product and asking whether you read it correctly is credible, while confidently characterising an architecture you have only inferred is not. ## Two things not to do Do not fill the gap with generic startup admiration — that they move fast, that the mission resonates, that the team looks strong. Every candidate says it, none of it is checkable, and it is the same recital failure in a different costume. And do not treat scattered anonymous commentary about a small company as fact. The smaller the employer, the smaller the sample and the more identifiable the individual writing it. Use a repeated theme to generate a neutral question you ask someone who works there now, and leave it at that; note also that impressions of pay and process at small companies vary widely by market and by role, so nothing you read there is a benchmark.
- What can the full set of a small company's open roles tell you about its engineering priorities?A great deal, because hiring is a roadmap in public. Which function is being staffed first, how many of each, and the vocabulary that repeats across postings all point at the current pain. A first dedicated data-platform hire beside several support roles says something quite specific about what is straining, and it converts directly into a question about what this hire is expected to fix.
- What would you ask a recruiter to gather material a small company has not published?What the team shipped in the last few months, what problem this hire is meant to solve, and who the person would work with day to day. Those are questions recruiters answer routinely, and the answers become research material for the later rounds. Anything they cannot answer they can usually carry to the hiring team, which is still a useful outcome.
saying these in an interview costs you the question
- Concluding there is nothing to research and reciting the About page
- Never signing up for or opening the product itself
- Generic startup admiration offered in place of specifics
- Reading only the posting you applied to
- Characterising an inferred architecture with unwarranted confidence
- Treating a handful of anonymous comments about a small employer as fact