# Senior Backend Engineer — System Design Interview Kit **Stack:** Python, Django, PostgreSQL, AWS | **Format:** System Design | **Level:** IC4–5 (Senior) --- ## STAGE 1: ROLE CALIBRATION & INTERVIEW RISK PROFILE | Dimension | Classification | Rationale | |-----------|---------------|-----------| | Seniority bar | IC4–5 (Senior) | STATED | | Primary signal sought | System thinking, with technical depth in DB/API as secondary | STATED (format) / INFERRED (weighting) | | False positive risk | Candidate performs well on high-level architecture but has never actually debugged a production DB or API issue — verbal system design can mask shallow hands-on experience | INFERRED | | False negative risk | Penalizing a candidate who defaults to talking through tradeoffs verbally rather than drawing, or who structures answers non-linearly | INFERRED | | Interview format fit | ⚠ Format is "system design" only, but two of the four stated competencies (API design, debugging under ambiguity) are more naturally tested via live coding or incident-simulation formats. This kit embeds them *within* system-design scenarios to compensate, but the signal is weaker than a dedicated hands-on session. | INFERRED | **Failure mode priority map:** | Failure Mode | Priority | Evidence Type | Conf | |-------------|----------|---------------|------| | Questions testing knowledge recall instead of applied thinking | MED | INFERRED | 70 | | Rubric that can't distinguish a senior from a mid answer | HIGH | INFERRED | 85 | | No behavioral questions → personality/ownership blind spot | HIGH | STATED (format has none) | 90 | | System design question with no scope constraint → endless | HIGH | INFERRED | 85 | | Tech stack trivia that filters for memorization, not skill | LOW–MED | INFERRED | 60 | --- ## STAGE 2: COMPETENCY COVERAGE MAP | Competency | Question Type | Time Allocation | Evidence Type | |-----------|--------------|----------------|---------------| | System design | System design | 20 + 15 + 8 = 43 min | STATED | | Database optimization | System design (schema + debugging) | 15 + 15 = 30 min | STATED | | API design | System design (contract + evolution) | 15 + 10 = 25 min | STATED | | Debugging under ambiguity | System design (verbal incident scenarios) | 15 + 12 = 27 min | STATED | | Ownership/self-critique (gap) | Synthesis question folded into system design | 8 min (counted above) | INFERRED — no behavioral format was requested, so this is a lightweight compensating mechanism, not a substitute for real behavioral interviewing | **Total: ~125 minutes.** See Assumption Ledger — this likely needs to run as one extended senior-loop session or be split across two. --- ## STAGE 3: QUESTION SET The questions share one running scenario — a multi-tenant appointment booking platform — so later questions build on earlier design decisions instead of testing isolated trivia. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q1 — System Design (Architecture)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "Design the backend architecture for a multi-tenant appointment booking platform. It needs to support 5,000 businesses, each with their own staff, services, and availability calendars, serving roughly 2 million bookings a month. Assume Python/Django, PostgreSQL, and AWS. Walk me through your architecture." **Time:** 20 min | **Format:** whiteboard **Follow-up probes:** 1. How do you isolate tenant data across 5,000 businesses — schema-per-tenant, row-level multi-tenancy, or separate databases? What drove the choice? 2. Which components would you put behind a queue vs. handle synchronously, and why? 3. What's the single point of failure in this design, and how would you mitigate it? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Chooses row-level multi-tenancy (tenant_id column + query-scoping) as default and explains why schema-per-tenant breaks down operationally past a few hundred tenants; separates read/write paths early; treats async work (notifications, reminders) as queue-based from the start; names specific AWS services with reasoning (RDS Multi-AZ, ElastiCache, ALB), not just a buzzword list | HIRE strong signal | | Acceptable (Mid) | Correct high-level components (app servers, DB, cache, queue) but needs prompting to address tenant isolation tradeoffs or can't justify choices operationally | HIRE signal | | Weak (Junior) | Designs a single-tenant CRUD app and treats "5,000 businesses" as a minor detail; no mention of caching/queuing/failure modes without heavy prompting | No hire at senior level | | Red flag | Proposes a fully custom database-per-tenant scheme with no acknowledgment of the operational cost of 5,000 databases | Explicit no-hire | **Green flags:** Asks about read/write ratio or peak concurrency before diagramming anything; explicitly says "I'd start simple and evolve it this way" instead of over-engineering; proactively raises noisy-neighbor tenant risk. **Common mistakes:** Jumping to microservices prematurely; ignoring tenant isolation until asked directly; treating caching as the answer to every scaling question. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q2 — System Design (Scaling & Contention)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "Traffic grows to 50 million bookings a month, and some tenants run flash-sale-style events where a limited number of slots open at once and get booked within seconds. How does your architecture evolve?" **Time:** 15 min | **Format:** whiteboard **Follow-up probes:** 1. How do you stop flash-sale contention on one tenant from degrading the platform for everyone else? 2. Would you shard the database at this scale? On what key? 3. What would you monitor to know this design is holding up versus quietly degrading? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Identifies this as a hot-partition/thundering-herd problem on a specific subset of rows, not general load growth; proposes a queue-based reservation system (short-lived hold via Redis TTL, then confirm) instead of relying on raw row locks at high concurrency; shards by tenant_id specifically to contain blast radius; names concrete metrics (per-tenant p99 latency, connection pool saturation, queue depth) | HIRE strong signal | | Acceptable (Mid) | Reaches for read replicas, more caching, and per-tenant rate limiting, but treats the flash sale as "more load" rather than a distinct contention problem | HIRE signal | | Weak (Junior) | "Add more servers" / vertical scaling as the primary answer; no distinction between volume growth and burst contention on shared rows | No hire at senior level | | Red flag | Suggests dropping transactional guarantees around booking confirmation "to make it faster," without acknowledging the double-booking risk | Explicit no-hire | **Green flags:** Separates "scaling for volume" from "scaling for contention" explicitly; brings up idempotency keys unprompted when discussing retries under load. **Common mistakes:** Reaching for DB sharding as the first move instead of addressing the specific hot-row problem; adding caching without a plan for slot-availability invalidation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q3 — Database Optimization (Schema Design)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "Sketch the core PostgreSQL schema for businesses, staff, services, availability slots, and bookings. What indexes would you add, and why?" **Time:** 15 min | **Format:** whiteboard/verbal **Follow-up probes:** 1. How does this schema handle a service offered by multiple staff members with different durations? 2. Which table is your biggest write bottleneck, and why? 3. How would you handle historical/soft-deleted bookings without bloating your indexes? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Normalized schema with clear FKs (tenant → staff → service → slot → booking); adds a composite index on (tenant_id, staff_id, start_time) rather than single-column indexes, and can explain selectivity/column-order reasoning; flags that a unique constraint alone won't prevent double-booking under concurrency — connects schema back to Q1/Q2's locking discussion | HIRE strong signal | | Acceptable (Mid) | Correct normalized schema with reasonable indexes, but added by intuition rather than selectivity reasoning | HIRE signal | | Weak (Junior) | Schema largely correct but flat/denormalized without justification, or indexes everything "just in case" with no write-cost discussion | No hire at senior level | | Red flag | Doesn't know the difference between a unique constraint and an index, or claims indexes have no cost | Explicit no-hire | **Green flags:** Proactively mentions partial indexes (e.g., indexing only active/future bookings); names EXPLAIN ANALYZE as their go-to diagnostic tool unprompted. **Common mistakes:** Indexing every foreign key regardless of query pattern; ignoring composite index column order. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q4 — Database Optimization (Query Debugging)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "The bookings-list endpoint on the business dashboard used to respond in 50ms. As tenant data has grown, it now takes 4 seconds for some businesses. Walk me through how you'd diagnose and fix this." **Time:** 15 min | **Format:** verbal **Follow-up probes:** 1. What's the difference between what EXPLAIN and EXPLAIN ANALYZE tell you here? 2. If it's an N+1 query from the Django ORM, how do you find and fix it? 3. The fix works in staging but the query is still slow in production — what would you check first? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Structured diagnosis: reproduce with EXPLAIN ANALYZE → check for missing/unused indexes → check for N+1 queries (select_related/prefetch_related) → check whether slowness correlates with specific large tenants (data skew) vs. platform-wide; distinguishes a slow query from lock contention or connection pool exhaustion; names production-only factors (data volume, stale statistics/ANALYZE) staging won't replicate | HIRE strong signal | | Acceptable (Mid) | Correctly identifies N+1 queries and indexing as likely culprits and knows Django tooling, but jumps between hypotheses without a structured order | HIRE signal | | Weak (Junior) | Guesses at fixes ("add indexes," "add caching") with no diagnostic process; no mention of EXPLAIN or ORM-specific tooling | No hire at senior level | | Red flag | Proposes caching the slow query as the fix without ever diagnosing the cause | Explicit no-hire | **Green flags:** Mentions pg_stat_statements or similar for proactively surfacing slow queries; distinguishes data skew (one huge tenant) from a systemic problem. **Common mistakes:** Assuming N+1 without checking; not considering stale table statistics causing a bad query plan even with correct indexes. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q5 — API Design (Resource Modeling & Concurrency)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "Design the REST endpoint for creating a booking. How do you prevent two customers from double-booking the same slot when requests arrive concurrently?" **Time:** 15 min | **Format:** whiteboard/verbal **Follow-up probes:** 1. Where does the concurrency protection actually live — application code, database constraint, or both? 2. What status code and response body do you return when a slot is already taken? 3. How does a client safely retry this request after a timeout without risking a duplicate booking? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Clean POST /bookings contract; places the real concurrency guard at the DB layer (unique partial index on slot_id where status='confirmed', or SELECT ... FOR UPDATE in a transaction) rather than trusting application-level checks alone; returns 409 Conflict with a machine-readable error code; supports idempotency keys for safe retries | HIRE strong signal | | Acceptable (Mid) | Reasonable endpoint, uses a DB transaction, but relies on check-then-insert without recognizing the race until prompted | HIRE signal | | Weak (Junior) | Correct request/response shape but no concrete answer for concurrent double-booking beyond "check if it's booked first" | No hire at senior level | | Red flag | Dismisses the concurrency scenario as unlikely to matter in practice | Explicit no-hire | **Green flags:** Brings up idempotency keys before follow-up 3 asks for them; separates "prevented at the DB layer" from "handled gracefully at the API layer." **Common mistakes:** Optimistic check-then-insert with no DB constraint or row lock; returning a generic 500 for an expected conflict instead of 409. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q6 — API Design (Versioning & Compatibility)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "You need to change the shape of the booking API response for a new mobile client, but 200 existing partner integrations depend on the current shape. How do you evolve the API without breaking them?" **Time:** 10 min | **Format:** verbal **Follow-up probes:** 1. How do you decide when it's safe to fully deprecate the old version? 2. How do you communicate and enforce this with 200 partners who may not be paying close attention? 3. Give an example of a change that would *not* require a new version. | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Distinguishes additive/backward-compatible changes from breaking ones and only versions for the latter; picks a concrete versioning strategy with a deprecation timeline; proposes tracking real usage telemetry to see who's still on the old version before sunsetting it | HIRE strong signal | | Acceptable (Mid) | Knows to version the API and picks a reasonable strategy, but no clear plan for measuring adoption before deprecating | HIRE signal | | Weak (Junior) | Suggests changing the shape and notifying partners after the fact; can't articulate breaking vs. non-breaking changes | No hire at senior level | | Red flag | Proposes silently changing the response shape without versioning "since most fields are similar" | Explicit no-hire | **Green flags:** Uses usage telemetry to know exactly who's still on v1 before removing it, rather than deprecating on a fixed calendar date alone. **Common mistakes:** Versioning for every change (unnecessary churn); no concrete sunset plan. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q7 — Debugging Under Ambiguity (Silent Production Failure)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "It's 2am and you're paged: bookings are silently failing for exactly one tenant, nothing in your logs or monitoring. Walk me through how you'd debug this with the limited information you have." **Time:** 15 min | **Format:** verbal **Follow-up probes:** 1. What's your first move — checking logs, trying to reproduce it, or something else? Why? 2. If nothing shows up in application logs, where else would you look? 3. How do you rule out "it's actually working, but the tenant's client is misreporting"? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Structured, falsifiable hypothesis process: first scopes the issue (is it really 100% of that tenant's requests, and only that tenant?), checks tenant-specific config/feature flags before assuming a code bug, considers that "silent with no logs" often means an error is being swallowed somewhere or happening upstream of logging middleware (e.g., load balancer/WAF); explicitly separates hypotheses from confirmed facts as they go | HIRE strong signal | | Acceptable (Mid) | Reasonable set of places to check (logs, recent deploys, tenant config) but jumps between them without a narrowing process; needs prompting to look outside the application layer | HIRE signal | | Weak (Junior) | Jumps straight to "redeploy" or "restart the service" without gathering information first | No hire at senior level | | Red flag | Says they'd wait until morning since it's only one tenant, showing no urgency or ownership — or would guess-and-check directly in production with no hypothesis process | Explicit no-hire | **Green flags:** Asks what "silently failing" actually means (returns success but no booking created? times out? error swallowed client-side?) before diving in. **Common mistakes:** Assuming a code bug before checking tenant-specific config or recent scoped changes; not considering the failure might be client-side. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q8 — Debugging Under Ambiguity (Distributed Edge Case)** | Type: System Design ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "After a deploy, some customers report getting their booking confirmation notification twice. How do you investigate and fix this?" **Time:** 12 min | **Format:** verbal **Follow-up probes:** 1. Is this a bug, or an inherent property of the notification system you'd need to design around? 2. How do you fix it without introducing a new failure mode, like now silently dropping notifications? 3. How do you verify the fix worked, given the bug is intermittent? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Recognizes this as a classic at-least-once delivery problem (likely a queue/worker retry after a timeout) rather than hunting for one faulty line; proposes an idempotent notification-send (dedup key per booking + notification-type checked before sending) rather than chasing exactly-once delivery; is careful the fix doesn't silently drop legitimate resends | HIRE strong signal | | Acceptable (Mid) | Correctly guesses it's a retry/duplicate-processing issue and proposes a reasonable dedup mechanism, but doesn't clearly articulate at-least-once vs. exactly-once | HIRE signal | | Weak (Junior) | Treats it as a one-off bug to patch rather than a systemic property of queue-based systems; proposes removing retries entirely | No hire at senior level | | Red flag | Can't explain why a distributed queue would ever deliver a message twice | Explicit no-hire | **Green flags:** Uses the concept of an "idempotent consumer" unprompted; thinks about what "verify the fix worked" means for an intermittent, timing-dependent bug (synthetic testing with injected delay, not just "watch and hope"). **Common mistakes:** Removing retry logic as a blunt fix instead of adding deduplication; not testing the fix under the same race condition that caused the bug. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Q9 — Synthesis / Self-Assessment** | Type: System Design (ownership signal) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Prompt:** "Looking back across everything we've designed today, what part of this system are you least confident in, and what would you actually do in the first two weeks after launch to de-risk it?" **Time:** 8 min | **Format:** verbal **Follow-up probes:** 1. How would you know within two weeks whether that risk actually materialized? 2. What would you have done differently if you'd talked this through with the team before writing any code? 3. What's the one metric you'd put on a dashboard on day one? | Level | Answer Characteristics | Signal | |-------|----------------------|--------| | Strong (Senior+) | Specific, self-critical answer tied to a real decision made earlier ("the flash-sale locking approach — I'd want to load-test it against realistic contention before trusting it"); proposes concrete, measurable de-risking actions (load testing, canary rollout to a subset of tenants, a specific dashboard) rather than vague reassurance | HIRE strong signal | | Acceptable (Mid) | Identifies a real weak point but the de-risking plan is generic ("monitor it closely") | HIRE signal | | Weak (Junior) | Claims confidence in everything, or names a cosmetic concern instead of a real architectural risk from the session | No hire at senior level | | Red flag | Becomes defensive or dismissive when asked to critique their own design | Explicit no-hire | **Green flags:** Ties the answer directly to a specific tradeoff made earlier, showing they were tracking their own decisions critically in real time. **Common mistakes:** Treating this as a "gotcha" and refusing to commit to a real answer; naming a risk unrelated to anything actually discussed. --- ## STAGE 4: ASSUMPTION LEDGER | Assumption | Where It Enters | If False — Interview Effect | |------------|----------------|----------------------------| | Candidate has access to a whiteboard or shared drawing tool | Q1, Q2, Q3, Q5 | Switch to verbal-only walkthrough; interviewer sketches as candidate describes | | Interview runs as one 60–90 min slot | All — total scripted time is ~125 min | Trim to a 60-min core: keep Q1, Q3, Q4, Q5, Q7; drop Q6 and Q9; compress Q2 and Q8 into single follow-up probes | | Candidate has hands-on Django/PostgreSQL production experience, not just academic knowledge | All DB and debugging rubrics | Weak/junior-level answers become the expected baseline rather than a red flag; recalibrate to IC3 | | AWS is the candidate's actual production environment | Q1, Q2 AWS-specific probes | Accept GCP/Azure equivalents as valid; don't penalize AWS-specific terminology gaps | --- ## STAGE 5: EVALUATION SCORECARD | Competency | Weight | Question # | Score (1–4) | Notes | |-----------|--------|-----------|-------------|-------| | System design | 35% | Q1, Q2, Q9 | | | | Database optimization | 25% | Q3, Q4 | | | | API design | 20% | Q5, Q6 | | | | Debugging under ambiguity | 20% | Q7, Q8 | | | *Weighting is INFERRED — not stated in the inputs. Confirm with the hiring manager before use; system design was weighted highest because it is both the interview format and the role's primary stated signal.* **Hire/No-hire decision logic:** | Outcome | Condition | |---------|-----------| | Strong Hire | Weighted average ≥ 3.5, no red flags, and both System Design and Debugging Under Ambiguity individually score ≥ 3 | | Hire | Weighted average ≥ 3.0, no red flags, no competency scored below 2 | | No Hire | Weighted average < 3.0, or System Design or Debugging Under Ambiguity scores a 1 | | Strong No Hire | Any red flag triggers this regardless of score — specifically: dismissing the double-booking concurrency risk (Q5), no structured process under ambiguity (Q7), or defensiveness when asked to self-critique (Q9) | --- ## STAGE 6: DESIGN INTEGRITY CHECK | Check | Status | Note | |-------|--------|------| | Every competency from inputs has at least one question | ✅ | System design ×3, DB optimization ×2, API design ×2, debugging ×2 | | Every rubric concretely distinguishes senior from mid answers | ✅ | Each rubric ties "Strong" to a specific mechanism (e.g., DB-layer locking, idempotent consumer), not adjectives | | No question tests pure knowledge recall without application | ✅ | All questions are scenario-driven within the running booking-platform design | | Total interview time fits the stated format | ⚠ | 125 scripted minutes exceeds a typical single 60-min system-design slot — see Assumption Ledger for the trimmed-down variant | | Scorecard weights sum to 100% | ✅ | 35 + 25 + 20 + 20 = 100 | | All INFERRED findings are labeled | ✅ | | **DESIGN CONFIDENCE: 82/100** — Rubric specificity and competency coverage are strong; the main open question is time budget and competency weighting, both of which are INFERRED rather than stated by the hiring team. **Biggest unknown:** Whether the verbal-only debugging questions (Q7, Q8) actually predict real on-call performance. A pure system-design format has no hands-on incident simulation (e.g., a genuinely broken staging environment), so this kit measures *how a candidate reasons about* ambiguity, not how they perform under it. **STATED vs. VERIFY breakdown:** *STATED (given directly in inputs):* - Role/level: Senior Backend Engineer - Tech stack: Python, Django, PostgreSQL, AWS - Competencies: system design, database optimization, API design, debugging under ambiguity - Format: system design *VERIFY (inferred, confirm with hiring manager before running):* - Actual interview slot length / number of sessions (assumed 125 min needs splitting or trimming) - Whether candidate will have whiteboard/collaborative doc access - Whether debugging questions should stay verbal-only or pair with a real broken-repro environment - Relative competency weighting (35/25/20/20 assumed, not stated)