Scribd runs a set of digital reading and subscription products: Scribd, Everand, SlideShare and Fable. Software Engineers build the services behind document viewing, content discovery and subscription access, and the pipelines that ingest and enrich uploaded documents. Reported team alignments include ML Data Engineering, Web API Platform and Signup & Activation, so the work ranges from event-driven data pipelines to high-throughput backend APIs, depending on the team.
The stack named in candidate-facing notes is Python and Ruby on Rails on AWS, using ECS, Lambda, SQS and ElastiCache, with Terraform for infrastructure and Datadog for monitoring. Reported questions draw on this stack: one design question asks for an event-driven notification system built on SQS, Lambda and ElastiCache, and one domain question asks how you would provision a microservice cluster on ECS with Terraform.
For preparation, treat this as a backend role with a strong API and data-pipeline emphasis. Reported coding questions are practical rather than puzzle-based: reimplementing map, filter and reduce, extracting metadata tags from a document payload, a sliding-window rate limiter, and traversing nested document outlines. Reported design questions cover document ingestion at scale, a Web API layer in front of legacy services, a multi-brand subscription activation flow across Scribd and Everand, and caching for high-traffic endpoints. Reported behavioral questions are framed around Scribd's GRIT framework (Goals, Results, Innovation, Team).
Recruiter Phone Screen
reportedCandidates describe this as an initial call to align on background, location preferences and role expectations. Two things are worth settling here. First, location: candidate-facing notes describe a flexible model, Scribd Flex, tied to approved hiring hubs, so confirm where you live fits before a loop is booked. Second, team: reported alignments include ML Data Engineering, Web API Platform and Signup & Activation, and those point to different preparation (pipelines versus APIs versus growth funnels). Ask which team the seat sits on so you know where to spend your design practice.
What to demonstrate
- Whether your background, location and timeline are compatible with the role before technical rounds are scheduled
- Whether you can summarise your backend experience in terms that map to the role: services and APIs you built, pipelines you ran, languages you used in production
- Whether you give a clear answer on compensation expectations and competing timelines instead of deferring them to offer stage
How to prepare
- Write a short summary of your backend work that names the languages, datastores and queues you used, so the recruiter can place you against Python, Rails and AWS work
- Ask which team the role is on and whether the later rounds lean toward API design, data pipelines or product growth work
- Confirm your location against the hiring-hub model and state any hard constraints (start date, work authorisation, other processes) as facts on this call
Technical Phone Screen
reportedCandidates describe a live coding session focused on data structures, algorithms and practical problem-solving, and source notes say the technical screen is with a hiring manager or senior engineer. In live coding, narrate your reasoning and edge cases as you go so the interviewer can follow your approach, not just the final code. Reported coding questions (not tied to a specific round) include reimplementing map, filter and reduce without built-in helpers, extracting valid metadata tags from an unstructured payload, a sliding-window rate limiter, a word-based sliding-window problem tracking character frequencies, and traversing nested document outlines or category trees; they are the most direct practice material for a practical live-coding session.
What to demonstrate
- Whether you clarify input shape, invalid cases and constraints before coding, especially on loosely stated prompts
- Whether your code is modular and readable, with helper functions and clear names rather than one long loop
- Whether you find the edge cases yourself: empty input, malformed data, boundary conditions, deep nesting
- Whether you can state the time and space complexity and explain why your structure fits the access pattern
How to prepare
- From the reported coding category, reimplement map, filter and reduce from scratch in your interview language, including an initial-value case for reduce and a callback that receives the index
- Build a per-user sliding-window rate limiter with a deque of timestamps and decide, out loud, whether a request exactly at the window edge counts
- Write recursive and iterative traversals that render a nested outline with indentation, then handle a tree too deep for the recursion limit
- Practise narrating: state the brute force, the target complexity and the edge cases before the first line of code
Virtual Onsite Loop
reportedCandidates describe multiple specialised rounds covering advanced coding, system design and behavioral interviews, and source notes describe meeting multiple engineers and engineering leaders across modules on data structures, algorithm design, system architecture, database design and behavioral alignment. The source does not assign its reported design, database or language questions to this or any other round, so prepare by module rather than by expected question: for system architecture, practise the reported design questions as a category; for database design, the reported pagination, indexing and query-optimisation questions; for coding, the reported coding category; and for behavioral alignment, GRIT-framed stories.
What to demonstrate
- Whether a design answer starts from clarified requirements and stated throughput and latency assumptions rather than boxes
- Whether APIs you design are constrained: pagination, rate limits, payload size limits, input validation and a versioning story
- Whether pipeline designs handle failure: at-least-once delivery, idempotent writes, dead-letter queues, replay and monitoring
- Whether behavioral stories show ownership from decision through rollout and incident follow-up
How to prepare
- Practise the reported design question on document ingestion and enrichment end to end: upload, queue, workers, retries, dead-letter queue, deduplication and the metrics you would alert on
- Prepare a pagination answer that compares offset and keyset pagination, names the index each needs, and explains why offset degrades on deep pages
- Rehearse diagnosing an N+1 query in Rails or Django and the fix (eager loading, a join, or a batched lookup), with how you would confirm the improvement
- Prepare a Python or Ruby answer on memory growth and concurrency in long-running jobs, including how the GIL or GVL affects CPU-bound versus I/O-bound work
Collaborative Interviews
reportedCandidates describe meeting future teammates and cross-functional partners to work through simulated real engineering problems. Identify early what each session is: working a problem together, discussing how you collaborate with product, design or data partners, or probing work you have described. Source notes describe cross-functional work with Product, Data Science and Design, so expect to explain technical trade-offs to people who are not engineers. The bank's collaboration questions (working with product, creating a sprint, resolving cross-team technical conflict) are useful practice for this.
What to demonstrate
- Whether you work with the interviewer on a shared problem, asking and incorporating their input rather than solving alone
- Whether you can explain a technical trade-off, such as shipping a narrower version first, in terms a product partner can act on
- Whether you handle a challenge to your design with evidence and a willingness to change course
How to prepare
- Pick one feature you shipped with product and design partners and rehearse how scope was agreed, what was cut, and how you communicated the cut
- Practise a paired problem with a friend acting as a teammate who pushes back on one of your choices, and respond with a test or measurement rather than restating your view
- Prepare questions for the team about how they manage deployment risk, technical debt and on-call, which gives the conversation an operational focus
1 candidate reports. Individual accounts describe a particular role and hiring cycle.
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: u…
Read full experiencePracHub editorial advice for the preparation topics above.
Reaching for built-in helpers when the reported utility question asks you to reimplement map, filter or reduce
The bank's versions of this question say to implement the logic without the language's collection helpers, so calling the built-in misses the point of the exercise. Write the loop yourself, decide how reduce behaves with and without an initial value and on an empty input, and say whether your versions are eager or lazy. Test with a callback that uses the index and with one that raises.
A sliding-window rate limiter that is wrong at the window boundary or grows without limit
State whether a request exactly one window old is inside or outside the window, and test that case. A per-user deque of timestamps gives amortised O(1) checks, but idle users keep their entries forever unless you evict them; say how you would bound memory, and how the design changes when several servers must share the limit (for example a shared store such as Redis).
Designing an API or platform layer with no pagination, rate limits, payload limits or versioning
Source notes explicitly warn against unconstrained endpoints in design rounds. For the reported Web API layer over legacy services, name the pagination scheme (keyset over offset for large tables), the rate limit, payload size limits, input validation, and how you version the API without breaking existing web and mobile clients. Add a cache only after saying what invalidates it.
Treating a queue-based pipeline as if every message arrives exactly once
For the reported ingestion and SQS/Lambda notification designs, assume at-least-once delivery. Make writes idempotent with a key per document or event, set a retry limit with a dead-letter queue, decide how failed items are replayed, and name the metrics you would watch (queue depth, age of oldest message, error rate) so a slowdown is visible before it becomes a backlog.
GRIT stories told in 'we' with no decision or result that belongs to you
Reported prompts ask about a mid-project scope change, balancing ideal architecture against a deadline, being challenged on a design, and owning an incident through post-mortem. For each, say what you decided, what evidence you used, and the measured outcome. If a teammate made the key call, say so and describe your part precisely.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Technical interviews test your ability to write clean, modular code, h…
Technical interviews test your ability to write clean, modular code, handle edge cases, and communicate your problem-solving process in real time.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Traversal and manipulation of hierarchical data structures, such as re…
Traversal and manipulation of hierarchical data structures, such as rendering nested document outlines or category trees.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Given an unstructured string or document payload, parse and extract va…
Given an unstructured string or document payload, parse and extract valid metadata tags while maintaining optimal time complexity.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Walk one small example through your approach before writing the whole thing.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Implement a rate limiter or sliding window mechanism to throttle incom…
Implement a rate limiter or sliding window mechanism to throttle incoming API requests for a high-volume service.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- State the target complexity and say which constraint rules the naive version out.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Describe how you would write Infrastructure-as-Code using Terraform to…
Describe how you would write Infrastructure-as-Code using Terraform to provision a resilient microservice cluster on AWS ECS.
Approach
- Identify the window where an invariant is briefly untrue.
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
Follow-up
- Where could this allocate more than you expect?
- What happens if two callers reach this at the same time?
Domain-specific questions evaluate your hands-on mastery of language f…
Domain-specific questions evaluate your hands-on mastery of language fundamentals, framework internals, and cloud infrastructure.
Approach
- Identify the window where an invariant is briefly untrue.
- Reach for the cheapest primitive that closes the race, not the broadest lock.
- Say what the runtime actually does before reasoning about the code.
Follow-up
- How would you prove the race exists rather than suspect it?
- What happens if two callers reach this at the same time?
Parse and verify a timestamped multi-signature webhook header
An inbound webhook carries a signature header of at most 1 KiB shaped t=<unix seconds>,v1=<64 hex chars>, with up to five v1 values during secret rotation and possibly unknown scheme keys. You hold the raw request body bytes and the currently active signing secrets. Write the parser and the verifier: accept when any active secret reproduces a signature and the timestamp is within a five-minute tolerance in either direction, reject otherwise. Single left-to-right pass over the header, no regular expression. State what is inside the MAC and why.
Approach
- Parse in one scan: split on
,, then on the first=only, since a value may itself contain=under a future scheme. Accepttexactly once and treat a secondtas a reject rather than last-wins. Push everyv1onto a short list and ignore any other key, so av2can be introduced later without breaking this verifier. - Say what is signed: HMAC-SHA256 over the exact byte string
<t>.<raw body bytes>, yielding 32 bytes or 64 hex characters. The timestamp sits inside the MAC because otherwise an attacker replays yesterday's body with its still-valid signature and only has to edit the header timestamp. - Hash the bytes as received. Verifying against a re-serialised JSON body is the usual defect: key order, whitespace and number formatting all change the bytes while the parsed objects compare equal, so signatures fail for honest senders and the popular 'fix' is to stop checking.
- Compare in constant time over fixed-length digests. Decode the hex to 32 bytes, accumulate
acc |= a[i] ^ b[i]across the whole length, and testacc == 0at the end. Evaluate every candidate without an early exit; at five candidates that is five HMACs over the body, linear in body size and negligible beside the network. - Apply the tolerance as a two-sided bound, rejecting when
|now - t| > 300seconds. A sender whose clock runs ahead of yours is an ordinary case, and an unbounded future timestamp is a free replay window. - Complexity: O(L) over the header producing k candidates, plus k HMACs at O(|body|) each. Space is O(k) beyond the body itself. Do the cheap rejections, including the tolerance check, before any cryptography runs.
Worked solution 15 min
- Write the grammar on one line before coding:
header := field (',' field)*,field := key '=' value, split on the first=only. - Implement the parser to return
{t: int, v1: [hex, ...]}, rejecting a missingt, a duplicatet, anyv1that is not 64 hex characters, and a header over 1 KiB, all before any cryptography runs. - Implement the verifier: for each active secret compute
HMAC-SHA256(secret, f'{t}.'.encode() + raw_body), compare it in constant time against each parsedv1, and OR the results with no early exit. - Test with a valid signature; the same body with
tmoved 400 seconds into the past; the same body witht400 seconds into the future; a header carrying an unknownv2=alongside a validv1; and a body re-serialised with different JSON key order.
Follow-up
- The body is 40 MB. What changes about where you verify, and what can you do before the whole body has arrived?
- A customer reports that signatures fail for exactly the requests whose body contains a non-ASCII character. What is your first hypothesis?
- How do you rotate the signing secret with no failed deliveries, and how long do both secrets stay live?
Enforce a concurrent-run quota that survives simultaneous requests
A plan allows at most 20 concurrently running rows in job_run per tenant. The table holds run_id, tenant_id, workspace_id, status (queued, leased, running, succeeded, failed, timed_out, cancelled, lost), lease_token, leased_until, started_at and finished_at. Today the service runs select count(*) from job_run where tenant_id = $1 and status = 'running', compares the result to 20, then inserts. Under load a tenant exceeds the cap by exactly the number of concurrent requests. Name the anomaly, say which isolation levels do and do not prevent it, and give a version that holds, as SQL.
Approach
- Name it: write skew. Each transaction reads a predicate (the count of running rows), neither modifies what the other read, and both then insert rows that jointly violate an invariant no single row expresses. Read committed permits it. So does repeatable read, because snapshot isolation's first-updater-wins check fires only on conflicting row updates, and these are inserts touching disjoint rows.
- Enumerate the fixes with their real costs. SERIALIZABLE works: PostgreSQL's SSI tracks the predicate read and aborts one transaction with SQLSTATE 40001, which obliges the caller to retry and makes the abort rate rise with contention on a hot tenant. Folding the predicate into the write as
insert ... select ... where (select count(*) ...) < 20narrows the race to the statement's snapshot but does not close it under read committed. - Give the version that holds at read committed: serialise on a row both transactions must touch.
update tenant_concurrency set running = running + 1 where tenant_id = $1 and running < 20 returning runningupdates zero rows when the cap is reached, and zero rows is the rejection. This works because at read committed a blocked UPDATE re-evaluates its WHERE clause against the newly committed row; at repeatable read the same statement raises a serialisation error instead, so the isolation level changes the calling contract. - State the cost you just bought. That row is now a per-tenant serialisation point, so admission throughput for the tenant is bounded by one divided by the lock hold time; at a 2 ms hold that is roughly 500 admissions/second. Keep the critical section to the single UPDATE, with no network call or scheduling decision inside the transaction, and decrement in the same transaction that writes the terminal status.
- Close the leak the status enum implies: a run can end as
lost, so a crashed worker otherwise consumes a slot forever. Reconcile on a schedule againststatus = 'running' and leased_until < now(), and treat the counter as a fast path overjob_run, which stays the system of record.
Worked solution 25 min
- Seed a tenant with 19 running rows, then fire 8 concurrent sessions each running the select-then-insert, and count the resulting running rows.
- Repeat at REPEATABLE READ and confirm the count still exceeds 20.
- Repeat at SERIALIZABLE, count the 40001 aborts, and note that without a retry loop those requests fail rather than queue.
- Implement the atomic counter UPDATE, re-run the 8-way test, and confirm exactly 20 running rows with zero over-admissions.
- Kill a worker mid-run, let the lease expire, and check whether the slot comes back without intervention.
Follow-up
- Write the retry loop for the SERIALIZABLE version. What does the caller see when it keeps aborting, and what bounds the retries?
- Two regions each keep a counter. What is the effective cap, and what does admission do when the counter store is unreachable?
- The cap changes mid-flight on a plan upgrade. Do running jobs get killed, and what does the counter row look like during the change?
Migrate a live partitioned event table without blocking ingest
usage_event is range-partitioned daily on ingested_at, holds roughly 250M rows per day across 400 live partitions, and is written at 10-40k rows/second. Two changes are required: quantity must move from double precision to numeric(20,6), and a new environment column must become NOT NULL with a default of 'production'. Ingest cannot stop. Give the ordered plan, naming for each step the lock it takes, what that lock blocks, and roughly how long it is held. Identify the one step that cannot be rolled back cleanly once traffic depends on it.
Approach
- Classify the two changes before planning anything. Adding a column with a non-volatile default has been metadata-only since PostgreSQL 11, so it is cheap. Changing double precision to numeric is not binary-coercible, so
alter column ... typerewrites every partition under ACCESS EXCLUSIVE and rebuilds its indexes; on this volume that is hours of blocked ingest and is simply not an option, which is why the plan is expand-and-contract rather than one statement. - Expand: add
quantity_numeric numeric(20,6)andenvironmentwith its default on the parent. Both are catalogue-only but both take a brief ACCESS EXCLUSIVE that cascades to partitions, so run each withlock_timeoutset to a second or two and retry on failure. A queued ACCESS EXCLUSIVE request blocks every reader behind it, which is how a metadata-only change turns into an outage. - Dual-write: deploy producer code that populates both columns on every insert, and leave it running before anything reads the new column. This is the step that cannot be reverted cleanly. Once readers depend on quantity_numeric, reverting the writer leaves rows with a null there, and the gap is only discoverable by re-reading the old column, which the readers have stopped doing.
- Backfill older partitions in batches keyed on the primary key, oldest first, committing every few thousand rows with a pause between batches, and skipping the partition still receiving writes until it rotates. Each batch is an ordinary UPDATE taking row locks only. The cost is bloat and WAL rather than blocking, so watch dead tuples and let autovacuum keep pace instead of wrapping 400 partitions in one transaction.
- Make NOT NULL cheap with the three-step form:
add constraint ... check (environment is not null) not valid(brief ACCESS EXCLUSIVE, no scan), thenvalidate constraint(SHARE UPDATE EXCLUSIVE, scans while reads and writes continue), thenset not null, which from PostgreSQL 12 uses the validated check and skips its own full scan. Do this per partition, then on the parent. - Switch and contract: move reads to the new column behind a flag, verify over a full period that both columns agree on freshly written rows, drop the old column (metadata-only), and only then remove the dual-write. Any index on the new column goes on with CREATE INDEX CONCURRENTLY per partition, since CIC is not supported on a partitioned parent: create the parent index with ONLY, build each child concurrently, then ALTER INDEX ... ATTACH PARTITION until the parent index becomes valid.
Follow-up
- A CREATE INDEX CONCURRENTLY fails halfway through the partition list. What state is the table in, how do you detect it, and what do you run?
- The producer computes quantity itself. What happens to a request already in flight when the dual-write deploy lands, and does it matter?
- Give two queries that prove the backfill is complete: one cheap enough to run every minute, one authoritative.
Architecture sessions assess how you build reliable, distributed syste…
Architecture sessions assess how you build reliable, distributed systems that scale safely under high throughput and real-world operational constraints.
Approach
- Name the failure you are designing for, then the recovery path.
- Name the read and write paths separately; they rarely have the same bottleneck.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How would you design an event-driven system using AWS SQS, Lambda, and…
How would you design an event-driven system using AWS SQS, Lambda, and ElastiCache to handle asynchronous content notifications?
Approach
- Name the failure you are designing for, then the recovery path.
- Name the read and write paths separately; they rarely have the same bottleneck.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What would you drop to keep the system up under load?
- What breaks first when traffic grows ten times?
An idempotent create endpoint that returns a one-time secret
POST /v1/api-keys inserts a tenant_api_key row (tenant_id, workspace_id, name, key_prefix, secret_hash, scopes, status, auth_version, created_at, expires_at) and returns the plaintext secret exactly once, since only its SHA-256 is stored. Write volume is tens per second and clients retry on timeout. Design the idempotency mechanism: what the key is scoped by, where the record lives, its retention, what happens when the same key arrives with a different body, what happens when a retry arrives while the first request is still in flight, and what a replay returns for the secret.
Approach
- Scope the key by tenant, not globally: uniqueness is on (tenant_id, idempotency_key), or one tenant's key collides with another's and the second caller receives a stored response for a request it never sent. Store a fingerprint of the request alongside it - method, path and a hash of the canonicalised body - so a mismatch is detectable.
- Let the unique constraint decide the race instead of application logic. In the same transaction as the credential insert, run INSERT INTO idempotency_record (tenant_id, key, request_fingerprint, status) VALUES (...) ON CONFLICT DO NOTHING RETURNING id; no returned row means this is a replay, and the existing record is then read. A select-then-insert here loses to itself under concurrency in exactly the way this endpoint is meant to prevent.
- Write the three replay outcomes as a decision table rather than as prose: same fingerprint and completed returns the stored response; same fingerprint and still in flight returns 409 with Retry-After, without blocking and without executing; different fingerprint returns 422, because replaying a stored response for a mutated body would tell the caller a credential was created for parameters it never sent.
- Handle the secret as the part that makes this endpoint different from an ordinary idempotent create. The plaintext cannot be regenerated from secret_hash, so either the stored response holds it - making the idempotency record a secret at rest whose retention is now the secret's exposure window - or a replay returns the key metadata without the secret and the documentation says a lost response is resolved by listing keys and revoking the orphan. The second is the safer default precisely because credentials are listable and revocable.
- Set retention from the client's retry budget, not from a round number: the record must outlive the SDK's maximum total retry duration, so twenty-four hours is defensible if that budget is minutes. After expiry the key is reusable and a very late retry creates a second credential, which is acceptable here only because the object is listable and revocable, and would not be for an unlistable side effect. Expire with a scheduled delete on an index over created_at.
Worked solution 20 min
- Write the DDL for the idempotency record, including the unique constraint that makes the concurrent case impossible rather than unlikely.
- Write the four outcomes - fresh, replay-completed, replay-in-flight, fingerprint-mismatch - as a decision table with the HTTP status for each.
- Decide what a replay returns for the plaintext secret and write the exact sentence the API reference has to carry about it.
- Pick a retention and justify it from the client library's own maximum retry duration rather than from a round number.
Follow-up
- Two requests with the same key arrive concurrently. Show the exact statements and say which one loses, and how it finds out.
- The client receives a timeout, retries, and gets 409 in-flight. What should the client library do next, and for how long?
- How does the design change if the created object is not listable - a one-off payout, say - so an orphan cannot be found afterwards?
Webhook workers leak until OOM and drop in-flight deliveries
webhook-delivery workers grow from 400 MB to a 2 GB limit over about 36 hours, are OOM-killed, restart, and repeat. Each restart abandons in-flight attempts, so webhook_delivery rows sit in in_flight until their leases expire and the backlog spikes. The live set measured after a forced full collection also grows. The fleet serves tens of thousands of subscriptions, several thousand of which have been failing for weeks. Give an ordered checklist, the measurement separating retention from fragmentation, and the fix.
Approach
- Separate the two failure shapes with one measurement: track resident set size against the live set after a forced full collection. A live set that climbs monotonically is retention; a flat live set under a rising RSS is fragmentation, off-heap or native allocation, or an allocator that never returns pages. The stated symptom puts this in the first category, which rules out allocator tuning as a fix.
- Characterise the curve rather than the total. Growth linear in uptime implies an unbounded structure keyed by something that keeps arriving; step growth implies buffering a large object. Correlate the slope against event rate and separately against the count of distinct subscriptions seen, because those two diverge and only one of them will fit.
- Diff two heap snapshots an hour apart by retained size grouped by dominant root, not by allocation count, which is dominated by short-lived objects and will point at the wrong thing.
- Expect a per-subscription map with no eviction: circuit-breaker or backoff state created on first failure and never removed, so the retained set grows with endpoints that have ever failed, and the several thousand permanently dead endpoints hold theirs forever.
- Fix in two places. Bound the in-memory structure with a size-capped LRU or a TTL keyed on last use, and move state that must survive a restart onto the subscription or webhook_delivery row, since the worker holding it in memory is exactly why a restart loses it.
- Repair the second-order damage separately, because it will outlive the leak: workers claim by compare-and-set with leased_until, so a bounded lease returns in_flight rows to pending on a known schedule, and a graceful shutdown releases leases instead of waiting them out.
Follow-up
- The backlog spike after a restart is itself a thundering herd against customer endpoints. What stops the recovery from becoming a second incident?
- Suppose the live set had been flat while RSS still climbed. Name two causes and the measurement that separates them.
- How would you size the LRU, and what does a miss on an evicted circuit-breaker entry cost a customer whose endpoint is down?
For someone who has spent the last few years shipping features and reading other people's code, and who has not solved a timed problem from a blank file in a long time. Five days rebuild the primitives and the patterns that sit on them, working from invariants rather than remembered solutions, and the last two attach that back to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Recruiter call and product groundwork
- Create an account and use Scribd, Everand and SlideShare as a reader: open a document, search, save something, and note where subscription access changes what you can see
- For each product flow you tried, sketch the backend it implies: a document viewer API, a search or recommendation call, an entitlement check
- Write your recruiter-call summary: languages, datastores, queues and cloud services you have used in production, plus your location and timeline constraints
- List the questions you will ask about team alignment (ML Data Engineering, Web API Platform, Signup & Activation) and which rounds lean toward APIs or pipelines
Deliverable: A one-page note with three product flows and their implied APIs, plus your recruiter-call summary and questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Coding: collection utilities and tree traversal
- Reimplement map, filter and reduce without built-in helpers, handling an empty input and reduce with and without an initial value
- Solve the bank's top K most frequently read books with a hash map plus a heap, and state when a full sort is simpler
- Render a nested document outline with indentation both recursively and with an explicit stack, then test on a deeply nested input
- Reverse a linked list iteratively and recursively and explain the space difference
Deliverable: Four solutions, each with its edge cases listed above the code and its time and space complexity stated.
Practice prompt ↗Practice prompt ↗Practice prompt ↗03Coding: parsing and sliding windows
- Extract valid metadata tags from an unstructured string in one pass, defining what makes a tag valid before you code
- Build a per-user sliding-window rate limiter and test the request that lands exactly on the window boundary
- Solve a sliding-window problem over words or characters that tracks frequencies, and write the window invariant above the loop
- Work the worked exercise 'Parse and verify a timestamped multi-signature webhook header' as practice for single-pass parsing with strict rejection rules
Deliverable: Three solutions narrated out loud from clarifying questions to complexity, plus the completed webhook-header exercise.
Practice prompt ↗Practice prompt ↗04Database fundamentals: pagination, indexing, query optimisation
- Compare offset and keyset pagination over a large table, write both queries, and name the index each one needs
- Take a Rails or Django view with an N+1 query, fix it with eager loading or a join, and say how you would confirm the improvement
- Design a many-to-many schema with a join table and composite primary key, then write the queries it has to serve
- Work the worked exercise 'Enforce a concurrent-run quota that survives simultaneous requests' to practise isolation levels and race conditions
Deliverable: A written pagination comparison, one before-and-after query fix, a schema with its queries, and the completed quota exercise.
Practice prompt ↗Practice prompt ↗Worked solution ↗05System design: ingestion and event-driven pipelines
- Design a high-throughput document ingestion and metadata enrichment pipeline: upload, queue, workers, retries, dead-letter queue, deduplication and replay
- Design the reported asynchronous content-notification system on SQS, Lambda and ElastiCache, stating what happens when a consumer fails mid-batch
- Add observability to both designs: the metrics, logs and alerts you would set up and what each would tell you
- Work the worked exercise 'An idempotent create endpoint that returns a one-time secret' to practise idempotency keys under retries
Deliverable: Two design diagrams with written failure handling and an alert list, plus the completed idempotency exercise.
Practice prompt ↗Practice prompt ↗06System design: API layers, subscriptions and caching
- Design a Web API platform layer between front-end clients and legacy microservices, covering contracts, pagination, rate limits and versioning
- Design a subscription entitlements API that supports access across Scribd and Everand, including how an upgrade or cancellation propagates
- Write a caching strategy for a high-traffic endpoint: what is cached, the key, the TTL, what invalidates it and what happens on a cache miss storm
- Prepare a short comparison of REST, GraphQL and gRPC for web and mobile clients, and a Python or Ruby answer on memory and concurrency in long-running jobs
Deliverable: Two API designs with explicit constraints, a caching plan, and a one-page notes sheet for the language and API-style questions.
Practice prompt ↗Practice prompt ↗07Behavioral and collaborative rounds
- Write GRIT-mapped stories for a mid-project scope change, an architecture-versus-deadline trade-off, a design challenge from a teammate, and an incident you owned through post-mortem
- For each story, mark the decision you personally made, the evidence you used and the measured result, and remove sentences that only say 'we'
- Rehearse a collaboration story with product partners (scope agreed, what was cut, how it was communicated) and a cross-team technical conflict
- Run a paired mock where a friend plays a teammate who challenges one of your design choices, and respond with evidence rather than repetition
Deliverable: Five stories rehearsed at a short and a long version, plus notes from one paired mock session.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Reported behavioral questions are framed around Scribd's GRIT framework (Goals, Results, Innovation, Team), and one reported prompt calls a mid-project scope change a 'plot twist'. Prepare four or five stories that each show a decision you made, the evidence behind it and a measured result. Keep yourself as the subject, name the trade-off you accepted, and be ready for a follow-up asking what you would do differently.
Describe a situation where you had to balance building an ideal softwa…
Describe a situation where you had to balance building an ideal software architecture against tight product deadline constraints.
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Pick a story where you made the decision, not one where you watched it.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- How did you know your change caused the improvement?
Disclose a cross-tenant webhook delivery to affected customers
An enqueue path took the subscription from one lookup and the payload from another. For nineteen minutes, webhook_delivery rows were created whose tenant_id did not match the subscription's tenant, and eleven payloads were signed and sent to four endpoints belonging to other customers. You hold payload_digest, delivery timestamps and response codes. Describe how you handle a disclosure of this kind: what the records prove, what they cannot prove, what you say before you know everything, the one code change that closes it, and which parts you personally drove.
Approach
- Bound the population before saying anything externally. The affected set is deliveries in the window where the event's tenant and the subscription's tenant differ; the ones that actually left are those with delivered_at set and a 2xx in last_response_code. Attempted and delivered are two different counts and a disclosure has to use the right one in the right sentence.
- Separate what the records prove from what they do not, and say both halves rather than the flattering one. They prove which payloads were signed, where they went, and — through payload_digest — exactly which bytes. They do not prove what the receiving system did with them, and they do not bound the window more precisely than your deploy timestamps do.
- Communicate on the facts you hold, with the scope stated as an upper bound: 'at most eleven payloads, four recipient endpoints, these fields, this window' is more useful and more honest than waiting a day for certainty. The field list matters more than the event count, because a customer cannot assess exposure from 'an event'.
- Name the code change precisely, because this class never originates in the delivery worker. Compare the event's tenant against the subscription's tenant at enqueue and again immediately before the payload is signed, and make the second comparison drop the delivery rather than log a warning. Say why one check is insufficient: the enqueue check protects against the bug you know about, the pre-signing check protects the boundary itself.
- Run the history question in parallel and say so: a query over historical deliveries for the same mismatch tells you whether this was nineteen minutes or a year, and you would rather find the second case yourself than have a customer find it after your disclosure.
- Split the response into workstreams with owners — recipients asked to delete, affected customers notified, the check landed with a test, history swept — and say which you personally drove and which you handed off. Claiming all four is not credible and claiming none is not ownership.
Follow-up
- The historical sweep finds two more instances from last year. What changes in what you have already told people?
- Who approves the wording, and what do you do when you are asked to soften the scope?
- A customer asks you to prove a redelivery contained the same bytes as the original. What do you show them?
Ship metered billing with a named deduplication horizon
Metered billing must be on in three weeks. usage_event is partitioned daily, so its unique index must include the partition key and deduplicates only within a day: a producer retry that crosses midnight, or a replay run a week later, gets through. A cross-partition dedup store is two weeks you do not have. Describe shipping with debt you named in advance: what you shipped, what you wrote down, the detector you added, the trigger and date for paying it off, and what you would have refused to ship under the same pressure.
Approach
- Show you can separate the two kinds of debt, because that distinction is what the question actually probes. Debt that costs engineering time later is shippable on a deadline. Debt that silently corrupts a number a customer gets charged for is not shippable unless the corruption is detectable, and detectability is the whole negotiation.
- Make the exposure narrow and measured rather than gestural. The hole is duplicates whose occurrences straddle a UTC day boundary, plus any replay older than partition retention. Measure it before arguing about it: how often an idempotency_key recurs at all, and the distribution of the gap between first and last occurrence. If the ninety-ninth percentile of that gap is four minutes, the residual risk is a small band around midnight and you can say so numerically.
- Add the detector before the feature, not after. A nightly job counting keys that appear in more than one partition is one grouped scan over recent partitions, and it converts a silent overcount into a page. State what it costs to run and what it fires on.
- Buy the cheap half of the real fix immediately: extend partition retention so the dedup horizon exceeds the producer's maximum retry window plus the longest replay you intend to support. That reframes retention as a correctness parameter rather than a storage cost, which is the sentence you need on record before someone optimises the bill.
- Make repayment mechanical instead of aspirational: a dated entry with a named owner, plus a threshold that pulls the date forward — first detector hit above N events, or first customer dispute. Debt with a trigger gets paid; debt with only a date does not.
- Answer the second half honestly by naming what you would refuse under identical pressure: the sealing path, because a sealed row is frozen and a wrong number there stops being a bug and becomes an adjustment line, a dispute and an audit question.
Follow-up
- The detector fires on forty duplicate events for one tenant, and two of their invoices have already sealed. What happens next?
- Whom did you tell that the billing numbers had a known hole, and in what words?
- Finance asks you to cut storage by shortening partition retention. What do you say, and to whom?
- 01
Tell me about a time when a project scope changed drastically mid-development and how you adapted your technical execution.
- 02
Describe a situation where you had to balance building an ideal software architecture against tight product deadline constraints.
- 03
How do you handle a scenario where an interviewer or teammate challenges your architectural design choices?
- 04
Walk me through a complex technical incident you owned from initial detection to root-cause post-mortem and remediation.
- 05
Give an example of a time you advocated for resolving technical debt when product managers wanted to push new user features.
- 06
Tell me about a project you owned end to end with ambiguous requirements: how you prioritised, what you measured, and what you would change.
Is this an official Scribd interview guide?
No. It is an independent preparation guide for the Software Engineer role at Scribd. Rounds and questions reflect what candidates have reported, not a process Scribd has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What rounds should I expect, and how long does the process take?
Candidates report four stages: a recruiter phone screen, a technical phone screen with live coding, a virtual onsite loop with coding, system design and behavioral modules, and collaborative interviews with future teammates and cross-functional partners. The reported end-to-end timeline is roughly 3 to 5 weeks, depending on scheduling. Ask your recruiter which modules your onsite includes, since source notes say the format can vary by team.
PracHub Software Engineer practice ↗How difficult are the technical interviews at Scribd?
Candidate-facing notes describe the technical rounds as practical rather than puzzle-based: data-structure problems of moderate to advanced difficulty and design questions built on databases, caches and message queues. The reported coding questions bear that out, with collection utilities, metadata parsing, a sliding-window rate limiter and tree traversal. Prepare to write clean, tested code and explain edge cases, rather than memorising obscure algorithms.
PracHub interview research ↗What programming languages can I use during the coding rounds?
The backend stack described in source notes is Python and Ruby on Rails, and the notes say candidates are generally free to use a modern language they are comfortable with in algorithmic rounds, such as Python, Ruby, Java, C++ or Go. Confirm with your recruiter, and note that language and domain questions ask about Python or Ruby internals specifically.
PracHub interview research ↗Can Software Engineers at Scribd work remotely?
Candidate-facing notes describe a flexible work model called Scribd Flex, under which you can work remotely if your primary residence is in an approved hiring hub in the United States, Canada or Mexico, with occasional in-person gatherings. Confirm your location on the recruiter call.
PracHub interview research ↗How should I approach the system design questions?
Start with clarifying questions, define the system's bounds, and state throughput and latency assumptions before drawing anything. Source notes specifically warn against unconstrained API endpoints: discuss pagination, rate limiting, payload size limits and query validation explicitly. For pipeline questions, cover retries, idempotency, dead-letter handling and the monitoring you would use.
PracHub interview research ↗How do I prepare for the Collaborative Interviews round?
Candidates describe meeting future teammates and cross-functional partners to work through simulated engineering problems. Practise solving a problem with someone rather than in front of them: ask for their view, adjust when they push back, and explain trade-offs in terms a product or design partner can act on. A story about agreeing scope with product, and one about resolving a technical disagreement, are useful to have ready.
PracHub Software Engineer practice ↗Should I study Scribd's products before interviewing?
Yes. Source notes suggest exploring Scribd, Everand and SlideShare before the technical rounds. Using each product as a reader helps you ground design and API answers in real features such as document viewing and content recommendations. As you go, note the APIs and data flows each feature implies.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Omnissa Software Engineer Interview Guide
Concurrency exercises for Omnissa candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
NetApp Software Engineer Interview Guide
Failure-handling practice for NetApp software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Nuro Software Engineer Interview Guide
Debugging practice for Nuro software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Palo Alto Networks Software Engineer Interview Guide
Timed practice for Palo Alto Networks software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.