How do you judge whether a company's engineering blog describes current practice or an aspiration?
answer
- Read it as a claim, not a description
- Written about the best-run corner
- Honest write-ups admit what got worse
- Check the product behaviour against the post
- Weak corroboration becomes a question, not a claim
basics
~20 sPublished engineering writing is partly recruitment marketing, so corroborate it. Check whether the post admits costs, whether later posts and open roles build on it, whether the product shows it, and whether the people you meet can discuss it unprompted.
solid answer
~40 sI read a public engineering write-up as a claim, not as a description. Posts are often written about the best-run corner of the estate, sometimes while the work is still in progress, and almost always by people who want to hire. Four checks help. Does the post name what the change cost, or only what it gained — honest write-ups admit a tradeoff. Do later posts and current job openings build on it, or does the thread stop there. Does the product behave as the post implies. And can the people I speak to talk about it in their own words. I keep the finding either way; if the corroboration is thin, it becomes a question I ask instead of a claim I make.
go deeper
Know that public engineering writing is selective and sometimes describes work still in progress. Quote it as something you read rather than as a fact about how the company works today.
Explain the biases — teams write about their proudest corner, often at decision time, often to recruit — and name at least one way to corroborate a claim, such as checking whether the product behaves as the post implies.
Demonstrate the judgment call. Show how you decide whether a finding is solid enough to build a hook on, and how you phrase a weakly corroborated one so it works whether the work shipped, stalled or was scoped down.
Own what a company's public technical writing tells you about the organisation behind it — what it chooses to publish, what it never mentions, and how much weight that deserves against everything else you can observe before joining.
## Why the blog is a claim, not a description Public engineering writing is genuinely useful and structurally biased at the same time. Three biases matter: - **Selection.** Teams write about the corner of the estate they are proud of. A polished write-up about one pipeline says nothing about the four services nobody wrote about. - **Tense.** Posts are often published at the moment of the decision or the pilot, not after the migration finished. The design in the post may describe an intended end state that part of the system has not reached. - **Purpose.** Much of this writing exists partly to recruit. That does not make it dishonest; it makes it selective about what gets emphasised. So the useful stance is neither cynicism nor credulity. Read it as a claim, and see how much corroboration it has. ## Four corroboration checks **1. Does the post name a cost?** The single strongest tell of a write-up grounded in practice is that it says what got worse. A post describing a move to event-driven ingestion that mentions harder debugging, replay complexity or an increase in on-call noise is describing something that ran. A post where every consequence is an improvement is describing a plan or a pitch. **2. Does the thread continue?** One post is an intention; a follow-up, a talk, or a set of open roles that assume the new design is a practice. If the writing stops abruptly and nothing downstream references it, that is worth noticing quietly. **3. Does the product show it?** This is the check candidates most often skip, and the one that costs nothing. If the write-up claims per-record streaming ingestion, does an import in the actual product report failures per record, or does it still fail the whole file? Behaviour is harder to stage than prose. **4. Can the people you meet talk about it?** The highest-value check happens in the conversation itself. When someone who works there can pick up a specific reference and describe the messy parts in their own words, the thing is real. When the reference lands and the answer stays at the level of the post's summary, you have learned something too. ## What to do with a weakly corroborated finding Do not delete it, and do not lead with it. Convert it from a claim you make into a question you ask. Instead of asserting that they run event-driven ingestion, ask what it cost: *Your engineering blog described moving to event-driven ingestion — what did that cost you in debugging?* That phrasing survives every outcome. If the migration finished, you get a real answer about tradeoffs. If it stalled, you get an honest account of why, which is more useful to you than the post was. And if it never started, you asked a fair question about their own published material rather than making a wrong assertion about their systems. The risk of skipping this check is specific and unpleasant: you build a strong hook on a claim, deliver it confidently, and someone who works there corrects you. Overstating what you know about a stranger's architecture is worse than saying less, because it converts preparation into a credibility problem. ## The same discipline on non-technical sources Apply proportional scepticism elsewhere. Anonymous employee reviews are a self-selected sample skewed toward strong feelings and rarely say which team or period they describe; a repeated theme is worth a neutral question, not a verdict. Self-reported pay entries and published ranges vary by market, level and local practice and should be treated as orientation rather than as a number to quote as fact. Funding and financial narratives describe intent as much as outcome — a stated push into a new segment is a direction, not a delivered capability. Across all of them the rule is the same: corroborated findings can become things you say; uncorroborated findings become things you ask.
- What in a published engineering write-up most suggests the work actually shipped?An admitted cost. When a write-up says what got harder — debugging, replay, on-call noise, a migration that took longer than planned — someone is describing lived experience. Posts in which every consequence is positive read as design intent or as recruitment material. A continuing thread of later writing and open roles that assume the new design is the second-best signal.
- How would you raise a finding you are not certain still holds true?As a question about its consequences rather than an assertion about their systems. Naming where I read it and asking what it cost keeps me honest and works whether the change shipped, stalled or was scoped down. It also gives the other person room to correct the record without either of us losing face, which a confident wrong statement does not.
saying these in an interview costs you the question
- Treating a published design post as a description of today
- Asserting details of a stranger's architecture as established fact
- Ignoring that engineering writing partly exists to recruit
- Never checking the claim against the actual product behaviour
- Discarding a finding entirely instead of turning it into a question
- Reciting the About page and calling that corroboration