Scribd Software Engineer Interview Experience — Rejected at Onsite Coding Over Missing Metrics

Interviewed for the content understanding team, mid-level, in June/July.

Phone screen
Structure: self-intro → why I'm leaving my current company → DB schema + SQL → a small system design question → observability → my questions for them.

Schema / SQL: given a many-to-many relationship, design the tables (they wanted a join table with a composite primary key), then write the query.

System design: use an LLM to enrich documents — batch-feed documents to an external LLM API and write the results back. Main follow-up: what do you do when the third-party API call gets rate-limited (429)? He gave me almost 10 minutes on this and I never assembled the answer on my own — in the end he walked me through it: read Retry-After → write it into a shared cache → the whole worker fleet backs off together. A single worker backing off on its own isn't enough — that was the point of the question. He also asked how you dedupe (atomic claim + lease), and how you replay the last 5 days of data (a status table + an updated_at window).

Onsite Round 1 — Coding (this is the round I got rejected at)
The interviewer was based in the Vancouver hub. The team splits into two halves: content trust (detecting policy-violating/harmful content) and content understanding (document enrichment, generating metadata). He opened by saying no LLM tools allowed, and that the environment didn't have a real database, so it was fine if the code didn't actually run — the focus was on process and talking through your thinking. Two questions:

Q1 — Write an event-ingestion function. Given an event (fields like event_id, object_id, etc.), do field validation and type validation, then write to the DB. Follow-ups: why did I only enforce types on event_id and object_id? Why not the other fields? "If there's a network failure upstream and we start getting duplicate events, how does your code handle that right now?" → idempotency (event_id as primary key + ON CONFLICT).

Q2 — An aggregate query over movie/person data. object_id can point to either a movie or a person; the same person can have multiple roles in one movie (actor, director, etc.), so you need to split by role and only count actors. It wanted something like "most popular actor" as an aggregate. I didn't finish this one.

Where I lost the most points: in Q1, when validation failed I just did a return — the interviewer asked about it twice before I added logging and a DLQ; the whole time I didn't output a single metric. That was literally what the feedback said. The lesson is direct: the moment you write any handler, talk through metrics / DLQ / retry right then, don't wait to be asked. The lesson is direct: the moment you write any handler, talk through metrics / DLQ / retry right then, don't wait to be asked.

Onsite Round 2 — System Design
This one was interviewed by one of their principals. He spent the first 10 minutes walking me through their data platform background (Databricks/Spark → SQS + Lambda for async processing → an LLM batch inference platform; 500 million documents × an average of 30 pages, on the order of tens of billions of embeddings). He opened by saying "the prompt is deliberately vague — I'm not giving you all the details, I want you to ask."

Question: design event tracking + an analytics system for a product feature. The web app's various features emit JSON events with a source field (which feature) and a type field (what action); different features also attach their own extra key-value pairs (e.g. the Doc Chat feature needs to additionally log the question and answer). You need to design the whole pipeline from ingestion to storage to analysis.

Constraints he gave, all pulled out by asking:

• Volume: currently 10 events/sec, could grow to 100–200/sec
• Event timestamps: the web app team can be asked to add them
• source and type values will keep being added, so the schema needs to be extensible
• I had to propose the retention policy myself (he hinted that Scribd has been around 20 years, so keeping everything forever adds up)
• Query latency: second-level is fine, this is purely internal use
• Two kinds of queries to support:
  • Time-window aggregates: how many unique users last week, unique counts filtered by source/type
  • Debugging-style queries: e.g. find Doc Chat records where the answer is empty or under 10 characters

Main follow-ups:

• How exactly do events get into the topic you drew? (He challenged my understanding of SNS — SNS isn't just "notifications," you can publish the message body directly into the topic.)
• What do you use for the event processor? How do you scale it?
• How do you design the schema so it stays flexible (I initially gave Doc Chat its own question/answer columns; he said "that's not wrong, but what we want is flexibility")
• "You picked Postgres. What about the data-warehouse path instead — Redshift, S3 + Parquet, Spark? If you could only pick one, which and why?" This was the core tradeoff question of the round.
• Retention policy

Onsite Round 3 — Behavioral
Standard questions: the project I'm most proud of, the biggest ambiguity/change in a project and how I handled it, a time I had to make a tradeoff.

Summary
Scribd's coding round isn't testing algorithm difficulty, it's testing production mindset: idempotency, what to do when validation fails, where failed messages go, what metrics you emit, how you alert. Practice along that line — it's more useful than grinding LeetCode. Their recruiter was great about telling you what to expect going in; the things they test are different from most other companies.