Instacart Coding Interview Questions: Marketplace, Substitutions, and Batching

It is tempting to lump Instacart in with every other delivery app. The engineering problems are different enough that doing so will cost you in the interview. Instacart is a grocery marketplace connecting three groups: customers who build a basket, shoppers who pick and deliver it, and retailers whose stores and catalogs supply the items. A grocery order is not one sealed bag waiting at a counter. It is often dozens of individual items, any of which might be out of stock by the time a shopper reaches the aisle - and that single fact drives much of what Instacart engineers work on.

This guide covers the loop candidates commonly describe, the marketplace thinking that runs through it, the types of problems worth preparing, and a two-week plan. As with all our company guides, we describe representative patterns rather than publishing invented "leaked" questions, because question sets rotate and pattern fluency is what transfers.

The Instacart engineering loop

Candidates typically describe a process shaped roughly like the table below. The stages, their order, and the tools vary by team and level, and processes change, so confirm your specific schedule with your recruiter.

Ask your recruiter whether coding rounds use a shared editor or your own environment, whether code is expected to run, and which team area - shopper experience, catalog, ads, fulfilment, or another - the role belongs to. The answers change how you should practice.

The three-sided marketplace, and why it shows up everywhere

The fastest way to sound like an Instacart engineer is to reason about all three sides at once. Almost every design or product-flavored question involves a tension between them:

• Customers want the right items, sensible substitutions when something is missing, accurate prices, and a delivery window they can trust.
• Shoppers want batches and routes that make their time worthwhile, clear item locations, and fast answers when something is out of stock.
• Retailers want their catalog and inventory represented accurately, their brand respected, and tools - including ads and promotions - that drive sales.

A strong candidate names the trade-off explicitly. Batching more orders together helps shopper efficiency but can stretch delivery times for customers. Showing more items as available lifts basket size but increases the chance of a disappointing substitution. Saying which side you would favor in a given case, and why, is the kind of judgment interviewers look for.

Topic emphasis for the coding rounds

Prioritize roughly in this order:

• Hash maps and sets. Basket aggregation, catalog lookups, deduplicating products from different retailer feeds.
• Sorting and intervals. Delivery windows, shopper availability, and overlapping time slots - practice the merge intervals pattern until it is automatic.
• Heaps and greedy algorithms. Assigning work to limited capacity and picking the best next option.
• Graphs. Traversal and shortest paths on small networks, the building blocks behind routing questions.
• String and data parsing. Normalizing messy product data such as names, sizes, and units.
• Clean object modeling. Orders, items, shoppers, and batches expressed as clear types you can extend when requirements change.

Because rounds are commonly described as practical, run your solutions and write a quick test for the tricky case. Our LeetCode patterns guide covers the underlying fundamentals; spend the remaining time building small components end to end.

Domain themes: availability, substitutions, batching, and ads

For mid-level and senior roles, design discussions commonly draw from Instacart's actual problem space. You do not need insider knowledge - you need to reason clearly about data, uncertainty, and trade-offs.

Real-time item availability

Retailer inventory data is often incomplete or delayed, so "is this item on the shelf right now?" becomes a prediction rather than a lookup. Think about the signals you would use - recent shopper found or not-found events, time of day, store and item history - how fresh they need to be, and what the customer sees when confidence is low.

Substitutions

When an item is missing, which replacement will the customer accept? Consider customer preferences and approvals, product similarity by brand, size, and category, price differences, and how the shopper and customer communicate in real time. Our recommendation system design walkthrough is useful background for the ranking side.

Shopper batching and routing

Grouping several customer orders into one shopper trip is a capacity and scheduling problem layered on a routing problem: delivery windows must be compatible, the items must fit, and the path through the store and then to each address must be sensible. Expect to discuss greedy heuristics versus optimization, and how often to re-plan as new orders arrive.

Ads and catalog data

Retailers and brands supply huge, messy catalogs, and sponsored product placements sit inside search and browse results. Design prompts here tend to involve ingesting and normalizing catalog feeds, matching the same product across retailers, and serving and measuring ads without degrading relevance. For the measurement pipeline, see our ad click aggregator design, and use our system design reference to refresh queues, caching, and storage choices.

Representative problem types

These are the kinds of problems candidates commonly describe, given as categories so you prepare the pattern rather than one prompt:

• Basket and catalog aggregation. Combine line items, apply quantity and unit rules, or merge product records from multiple sources.
• Time-window scheduling. Merge delivery windows, find a feasible slot, or detect conflicts in a shopper's schedule.
• Capacity-constrained grouping. Pack orders or items into batches under limits on size and time.
• Ranking with a heap. Pick the top candidates - substitutions, nearby shoppers, or best-matching products - by a scoring function.
• Build and extend a component. Implement a small class such as an order tracker, then add requirements as the interviewer introduces them.
• Marketplace design (experienced roles). Availability prediction, substitutions, batching, catalog ingestion, or ads serving.

Here is the flavor of the capacity-constrained grouping type: a simple greedy that batches orders for one shopper when their delivery windows share a common overlap and the combined item count stays within capacity.

def batch_orders(orders, capacity):
    # orders: list of (order_id, window_start, window_end, item_count)
    batches, current = [], []
    load, shared_start, shared_end = 0, None, None

    for order_id, start, end, items in sorted(orders, key=lambda o: o[1]):
        overlap_start = start if not current else max(shared_start, start)
        overlap_end = end if not current else min(shared_end, end)
        fits = current and overlap_start < overlap_end and load + items <= capacity

        if fits:
            current.append(order_id)
            load, shared_start, shared_end = load + items, overlap_start, overlap_end
        else:
            if current:
                batches.append(current)
            current, load, shared_start, shared_end = [order_id], items, start, end

    if current:
        batches.append(current)
    return batches

The strong answer is upfront that this is a heuristic, not an optimal packing: sorting by window start gives O(n log n) and a reasonable result, but it can miss better groupings. It then covers edge cases - an order larger than capacity on its own, windows that touch but do not overlap - and offers follow-ups: weighting by store location, limiting batch size for customer experience, or re-batching when a new order arrives.

What interviewers actually score

• Working code. Complete, runnable solutions with sensible structure, not pseudocode.
• Handling new requirements. A design that absorbs the follow-up without a rewrite.
• Marketplace judgment. Seeing how a decision affects customers, shoppers, and retailers.
• Comfort with uncertainty. Treating availability and timing as probabilities, and designing for being wrong.
• Ownership. Behavioral and project stories where you drove an outcome and worked across functions.

A note on integrity: prepare thoroughly and reason honestly in the room. Practical rounds invite follow-up questions about why your code works, and real understanding holds up where a memorized answer does not.

A realistic two-week prep plan

1. Days 1-3: Fundamentals - hash maps, sorting, and strings. Run every solution and test the edge cases.
2. Days 4-6: Intervals, heaps, and greedy algorithms framed as grocery problems: delivery windows, shopper capacity, top substitutions.
3. Days 7-8: Graph traversal and shortest paths, then build a small order-and-batch component end to end and add two requirements you did not plan for.
4. Days 9-11: Design. Practice availability prediction, substitutions, and batching out loud, naming the trade-off for each side of the marketplace. Add catalog ingestion or ads if your target team works there.
5. Days 12-13: Behavioral and project deep dive: one project you can discuss in detail, including what went wrong.
6. Day 14: A timed solo mock in your real setup.

FAQ

Are Instacart coding interviews LeetCode style?

Partly. Candidates commonly describe a mix of standard data structures and algorithms and more practical problems - building a small working component, parsing and transforming data, or extending code as requirements are added. Hash maps, sorting, heaps, intervals, and graphs still matter, but writing clean, runnable code and handling follow-up requirements tends to matter as much as knowing a specific algorithm.

What makes Instacart different from other delivery companies in interviews?

Instacart is a grocery marketplace with three sides - customers, shoppers, and retailers - and its hardest problems come from groceries themselves. A single order can contain dozens of items from a retailer's catalog, some of which may be out of stock by the time a shopper reaches the shelf. That makes item availability, substitutions, batching several orders for one shopper, and catalog quality recurring themes, rather than the restaurant preparation and single-pickup framing typical of meal delivery.

Does Instacart ask system design questions?

For mid-level and senior engineers, candidates typically report a design round, often tied to Instacart's domain. Representative themes include predicting item availability, recommending substitutions, batching and routing orders for shoppers, ingesting large retailer catalogs, and serving or measuring sponsored product ads. Expectations vary by team and level, so confirm the format with your recruiter.

What topics should I study for an Instacart software engineer interview?

Cover hash maps, sorting, heaps, intervals, and graph traversal, and practice writing complete, runnable solutions. Add design practice for marketplace problems such as availability, substitutions, batching, and catalog ingestion, basic comfort with data pipelines and ranking if your team works on ads or search, and behavioral stories about ownership and working across functions.

How should I think about the three-sided marketplace in an Instacart interview?

For any design or product-flavored question, ask how the decision affects each side. Customers want the right items on time, shoppers want batches and routes that make their time worthwhile, and retailers want accurate inventory, their catalog represented correctly, and useful promotion tools. Naming a trade-off between two sides, and explaining which you would favor and why, is a strong signal.