Axiom Command Deck

Competencies

weights sum to 1.00

Name	ID	Weight	Definition
Distributed Systems Rigor	distributed_systems_rigor	0.35	Deep understanding of consensus, ordering guarantees, and idempotent design patterns. For this role: architect payment state machines where every transition is recoverable, handle retry logic without double-charging, and reason about exactly-once delivery semantics across Kafka and Postgres.
Postgres Transactional Design	postgres_transactional_design	0.25	Expert-level schema design and optimization for high-throughput financial transactions. For this role: build double-entry accounting models, design ledger schemas that scale to millions of daily payments, and optimize for both consistency and performance under write-heavy workloads.
Domain Ownership & Reliability	domain_ownership_and_reliability	0.25	End-to-end accountability for production systems including design, deployment, on-call response, and postmortem-driven prevention. For this role: own critical payment paths, lead incident response on money-movement failures, and drive systemic improvements that eliminate recurring classes of failures.
Payments Domain Expertise	payments_domain_expertise	0.15	Working knowledge of payment rails (cards, ACH, wire transfers) and financial ledger systems. For this role: understand settlement flows, reconciliation mechanics, and compliance requirements well enough to navigate tradeoffs with risk and product teams.

Scoring Weights

Adjust how much each competency contributes to the final score. Changes apply to all future evaluations for this job spec.

distributed_systems_rigor

35%0.35

Scoring guideline

postgres_transactional_design

25%0.25

Scoring guideline

domain_ownership_and_reliability

25%0.25

Scoring guideline

payments_domain_expertise

15%0.15

Scoring guideline

Total weight: 1.00 ✓ balanced

Interview questions

AI-generated from the JD · auto-published · edit anytime

Question count3 currently · candidate sees this many

Title

Difficulty

Time budget (min)

Prompt

You are building a payment processor that must handle retries without double-charging. When a payment request arrives, it includes a unique `idempotency_key`. If the same key is submitted again (e.g., due to client retry), the system must return the same result without processing the payment twice.

Design a function that:
1. Accepts a payment dict with `idempotency_key`, `amount`, `from_account`, `to_account`
2. Records the payment request in a ledger table (simulate with a dict)
3. Returns `{"status": "success", "transaction_id": id}` on first call
4. Returns the same result on retry (same idempotency_key)
5. Rejects duplicate keys with different amounts (fraud protection)

Example:
- First call: `process_payment({"idempotency_key": "pay_123", "amount": 100, "from": "A", "to": "B"})` → `{"status": "success", "transaction_id": "tx_1"}`
- Retry: same input → same output, no new transaction
- Fraud: `{"idempotency_key": "pay_123", "amount": 200, ...}` → `{"status": "error", "reason": "idempotency_key_mismatch"}`

Starter code

Hidden tests

import uuid
ledger = {}
def test_payment_processing():
    # Test 1: First payment succeeds
    result1 = process_payment({"idempotency_key": "pay_1", "amount": 100, "from": "A", "to": "B"}, ledger)
    assert result1["status"] == "success"
    assert "transaction_id" in result1
    txn_id_1 = result1["transaction_id"]
    
    # Test 2: Retry returns same transaction_id
    result2 = process_payment({"idempotency_key": "pay_1", "amount": 100, "from": "A", "to": "B"}, ledger)
    assert result2["status"] == "success"
    assert result2["transaction_id"] == txn_id_1
    
    # Test 3: Different key, different transaction
    result3 = process_payment({"idempotency_key": "pay_2", "amount": 200, "from": "A", "to": "C"}, ledger)
    assert result3["transaction_id"] != txn_id_1
    
    # Test 4: Fraud detection - same key, different amount
    result4 = process_payment({"idempotency_key": "pay_1", "amount": 150, "from": "A", "to": "B"}, ledger)
    assert result4["status"] == "error"
    assert "mismatch" in result4.get("reason", "").lower()

Hints (one per line)

Behavioral round (Round 02)

Voice Q&A · pre-generated from the JD · edit anytime

4 prompts · Cal walks through each in order during Round 02

Prompt

Target competency

Time (min)

Follow-up (optional)

Live performance

Aggregated from candidates who took this job spec.

Interviews

1

0 completed

Avg score

—

out of 100

Completion

0%

0 of 1

Avg score per competency

Distributed Systems Rigorweight 0.35—n=0

Postgres Transactional Designweight 0.25—n=0

Must-haves

required5+ years of production backend systems engineering
requiredStrong SQL and schema design experience with Postgres at transactional scale
requiredDemonstrated understanding of distributed systems fundamentals (consensus, idempotency, ordering)
requiredTrack record of owning critical incidents, postmortems, and prevention measures

Senior Backend Engineer — Payments Platform

Competencies

Scoring Weights

Interview questions

Behavioral round (Round 02)

Live performance

Must-haves