# Filled hiring brief: backend engineer

SYNTHETIC EXAMPLE. The company, budget, role, people and candidate evidence below are invented to illustrate completion. This is not a customer case, live vacancy, salary benchmark or hiring result.

## 1. Real opening and approval
Role / req: Backend engineer / BE-01.
Hiring manager: engineering lead. Recruiter: founder. Budget approver: founder.
Example approval: one permanent opening, approved for this fictional exercise.
Business problem: the integration team needs reliable customer-facing APIs; the engineering lead currently owns every production escalation.
90-day deliverable: ship one customer API integration with automated tests, failure monitoring and an agreed incident runbook. Engineering lead reviews delivery and a walkthrough.
Target start: within eight weeks of launch; this is a planning target, not a promised fill time. Review after the first five profiles.

## 2. Constraints candidates need to know
Employment: permanent full time; remote within US locations the company is approved to hire in. Version v1: approved state list was a BLOCKER. In the completed v2 scenario, the founder confirms California, New York and Massachusetts as the fictional company's approved states. For your real role, verify your own list before launch.
Work hours: four working hours overlapping 09:00-13:00 America/New_York, with daylight-saving changes following that zone. Confirm with candidates; never infer availability from address.
Compensation: fictional approved base budget USD140,000-175,000/year; equity separate, range not yet approved. Do not advertise unapproved equity.
Version v1: sponsorship policy was a BLOCKER. In completed v2, the founder confirms this fictional opening cannot provide new sponsorship. Verify eligibility directly through your company's process; never infer it from identity or residence.
Travel and licenses: no essential requirement in this exercise.
Flexibility: engineering lead can trade language preference; founder alone approves budget/location changes.

## 3. Evidence-based requirements
A. Delivered a backend API used in production. Acceptable evidence: resume/project description plus a discussion of ownership, tests and failure handling; private-work examples can be described without sharing code. Missing: ask what they owned and how it operated after launch.
B. Operated a relational database in production. Acceptable evidence: PostgreSQL or equivalent transactional database work and a concrete query, migration or reliability example. Missing: ask for their own contribution and tradeoffs. A tool name on a profile is not enough.
C. Can work the agreed overlap and within an approved hiring location. Confirm directly; an absent location or schedule is UNKNOWN.
Preferences: Python, early-stage product work, customer integrations. Java/Go and another relational database can be equivalent. Degree, employer brand and exact title are not gates.
Exclusions: a confirmed inability to meet essential overlap after discussing feasible options; confirmed work limited to analytics dashboards with no production API responsibility. A thin profile is not an exclusion.

## 4. Calibration
A / proceed to verification: supplied resume describes shipping a Java API and owning MySQL incident follow-up. Skill evidence fits A/B through equivalent experience. Location, hours and interest still unknown; ask before treating as fully qualified.
B / clarify: supplied resume lists Python and PostgreSQL, but examples are reporting dashboards. Ask for one production API they owned; keep pending rather than infer no experience.
C / decline for this role: the person confirms only asynchronous work and no required overlap, after discussion of alternatives. Record the specific job constraint. Do not expand that decision into a judgment about general ability.
These are fictional evidence situations, not real people or automated hiring decisions.

## 5. Candidate proposition and outreach
The role owns an integration from requirements through operating it in production, with direct access to the engineering lead.
Approved claims: scope above, remote within approved locations, base range above. No guaranteed promotion, equity amount or customer-growth claim.
Founder approves each message; recruiter owns replies/opt-outs and takes unresolved technical questions to the engineering lead. In v1, no outreach while the location/sponsorship blockers remain. In v2, those decisions are recorded before approval.

Draft outreach for this fictional example, requiring review before real use: "Your production API and database work looks relevant to our backend opening. The role owns a customer integration through launch and operation. We are remote within our approved US states, with four working hours overlapping 09:00-13:00 America/New_York. Base budget is USD140,000-175,000. Would you be open to discussing the scope?" Add a genuine candidate-specific reason supported by evidence; do not claim interest or availability in advance.

## 6. Review and activation
Engineering lead reviews the first five profiles within two business days. Founder supplies interview availability before approved outreach starts: the fictional team reserves Tuesday/Thursday 10:00-12:00 America/New_York; confirm actual dates with each participant.
Interview plan: founder role/constraints conversation; engineering lead production-API walkthrough; practical discussion of database changes using candidate-permitted examples. Verify job evidence consistently.
v1 decision log: founder owned the state/sponsorship blockers; status DRAFT.
v2 decision log: founder confirms the example states and sponsorship policy above; engineering lead approves requirements A/B/C and the interview plan. Optional equity remains unapproved and is omitted from outreach. Status: READY TO CREATE THE ROLE in this fictional exercise, not a record of a real activation.
Then create the real role in Metix, check its structured brief against the approved version, review candidate evidence and approve outreach. Record the actual role/Agent ID and review date in the account. Do not paste this fictional job as a real vacancy.

## Feedback example
B | production API ownership | reporting dashboards described | API delivery unknown | verify with one concrete ownership question | no new exclusion yet
A | equivalent language | Java API with incident follow-up | role constraints and interest unknown | continue review | keep Python as a preference

Review success: did both reviewers use the same evidence bar, was an actual approved role activated, and could the team handle the resulting conversations? Track replies, booked interviews, attended interviews and hiring decisions as different stages. No outcome is assumed here.