Software Engineers at Moloco work on the systems behind its mobile advertising and commerce media products: real-time ad bidding, personalized recommendations, and ads data warehouse analytics. Platforms engineers work on include Moloco Commerce Media (MCM) and high-throughput ads data warehouses, with load measured in millions of queries per second and data in petabytes per day.
Reported day-to-day work for the role includes building low-latency APIs and backend services for real-time bidding and ad serving, optimizing ingestion and processing pipelines so telemetry is ready for ML model training, troubleshooting distributed-system failures and latency spikes in production, and working with product managers, data scientists and machine learning engineers to define requirements and deploy models. Design reviews, code reviews and operational planning are also part of it.
The reported interview questions follow the same themes. On the coding side: a custom hash map that counts ad-request frequencies, cycle detection in a linked list of user actions, substring matching over a stream of ad telemetry, DFS and BFS over a product category tree, and a revenue-maximization problem under budget constraints. On the design side: ad serving at 500,000 queries per second with sub-50ms latency, a petabyte-scale ads data warehouse, a distributed rate limiter for bidding services, cross-region consistency for real-time bidding, and a real-time recommendation pipeline.
Two kinds of preparation cover most of this. First, speed and accuracy on medium and hard coding problems, since the reported online assessment is 3 to 4 questions in 70 minutes. Second, the habit of opening every design answer with throughput, latency and consistency targets before drawing any components.
Recruiter Screen
reportedCandidates describe this as a conversation about background, career goals and compensation expectations. Candidates also report that recruiters may ask for salary expectations early and push for a number. Go in with a short account of the systems you have built and a range you have already decided on, so the call ends with a clear next step.
What to demonstrate
- Whether your background summary names specific systems and your part in them, not a list of technologies
- Whether your career goals line up with backend, data-pipeline or infrastructure work of the kind described for this role
- Whether you can give a compensation range with a stated split instead of deferring
How to prepare
- Write a short summary of your most relevant system: what it served, how much traffic or data it handled, and what you owned
- Decide a total-compensation range beforehand and name how you would split it across base, bonus and equity
- Ask the recruiter which level the loop is calibrated to and whether the onsite includes system design for that level, since design is reported for mid-to-senior roles and the number of rounds can vary with seniority and location
Online Coding Assessment
reportedCandidates report a CodeSignal assessment with 3 to 4 coding questions in 70 minutes. They describe the difficulty as coming from the time limit rather than from any single question. Time goes to half-remembered library calls, off-by-one loop bounds and random edits made to force a test to pass. Read every problem first, start with the one you can finish correctly fastest, and park any problem that stalls.
What to demonstrate
- Whether you reach a working approach quickly for medium and hard problems and write it without looking up standard-library calls
- Whether edge cases are handled as you write the code, not patched in at the end
- Whether you spread the time across all 3 to 4 problems instead of sinking it into one
How to prepare
- Practise sets of 3 to 4 medium and hard problems under a 70-minute limit, drawing on bank questions such as Support Dynamic Range Sums, Compute subarray span for each element, and Find single element when others repeat k times
- Write the library calls you use most from memory: sorting with a custom comparator, heap push and pop, string splitting, and deque operations
- When output is wrong, write down the smallest failing input and its expected and actual values before you change any code
Technical Phone Screen
reportedCandidates describe this as a live coding interview focused on technical skills. The reported coding questions, such as a custom hash map for ad-request frequencies, cycle detection and resolution in a linked list, substring matching over a telemetry stream, and DFS and BFS over a category tree, are good practice for it. Candidates report that subtle bugs and unhandled null or empty inputs are a common way to fail live coding, especially with linked lists, hash maps and substrings. Say your assumptions out loud, talk through your approach and its complexity before coding, and dry-run the code on edge cases before you call it finished.
What to demonstrate
- Whether you clarify input size, format and constraints before choosing a data structure
- Whether the code is correct on empty, single-element and boundary inputs
- Whether you explain your reasoning clearly and adjust when the interviewer pushes back
- Whether you can state and defend the time and space complexity of the final solution
How to prepare
- Implement a hash map with collision handling and resizing, and Floyd's cycle detection extended to find and break the cycle, both from a blank file
- Implement KMP or a rolling-hash matcher that keeps its state across chunk boundaries so a match split between two chunks is still found
- Practise in the editor or environment you will use so setup problems do not cost you time, and rehearse keeping the discussion moving yourself if the interviewer gives little direction
Virtual Onsite Loop
reportedCandidates report 2 to 3 live coding interviews, a system design interview for mid-to-senior roles, and a behavioral or hiring-manager discussion. For the design interview, frame every decision around scale, latency and resource limits, and be ready to trade off consistency, availability and latency. For the behavioral discussion, the reported behavioral questions (production debugging, ambiguous requirements, trade-off decisions, disagreements over architecture, learning a new domain quickly) are good material to prepare stories from.
What to demonstrate
- Whether your coding stays correct and well explained across several sessions, not just in one
- Whether a design answer starts from throughput, latency and data-volume targets and then justifies caching, queueing and storage choices against them
- Whether you say where you accept stale or eventually consistent data and what that costs
- Whether your behavioral stories name your own decisions, the evidence behind them, and the outcome
How to prepare
- Rehearse the reported ad-serving design question (500,000 queries per second, sub-50ms latency) with an explicit latency budget for each stage of the request path
- Rehearse the reported data-warehouse, rate-limiter, cross-region-consistency and recommendation-pipeline design questions, naming the partition key and consistency choice in each
- Prepare one production-incident story with the diagnosis, the fix and the prevention measure, plus one story each on ambiguous requirements and an architecture disagreement
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
Moloco Machine Learning Engineer Interview Experience — Ranking Design, Two Pointers, and ML Fundamentals
The phone screen was a conversation with the hiring manager that included a project deep dive and behavioral questions. The onsite included another project deep dive and a system design question related to ranking. The coding question used two pointers to find the longest consecutive run of 1s. The follow-up asked how to handle an especially long input across multiple machines. I was also asked a…
Read full experienceMoloco Data Scientist Interview Experience — A SQL and Open-Ended EDA Phone Screen, Rejected Days Later
Sharing an interview report for a niche ad company. A recruiter reached out to me on LinkedIn about an opening on a Product Analytics Data Science team. Before the interview they sent over a prep doc saying the technical phone screen would cover SQL + Python/R, with the focus on data manipulation, not modeling. The prep doc also mentioned they might ask about past project details and what I learn…
Read full experiencePracHub editorial advice for the preparation topics above.
Working the online assessment problems strictly in order and spending the time on one hard problem
Candidates report 3 to 4 questions in 70 minutes and say the time limit is what makes it hard. Read every problem before writing code. Start with the one you can finish correctly fastest, and decide beforehand when a stalled problem gets parked. Solving the easier problems first means you never finish with nothing correct. In practice sessions, track how much time goes to library lookups and debugging by random edits, and drill whichever costs you most.
Passing the happy path in live coding but missing null, empty or boundary inputs on linked lists, hash maps and substrings
Candidates report subtle bugs and unhandled null or empty inputs as a common way to fail live coding, especially with linked lists, hash maps and substrings. Before you call a solution finished, dry-run it on an empty input, a single element, and the case the structure is meant to handle: a self-loop or two-node cycle for linked lists, many keys in one bucket for a hash map, a pattern at the very start or end or split across a chunk boundary for substring matching. Say these cases out loud so the interviewer can see you checking.
Drawing an ad-serving or bidding architecture without a latency budget, throughput estimate or consistency choice
Some reported design questions come with numbers, such as 500,000 queries per second at sub-50ms latency or petabytes of daily logs; for the others, ask for the missing targets before designing. Restate the numbers you have first. Split the latency target across the stages of the request path, then choose caches, queues and storage to fit that budget. For cross-region and bidding questions, say which data must be current and where you accept staleness, and what goes wrong at the boundary you picked.
Answering the production-debugging prompt with a team story that has no timeline, root cause or follow-up
One reported behavioral question asks about debugging a critical production issue under tight time pressure. Prepare one real incident in order: what alerted you, what you ruled out and how, the root cause, the fix, and the change you made so it could not recur. Keep it in the first person and name what you decided, not what the team decided. Prepare the ambiguous-requirements and architecture-disagreement questions the same way, each with evidence and an outcome.
Reaching the recruiter screen without a compensation range or a clear account of your background
Candidates report that recruiters may ask for salary expectations early and push hard for a number. Settle a total-compensation range before the call, with base, bonus and equity named separately, so you can give a number instead of stalling. Pair it with a short summary of the systems you have built, so the conversation covers your background and not only the number.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Solve a multi-dimensional array optimization problem where you must ma…
Solve a multi-dimensional array optimization problem where you must maximize ad revenue under strict budget constraints.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- 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.
Follow-up
- What is the worst case, and how likely is it on real data?
- How does this change if the input no longer fits in memory?
Design an efficient system to track the frequency of specific ad reque…
Design an efficient system to track the frequency of specific ad requests using a customized hash map.
Approach
- 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.
- Restate the input: its shape, its size, and what is guaranteed about it.
Follow-up
- What is the worst case, and how likely is it on real data?
- How does this change if the input no longer fits in memory?
Given a linked list representing a sequence of user actions, implement…
Given a linked list representing a sequence of user actions, implement a method to detect and resolve circular dependencies.
Approach
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
- Restate the input: its shape, its size, and what is guaranteed about it.
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?
Implement a depth-first search (DFS) and breadth-first search (BFS) tr…
Implement a depth-first search (DFS) and breadth-first search (BFS) traversal to navigate a hierarchical category tree for e-commerce products.
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.
- 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?
- What is the worst case, and how likely is it on real data?
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
- Pin the comparison to a point in time or it reports lag as drift: consider only rows whose updated_at is older than now minus a lag margin, and re-check each candidate mismatch individually before repairing. At 1,200 writes per second a diff without this reports thousands of false positives, and an unattended repairer would then overwrite live rows with stale values.
- Make the run resumable and throttled: batch by range key, persist the last completed range, and watch a signal such as replica lag or primary CPU, pausing rather than pressing on. A reconciliation that cannot be stopped and resumed gets killed halfway and restarted from zero, which is how a repair becomes an incident.
Worked solution 35 min
- Compute the naive cost explicitly at 40,000,000 reads and 0.5 ms each, then at 100 concurrent, and state what those connections do to a pool already carrying 1,200 writes per second.
- Write the merge-join version over (tenant_id, resource_id) and state its memory.
- Define the range aggregate: the range key, the per-row hash input, and the combining function, with one sentence excluding XOR.
- Work an example with 40,000,000 rows, branching factor 256 and 5 differing rows, and count the ranges examined.
- Add the watermark filter and the resume point, and name the throttle signal the loop watches.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
- How would you run this continuously at low cost instead of only as incident response?
Denormalise tenant onto revisions and backfill it live
resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.
Approach
- Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
- Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
- Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
- Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.
- Step three, backfill: batch by primary key rather than by created_at so the cursor is dense and resumable — UPDATE resource_revision rr SET tenant_id = r.tenant_id FROM resource r WHERE r.resource_id = rr.resource_id AND rr.revision_id > $1 AND rr.revision_id <= $1 + 5000 AND rr.tenant_id IS NULL — committing per batch and persisting the cursor. Throttle on replica replay lag and on dead-tuple count, since each batch writes 5,000 new row versions. Run the backfill before the index exists so those updates can stay HOT.
- Step four, index then enforce then contract: CREATE INDEX CONCURRENTLY (cannot run inside a transaction block, scans the table twice, waits on open transactions, and leaves an INVALID index to drop concurrently if it fails); ADD CONSTRAINT ... CHECK (tenant_id IS NOT NULL) NOT VALID, then VALIDATE CONSTRAINT, which takes only SHARE UPDATE EXCLUSIVE, after which SET NOT NULL uses the validated check instead of re-scanning on PostgreSQL 12 and later. Only then move the audit reads onto the column and, in a later deploy, delete the join path.
Worked solution 40 min
- Write the five steps as separate scripts and state, for each, the lock mode it acquires and the deploy it pairs with.
- On a 20M-row copy, run the ADD COLUMN while a 30-second transaction holds a lock on the table, and record how long unrelated queries queue behind it.
- Run the batched backfill at 5,000 rows, kill it mid-run, restart from the persisted cursor, and confirm no row is processed twice and none is skipped.
- Build the index concurrently under concurrent write load, then add the CHECK ... NOT VALID, VALIDATE it and SET NOT NULL, timing each.
- Compare the audit-feed plan before and after: join-and-filter versus an index seek with no Sort.
Follow-up
- The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
- How do you verify the backfill actually finished, given rows are still being inserted while it runs?
- A resource must now be movable between tenants. What does that do to the composite foreign key and to the revisions already written?
Find version gaps and relay lag with window functions
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
- Interpret rather than report: no gaps plus a normal p95 of published_at - created_at points at the consumer; gaps or a fat lag tail point at the relay; rows still 'pending' with attempts > 0 point at neither, because they never left the database.
- Be explicit that the partial index on (created_at, event_id) WHERE status = 'pending' does not serve any of these — they read published rows. Name the index a recurring monitor would need, and say why a query run twice a year may not deserve one.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
- The consumer claims it never received event 4,812,006. What do you look at, in what order?
Design a real-time ad-serving system capable of handling 500,000 queri…
Design a real-time ad-serving system capable of handling 500,000 queries per second with sub-50ms latency.
Approach
- Choose a partition key and say what query it makes expensive.
- 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?
How would you architect a scalable ads data warehouse that ingests and…
How would you architect a scalable ads data warehouse that ingests and aggregates petabytes of daily event logs?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Choose a partition key and say what query it makes expensive.
- 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?
Relay committed events to the log without gaps or reordering
outbox_event rows are written in the same transaction as the state change and carry aggregate_type, aggregate_id, aggregate_version, payload and status, with a partial index on (created_at, event_id) WHERE status = 'pending'. The relay publishes about 4k events/second to a partitioned append-only log keyed by aggregate_id, with one leader per partition range holding a lease. Consumers must never miss an event; they may see one twice. Design the claim-publish-mark loop, and state exactly what consumers observe when a leader's lease expires while it is mid-batch.
Approach
- Claim with SELECT ... WHERE status='pending' ORDER BY created_at, event_id LIMIT $batch FOR UPDATE SKIP LOCKED inside a transaction. SKIP LOCKED lets several relay workers share a range without serialising on each other's rows, and the partial index keeps the claim proportional to the backlog rather than to a table that is overwhelmingly published rows. At 4k/second a batch of 500 is eight claims per second, each an index scan of 500 entries.
- Publish before marking, never the reverse, and say why it is a choice. Marking first loses the event outright if the process dies in the gap, and the loss is silent - nothing remains to retry, and it surfaces later as a projection missing a row. Publishing first can repeat the event, and repetition is what every consumer is already built to survive. That single ordering is the whole at-least-once guarantee.
- Preserve the only ordering on offer. Partition by aggregate_id and never publish two events for one aggregate concurrently: claim in (created_at, event_id) order and publish sequentially within an aggregate, or hash aggregate_id to a worker slot. Order across aggregates is not available at any price here, which is why the event carries aggregate_version and the full fact rather than a delta - a consumer can then discard what it has already applied without coordinating with anyone.
- State the failover behaviour precisely, because it is the consistency-versus-availability decision in this design. A lease expires because the holder is slow, and no mechanism distinguishes that from dead, so for the length of the lease window two leaders can publish the same claimed batch. The system accepts duplicates to avoid stalling publication for every aggregate in the range whenever one worker pauses. Consumers deduplicate on (aggregate_id, aggregate_version) and drop anything at or below what they have applied.
- Bound the failure paths and pick the right alarm. A row that fails to publish increments attempts, records last_error, and moves to 'dead' after a limit so one poison payload cannot block the backlog behind it. Alert on the age of the oldest pending row, not on the relay's error rate: the failure worth catching is a relay reporting itself healthy while nothing is being published.
Worked solution 25 min
- Write the claim statement and check it against the partial index: which columns it seeks on, how many entries it touches, and what two concurrent workers do to each other.
- Write both orderings of publish and mark, and for each state what exists after a crash at every point in the loop.
- Write the consumer's dedupe rule on (aggregate_id, aggregate_version) and test it against a replayed batch of 500.
- Compute the backlog after a 40-minute outage and the batch rate needed to drain it while 4k/second continues to arrive.
Follow-up
- The relay is down 40 minutes and 9.6 million rows are pending. What does catch-up do to the primary, and what changes in the claim loop to survive it?
- A consumer insists it never received an event. Which single query settles whether the relay lost it, and what does each answer look like?
- Delivery is at-least-once. What would exactly-once require end to end, and why is that a property of the consumer rather than of the relay?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
- Name the hazard the fix must not introduce. Serving a stale listing is acceptable only because the API reports the projection watermark, and a reader that loaded the old value before a write can repopulate the entry after the invalidation, so the bounded TTL is what actually caps staleness rather than the delete. Keep read-after-write pinned to the primary for the writing session regardless.
- Verify on miss concurrency, not hit rate. The hit rate barely moves, because the herd is one miss multiplied; the number that must change is distinct origin queries per key per minute.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
- What exactly does a client see during a stale-while-revalidate window, and how does the watermark let them tell?
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 done01Hash maps and linked lists from the reported coding questions
- Implement a hash map from scratch with separate chaining and a load-factor resize, then use it to count ad-request frequencies and answer frequency queries, following the reported custom-hash-map question. Be ready to explain your hash function and what many colliding keys do to lookup time.
- Solve linked-list cycle detection with Floyd's slow and fast pointers. Extend it to find the node where the cycle starts and break the link that closes the loop, which is one reading of the reported 'detect and resolve circular dependencies' question. Practise asking which reading the interviewer means.
- Test both on an empty input, a single node, a self-loop, a two-node cycle and a long list with no cycle, since candidates report linked lists and hash maps as where edge-case bugs catch them.
Deliverable: Two working implementations with a written list of edge cases and the time and space complexity of each.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Strings over a stream, and tree traversal
- Implement substring search with KMP or a rolling hash, then adapt it to a stream that arrives in chunks by carrying the matcher state across chunk boundaries. This matches the shape of the reported telemetry pattern-matching question.
- Implement iterative DFS with an explicit stack and BFS with a queue over a category tree. Write down when each fits: BFS for level-order output or the shallowest match, DFS for full-path questions.
- Solve Tree Column Order Traversal from the question bank using BFS with column indices, then test every traversal on an empty tree and a tree that is a single long branch.
Deliverable: A stream matcher that passes a boundary-straddling test, plus DFS, BFS and column-order traversals with their complexities.
Practice prompt ↗Practice prompt ↗03Optimization, backtracking and interval scans
- Treat the reported max-revenue-under-budget question as a knapsack variant. Define the state, write the recurrence, then cut memory by iterating the budget dimension in reverse for 0/1 choices. Add a second constraint dimension for the multi-dimensional version and state the complexity.
- Solve the bank's Backtracking Combination Problem (each candidate used at most once, unique combinations): sort first, then skip equal neighbours at the same recursion depth.
- Solve interval merging (Devise and Implement Algorithm, Coding Interview Mix) and greedy line wrapping (Sentence Breaking Into New Lines). Write the invariant each linear scan keeps before you write the loop.
Deliverable: Four solved problems, each with its recurrence or loop invariant written above the code.
Practice prompt ↗Practice prompt ↗04Online assessment simulation
- Run a full simulation in the reported format, 3 to 4 problems in 70 minutes, mixing this week's topics with bank questions such as Support Dynamic Range Sums, Compute subarray span for each element, and Find single element when others repeat k times.
- Read every problem before coding, order them by how quickly you can finish each one correctly, and park any problem that stalls without a working approach.
- Afterwards, sort the time you lost by cause (library lookups, off-by-one bugs, wrong approach, random-edit debugging) and re-drill the biggest cause.
Deliverable: A simulation log showing problems solved, time lost by cause, and one fix aimed at the largest loss.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Low-latency system design
- Design the reported real-time ad-serving system at 500,000 queries per second with sub-50ms latency. Open with clarifying questions, split the latency target across the stages of the request path, and say what you cache, precompute or drop when a stage runs over.
- Design the reported distributed rate limiter for bidding services. Compare token bucket with sliding window, decide where the counters live, and say whether the limiter fails open or closed when the counter store is down.
- Work the cache-stampede drill 'Read latency spikes on a sixty-second sawtooth', then add single-flight and TTL jitter to the cache layer of your ad-serving design.
Deliverable: An ad-serving design with a written latency budget per stage, and a rate-limiter design with its failure behaviour stated.
Practice prompt ↗Practice prompt ↗06Data pipelines and cross-region consistency
- Design the reported ads data warehouse for petabytes of daily event logs: queue-based ingestion, a partitioning scheme, pre-aggregated rollups for common queries, and a plan for late-arriving events.
- Design the reported real-time recommendation pipeline that updates user profiles from clickstream data. For the reported cross-region bidding question, decide which data must be current in every region and which can lag, and state what that choice costs.
- Work the existing worked exercises 'Relay committed events to the log without gaps or reordering' and 'Diff a projection against the primary without per-row point reads' for practice with at-least-once delivery and reconciliation.
Deliverable: Two pipeline designs, each naming its partition key, its consistency choice and the failure it tolerates.
Practice prompt ↗Practice prompt ↗07Behavioral stories, recruiter prep and a narrated mock
- Write STAR stories for the reported behavioral questions: a critical production issue under time pressure, ambiguous requirements, a complex trade-off decision, a disagreement with senior engineers over architecture, and learning a new domain quickly.
- Prepare for the recruiter screen: a short background summary and a total-compensation range with base, bonus and equity named separately.
- Run a mock live-coding session on one problem from Days 1 to 3. State your assumptions and complexity before coding, and dry-run edge cases before calling it finished.
Deliverable: Five STAR stories, a compensation range with its split, and a recording of one fully narrated solution.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report a behavioral or hiring-manager discussion in the virtual onsite. The reported behavioral questions focus on production incidents, ambiguity, trade-offs and disagreement. Structure each answer as Situation, Task, Action and Result. Keep the situation short, and spend most of the time on what you decided, what evidence you used, and what happened. Where a story involves a production failure, include the root cause and the prevention step you put in place.
How do you handle disagreements with senior engineers or stakeholders …
How do you handle disagreements with senior engineers or stakeholders regarding system architecture?
Approach
- Name the disagreement and how you resolved it with evidence.
- Close with what you would do differently, concretely.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Describe a situation where you had to quickly learn a new technology o…
Describe a situation where you had to quickly learn a new technology or domain to deliver a critical feature.
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.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Argue against a design, lose, and commit anyway
Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.
Approach
- State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
- Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
- Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
- Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.
- Report the outcome without editing it. If the design held and your predicted mechanism never fired, say so and say what you had mis-weighted, which is more persuasive than a vindication story.
Follow-up
- What threshold on that alert would have proved you right, and did anyone ever look at it?
- If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?
- How did you behave toward the design once it shipped and started failing in a different way than you predicted?
- 01
Describe a time when you had to debug a critical production issue under tight time constraints.
- 02
How do you approach designing a system when the initial requirements provided by product managers are highly ambiguous?
- 03
Talk about a complex technical decision you made on a past project. How did you evaluate the trade-offs, and what was the outcome?
- 04
How do you handle disagreements with senior engineers or stakeholders regarding system architecture?
- 05
Describe a situation where you had to quickly learn a new technology or domain to deliver a critical feature.
- 06
Describe a design you argued against and lost: the failure you predicted, the evidence you brought, and what you did after the decision was made.
Is this an official Moloco interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Moloco. Rounds and questions reflect what candidates have reported, not a process Moloco has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the Moloco online coding assessment?
Candidates report a CodeSignal assessment with 3 to 4 LeetCode-style questions in 70 minutes. They say most of the difficulty comes from the time limit, not from how complex each question is. To prepare, practise medium and hard problems under the same limit, learn your common library calls well enough to write them from memory, and handle edge cases as you write rather than at the end.
PracHub interview research ↗How should I prepare for the system design round?
Candidates report a system design interview in the virtual onsite for mid-to-senior roles. The reported design questions are: real-time ad serving at 500,000 queries per second with sub-50ms latency, an ads data warehouse for petabytes of daily event logs, a distributed rate limiter for bidding services, data consistency across global regions for real-time bidding, and a real-time recommendation pipeline. Practise stating throughput, latency and data-volume targets first, then justify caching, queueing and storage choices against them, and say which consistency trade-off you accept.
PracHub interview research ↗What coding topics come up in Moloco Software Engineer interviews?
The reported coding questions cover a custom hash map for counting ad-request frequencies, cycle detection and resolution in a linked list, substring matching over a stream of telemetry data, DFS and BFS over a hierarchical category tree, and a multi-dimensional optimization problem that maximizes revenue under budget constraints. The question bank adds interval merging, backtracking combinations, greedy line wrapping, tree column-order traversal, range sums and single-element detection.
PracHub Software Engineer practice ↗Does the interview loop change by level?
Candidates report that the number of rounds can vary with seniority and location, and the system design interview is reported for mid-to-senior roles. If you are earlier in your career, ask the recruiter whether your onsite includes design, and if it does not, shift more of your preparation to live coding.
PracHub Software Engineer practice ↗Which behavioral questions should I prepare?
The reported behavioral questions cover debugging a critical production issue under time pressure, designing with ambiguous requirements, a complex technical decision and its trade-offs, disagreements with senior engineers or stakeholders over architecture, and learning a new technology or domain quickly. Prepare one specific STAR story for each, with your own decisions and a measurable outcome.
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.
Qualcomm Software Engineer Interview Guide
Concurrency exercises for Qualcomm candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Motive Software Engineer Interview Guide
Prepare for the software engineer interview at Motive with original coding, system design and debugging exercises, each paired with a worked solution and the reasoning behind it.
Attentive Software Engineer Interview Guide
Debugging practice for Attentive 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.
Whatnot Software Engineer Interview Guide
Debugging practice for Whatnot 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.