💼 Reading: Job Descriptions

Asynchronous messaging experience is in the "Required" section:

The job description clearly separates Required and Nice to Have:

Required:

• 5+ years of backend engineering
• Proficiency in a compiled language (Go, Rust, Java, C#)
• Distributed systems experience
• Relational database knowledge
• Experience with asynchronous messaging patterns (Kafka, RabbitMQ…) ← this one

Nice to Have:

• Fintech/payments domain experience
• PCI DSS familiarity
• On-call experience

The other three options are all in the Nice to Have section.

Job description reading strategy:

• Required / Must have → your application will likely be rejected without these
• Nice to Have / Preferred / Bonus → helpful but won't disqualify you; apply even if you're missing these
• Many candidates don't apply if they don't meet 100% of requirements — but studies show most job descriptions list aspirational requirements. Apply if you meet ~70-80% of the "Required" items.

Ownership = responsibility for decisions, reliability, and outcomes:

In job descriptions, "ownership" is a cultural term meaning you're accountable for outcomes, not just assigned tasks. The "What You'll Do" section reveals what ownership looks like at this company:

• "Lead technical design discussions and produce ADRs" → you make architectural decisions, not just implement someone else's
• "Own service reliability" → you're responsible for uptime, not just writing features
• "drive process improvements" → you change how the team works, not just follow existing processes

Ownership culture vocabulary in job descriptions:

• high ownership → you're a decision-maker, not a ticket-executor
• high impact → your work directly affects business outcomes (here: millions of transactions daily)
• drive → initiate and lead, not just participate
• own [something] → you're the person responsible if it breaks; you set the direction

Architecture Decision Records (ADRs):
Documents that record architectural decisions: the context, the decision made, and the consequences. Writing ADRs means you're explaining and documenting technical choices for the team.

On-call = designated incident responder during a scheduled window:

On-call rotation means a schedule where engineers take turns being the primary responder for production incidents outside business hours.

How it typically works:

• Each engineer is "on-call" for a fixed period (e.g., one week per month)
• If an alert fires (service down, error rate spike, latency increase), the on-call engineer gets paged
• They must respond within minutes — even at 3am on a weekend
• They investigate, escalate if needed, and write a post-mortem after

Why this job lists it as "Nice to Have":
On-call is mentioned in "What You'll Do" (you WILL do it), and having prior experience is the "Nice to Have" — meaning they'll train you if needed, but experience makes you more effective from day one.

Incident severity vocabulary (from the job description):

• P0 → Priority 0 — the most critical incident, complete outage or data loss, requires immediate all-hands response
• P1 → Priority 1 — major incident, significant impact, requires urgent response within hours
• post-mortem → a written analysis of what went wrong, why, and what to fix — blame-free and focused on process
• runbook → a documented playbook for responding to known types of incidents step by step
• observability → the ability to understand system state via logs, metrics, and traces

Tech job description jargon — decoded:

Many startup job descriptions use buzzwords that obscure the real working conditions. Here are the common ones decoded:

Buzzword	What it really means
wear many hats	You'll do tasks outside your job title — support, sales, writing, design
rockstar / ninja / wizard	Vague — means "excellent". Ask what specific skills are needed.
fast-paced environment	Priorities change frequently; expect overtime and incomplete specs
move fast and break things	Low emphasis on testing/process; speed over stability
thrive in ambiguity	Requirements are often unclear; you'll need to figure things out yourself
self-starter	Little mentorship or guidance provided; expected to work independently
culture fit / family	Can mean great culture — OR: informal hours expectations, blurred work/life boundary
passionate	Enthusiasm expected; may mean unpaid extra effort is expected
good vibes only	Conflict-averse culture — problems may not be raised openly

Questions to ask at an interview to verify the reality behind the buzzwords:

• "What does a typical week look like for this role?"
• "How often do priorities shift mid-sprint?"
• "What does the on-call rotation look like?"
• "How does the team handle technical debt?"

STAR structure for interview answers:

STAR = Situation → Task → Action → Result

When a job description lists a responsibility, prepare a STAR story that directly demonstrates that skill:

The winning answer (option B) works because:

• Situation: Specific problem — "high PR turnaround time affecting delivery" (business impact)
• Task: Clear ownership — "as the most senior engineer" (you were responsible)
• Action: Concrete steps — 3 specific things you did (1:1s, checklist, pair programming)
• Result: Measurable outcome — "40% reduction" + team member promoted (quantified + career impact)

Why the other answers fail:

• Option A: Too vague — no context, no measurable impact
• Option C: Describes learning, not mentoring others
• Option D: About receiving mentorship, not giving it

STAR tips for technical roles:

• Always quantify results where possible: 40% faster, 3 engineers mentored, 0 regressions in 6 months
• Match the situation to something in the job description — if the JD mentions "distributed systems", your story should involve distributed systems
• The "A" (action) should have 3-4 distinct steps — shows systematic approach, not just luck
• Practice translating each JD responsibility into one STAR story before the interview