Senior Backend Engineer

Deliberate decisions instead of defaults: an explicit versioning strategy, an auth model suited to the context, a consistent error format. At senior level, also look for how they drove alignment (an RFC, a design review, ADRs). Bonus: decisions they'd make differently today. An engineer who imposed choices with no alignment story shows a leadership gap.

A structured method (reproduction, logs, metrics, hypotheses) and, at senior level, incident leadership: coordinating others, communicating status, owning the post-mortem and the systemic fix (runbook, alert, architectural change). Honesty about duration. I restarted the service with no diagnosis or follow-up is a serious senior flag.

An incremental approach: online migration with dual writes or backfill, an explicit rollback plan, consistency validation before cut-over — plus how they sequenced and communicated it so the team could execute safely. Bonus: a migration that ran longer than planned and the lesson. A big-bang migration with no rollback is risk blindness at any level, worse at senior.

A structured method: keep rollback open, raise log level on affected endpoints, correlate with metrics, isolate the pattern (time, request type, tenant). At senior level: delegating investigation threads, communicating to stakeholders, and starting a post-mortem in parallel. Jumping to it's probably the DB without investigation is a bias to catch.

Clarifying the underlying business need before the solution, then offering options (index, materialized view, async job with cache, data-model change) in terms the PM can weigh. Senior signal: they turn it into a shared decision, not a veto. I'll just build it and optimise later shows a lack of foresight.

Diagnosis before action; prioritisation by risk and impact (monitoring first, then tests on the critical rules, then deploy automation, DB refactor last); and a plan that builds team buy-in and capability, not a solo heroics arc. Diving straight into a microservices rewrite, or fixing everything themselves without leveling up the team, both show poor senior judgement.

Clarification before proposing (volume, latency, retry, security). A coherent architecture: async queue, idempotent delivery with an event ID, retry with exponential backoff, dead-letter queue, signed payload, endpoint verification. Bonus: explicit handling of slow or failed receivers (circuit breaker, per-receiver throttling) and how they'd stage the rollout. Jumping to code without clarifying is a design weakness.

Recognising a naive UPDATE per request won't scale (lock contention, connection limits, WAL pressure). Solution space: in-memory counter with periodic flush, sharded counter, Redis increment with a persistence strategy, event stream with aggregation. Senior signal: an explicit, justified choice of consistency guarantee (eventual vs. strict) and failover behaviour, not just a menu of options.

A structured method: correlate with external factors (traffic, data growth, third-party latency), check slow-query logs and DB statistics (table size, index usage, vacuum), trace a slow request edge-to-DB, rank hypotheses (index bloat, cache-miss rate, exhausted pool). Senior signal: recognising a slow rise usually points to data growth or index degradation, and instrumenting so the next one is caught automatically.

A solid grasp of the anomalies (dirty read, non-repeatable read, phantom, write skew). Read Committed as the pragmatic default in Postgres, Repeatable Read for consistent reports, Serializable for rare but critical paths (accounting, inventory). Senior signal: the performance cost of Serializable and SELECT FOR UPDATE as a middle ground, and choosing per workload. Not separating the levels builds race conditions into production.

A clear separation of structured logs (trace ID), metrics (RED/USE) and distributed tracing, with a justified tool choice (Prometheus + Grafana, OpenTelemetry, Datadog, Sentry). Alerts only on actionable signals. Senior signal: explicit SLOs with an error budget and how they'd negotiate them with product. log everything shows a lack of high-load experience.

A clear list: injection, auth/session weaknesses, tenant-level authorization bypass, insecure secret handling, insecure deserialization, SSRF, open redirect. Concrete measures: parameterized queries, a secret manager, output encoding, per-request authorization checks. Senior signal: an OWASP Top 10 reference applied concretely to their own stack, and building these checks into the team's defaults.

Openness: separating code from ego. Bonus: a concrete case where a review changed a data model or API shape. At senior level, also how they model this for the team (inviting challenge to their own designs). Explaining their logic at the reviewer instead of listening is a coachability flag that undermines a senior's ability to lead reviews.

An active leadership posture: pairing on critical paths, pedagogical reviews with reasoning, documented decisions (ADR), spreading good practice (idempotency, backoff, safe deploys). At senior level this is a core deliverable, not a nice-to-have. I help when asked, with no more detail, is a weak answer for a role expected to lift the team.

A partnership posture: constructive challenge grounded in feasibility and operational cost, with alternatives, plus the ability to build alignment without formal authority (RFCs, spikes, data). Bonus: a case where they changed their own position after input. Treating other functions as people who don't understand backend is a serious flag for a senior expected to be a bridge.