Etsy Coding Interview Questions: Discovery, Seller Tools, and Engineering Culture

A hand-thrown mug, a decades-old denim jacket, and a hand-dyed skein of yarn have one thing in common: none of them comes with a barcode, a manufacturer description, or, very often, a second copy. That is everyday reality on Etsy, a marketplace for handmade goods, vintage items, and craft supplies sold by independent sellers, many of them running a shop on their own. (Under Etsy's rules, vintage items must be at least 20 years old.) Search, recommendations, and seller tools all have to work without the shared product catalog that most retailers lean on, and that shapes much of what Etsy engineers build.

Etsy is also closely associated with a particular engineering culture - frequent small deployments, heavy use of metrics, experiments, and blameless postmortems - largely because its engineers wrote about these practices in public for years on the company's Code as Craft blog. This guide covers the loop candidates commonly describe, the domain themes worth understanding, how that culture can surface in your rounds, the types of problems to practice, and a two-week plan. We describe problem categories, not invented "leaked" questions: question pools rotate, and pattern fluency is what transfers.

The Etsy engineering loop

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

Ask which product area the role supports - search and discovery, recommendations, seller tools, payments, ads, or infrastructure are all plausible - and whether your coding rounds expect code that actually runs. The answers tell you whether to spend your extra time on ranking, product-flavored design, or practical coding.

Search and discovery for one-of-a-kind items

Most e-commerce search can lean on a product catalog: one canonical record per product, with a brand, a model number, and structured attributes, and many offers attached to it. On Etsy, many listings are their own product. That changes the problem in several ways:

• Seller-authored everything. Titles, tags, attributes, and photos all come from the seller. Etsy lets sellers add a limited number of tags to each listing, and how well those words describe the item varies widely from shop to shop.
• Queries about style and occasion. A query can describe an aesthetic or an event rather than an object - think boho wall hanging or gift for new dad - so matching on meaning, category, and images matters as much as matching keywords.
• Listings as templates. Many listings offer variations such as size or color, or personalization such as an engraved name, so one listing can stand for many possible items.
• Inventory of one. When a single-quantity listing sells, it has to leave results quickly, and whatever engagement history it had built up leaves with it.
• Many small shops. A results page dominated by one shop is a poor experience for buyers looking for variety and for sellers trying to be found, so diversity across shops is a genuine ranking concern.

Etsy also runs Etsy Ads, which lets sellers set a daily budget to promote their listings in search and elsewhere on the site, so ranking questions can touch on how sponsored and organic results share a page. You do not need to know Etsy's actual models; you need to reason clearly about signals, sparse data, and fairness to sellers.

Seller tooling for one-person businesses

Many Etsy sellers photograph, list, price, pack, ship, and answer messages themselves. For them, seller tools are the job rather than an admin panel, and design questions in this area reward empathy for someone doing everything alone. Themes that fit:

• Listing creation and bulk edits. Creating listings with variations and personalization options, and editing many listings at once, with clear behavior when some updates succeed and others fail.
• Shop statistics. Views, favorites, and orders over time - numbers a seller makes decisions on, so freshness and correctness matter more than dashboard polish.
• Orders and shipping. Processing times, shipping labels, and tracking, often for items that are made to order after purchase.
• Buyer conversations. Messaging about custom work, where a request only becomes an order after some back-and-forth.
• Promotion and pricing. Sales, discounts, and advertising budgets that a seller without a marketing team can use safely.

Recommendations when inventory sells out

Our recommendation system design walkthrough covers the standard architecture - candidate generation, ranking, and the cold-start problem. The Etsy-specific wrinkle is the inventory itself:

• Cold start is the normal case. New, unique listings arrive constantly, and a one-of-a-kind item can only sell once, so there is little interaction history per item. Content signals - text, images, category, and attributes - and shop-level signals carry more weight than item-to-item purchase history.
• Recommend at the right level. When the exact item is gone, a similar item, a similar shop, or more from the same shop may be the useful suggestion.
• Style across categories. A mug and a print can share an aesthetic a buyer clearly likes, which is why embeddings built from images and text are a natural fit.
• Gift shopping. When a buyer is shopping for someone else, their own history can mislead: one baby gift does not mean they want baby products for months afterwards.
• Fast removal. Sold-out listings need to leave candidate sets quickly, or recommendations turn into a list of things nobody can buy.

Topic emphasis for the coding rounds

Candidates' descriptions vary: some report standard data structure and algorithm problems, others more practical exercises where working, readable code is the point. Prioritize roughly in this order:

• Hash maps and sets. Counting views and favorites, deduplicating results, and grouping listings by shop.
• Strings and text processing. Tokenizing titles and tags, normalizing case and spelling, and building a small inverted index from words to listings.
• Heaps, sorting, and merging. Top-k results by score and merging several ranked lists into one - the heap and priority queue pattern covers both.
• Greedy re-ranking under constraints. Adjusting a ranked list so it respects a rule such as a per-shop cap, as in the example below.
• Trees. Category taxonomies are trees, so traversal, lowest common ancestor, and path questions map onto them naturally.
• Readable code and tests. Small functions, clear names, and a test for the edge case you just mentioned.

Deploying often and experimenting carefully

Etsy's engineers have written publicly, over many years, about deploying small changes to production many times a day with a one-button tool they called Deployinator, using feature flags to turn changes on gradually, and measuring the effect of what they ship. StatsD, the widely used metrics daemon, was introduced on Code as Craft in 2011, and John Allspaw's 2012 post there on blameless postmortems - reviewing incidents to understand how the system allowed a mistake rather than to punish whoever made it - is still widely cited. Older posts may not describe how Etsy works today, so treat them as culture rather than a map of the current stack.

How this can show up in an interview:

• Small, reversible changes. In design rounds, explain how you would ship behind a flag, ramp up gradually, and know within minutes if something broke.
• Observability as part of the design. Name the metrics and alerts you would add, not just the boxes and arrows.
• Blameless incident stories. In behavioral rounds, a story about an incident you helped resolve - told without blaming a colleague and ending with what changed in the system - fits this culture well.

For the mechanics of A/B testing - assignment, primary and guardrail metrics, and sample size - our Booking.com coding interview guide covers the basics. What is different in a two-sided marketplace is interference. Buyers in the treatment and control groups compete for the same one-of-a-kind items: if a ranking change helps treatment buyers find and buy a particular listing, control buyers can no longer buy it, so a naive comparison can overstate the effect. Seller-facing changes raise a different problem - they may need to be randomized by shop rather than by buyer, which means fewer units and noisier results. Naming this trade-off, and a mitigation such as randomizing by shop or by market, is a strong signal in any experimentation discussion.

Representative problem types

Below are the kinds of problems worth practicing: common interview patterns, set in the problems a marketplace of unique items creates. They are categories, not a list of reported prompts.

• Text search basics. Build a small inverted index over titles and tags, then answer multi-word queries with a simple score.
• Top-k and merging. Return the best results by score, or merge ranked lists from several sources.
• Constrained re-ranking. Enforce a per-shop cap or another diversity rule without discarding relevance order.
• Event aggregation. Summarize views, favorites, and orders per listing or per shop over a time range.
• Tree traversal over a taxonomy. Find every listing under a category, or the nearest shared parent of two categories.
• Build and extend a component. A small listing or shop class with variations and personalization, extended as the interviewer adds requirements.
• Marketplace design (experienced roles). Search indexing for unique items, a recommendations service that drops sold-out listings quickly, a seller statistics pipeline, or a safe bulk-edit service.

Here is the flavor of the constrained re-ranking type: take a relevance-ordered list and cap how many listings any single shop can place on a page, backfilling if too few shops matched.

from collections import defaultdict

def diversify(ranked, max_per_shop, page_size):
    # ranked: list of (listing_id, shop_id), best match first
    if max_per_shop < 1:
        raise ValueError("max_per_shop must be at least 1")
    page, held_back = [], []
    shown = defaultdict(int)                  # shop_id -> listings already on the page

    for listing_id, shop_id in ranked:
        if len(page) == page_size:
            break
        if shown[shop_id] < max_per_shop:
            page.append(listing_id)
            shown[shop_id] += 1
        else:
            held_back.append(listing_id)      # keep rank order for the backfill

    # Too few shops matched to fill the page: use the best held-back listings.
    for listing_id in held_back:
        if len(page) == page_size:
            break
        page.append(listing_id)
    return page

The strong answer notes that this is one O(n) pass that keeps relevance order among the listings it shows, and walks through the edge cases: an invalid cap, an empty input, and a query where only one shop matches, which is exactly what the backfill handles. Then it offers follow-ups: a sliding cap for infinite scroll, such as no more than two listings from one shop in any ten consecutive results; a soft penalty instead of a hard limit; keeping pagination consistent so a held-back listing appears on the next page; and how you would test whether diversity actually helps buyers and sellers, given the interference problem above.

What interviewers look for

• Working, readable code. Solutions that run, with names and structure a teammate could extend.
• Comfort with sparse, messy data. Designing for listings with missing attributes, inconsistent tags, and little history.
• Seller empathy. Seeing how a ranking or tooling change affects a one-person shop, not just the buyer.
• Measurement and safe change. Knowing how you would ship, monitor, evaluate, and roll back a change.
• Collaboration and learning from failure. Behavioral stories that show how you work with others and what you changed after something went wrong.

A word on integrity: prepare thoroughly and reason honestly in the room. Practical rounds and design follow-ups tend to ask why your approach works and what you would change next, and real understanding is what holds up.

A two-week Etsy prep plan

1. Days 1-3: Fundamentals - hash maps, strings, and sorting. Build a tiny inverted index over listing titles and tags, and query it.
2. Days 4-6: Heaps and merging, then greedy re-ranking: top-k by score, a k-way merge of ranked lists, and the per-shop cap above with its follow-ups.
3. Days 7-8: Trees and taxonomy traversal, plus a small listing class with variations and personalization that you extend twice with requirements you did not plan for.
4. Days 9-11: Design. Practice search for unique items, recommendations that drop sold-out listings quickly, and a seller statistics pipeline. Our system design reference is a quick refresher on the building blocks.
5. Days 12-13: Behavioral stories: an incident you helped resolve and what changed afterwards, a feature you shipped gradually, and a time you spoke up for a group of users other than the obvious one.
6. Day 14: One timed coding problem and one design prompt, run end to end in the environment you will use on the day, followed by a short written note on what to tighten.

FAQ

What is the Etsy coding interview like?

Candidate accounts generally describe a recruiter call, a technical screen, and a final set of interviews covering coding, design for experienced engineers, and behavioral and collaboration questions. Accounts of the coding rounds differ - some describe standard data structure and algorithm problems, others practical exercises where clean, working code is the main signal. Formats vary by team and level, and processes change, so confirm the details with your recruiter.

Why is search at Etsy different from search at other e-commerce companies?

Many Etsy listings are handmade or vintage items with no barcode, no manufacturer description, and no shared product record, and some exist exactly once. Titles, tags, attributes, and photos are written by sellers, and queries often describe a style or an occasion rather than a specific product. That makes query understanding, image and text similarity, sparse data, and diversity across many small shops central to the problem.

Does Etsy ask system design questions?

Design rounds are commonly reported for mid-level and senior engineers. Natural themes include search and ranking for unique items, recommendations that drop sold-out listings quickly, seller tools such as shop statistics or bulk listing edits, and shipping changes safely with feature flags and monitoring. Expectations vary by team and level, so ask your recruiter what to prepare.

What is Etsy's engineering culture known for?

Etsy is widely associated with continuous deployment, feature flags, heavy use of metrics, experimentation, and blameless postmortems, largely because its engineers wrote about these practices publicly on the Code as Craft blog. StatsD, a widely used metrics tool, came out of Etsy. Older posts may not reflect current tools, but the underlying ideas - small reversible changes, measuring impact, and learning from incidents without blame - are worth bringing into design and behavioral answers.

What should I study for an Etsy software engineer interview?

Cover hash maps, strings and text processing, heaps and sorting, greedy re-ranking, and tree traversal, and practice writing readable, tested code. For design, practice search and recommendations for unique inventory, seller-facing tools, and safe rollouts with metrics. Add behavioral stories about collaboration, an incident you learned from, and a change you shipped gradually.