💼 Reading: Senior Backend Engineer Job Description

"Ambiguous projects" — a key senior-level signal

In software engineering JDs, "ambiguous" is not a bug description — it's a deliberate signal about role expectations. At junior levels, tickets are scoped by a senior or tech lead. At senior and above, you are often handed a problem, not a specification.

What "large, ambiguous projects end-to-end" really means:

• You'll receive a goal ("reduce API p99 latency from 800ms to under 200ms") without a detailed plan
• You're expected to break it down, identify unknowns, propose approaches, get alignment, then execute
• You handle ambiguity without constant escalation — asking the right questions early rather than stalling

Why companies want this at senior level: Engineering managers and product leads don't have time to write fully scoped technical requirements for every project. Seniors who can only execute well-defined tickets become bottlenecks — every feature needs a more senior person to break it down first.

How to answer this in an interview: Prepare a specific story using STAR format (Situation, Task, Action, Result) where you took an under-defined project, clarified requirements, made architectural decisions, and delivered. The phrase "I drove it end-to-end" should appear naturally.

Related phrases to recognise:

• "Greenfield opportunity" → building from scratch, maximum ambiguity
• "You'll define the roadmap" → even less structure than ambiguous projects
• "Startup-like within a larger org" → expect frequent pivots and reprioritisation

Vesting schedules — essential equity literacy for UK tech roles

This JD describes the most common UK/US startup equity structure: a 4-year vesting schedule with a 1-year cliff.

How it works:

1. Year 0 to Year 1 (the "cliff"): You earn zero options. If you leave before your 1-year anniversary, you get nothing.
2. At Year 1 (cliff triggers): You immediately receive 25% of your total grant (1/4 of the 4-year package).
3. Years 1–4 (monthly/quarterly vest): The remaining 75% vests gradually — typically monthly (so ~2.08% of the total grant per month).
4. After year 4: Fully vested — you hold 100% of the granted options.

Practical example with this JD: Say you're granted 0.2% of the company. After 1 year: 0.05%. After 2 years: 0.10%. After 4 years: 0.20%.

EMI (Enterprise Management Incentives): This is a UK government-approved scheme that gives employees significant tax advantages on share options. Key benefits: gains are taxed at Capital Gains Tax rates (~10–20%) rather than Income Tax rates (up to 45%).

What to check beyond the vesting schedule:

• The strike price (the price you pay to exercise options)
• The post-termination exercise window (how long you have to exercise after leaving)
• Whether options accelerate on acquisition (single-trigger vs double-trigger)

Understanding equity language is increasingly important as more UK engineers join scale-ups offering EMI options.

"Blameless post-mortems" — a cultural signal worth investigating

A post-mortem (also called an incident review or PIR — Post-Incident Review) is a structured analysis conducted after a production incident. The word "blameless" describes the philosophy:

Traditional (blaming) culture:

• "Who pushed the bad deploy?" → person is blamed, shamed, sometimes fired
• Engineers fear making mistakes → they avoid risk, hide problems, work in silos
• Root causes go unfixed because the "fix" was "tell Bob not to do that again"

Blameless culture:

• Assumes people acted rationally with the information they had at the time
• Focuses on: What system properties made this failure possible? How do we prevent the category of failure?
• Produces: Improved monitoring, better runbooks, automated safeguards, process changes
• Result: People report incidents quickly and honestly, because there's no punishment for transparency

Pioneer of this approach: Google's SRE (Site Reliability Engineering) book popularised blameless post-mortems. Etsy, Netflix, and other high-performing engineering orgs adopted the model. The phrase in a JD signals the team has at least read about modern engineering culture.

How to verify this claim in an interview: Ask "Can you walk me through a recent post-mortem? What actions came out of it?" If the answer focuses on process improvements → genuinely blameless. If the answer mentions a person being disciplined → the culture note is marketing.

Also notable in this JD: "On-call is shared equally across the backend team (~1 week in 7)" — this means roughly one week of on-call per 7 weeks. "Shared equally" signals no on-call exemptions for seniors — verify this claim too.