Interview candidates on the work they'll actually do.

Red flags

• Suggests only adding a cache without removing the query pattern
• Keeps offset paging at 30M rows without justification
• Ignores that anonymous callers have no per-viewer fields

• Name the two costs: per-row computed fields causing N+1 queries and a full count on every page
• Replace per-row resolution with one annotated or batched query for bookmark state and subscription state
• Move from offset to keyset (cursor) pagination, and either drop the exact total or serve an approximate or cached count
• Define indexes for the label, author and feed filters, including the composite order used for feed paging
• Describe contract changes (cursor tokens, total semantics) and a compatible rollout with deprecation
• Give measurements: queries per request, p95, plan inspection, and a load test with anonymous and authenticated mixes

The Token authentication component decodes a signed bearer token, loads the backing session row and then the account row, and optionally lets anonymous callers through. A token is issued, along with a new session row, on registration, login and every account update. Over the last quarter you observe three symptoms: median latency of authenticated read endpoints rose from 25 ms to 60 ms while anonymous reads did not change; the session table grew from 2 million to 41 million rows and its index no longer fits in memory; and a mobile client that refreshes its account on every launch creates about 200 sessions per active account per month. There were no recent deploys to the Token authentication component. Write down your ranked hypotheses, the queries or metrics you would use to confirm or kill each one, and the fix you would ship first. Then describe how you would clean up the existing rows safely, and what you would change so the problem cannot recur while keeping the ability to revoke a token.

Authors want to schedule an entry to appear at a future time. You are extending the Content entry API and the Relational data model and migrations in a Python service. Today an entry is created inside one transaction that also finds or creates its labels (flow: Entry creation), and every list, feed and read endpoint serializes entries through the Request and response schemas. Requirements: an author can set a publish time when creating or updating an entry; until that time only the author can see the entry; after it, everyone sees it without any manual action; the author can reschedule or cancel before publication; list endpoints keep their pagination contract and must not leak or count hidden entries; and existing entries must behave exactly as before. Deliverables: (1) the schema change and a migration plan that is safe on a table with 3 million rows; (2) the request and response schema changes, with validation rules; (3) pseudocode for the visibility predicate used by list, feed and read, and where you would apply it so no path can bypass it; (4) how entries become visible at the scheduled time and what happens if the process is down then; (5) a test plan listing the five most important cases, including time-zone and clock-skew edge cases.

A past migration replaced a third-party tagging library's tables with an owned label table and a link table between entries and labels, copying data with raw SQL and then dropping the legacy tables in a later migration. You are about to repeat this kind of change: the owned link table must be split so that each link also records the account that applied the label and the time it was applied, and the label table itself must be deduplicated case-insensitively. The service runs on a relational database with 5 million entries and about 20 million entry-label links, is deployed with rolling restarts, and cannot take more than a few seconds of write unavailability. Design the migration sequence, including how old and new application versions coexist during the rollout, how you backfill, how you verify correctness before cutting over, and how you roll back if verification fails after cutover. Call out which steps are reversible and which are not, and explain why you would or would not run the data copy inside a schema migration.