A Specialism the Reader Wasn't Looking For
Some engineers work in a corner of the field that most reviewers have never hired for: firmware, compilers and language tooling, geospatial systems, video encoding, industrial protocols, numerical simulation, accessibility, internationalisation, hardware bring-up.
The resume problem is that a reviewer with no slot for your specialism will read it as not the thing they need rather than as evidence of engineering ability. The fix is not to hide the specialism — it’s usually your strongest material — but to make the transferable property visible next to it.
Two very different situations
Applying inside the specialism. Rare, straightforward, and the easier case: write in the domain’s own vocabulary, name the standards and the constraints, and assume the reader knows what a real-time deadline or a wire format is. Nothing in this post applies except the section on positioning.
Applying to a general engineering role. The common case, because most postings are general. Here the specialism is simultaneously your differentiator and your obstacle, and the entire task is translation.
The mistake people make is choosing one or the other — either writing purely in domain terms, which loses the generalist reader, or scrubbing the domain out entirely, which leaves bullets so abstract they say nothing. The correct move is both, in the same sentence.
The translating clause
Keep the domain noun and add a clause naming the general engineering property underneath it.
Domain only: Implemented DNP3 outstation support for the substation gateway, including unsolicited response handling.
Translated: Implemented support for an industrial control protocol in the substation gateway — a binary, stateful protocol with strict timing requirements, where a malformed frame from a field device could not be allowed to stall the event queue for the other hundred devices on the link.
The second version is longer and readable by any backend engineer. It is also the same work: a binary protocol parser with isolation between connections and a timing constraint. Nobody had to know what DNP3 is to evaluate it.
The pattern generalises. Every specialism reduces to one or more properties that any engineer recognises:
- A hard constraint — memory, power, latency deadline, bandwidth, single-pass processing, an interface you cannot change.
- Correctness under an unforgiving definition — numerical stability, standards conformance, bit-exactness, a safety requirement.
- Concurrency or interrupts — anything real-time or event-driven translates directly.
- Performance work at an unusual level — cache behaviour, instruction counts, allocation, I/O patterns.
- Tooling you had to build because nothing existed — the most transferable thing on this list.
Name the property, keep the noun, and you have a bullet that works on both readers.
Where the specialism is straightforwardly an asset
Worth being explicit, because people in niches undersell them systematically.
Constrained-environment experience transfers upward. An engineer who has fitted a feature into a fixed memory budget has an intuition about allocation and data layout that most application developers never develop. Server work rewards it — that intuition is what cost optimisation and tail-latency work actually consist of.
Protocol and format work transfers to anything with a boundary. Parsers, wire formats, versioning, backward compatibility, and the discipline of not trusting input are the same skills whether the boundary is a serial link or a public API.
Simulation and numerical work transfers to data systems. Reproducibility, determinism, floating-point care, and the habit of validating a result against an independent computation are precisely the properties data pipelines need and rarely have.
Accessibility and internationalisation are scarce, checkable, and in demand. Both are specialisms that many teams need, few teams have, and every team eventually discovers they need. Neither should be buried in a skills list.
Compilers and tooling work signals depth. Anyone who has written a parser, a type checker, or a code generator has demonstrated an understanding of program structure that is hard to acquire any other way, and reviewers read it that way even when the role is unrelated.
The vocabulary decision, made deliberately
Three levels of language are available for any specialist bullet, and you should choose consciously rather than defaulting to the one you speak at work.
Full domain vocabulary for a role in the domain, and for the skills block, where a specialist scanning for a term needs to find it.
Translated vocabulary in the experience bullets of a general application. Plain nouns, the property named, the domain term kept once so you aren’t concealing anything.
Domain term with a gloss in parentheses as the compromise, useful when the term is short and the gloss is shorter: wrote the CAN bus driver (in-vehicle serial network) for the sensor board. This works well and is under-used.
What to avoid is a bullet where every noun is an acronym the reader has to look up. Two unexplained acronyms per bullet is the practical ceiling; past that the reviewer stops reading rather than researching.
The positioning line, which matters more here than usual
Specialists benefit disproportionately from two lines at the top of the page, because without them the reader has to infer a career shape from unfamiliar nouns.
Embedded engineer moving to backend work — a decade on constrained firmware, mostly C and protocol implementations. The transferable part is systems under hard constraints and building the tooling to prove they behave.
That paragraph does three things: names what you are, names what you are applying as, and states the transfer explicitly rather than hoping the reader performs it. The general case for a summary is in what belongs on an engineering resume; this is the case where it stops being optional.
For applications inside the specialism, the same two lines do the opposite job — they establish that you are one of the few people who has actually done this, which is the entire argument. Video pipeline engineer: encoding, container formats, and the operational side of large-scale transcoding. Nothing more is needed.
The skills list for a niche stack
The problem: your genuinely valuable tools mean nothing to a generalist and your generalist tools look thin.
Group so that both readings work, with the transferable layer first and the domain layer named as a domain layer:
Languages C, C++, Rust, Python Systems Linux, real-time scheduling, memory-constrained targets, cross-compilation toolchains Domain CAN, Modbus, MQTT, hardware-in-the-loop test rigs General Git, CMake, GitHub Actions, Docker
The generalist reads the first two lines and sees a systems engineer. The specialist reads the third and finds what they were looking for. Neither has to work at it. The general grouping argument is in the tech stack list problem.
The gap you should acknowledge
Honesty is cheaper than the alternative here. If you have never operated a web service, a general backend application will notice, and pretending otherwise gets found out in the first technical conversation.
Two things help. One is a small piece of genuine evidence in the target area — a service you built and deployed, a contribution to a project in that world — which is the argument in side projects, open source, and what counts. The other is stating the boundary yourself: no production experience with Kubernetes; I've deployed my own services on it but haven't operated a cluster. Reviewers respond well to that, because it tells them the rest of your list is accurate.
The check
Give your resume to an engineer outside your specialism and ask them to say what you would be good at.
If the answer is a general engineering property — constraints, correctness, protocols, performance, tooling — the translation is working. If the answer is “something with hardware, I think”, the domain nouns are load-bearing and the translating clauses are missing.