Backend Engineer

Deliberate decisions instead of defaults: an explicit versioning strategy (URL, header, no versioning with reasons), an auth model suited to the context (session, JWT, OAuth, mTLS), a consistent error format across all endpoints. Bonus: the candidate names decisions they would make differently today. Someone who names REST with JSON Web Token without reflection has rarely weighed it seriously.

A structured debug method: reproduction, logs, metrics, hypotheses validated by experiment. Honesty about duration (a real production incident is rarely closed in under 30 min). Bonus: the candidate names the root cause and the systemic fix (post-mortem, runbook, new alert), not just the hotfix. Answers like I restarted the service without diagnosis point to weak investigation skills.

An incremental approach: online migration with dual writes or backfill, an explicit rollback plan, consistency validation before the cut-over. Bonus: the candidate names a case where the migration took longer than planned and what they learned. Someone who describes a big-bang migration with no rollback shows risk blindness.

A structured method: (1) keep the rollback option open, (2) temporarily raise the log level on the affected endpoints, (3) correlate with metrics (latency, payload size, source), (4) identify the pattern (time of day, request type, a specific user or tenant). Someone who jumps straight to it's probably the DB without investigating has a bias. Bonus: explicitly mentions starting a post-mortem document in parallel.

Clarifying the underlying business need before discussing the solution (the use case can often be solved with aggregated data or an index). Offering options: a suitable index, a materialized view, an async job with cache, a data-model change. Answers like I'll just build it, we'll optimize later when the DB gets slow point to a lack of foresight.

Diagnosis first: not trying to fix everything at once. Prioritization by risk and impact (typically: monitoring and alerts first for visibility, then tests for the two or three most critical business rules, then deployment automation, database refactor last). Alignment with the team and tech lead before each move. Someone who dives straight into a microservices migration shows a lack of pragmatism.

Clarification before proposing (expected volume, latency requirement, retry behavior, security model). A coherent architecture: an async queue, idempotent delivery with an event ID, retry with exponential backoff, a dead-letter queue, a signed payload (HMAC or similar), endpoint verification. Bonus: explicit handling of slow or failed receivers (circuit breaker, per-receiver throttling). Someone who jumps straight into code without clarifying shows a design weakness.

Recognizing that a naive UPDATE per request does not scale: lock contention, connection limits, WAL pressure. Solution space: an in-memory counter with periodic flush, a sharded counter, a Redis increment with a persistence strategy, an event stream with downstream aggregation. Bonus: a discussion of consistency guarantees (eventually consistent vs. strict) and failover behavior. Someone who just uses a Postgres table has not thought through load and consistency.

A structured method: (1) correlate with external factors (traffic increase, data growth, third-party latency), (2) check slow-query logs and DB statistics (table size, index usage, vacuum status on Postgres), (3) trace a slow request from edge to DB, (4) rank hypotheses (index bloat, a risen cache-miss rate, an exhausted connection pool). Bonus: recognizing that a slow rise usually points to data growth or index degradation, not a sudden bug.

A solid understanding of the anomalies (dirty read, non-repeatable read, phantom read, write skew). Read Committed as the pragmatic default in Postgres, Repeatable Read for consistent reports, Serializable for rarely used but critical paths (accounting, inventory). Bonus: mentioning the performance cost of Serializable and SELECT FOR UPDATE as a middle ground. Someone who cannot separate the levels builds race conditions into production.

A clear separation of logs (structured, with a trace ID), metrics (RED or USE method: rate, errors, duration; or utilization, saturation, errors) and distributed tracing. A concrete tool choice with reasoning (Prometheus plus Grafana, OpenTelemetry, Datadog, Sentry). Alerts only on actionable signals, not on every anomaly. Bonus: explicit SLOs with an error budget. Someone who just says log everything shows a lack of experience with high-load services.

A clear list: injection (SQL, OS, template), auth and session weaknesses, authorization bypass at the tenant level, insecure secret handling (plaintext in the repo, in logs, in tracing), insecure deserialization, SSRF from backend calls, open redirect. Concrete measures: parameterized queries, a secret manager, output encoding, authorization checks on every request, logging without sensitive data. Bonus: an OWASP Top 10 reference with concrete application in their own stack.

Openness: the ability to separate code from personal ego. Bonus: the candidate names a case where a review actually changed their mind (a different data model, a different API shape). Someone who describes having explained their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small backend team this is a hard no-go signal.

An active mentoring posture: pair programming on critical paths, pedagogical reviews with reasoning (not just an ok merge), documented architecture decisions (ADR), passing on good practices (idempotency, backoff, safe deploys). Someone who says I help when asked, without more concrete detail, shows a passive posture. At an SMB with a small backend team, the ability to pass on knowledge is decisive for the team's sustainability.

A partnership posture: constructive challenging based on feasibility, complexity or operational consequences, with alternative proposals. Bonus: the candidate names a case where they accepted the original proposal after exchange (no systematic opposition). Someone who describes frontend, SRE or DBA as people who don't understand backend shows a weakness in cross-functional teamwork.