Designs by Duhart ← All infographics

Designs by Duhart · evidence map

Skills, and the evidence for each

Rows are what a distributed-systems loop tests. The first three columns are how much each employer weights that skill; the last is how much evidence exists in /srv, 0–5. Read across: a dark weight beside a pale depth is a gap worth preparing for.

Employer weight — LOW · MED · HIGH · CRIT Evidence depth 0 none 1–2 touched 3 built 4–5 built, shipped, debugged

Both encodings use the same single-hue ordinal ramp — darker (lighter, in dark mode) means more. Every cell carries a text label as well as a shade, so nothing depends on color alone.

Skill · where the evidence is Google
weight		 Spotify
weight		 Bank
weight		 Evidence
depth
Event logs & consumer groupsBillboardActivityService · Kafka, 3 groups HIGH HIGH HIGH 5
Idempotency & delivery semanticsthree sinks, three mechanisms HIGH HIGH CRIT 5
Partitioning & shard-key designMatchService · (service_region, geohash4) HIGH HIGH HIGH 5
Concurrency correctness in Gofatal map race G-07 · calling_race_test.go CRIT HIGH HIGH 5
Realtime transport & presenceGlobalChatService · WebSocket, TTL presence MED HIGH MED 5
Contract discipline in CIOpenAPI + AsyncAPI + 24 protobufs HIGH MED CRIT 5
Kubernetes & autoscalingSolomon · k3s, Helm, HPA, NetworkPolicy CRIT HIGH MED 4
Auth, tokens & key handlingAuthGateway · RS256, ACL, mode-sync MED MED CRIT 4
Large-file & media pipelinesR2 multipart, IngestDO, TUS, range streaming MED CRIT LOW 4
Audio DSP & fingerprintingvDSP FFT on-device · kissfft.wasm at the edge LOW CRIT — 4
ML platform & release gatingSolomon · 9 promotion-blocking gates HIGH MED HIGH 4
Operational writing & postmortems54 manual chapters · gap registers CRIT MED CRIT 5
Distributed consensus & replicationconsumed, not implemented CRIT MED HIGH 2
Multi-region & failoversingle-region deployments HIGH HIGH CRIT 2
The two rows in the palest shade are the honest answer to "what are you weakest at?"

Consensus protocols and multi-region failover are both consumed here and neither is implemented or exercised. Naming them before an interviewer finds them costs nothing and buys credibility for every other row on this page. The preparation is specific: read the Raft paper properly, and be ready to talk through a region-failover design for the activity graph — which is a good design question precisely because the outbox makes it tractable.

What to lead with, by employer

Google

Weights scale reasoning, correctness, and written design.

  • The activity graph and its delivery semantics
  • The Cassandra phantom-partition root cause
  • Helm, HPA, NetworkPolicy, dry-run validation
  • The gap registers as design-doc evidence

Spotify

Weights the music domain and the delivery path.

  • Constellation fingerprinting, twice, two runtimes
  • R2 multipart ingest and range streaming
  • The feed/activity graph for playlists and follows
  • The 14/52 parity analysis you wrote unprompted

Financial institution

Weights auditability, contracts, and fail-closed behavior.

  • RS256 auth, four tiers, identity bound to the token
  • Contract gates that fail the build on drift
  • Fail-closed ingest — WARN-blocked, not silently wrong
  • The restore-verify systemd timer