Day 85: Progressive KV Store (Anthropic style)

Day 85 — Progressive KV Store (Anthropic style)

Coding problem

Solution outline (coding)

• Layer features: base KV → snapshots → optional TTL; define invariants per layer.
• Pick storage: in-memory maps + vectors of versions; binary search for get at version.
• Walk through a concrete sequence of set/snapshot/get calls.

Time complexity: Target O(log V) per versioned read if V versions; O(1) for latest.

Space complexity: O(keys · versions) worst case.

class ReviewDay:
  """Practice / review: Progressive KV Store (Anthropic style)."""

  def practice_plan(self):
    return [
      "Pick 2–3 problems from this phase; re-solve timed without notes.",
      "For each: pattern name, time/space complexity, one alternative approach.",
    ]


# Input:  (your choice of problems from this week or phase)
# Output: a short list of gaps to drill before the next session

SQL interview practice

1. Interview question

Companies / track: Anthropic

Frontier AI lab: interviews often stress clean grain, experiment or eval metrics, and reproducible joins over logging and offline tables—similar rigor to research engineering.

What you are asked to write (SQL prompt):

Frame this as metrics work for **Anthropic**-scale surfaces (ads, product, or engagement — as the tables suggest).
kv_requests(key, ts, op, latency_ms). BigQuery: build progressive KV-store metrics—P95 latency by key, error rate, traffic distribution—simulating Anthropic-style progressive builds.

Tables implied by the prompt:

• kv_requests(key, ts, op, latency_ms)

Engine: BigQuery — use its date, array, and approximate functions as documented.

2. Solution outline

• Clarify out loud: result grain (one row per what?), join keys, time zone, and any ORDER BY / LIMIT / tie-breakers.
• Map Design / Build to SQL: say the relational equivalent (e.g. hash map → GROUP BY + key; two pointers → ordered window + filter).
• Rates: SAFE_DIVIDE or NULLIF; define numerator and denominator.
• Percentiles: approx vs exact; say so if you use APPROX_QUANTILES.
• Structure: CTEs (WITH) — one step per CTE; validate on a tiny slice (counts, nulls, duplicates).

SELECT key,
  APPROX_QUANTILES(latency_ms, 100)[OFFSET(95)] AS p95
FROM kv_requests
GROUP BY key;