Job Description Templates
The AI-Era Engineering Playbook — Practitioner Reference
These templates are designed to attract the right candidates by signalling clearly what the role requires and how you assess it. The "How we assess" and "How we don't assess" sections do two things: they filter out candidates who are optimised for the old interview (not the role), and they tell strong candidates that this company has thought carefully about what the job actually requires.
Placeholders are marked [LIKE THIS]. Replace all before posting.
Template 1: System Engineer
System Engineer
[COMPANY NAME] · [LOCATION OR REMOTE] · [EMPLOYMENT TYPE]
About the role
We're looking for a System Engineer to define the technical backbone of our engineering team.
This is not a senior individual contributor role in the traditional sense. The job is not to write the most code — it is to make it safe for others to write code quickly. You will design the systems, define the constraints, own the failure modes, and transfer enough of your mental model to the team that they can operate without you in the room.
One excellent System Engineer enables four to eight engineers to work faster, build more reliably, and ship with confidence. That is the leverage point this role sits at.
[ONE OR TWO SENTENCES ABOUT THE PRODUCT / DOMAIN / STAGE OF COMPANY]
What you'll do
- Design the system architecture that other engineers build within — data models, API contracts, service boundaries, consistency guarantees
- Enumerate how each system can fail before it does, and build the observability that makes failures diagnosable by the team
- Define what Product Engineers can deploy autonomously and what requires your review — and build automated guardrails where human review is too slow
- Establish standards for AI-generated code entering the codebase; maintain a running catalogue of the patterns AI generates that are unsafe in our context
- Transfer your mental model to the team — document the why behind architectural decisions, not just the what; run design reviews as teaching sessions, not approval gates
- Own post-mortems end-to-end: the fix must close the class of problem, not just the instance
What we're looking for
We are not filtering on years of experience, specific frameworks, or degrees. We are looking for evidence of specific behaviours.
What strong candidates demonstrate:
- They talk about what a system must guarantee before they talk about how to build it
- They can enumerate the failure modes of systems they've built, unprompted, with specific examples
- They have a principled view on what to delegate to AI and what to own — and they've revised that view as AI capability has changed
- They have designed systems that non-experts could operate safely — and can show evidence that this worked
- They have transferred knowledge to others in ways that made those people genuinely more independent, not just more compliant
- They have experimented with new tools and techniques on their own initiative and formed opinions from actual use
Technical areas we care about:
- Systems design and architectural tradeoffs
- Failure mode reasoning and distributed system behaviour
- Security fundamentals (OWASP-level minimum; threat modelling preferred)
- AI output evaluation — reading and auditing AI-generated code for correctness and safety
- Data modelling and API contract design
How we assess
Our interview process is designed to observe the behaviours above directly — not to test your ability to prepare for an interview.
| Stage | What you'll do | What we're looking for |
|---|---|---|
| Systems case study | We give you a scenario in writing. You think, then we discuss. | How you define constraints before architecture; how you reason about tradeoffs; what failure modes you anticipate |
| Failure mode review | We give you a system description and an incident report. | Whether you form hypotheses or reach for fixes; whether you identify the class of problem or just the instance |
| AI output audit | We give you 60–100 lines of AI-generated code with issues planted. | Whether you evaluate against behaviour and correctness, or against style; what questions you'd ask before approving |
| Structured behavioural | We ask the same questions we ask every candidate, in the same order. | Track record of the above behaviours in real situations |
The process takes approximately four hours across two sessions.
How we don't assess
We have deliberately removed the following from our process:
- Algorithm puzzles (LeetCode-style) — AI solves these reliably on first attempt. Passing them signals interview preparation, not engineering judgement.
- Syntax and language trivia — The information is a prompt away. Retention of it tells us nothing about your ability to design or evaluate systems.
- "5 years of [framework]" requirements — AI generates framework code. What we need is judgement that outlasts the current framework generation.
- Timed coding under pressure — Implementation speed is not the bottleneck. Specification quality and output evaluation are.
What we offer
[COMPENSATION RANGE]
Note on compensation: System Engineers command a premium because their leverage is real and their mistakes are expensive. A System Engineer who prevents one bad architectural decision pays for themselves many times over. We price accordingly.
[BENEFITS, EQUITY, REMOTE POLICY, ETC.]
About us
[COMPANY DESCRIPTION — 3–5 SENTENCES]
To apply: [APPLICATION LINK OR INSTRUCTIONS]
Template 2: Product Engineer
Product Engineer
[COMPANY NAME] · [LOCATION OR REMOTE] · [EMPLOYMENT TYPE]
Also posted as: Software Engineer / Full-Stack Engineer depending on market convention — same role, same criteria
About the role
We're looking for a Product Engineer to own a business domain and be accountable for what ships within it.
This role is not defined by which tools you use. It is defined by what you own. You will take business requirements, translate them into precise specifications, evaluate the output for correctness, and be the person accountable when something behaves wrong in production.
That accountability requires domain knowledge deep enough to catch what AI gets wrong about your domain — not just technical correctness, but business correctness. The person who ships a feature that runs correctly but behaves wrongly is a Product Engineer who didn't understand the domain well enough. We hire to prevent that.
[ONE OR TWO SENTENCES ABOUT THE PRODUCT / DOMAIN / STAGE OF COMPANY]
What you'll do
- Own a business domain — its rules, its edge cases, its history, its failure modes
- Take business requirements — often ambiguous ones — and translate them into precise behavioural specifications before any code is generated
- Evaluate generated output for correctness: not just "does it run" but "does it behave correctly for this domain under the conditions that matter"
- Be the quality gate on your own work — you are accountable for what goes to production, which means you evaluate it against correctness before it gets there
- Track the AI tooling landscape on your own initiative; experiment with new tools before they're mainstream; form specific opinions from actual use
- Work with System Engineers when a problem exceeds your scope — escalate before it becomes a crisis, not after
What we're looking for
We are not filtering on specific languages, frameworks, or years of experience. We are looking for evidence of specific behaviours.
What strong candidates demonstrate:
- Before building anything, they ask what the requirement actually means — and they don't stop asking until it's unambiguous
- They evaluate generated code against what they specified, not against whether it looks right or tests pass
- When output is wrong, they diagnose what the specification missed — they don't re-prompt randomly
- They understand their domain well enough to identify domain-specific errors in technically correct code
- They have caught output that looked correct but wasn't — and can explain how they caught it
- They have experimented with tools on their own initiative in the last 90 days and have a specific, honest assessment of each
Background diversity is expected: Strong Product Engineers come from many paths — traditional software engineering, QA, product management, domain expertise in a specialised field (fintech, healthcare, legal, logistics). The common thread is domain ownership and the discipline of evaluating correctness before shipping — not the background.
How we assess
Our interview process observes the behaviours above directly.
| Stage | What you'll do | What we're looking for |
|---|---|---|
| Specification exercise | We give you a vague requirement. You think, then write a specification. | Whether you resolve ambiguity before specifying; whether the spec is behavioural and testable; what you deliberately left out |
| Live AI-assisted build | You implement part of your specification using your preferred AI tool, with us observing. | Your process; how you evaluate the output; how you iterate when something is wrong |
| Output review | We give you AI-generated code with issues planted. | Whether you evaluate against correctness and behaviour, or against style; whether you find domain-specific and security issues |
| Structured behavioural | We ask the same questions we ask every candidate, in the same order. | Track record: specification failures, output catches, early adoption evidence |
The process takes approximately three and a half hours across two sessions.
How we don't assess
We have deliberately removed the following from our process:
- Algorithm puzzles (LeetCode-style) — AI solves these reliably. The test selects for interview preparation, not engineering judgement.
- Framework depth ("5 years of React") — AI generates framework code. What we need is domain knowledge and output evaluation, which transfer across frameworks.
- Syntax recall — The information is a prompt away. It tells us nothing about your domain judgement.
- Timed bug fix speed — We are not measuring how fast you type. We are measuring whether you understand what correct looks like before you ship it.
What we offer
[COMPENSATION RANGE]
Note on compensation: Product Engineers with deep domain expertise in a specialised field command a premium — the domain knowledge is the scarce asset, not the technical execution. Engineers who bring demonstrated early adoption of tools that give the team a compounding advantage are also compensated above the standard range.
[BENEFITS, EQUITY, REMOTE POLICY, ETC.]
About us
[COMPANY DESCRIPTION — 3–5 SENTENCES]
To apply: [APPLICATION LINK OR INSTRUCTIONS]
Usage Notes
On the "How we don't assess" section: This section does more than filter candidates. It signals to strong candidates — particularly those who have been penalised by legacy interview processes — that this company has thought carefully about what the job actually requires. Engineers who spent years building real systems in real domains instead of practising LeetCode will recognise this and self-select in. That is the intended effect.
On the role title: "Product Engineer" maps to what the role actually is — ownership of a product domain. Externally, title the JD to match the seniority level and market convention for your sector. Common external titles: Software Engineer, Full-Stack Engineer, Product Engineer. Avoid titles that suggest deep algorithm or systems knowledge that the role does not require — this drives the wrong applicants and loses the right ones.
On the assessment table: The table is intentionally transparent. Candidates who read it and self-select out because they know they haven't been experimenting with AI tools or cannot write a behavioural specification are self-screening correctly. That is a filtering function, not a deterrent.
Role profiles: System Engineer | Product Engineer Interview guides: System Engineer | Product Engineer
© Gabor Mayer. Licensed under Creative Commons Attribution 4.0 (CC BY 4.0). Free to share and adapt with attribution.