Interviewer — loan voting
Candidate prompt: prompt. Method: Method.
Do not let the candidate read this file. Give numbers and product rules only when they ask, or when they are stuck after you have nudged them to ask.
This is an Engineering Manager loop. Correctness and exec trade-offs beat Twitter-scale trivia.
How to run it (45–60 min)
| Step | Time | Do not leave until |
|---|---|---|
| 1. Requirements | 8–10 min | Actors, use cases, “worse of stale/wrong/down/leaked,” NFRs on the board |
| 2. APIs | 3–5 min | At least configure, submit, read status; authz mentioned |
| 3. High-level design | 12–15 min | Eligibility source, accept path, and progress path are different |
| 4. Deep dives | 12–15 min | Two of: submit idempotency, deadline clock, hot facility, downstream failure |
| 5. EM close | 3–5 min | v1 cut, team topology, KPI, exec sentence |
If time dies, skip CDN, object storage, and Angular vs React. Keep who is allowed to vote and what happens when the agent feed is late.
Step 1 — Requirements
Open
“Take a minute with the prompt, then walk me through how you’d approach it. I’ll answer questions.”
If they jump to boxes: “Pause. What do you need to know before you draw?”
They should ask (nudge if silent)
- Who are the actors? (agent ops vs lender ops vs fund/legal entity vs internal ops)
- What does a successful vote mean? (eligibility, one vote per entity, deadline)
- Write vs read? Peak? (deadline)
- What’s worse: stale, wrong, down, or leaked?
- Does the data platform already have positions? (yes — see prompt)
- Retention / audit?
- Multi-region? (only if they care)
Answers to give when asked
| Question | Give them |
|---|---|
| Actors | Agent operations starts/configures/closes a vote. Lender operations votes for one or more legal entities / funds. Internal ops/support can see what they are entitled to. Downstream: agent servicing / internal bank systems via API. |
| Eligibility | Votes must be based on settled, agent-sourced positions, by legal entity. Last-seen UI cache is not eligibility. |
| Multi-fund | One human may vote for several funds. Each fund is a separate ballot. |
| Deadline | Agent sets a deadline. Peak is the last 5–15 minutes on a large facility. |
| Scale | ~11k facilities, ~$4.8T commitments. Concurrent users: thousands of ops people, not millions. Hot path is one facility, many funds, same minute. |
| Real time | Progress dashboard can lag a few seconds if labeled. Official result cannot. |
| Audit | Who voted, as what entity, on what snapshot, when. Keep for years (say 7). |
| Failure preference | Wrong or leaked is worse than down. A missed deadline because the system refused is better than counting an ineligible vote. |
| Cloud | Azure, start single-region. Don’t invent multi-region unless they argue for it. |
| v1 scope if they ask | One amendment type, one vote per entity, no fancy Excel grid. |
Gate
Do not start APIs until they have written, roughly:
- Verbs: configure, snapshot/eligibility, submit, tally, notify/export
- Nouns: vote, facility, legal entity, position, entitlement, deadline
- NFRs: strong consistency on accept; labeled eventual OK on progress; entitlement false-allow = 0
If they never rank stale/wrong/down/leaked, ask: “If we can only pick one, would you rather the submit button fail or count a vote that wasn’t eligible?”
Weak: “We’ll cache positions in Redis for speed.” Challenge: “What if that cache is from this morning and the trade settled at noon?”
Strong: They say eligibility is a snapshot at rule time, not a live read at click time.
Step 2 — APIs
Keep this short. Readable resources, not REST theology.
They should name something like:
- Agent: create/configure vote (facility, terms, deadline, docs)
- System: freeze eligibility (they may not call it snapshot yet — listen for the idea)
- Lender: submit vote (vote_id, legal_entity_id, choice, idempotency key)
- Anyone entitled: get vote status / progress / official result
- Downstream: export / webhook / pull API
- Authz on every call: this lender cannot see another lender’s ballot
If they omit authz: “Does the API for lender A ever return lender B’s position?”
If they omit idempotency: wait for deep dive unless they have extra time.
Gate
Move on when there is a submit operation and a read-status operation, and they have said who is allowed to call them.
Step 3 — High-level design
Ask them to draw one box at a time and say what problem it solves.
Boxes you want to see (order flexible)
- Clients (agent UI, lender UI)
- API gateway: authn, rate limit, audit
- Voting service (eligibility check + accept)
- Position snapshot from golden source at rule-T — freeze who can vote
- Entitlements (every read and submit)
- Vote store with uniqueness on
(vote_id, legal_entity)and/or optimistic concurrency - Official tally (strong) vs progress UI (eventual, labeled)
- Queue for reminders / downstream (not for the legal accept, unless they justify)
- DLQ + replay for notify path
Push questions
- “At click time, where does eligibility come from?”
- “Is the progress bar the same data as the official result?”
- “What happens if they double-click Submit?”
- “Show me the path when the agent feed is 20 minutes late.”
Common traps — do not rescue immediately
| Trap | Let them sit, then |
|---|---|
| Redis as source of vote weight | “So a cache miss means they can’t vote, or they vote with a guessed position?” |
| Kafka on the accept path | “If the queue is behind, did they vote?” |
| One microservice named “voting” that also owns ingest | “Who gets paged when an adapter breaks during a deadline?” |
| Live golden-source read at click | “Trade settles during the vote. Do they gain/lose voting power mid-flight?” |
Gate
Do not start deep dives until:
- Submit is synchronous enough that the user knows accepted / rejected / in doubt
- Eligibility is not “whatever is in the SPA”
- They can point to where a leaked row would be stopped
Step 4 — Deep dives (pick 2–3)
A. Idempotent submit
Ask: “They click twice. Network retries. What is in the tally?”
Want: client idempotency key; unique (vote_id, legal_entity); at-least-once queue if any does not double-count.
B. Clock / deadline
Ask: “Whose clock? Vote arrives at 12:00:00.002. Agent deadline was 12:00.”
Want: server clock (or agreed source), documented grace or none, late votes rejected and audited, not silently counted. Do not roll your own distributed clock unless they can defend it.
C. Hot facility (celebrity analog)
Ask: “JPM-sized facility, thousands of funds, last two minutes. What melts?”
Want: partition/key by vote_id or facility_id; snapshot is read-mostly; writes go to vote store; rate limit; don’t shard by user_id in a way that still hotspots one vote row.
D. Downstream notify fails (saga)
Ask: “Vote accepted. Email/API to the agent book fails.”
Want: the vote still counts. Compensate with retry/outbox. Do not un-vote because SMTP failed. In-doubt only if accept itself is unknown.
E. Entitlement leak
Ask: “Write the test that must never fail in CI.”
Want: negative test — user must not see another lender’s ballot or position. False-allow is P0.
If they are flying, add: “Product wants the grid to look live for a demo on Friday.” Use the stakeholder spine: outcome → constraint → two hows → risk → staffing → decision. Never “engineering says no.”
Step 5 — EM close
Prompt: “You’re the EM in the room with product and the bank. What ships, who owns it, what do you measure?”
Listen for:
- v1: one amendment type, real settled positions, real entitlements, ugly UI OK
- Topology: voting squad vs platform/ingest vs shared entitlements; architecture owns long-term model
- DoD: snapshot tests, idempotent submit, entitlement negative tests
- KPIs: % votes on eligible settled positions; entitlement false-allow = 0; p95 submit; escaped P0s
- People: war room for first live votes; on-call not only the senior; off-hours release is in the JD
- Exec: “Live-looking and wrong this week, or smaller honest slice in two. I recommend two. If the date is political, cut scope, not golden source.”
Rubric
| Weak | Hireable | Strong | |
|---|---|---|---|
| Requirements | Draws Kafka first | Asks actors + NFRs | Ranks leaked/wrong above down; names snapshot without being fed the word |
| Design | Cache is truth | Separate accept vs progress | Snapshot id on every vote; saga on notify |
| EM | Implementation details only | Mentions tests | Capacity, KPI, stakeholder two-hows |
Personal parallel (candidate, not you): Phia deadlines / Temelio honesty. Don’t force it.