A Software Engineer at adMarketplace sits at the intersection of high-scale data processing and sophisticated advertising technology. You are not just writing code; you are building the infrastructure that powers search advertising across a massive network of publishers and advertisers. The work requires a balance of high-performance backend engineering and intuitive frontend interfaces to manage complex data ecosystems.
This role is critical to the company’s ability to deliver relevant search results and optimized ad performance in real-time. You will work on systems that handle significant traffic, meaning your technical decisions directly impact the company’s bottom line and the user experience for millions. The environment is fast-paced, and success here requires a mindset that values both architectural elegance and the practical realities of a high-growth ad-tech business.
Recruiter Screen
reportedThe title covers product work, platform work, infrastructure, mobile and frontend, and those are different jobs with different loops behind them. A screening call is the cheapest place to find out which one the seat is, and asking reads as experienced rather than fussy. The questions that separate them: what the team is on call for, what the last three projects were, and whether any round happens inside an existing repository instead of a blank file. Then say which of that you have done and which you have not. Claiming the whole posting is the fastest way to be found out one round later.
What to demonstrate
- Whether you can locate your experience inside one flavour of the role honestly instead of claiming the entire requirements list
- Whether you name what you have not done, which an experienced screener reads as a level signal and can plan the loop around
- Whether what you want next matches what the seat is: someone who wants greenfield work landing on a team that mostly operates an existing system is a hire that leaves within the year
How to prepare
- Mark every line of the posting as done, adjacent or new, and write one sentence for each adjacent line naming the closest thing you actually built
- Split your last two years into rough percentages across feature work, operating and debugging live systems, and design or review, so a question about scope gets numbers rather than adjectives
- Bring three questions that discriminate between seats: what the team is paged for, how much of the work is changing existing code versus standing up something new, and what shipped in the last quarter
Hiring Manager Conversation
reportedExpect the estimate to be probed harder than the outcome. A manager asking how long something will take is checking whether your number covers the parts that reliably go wrong: migrating the rows that already exist, and the second service that has to change at the same time. A single confident number is the weak answer. The strong one states what the estimate assumes, names the unknown that could double it, and says what you would cut first if the date were fixed. Scope is the variable you control; hours are not.
What to demonstrate
- Whether an estimate arrives with its assumptions attached, including what it excludes and how much of it is waiting on review, environments or another team
- Whether you can name work you cut and the person you told, since a cut nobody heard about surfaces later as a surprise rather than a decision
- How you order two tasks that both look urgent, and whether that order survives being told the deadline moved in by a week
- Whether you separate what must be done before launch from what must be done before the thing can be left running unattended
How to prepare
- Take the last three things you shipped and write down, from memory, the estimate you gave and the time it actually took. Bring the largest miss and why it missed; a candidate who has never missed has never committed to a date.
- Against your current queue, write who is blocked until each item lands. Anything with nobody behind it becomes your worked example of what you would drop and how you would say so.
- Rehearse the fixed-date answer aloud: which slice ships, which slice is deferred and written down somewhere it will be found, and the one thing you would refuse to cut because removing it makes the release unsafe rather than smaller.
Technical Assessment
reportedThe same problem is scored by two different mechanisms depending on the format, and preparing for one does not cover the other. With a person watching, partial progress is visible and a hint is a correction you can absorb; silence is the expensive failure, because nobody can read a half-written function. With an automated grader there is no partial credit for what you were about to do, nobody to ask, and the worked examples in the prompt are the entire specification. Read them as a contract, down to whether an empty result should be an empty list or no output at all.
What to demonstrate
- In a live session, whether your commentary tracks what your hands are doing, and whether a hint redirects you or gets defended against
- In an automated one, whether you cover the cases the examples do not show, since the hidden cases are where the score moves
- Whether you manage the clock on purpose: abandoning an approach that is not converging while there is still time to write something simpler that finishes
How to prepare
- Have someone hand you a problem and feed you one deliberately wrong hint. Practise testing it against a concrete case instead of accepting or rejecting it on authority.
- Do one timed run a week in a plain browser editor with autocomplete, linting and your own snippets switched off, which is closer to what these environments give you
- For the automated format, write the harness before the solution: a main that feeds the worked examples plus an empty and a single-element case and prints expected against actual, so a wrong submission is caught by you first
Onsite/Virtual Loop
reportedCoding rounds mostly set a floor. They decide whether you clear the bar, not where you land on the ladder. Level tends to come out of the design discussion and the ownership stories, so the question worth auditing beforehand is whether the scope you describe matches the scope of the job. Work that stops at your own service, or a story whose hard part was writing the code rather than getting several people to agree on an interface, reads a level below where you think you are interviewing, and that gap is usually resolved downwards.
What to demonstrate
- Whether the largest thing you describe owning ran end to end — the decision, the migration path, the rollout, and what you did when it went wrong — or stopped at the change you merged
- Whether design answers include what you would not build, what you would defer, and what you would measure before committing, rather than only what the boxes are
- Whether a disagreement in a story was settled with something checkable — a benchmark, a prototype, a written proposal — instead of by seniority or by waiting it out
- Whether you can say which calls you made alone and which you escalated, and why the line sat where it did
How to prepare
- Write your largest piece of owned work as a timeline of decisions — who decided what, when, and what you did when the plan broke — then delete every sentence whose subject is "we" and see how much survives
- Take one system you know well and drill the migration answer: how old and new paths run side by side under live traffic, how you compare their outputs, what the rollback is once writes are going to both, and which step you would not automate
- Map each line of the ladder in the job posting to a specific thing you have done, find the line you cannot support, and prepare the closest evidence you have plus an honest account of the gap
PracHub editorial advice for the preparation topics above.
Treating the provider's device as the source of truth for state
The app is offline part of the time and buffers transitions, so events arrive late, out of order, and occasionally duplicated after a retry. A status column written last-write-wins will therefore accept 'started' after 'completed' and resurrect a cancelled booking, which re-enables charging on it. Client timestamps make it worse because the device clock is user-settable and drifts, so ordering by them is not ordering at all. The server must assign the ordering (a per-aggregate monotonic sequence) and every transition must be a guarded write against the expected current state, with the client event treated as a request to transition rather than as the transition.
Sharding by market_id and treating the partitions as comparable
Marketplace traffic is extremely skewed: the densest market can carry an order of magnitude more load than the median one, and within it a single venue at closing time or a transport hub at a flight bank produces a burst concentrated in a handful of cells. A hash on market_id gives an even key distribution and a wildly uneven load distribution, so one partition saturates while the fleet looks half idle, and the standard remedies collide with correctness: sub-sharding by cell breaks the single-writer-per-market property the dispatch loop relies on, so the 'one live offer per provider' rule has to be enforced globally by a constraint rather than by partition locality.
Going silent while thinking
Narrate the candidates and why you are discarding them, even in fragments: sorting first would make this a two-pointer scan, but it destroys the original indices, which the output needs. From the other side of the table, a candidate thinking hard and a candidate stuck are indistinguishable until one of them speaks.
Assuming the input fits in memory
Ask how large the input is in bytes before committing to an in-memory algorithm; beyond that point the options are a single streaming pass, an external sort with bounded buffers, or a sketch that trades exactness for constant memory. An algorithm that assumes random access to the whole input is a different algorithm from one that sees each element once.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you detect a loop in a linked list?
How do you detect a loop in a linked list?
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
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?
How would you find the intersection of two huge lists?
How would you find the intersection of two huge lists?
Approach
- 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.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
How do you differentiate between Vector and ArrayList?
How do you differentiate between Vector and ArrayList?
Approach
- 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.
- 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?
How would you find the middle of a linked list?
How would you find the middle of a linked list?
Approach
- Walk one small example through your approach before writing the whole thing.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Why the naive proximity scan fails at market scale
provider_presence holds 120,000 rows for one dense market, with lat, lon, cell_id, status and expires_at. The dispatch loop runs every 500 ms and, for each of up to 400 open requests, needs the ten nearest idle providers within 3 km. The obvious implementation computes a great-circle distance for every row and sorts. It returns the correct answer. Quantify why it cannot be shipped, give a design that holds a p99 under 30 ms, and state precisely what that design gives up.
Approach
- Cost it in numbers, not adjectives: 400 requests times 120,000 rows is 48 million distance evaluations per cycle, and at a 500 ms cadence that is 96 million per second, plus 400 sorts of 120,000 elements. The defect is not that the haversine formula is slow; it is that the work per request is proportional to fleet size while the whole dispatch budget is a couple of seconds end to end.
- Explain why no B-tree rescues it. The predicate is a function of two columns, so an index on lat, or a composite on (lat, lon), can restrict only the leading column and the rest is a filter. A degree bounding box is index-assisted on that leading column but over-selects: the square circumscribing a circle of radius r has area 4r^2 against the circle's pi*r^2, so under locally uniform density about 21 percent of the rows that survive the box fall outside the radius, (4 - pi)/4, and still need an exact second pass. Keep the two ratios apart: 4/pi - 1, about 27 percent, is how much more area the box covers than the circle — the extra work done, not the false-positive share of what comes back. Converting metres to a longitude delta divides by cos(latitude), which inflates the box toward the poles.
- Give two designs that work. In PostgreSQL: a geography column with a GiST index and ST_DWithin(pos, point, 3000), which is index-assisted, plus ORDER BY pos <-> point LIMIT 10 for ordered nearest-neighbour. ST_Distance(...) < 3000 written as a predicate is not index-assisted and is the version written by accident. Outside PostgreSQL: bucket on cell_id in an in-memory store and read the block of cells covering the radius, which keeps the candidate set in the low thousands.
- Argue the storage split with the write rate rather than by preference: 100,000 providers heartbeating every 4 seconds is about 25,000 writes per second, which is presence traffic competing for the same WAL as bookings, for state that is worthless 30 seconds later. Redis matches the durability this data actually needs: GEOADD stores members in a sorted set scored by a 52-bit interleaved geohash, and GEOSEARCH ... BYRADIUS reads it. Expiry has to be built rather than assumed, because a sorted set has no per-member TTL — EXPIRE applies to the whole key, and per-field expiry exists only for hashes, via HEXPIRE from Redis 7.4. Have each heartbeat also ZADD presence:seen <epoch_seconds> <provider_id>, sweep with ZRANGEBYSCORE presence:seen -inf (now - 30) and ZREM those members from both keys in one pipeline, and re-check the stored heartbeat at offer time so a member that outlived a missed sweep is still discarded. Snapshot periodically for analytics.
- State what is given up. Great-circle distance is a lower bound on road distance, so a radius prefilter on it never drops a provider whose road distance is inside the radius — the shortlist is admissible. Ranking on it is not defensible: it ignores rivers, one-way systems and the direction of travel. Shortlist by distance, then rank the shortlist by a routing ETA, paying that call on 50 candidates rather than 120,000.
- Name the residual failure modes so the design is not oversold: cell bucketing misses a provider just across a boundary unless the neighbouring cells are queried, and a radius that returns nothing must widen rather than fail — with a bounded number of widenings, because a request that expires unmatched is a first-class outcome, not an error.
Worked solution 30 min
- Write the naive cost: 400 x 120,000 = 48M distance evaluations per cycle, 96M per second at a 500 ms cadence, before the sorts.
- Assume the market spans about 40 km by 40 km, giving a density of 120,000 / 1,600 = 75 providers per square kilometre.
- Size a geohash-6 cell: 360 / 2^15 degrees of longitude is about 1.22 km and 180 / 2^15 degrees of latitude is about 0.61 km, so a 3 km radius needs about 3 rings east-west and 5 rings north-south, a 7 x 11 block of 77 cells.
- Compute the candidate set: 77 cells x 0.744 square kilometres each is about 57 square kilometres, so about 4,300 candidates, against the exact circle's pi x 9 = 28.3 square kilometres and about 2,120 providers.
- Compare: 120,000 / 4,300 is roughly a 28x reduction in rows scanned, with about half the survivors inside the true radius and needing the exact distance filter.
- Redo step 1 with a fleet of 12,000 to see where the naive plan becomes acceptable.
Follow-up
- At what fleet size does the naive version start meeting the budget again — show the arithmetic rather than guessing.
- The 3 km radius returns zero idle providers at 03:00; what does the loop do next, and when does it stop trying?
- Two dispatch partitions read the same idle provider from the index within one cycle — which layer prevents the double assignment, and why not this one?
Add a no-overlap reservation constraint to a live table
booking holds 400 million rows and takes roughly 1,200 writes per second. Rental and freelance bookings store start_at and end_at, and overlaps are currently prevented by an application-level select-then-insert that has produced 61 double bookings in six months. Add reserved_during TSTZRANGE and enforce non-overlap per listing_id across non-cancelled rows. Give the ordered migration, the exact statements, the lock each one takes, and say what you do about the step that has no concurrent path.
Approach
ALTER TABLE booking ADD COLUMN reserved_during tstzrange;— nullable with no default is catalog-only and does not rewrite the table, but it still takes ACCESS EXCLUSIVE briefly, and that request queues behind any open transaction while blocking every reader that arrives behind it. So each DDL statement runs withSET lock_timeout = '2s'and a retry loop. Reject the tidierGENERATED ALWAYS AS (tstzrange(start_at, end_at, '[)')) STOREDform: adding a stored generated column rewrites all 400 million rows under that lock.- Deploy dual-write before backfilling, not after. The application writes
reserved_duringalongsidestart_atandend_aton every insert and update; backfilling first leaves a growing gap of rows the backfill has already swept past. - Backfill by keyset pagination over the primary key in batches of a few thousand, one transaction per batch, pausing between batches:
UPDATE booking SET reserved_during = tstzrange(start_at, end_at, '[)') WHERE booking_id > $last AND booking_id <= $last + $n AND reserved_during IS NULL AND start_at IS NOT NULL;. Every touched row is rewritten, so this is 400 million dead tuples' worth of vacuum pressure and WAL; pace the batches against replication lag andn_dead_tuprather than running as fast as the database accepts. - Find the pre-existing violations before you attempt the constraint, because the 61 known double bookings will abort the DDL only after it has already built the entire index. Build
CREATE INDEX CONCURRENTLY booking_listing_range_idx ON booking USING gist (listing_id, reserved_during) WHERE status <> 'cancelled';(needsCREATE EXTENSION btree_gist), then self-join witha.listing_id = b.listing_id AND a.booking_id < b.booking_id AND a.reserved_during && b.reserved_duringand resolve each conflict as a product decision, not a data edit. - Confront the step with no concurrent path:
ALTER TABLE booking ADD CONSTRAINT booking_no_overlap EXCLUDE USING gist (listing_id WITH =, reserved_during WITH &&) WHERE (status <> 'cancelled');takes ACCESS EXCLUSIVE and builds its own index inline. There is noCREATE INDEX CONCURRENTLYequivalent,ADD CONSTRAINT ... USING INDEXaccepts only UNIQUE and PRIMARY KEY indexes, andNOT VALIDapplies to CHECK and foreign-key constraints, not to exclusion constraints. Either take a bounded window sized by a timed build on a sample, or get the invariant from aBEFORE INSERT OR UPDATEtrigger that first runsSELECT 1 FROM listing WHERE listing_id = NEW.listing_id FOR UPDATE, serialising writers per listing so the subsequent overlap check is safe. Say which you chose, and say that the trigger is the weaker of the two because it can be disabled and the constraint cannot. - Retire the old columns in a separate deploy: stop reading
start_atandend_atfirst, then drop them. Dropping them while any read path still uses them converts a reversible migration into an outage.
Follow-up
bookingis partitioned bymarket_id, and PostgreSQL does not allow an exclusion constraint on a partitioned table. What does a per-partition constraint actually guarantee here, and is it enough?- The backfill reaches row 180 million and replica lag hits 40 seconds. What do you change, and what do you deliberately leave alone?
- Half-open
[)or closed[]for the range: which did you choose, and what happens to a check-out at 11:00 followed by a check-in at 11:00 under each?
Model provider deactivation, audit history and erasure together
provider(provider_id, email CITEXT UNIQUE, compliance_state, payout_account_ref, legal_name, phone) is referenced by booking.provider_id and, through it, by ledger_entry. Three requirements land in the same sprint: support must deactivate and later reactivate a provider; a dispute six months later must show which compliance state was in force on a given date; and an erasure request must remove personal data while payout history stays reconcilable. A deleted_at column plus query filters is proposed. Give the schema, and say precisely what deleted_at alone breaks.
Approach
- Let the erasure requirement decide the layout, because it is the one that constrains the others. Split identity from personal data:
providerkeeps the surrogate key, compliance state,eligibility_versionand the payout reference, whileprovider_pii(provider_id, email, legal_name, phone)holds everything erasable. Erasure deletes or crypto-shreds that row;bookingandledger_entrycarry onlyprovider_id, so every historical sum stays reproducible and no ledger row is ever touched. - Enumerate what
deleted_atalone breaks, concretely rather than as a style objection.UNIQUE (email)now blocks the same person re-registering, so it must becomeCREATE UNIQUE INDEX ... ON provider_pii (email) WHERE deleted_at IS NULL. Every query silently includes deleted rows unless it remembers the filter, and the queries that forget are the aggregates nobody re-reads. Foreign keys still resolve, which is correct and is exactly why the row cannot be hard-deleted — and whyON DELETE CASCADEanywhere on this chain would destroy financial history. - Treat deactivation as a state, not a deletion: a value in the compliance state machine with legal transitions (
approved -> suspended -> deactivated -> approved), andeligibility_versionbumped on every change so dispatch re-reads eligibility at dispatch time instead of trusting a flag cached at login. A boolean cannot express reactivation at all, and a nullable timestamp can only express it by being nulled, which erases the history you were asked to keep. - Record the audit trail as an append-only table written in the same transaction as the state change:
provider_compliance_event(event_id, provider_id, from_state, to_state, actor_type, actor_id, reason, occurred_at).provider.compliance_statethen becomes a cache of the latest event rather than an independent fact. - Make 'what was in force on date D' a temporal query with a temporal structure:
provider_compliance_period(provider_id, state, valid_during TSTZRANGE)withCREATE EXTENSION btree_gistandEXCLUDE USING gist (provider_id WITH =, valid_during WITH &&). The open period has an unbounded upper bound, and the dispute query isWHERE provider_id = $1 AND valid_during @> $d, which the GiST index serves. Closing one period and opening the next must happen in a single transaction, or the constraint rejects the overlap — which is the constraint working, not an obstacle. - State the cost honestly: three artefacts now describe the same state, so nominate one writer. Either the application writes the event and a trigger maintains the period and the cached column, or the period table is derived by a job from the event log; say which, and say what a crash between two of them leaves behind.
Worked solution 40 min
- Write the DDL for all four tables, including the exclusion constraint and the partial unique index on email.
- Insert a provider, then suspend, reactivate and deactivate them, producing four periods, and query the state at three different instants.
- Attempt to open a new period without closing the previous one and observe the failure.
- Delete the
provider_piirow and re-run a payout sum for a historical period, comparing it byte for byte with the pre-erasure result. - Re-register a new provider with the erased email, and separately with a live provider's email.
Follow-up
- A partial unique index's predicate must be immutable. Why can it not be
WHERE deleted_at > now() - interval '30 days', and how would you express a 30-day grace period instead? - Erasure removed the email, and a chargeback then arrives on a two-year-old booking. What can you still do, and what can you no longer do?
- Who writes
provider_compliance_period— the application, a trigger on the event table, or a batch job? Defend the choice against a crash mid-transition.
How does serialization work in Java?
How does serialization work in Java?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Work from the requirement backwards to the design.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Explain the synchronized keyword in Java.
Explain the synchronized keyword in Java.
Approach
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer contains.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Specify the idempotency contract for booking creation from a quote
POST /bookings binds a consumer to an existing quote: the body carries quote_id, request_id and a tokenised instrument. The server authorises against the payment gateway and inserts a booking row; booking has UNIQUE (request_id) and quote rows are immutable with an expiry. The caller is a mobile client with a 10 s timeout that retries twice. Specify the idempotency contract: where the key comes from, what is persisted and at what point, the response when the same key arrives with a different body, the response while the first call is still in flight, and the retention floor.
Approach
- Tie the key to the user's intent, not to the HTTP attempt: the client mints a UUID when the consumer taps confirm, stores it, and replays it on every retry of that tap. A key generated per request defeats the whole mechanism while leaving it visibly in place, which is the failure mode that survives code review.
- Persist the key before doing anything external. Insert an idempotency record with a UNIQUE constraint on the key and a status of in_progress, and commit that before calling the gateway - if it is written after the call, a crash in between leaves a charge with nothing pointing at it. Store a fingerprint alongside it: a hash over the canonicalised fields that must not change, here quote_id, request_id and the instrument token.
- Define the three arrival cases precisely. A new key runs the operation. A known key whose fingerprint matches and whose record is completed replays the stored status code and body byte-identically, including when that status was a 4xx. A known key whose fingerprint differs is refused with 422 and a distinct code, without executing - the client has reused a key for a different intent, and guessing which one it meant is how you double-book.
- Handle the in-flight case explicitly rather than by waiting: return 409 with Retry-After: 1 and a code the client can act on. A 202 invites the client to move on as though a booking exists, and blocking the second request until the first finishes just moves the timeout.
- Set retention from the client's behaviour, not from taste: the record must outlive the longest retry horizon the client can produce plus the gateway reconciliation lag for unknown outcomes, so 24 hours is a floor here, held in a TTL-partitioned table. Note the interaction with quote expiry: a replay must return the stored response and must not re-validate the quote, because the booking already exists and re-checking an expired quote would turn a successful retry into a spurious failure. UNIQUE (request_id) is the backstop for a client that loses its key entirely - map that violation to the existing booking's representation rather than a 500.
Worked solution 30 min
- Write the key provenance rule and the exact moment the client generates and discards a key.
- Implement the reservation insert with its UNIQUE constraint, committed before the gateway call, and the read-back path on conflict.
- Define the fingerprint over the canonicalised triple and the 422 refusal on mismatch.
- On completion, write the status code, response body and booking_id in the same transaction that flips the record to completed.
- Exercise three interleavings: a sequential retry after a timeout, two concurrent requests sharing a key, and a replay issued after the quote has expired.
Follow-up
- The gateway call times out and the record stays in_progress forever because the process died. What sweeps it, and what does the endpoint return in the meantime?
- The consumer taps confirm twice deliberately, wanting two bookings. How does the contract tell that apart from a retry?
- Where does the idempotency record live relative to the booking row, and what breaks if they are in different databases?
Quote latency spikes every sixty seconds during a demand-signal outage
The demand multiplier is cached per (cell, tier) with a 60-second TTL and refreshed from an aggregator. The aggregator starts returning 504s for about 30% of cells. Quote p99 goes from 40 ms to 3.1 s in a sawtooth with a 60-second period, aggregator load triples although request volume is flat, and the dispatch loop begins missing its two-second budget so accept windows are wasted. Each refresh retries three times with a two-second timeout. Give the ordered checklist, the two independent defects, and the degraded behaviour you ship.
Approach
- Chart cache hit rate per cell at one-second resolution first. A sawtooth whose period equals the TTL is the signature of synchronized expiry -- entries written together by a warm-up or by an earlier mass refresh expire together -- and it distinguishes a stampede from a dependency that is merely slow, before you touch the dependency at all.
- Then put origin call rate next to incoming request rate. Load tripling while requests stay flat is retry amplification, not demand: three attempts per miss, and each concurrent miss on the same key mounts its own set of attempts because nothing coalesces them. The multiplier falls straight out of the ratio.
- Then characterise the dependency's failure shape -- which cells, which regions, whether the 504s are uniform or concentrated. A partial failure across 30% of cells is a different incident from a whole-region loss, and the correct degraded behaviour differs between them.
- Separate the two defects, because fixing either alone leaves the incident standing. First, there is no single-flight, so N concurrent misses on one key produce N origin calls rather than one. Second, refresh treats an error as absence and evicts, so a failing dependency empties the cache instead of leaving it populated. Independently each is survivable; together they convert a 30% dependency failure into a cache with a near-zero hit rate.
- Ship the degraded behaviour explicitly rather than leaving it implicit. Serve the last known multiplier past its TTL under a bounded staleness ceiling, and once that ceiling is exceeded fall back to the base rate rather than to the last surge value -- charging a multiplier you can no longer justify is the asymmetric error and it surfaces as disputes and chargebacks rather than as an alert. Add per-key single-flight, jitter the TTL so entries stop expiring in lockstep, and replace per-call retry counts with a retry budget capped as a fraction of total calls behind a circuit breaker.
- State what does not change, because this is the part people break while fixing the rest. Quotes already issued are immutable and stay honoured for their full lifetime; the booking binds to quote_id, so the degraded path must never reprice a booking already bound to one. A quote that expires mid-flow is a user-visible re-quote, not a silent background refresh.
Follow-up
- Single-flight makes one caller wait on the origin. What does that waiter do when the origin exceeds the dispatch budget, and who decides -- the cache or the caller?
- You choose a five-minute staleness ceiling. Justify the number against what the multiplier actually does over five minutes in a dense cell.
- The aggregator recovers. Describe the recovery traffic and what stops it from becoming a second stampede.
Four days sample coding, design, fundamentals and the practical rounds at deliberately shallow depth, which is enough to surface the topics you did not know were in scope. That map, rather than a guess made on day one, decides where the last three days go.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Coding, one pass at shallow depth
- Solve one problem from each of six families, an array with two pointers, hash counting, binary search, a tree traversal, a graph traversal and one dynamic program, under a hard twenty-minute cap with no extensions, marking each finished, late, or stalled.
- For every stall, write the exact move you could not make rather than the subject, so the note reads could not turn the recurrence into a loop rather than bad at dynamic programming.
- Fix nothing today. The value of the pass is the unfixed record.
Deliverable: Six timed attempts marked finished, late or stalled, each stall carrying a named blocking move.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Design, one pass at shallow depth
- Spend twenty minutes each on three different shapes, a read-heavy feed, a write-heavy ingest path, and something needing a transaction across two entities, stopping each at requirements, interface and data model.
- After each, write the first question you could not answer, which is usually a number you could not estimate or a failure mode you had no vocabulary for.
- Mark which of the three you would be most relieved not to be asked, and treat that as data rather than as a preference.
Deliverable: Three shallow designs, each with the first unanswerable question written at the bottom.
Practice prompt ↗Practice prompt ↗03Fundamentals and the practical rounds
- Answer eight short questions in writing at four minutes each, covering the material that fills the gaps between the big rounds: what happens between a URL and a rendered page, what an index costs on write, when a process is preferable to a thread, and what conditions a deadlock requires.
- Do one thirty-minute practical task of the kind a take-home compresses: read an unfamiliar two-hundred-line file and write what it does, what you would change, and the one thing you remain unsure of.
- Score every answer fluent, correct but slow, or absent, and keep the absent ones visible.
Deliverable: Eight scored short answers and one written reading of unfamiliar code.
Practice prompt ↗Practice prompt ↗04The rounds that are about you, and the map
- Deliver three behavioural answers aloud against a timer, a conflict, a failure you owned, and a decision made without enough information, marking any that ran past three minutes or contained no number.
- Assemble the map: every marked item from days one to three on a single page, sorted by how likely it is to appear in your loop rather than by how uncomfortable it felt.
- Choose exactly two areas for the remaining three days and write down what you are deliberately abandoning.
Deliverable: A one-page scored map of the whole surface area with two areas chosen and the rest explicitly abandoned.
Practice prompt ↗Practice prompt ↗Worked solution ↗05First chosen area, to the depth you skipped
- Work the higher-ranked area in four focused blocks, choosing items one level above where you stalled rather than repeating what already works.
- After each block write the rule you extracted in one sentence with its precondition attached, since a rule carrying no precondition is exactly what fails under a variation.
- Re-attempt the day-one or day-two item that exposed this area and compare against the original timing.
Deliverable: Four worked blocks, a timed re-attempt against the original, and three one-sentence rules with preconditions.
Practice prompt ↗Practice prompt ↗06Second chosen area, where the gap is coverage rather than speed
- Treat the second area differently from the first. Day five drilled something you could already half-do; this one is usually a topic you had simply never met, so build one worked reference example end to end and keep it, rather than attempting six problems badly.
- Write down the vocabulary you were missing on day two or three, five terms at most, each with the one sentence that makes it usable in an answer rather than the textbook definition.
- Redo the shallow attempt that exposed this area and note whether you now fail later in the problem, because moving the failure point is the realistic gain from a single day and is worth more than a score that did not change.
Deliverable: One worked reference example for the newly covered area, a five-term vocabulary list, and a note on where the failure point moved.
Practice prompt ↗Practice prompt ↗07Reassemble the loop
- Sit two rounds back to back with no gap, ordering them so the area you chose second comes last, because the map was built from rested, isolated attempts and the loop will reach your weaker area when you are already spent.
- Write where the second round suffered from the first, which is normally the point at which structure collapses into narration.
- Reduce the week to one page holding only the rules you can state without reading them.
Deliverable: Mock notes on cross-round carryover plus a one-page card of rules you can recite from memory.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Keep one story where the bad call was yours rather than a dependency's or a manager's. Name the check that would have caught it, whether you added that check afterwards, and whether it has fired since. Answers that route blame outward end the conversation early; answers that end in a guardrail someone still relies on tend to open it up.
What is your experience with building microservices?
What is your experience with building microservices?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- What did you decide not to do, and why?
- How did you know your change caused the improvement?
How do you communicate technical decisions to non-technical stakeholde…
How do you communicate technical decisions to non-technical stakeholders?
Approach
- Close with what you would do differently, concretely.
- 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.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
Unblocking a stuck engineer without taking the keyboard
Describe a time you unblocked someone who had been stuck for more than a day. Say how you learned they were stuck, what you diagnosed the real blocker to be - missing context, a wrong mental model, a genuinely hard bug, or reluctance to ask - and what you actually did. State explicitly whether you took the keyboard and what that cost. Then say what changed so the next person is not stuck in the same place: a document, a test, a renamed function, a constraint that turns the mistake into an error.
Approach
- Diagnose the blocker type first, because the responses diverge sharply. Missing context is a five-minute fix; a wrong mental model has to be corrected out loud and checked; reluctance to ask is a team-norm problem you cannot solve in one sitting and should not pretend you did.
- Describe the intervention at the level of what you said or drew - the interleaving you sketched, the question that surfaced their hidden assumption - rather than the word 'pairing', which conveys nothing about what you contributed.
- Be explicit about taking the keyboard. It is sometimes right under time pressure and it always trades their learning for your speed. Naming the trade is the difference between mentoring and rescuing.
- Verify the unblock rather than assuming it: did they finish it alone, did they hit the same wall a fortnight later, did they later explain it to someone else. That last one is the strongest available evidence.
- Name the durable artifact. A mentoring answer with no residue describes one act of help; the leverage is in the test, the comment, or the constraint that makes the same confusion impossible next time.
Follow-up
- How long did you let them struggle before stepping in, and how did you choose that duration?
- What did you get wrong about why they were stuck?
- When is taking the keyboard the correct call rather than the easy one?
- 01
What is your experience with building microservices?
- 02
How do you communicate technical decisions to non-technical stakeholders?
- 03
Describe a time you unblocked someone who had been stuck for more than a day. Say how you learned they were stuck, what you diagnosed the real blocker to be - missing context, a wrong mental model, a genuinely hard bug, or reluctance to ask - and what you actually did. State explicitly whether you took the keyboard and what that cost. Then say what changed so the next person is not stuck in the same place: a document, a test, a renamed function, a constraint that turns the mistake into an error.
Is this an official adMarketplace interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at adMarketplace. Rounds and questions reflect what candidates have reported, not a process adMarketplace has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult is the interview process?
Candidates generally report an average level of difficulty. The process is thorough, focusing on both your technical depth and your ability to fit into a fast-moving, collaborative culture.
PracHub interview research ↗What is the timeline from screen to offer?
The process can vary, but expect a multi-week engagement. Given the potential for communication delays, stay proactive and keep interviewing elsewhere until you have a signed offer in hand.
PracHub interview research ↗What differentiates successful candidates?
Successful candidates are those who can clearly articulate the reasoning behind their technical decisions and demonstrate a genuine interest in the specific challenges of the ad-tech industry.
PracHub interview research ↗Are the interviews remote or onsite?
While processes have shifted, expect a mix of virtual and potentially onsite interviews. Always clarify the format with your recruiter early in the process.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Times Internet Software Engineer Interview Guide
What Times Internet asks Software Engineer candidates, from reported rounds and questions.
Envestnet Software Engineer Interview Guide
What Envestnet asks Software Engineer candidates, from reported rounds and questions.
Turo Software Engineer Interview Guide
Take-home style practice for software engineers preparing for Turo: build a small service against a fixed time budget, then write down what you left out and why a reviewer should accept that.
Spectrum Software Engineer Interview Guide
A study plan for Spectrum software engineer prep built on spaced review: commit to a full answer before opening any solution, and repeat every missed exercise three days later.