Lyst · Software Engineer
Updated · 2026-09-20

Lyst Software Engineer
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

Lyst helps shoppers discover fashion products across brands and retailers.

Affiliate Operations engineers build partner integrations, product-data services and acquisition platforms using a Python/Django backend.

Interview rounds are not published in the reviewed opening; use four role-specific preparation checkpoints.

Correct partner feedsCampaign SQLProduction ownership

16 min read

Practice 11 Software Engineer prompts
11Practice promptsAcross five skill areas
4With worked solutionsIncluded in the practice prompts

This guide uses the current Software Engineer — Affiliate Operations opening as its main track. Its public description connects engineering work to partner integrations, customer acquisition and operational reliability. That makes a useful preparation question very concrete: when a retailer sends late or repeated data, how do you protect the result a shopper or business team sees?

Build one small practice service around offers and campaign events. Start with a contract for price units, stock status and identifiers, then add a repeatable data import and a daily report. Keep a failed import out of the visible catalog and make a repeated conversion event harmless. These exercises create a coherent story across coding, SQL, system design and debugging rather than four unrelated answers.

Use Python and relational data as the main implementation path for this opening. Lyst lists Django, AWS, PostgreSQL and messaging services in the role description, alongside testing and service ownership. A small local fixture is enough to practise the reasoning, but be precise about its limits: a passing SQLite transaction test does not establish the throughput of a cloud pipeline. Bring the contract, a failure case and the measurement you would run next.

01

Connect your experience to the product

editorial

Begin with a specific part of the affiliate platform: a partner integration, a product-data service or a campaign decision. Explain the user or business outcome it serves before naming a tool. This gives your technical examples a clear purpose and helps distinguish a reliability requirement from an optional improvement.

What to demonstrate

  • Explain a data contract in terms another team can check: what one record represents, which identifier is stable and what happens when a partner repeats a delivery.
  • Connect an engineering decision to a shopper or partner outcome, such as preventing an unavailable offer from being displayed or keeping a report consistent.

How to prepare

  • Prepare a short diagram from partner input to stored data and the consumer of that data. Mark the point where an incomplete import becomes visible and how you would prevent that.
  • Choose one past integration or data-quality problem. State your own contribution, one important constraint and the evidence that showed the final behavior was better. Keep estimates separate from measurements you actually recorded.
Read the source
02

Practise precise backend changes

editorial

Work through a contained Python change with an explicit input contract. An offer-selection function is a good rehearsal because small ambiguities change the answer: currency, unavailable inventory and equal prices all matter. Make those choices visible in tests before discussing a larger application structure.

What to demonstrate

  • Keep the result deterministic across different input orders, and explain why comparing amounts without a shared currency or unit would be incorrect.
  • Select a representation whose cost you can describe, including the number of products held in memory and the effect of a very large partner feed.

How to prepare

  • Implement the cheapest-offer exercise, then add empty input, equal prices, unavailable stock and malformed price cases. Run the same input in a different order and compare the result.
  • Wrap one operation in a simple API contract on paper: validation errors, a successful response and a repeated request. Explain where application validation ends and a database constraint must protect the stored state.
Read the source
03

Reason across data and system boundaries

editorial

Practise a query and a failure scenario together. A campaign report can look plausible even when joining two event tables multiplies its totals. A product feed can look complete even when a stale retry replaces a newer snapshot. Use a small counterexample to make each defect observable.

What to demonstrate

  • Distinguish events, entities and aggregate rows before joining data; show how row multiplicity affects a count or sum.
  • Identify the single publication boundary in a feed pipeline and explain which state must remain consistent if a download, validation or delivery attempt fails.

How to prepare

  • Create three campaigns with different click and order counts, including a campaign with no activity. Predict the report by hand, then compare it with both a direct join and independent aggregates.
  • Walk through a feed arriving out of order. Keep staging separate from publication and state the version rule that stops an older successful download from becoming the current catalog. Describe a safe recovery step using the previous complete snapshot.
Read the source
04

Explain decisions and the work after release

editorial

Prepare a service-ownership example that includes a result after the first release. Lyst’s current opening describes engineers operating the systems they build. Its 2021 engineering-culture article also provides dated context on constructive feedback and sustainable delivery; use your own evidence to explain how you work.

What to demonstrate

  • Make the operational consequence of a choice clear: which signal detects a problem, who can act on it and what a safe response looks like.
  • Explain a disagreement with Product, Marketing, Analytics or another partner by showing the competing objectives and the evidence used to decide.

How to prepare

  • Bring one example where a metric challenged your first interpretation. Describe the population, time window and an alternative explanation you checked before recommending a change.
  • Write a brief handoff for the practice feed service: the normal freshness check, the failed-import signal and the rollback condition. Ask another person to follow it without a verbal explanation, then improve the part they could not reproduce.
Read the source

PracHub editorial advice for the preparation topics above.

01

Comparing offers before defining money and availability

State the currency, price unit and stock rule first. An integer amount of 1299 has no useful ordering against another currency unless a conversion policy exists. An unavailable offer should not win simply because it is cheaper. In your practice function, cover equal prices and changing input order so a reviewer can see that the result follows a contract rather than whichever record happened to arrive first.

02

Accepting a plausible campaign total without checking row multiplicity

Before optimizing a report, draw the grain of each table and predict one campaign’s result by hand. Three clicks joined to two orders can produce six rows; summing on that result inflates revenue even though the SQL executes successfully. Aggregate independent event streams separately, then join their summaries. Include a campaign with no events so missing activity is not confused with a missing campaign.

03

Treating the last feed to finish as the newest catalog

A slow retry can finish after a newer export. Use an explicit version contract and separate validation from publication, keeping the current catalog intact until a complete candidate is ready. Walk through both a malformed feed and an older successful feed. Your recovery explanation should identify the previous complete snapshot and the freshness signal that tells an operator the system is behind.

04

Calling an experiment successful from one improved number

Explain the assignment unit, time window and guardrail before interpreting the result. An apparent campaign improvement might coincide with inventory changes or a different partner mix. State a competing explanation and the evidence that would distinguish it. If the data cannot answer the original question, make the narrower decision it supports instead of presenting confidence that the experiment did not earn.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

8 technical prompts4 include a worked solution

Choose the cheapest available offer per product

mediumWorked solution
MapsMoneyDeterminism

Given unique offer IDs, product IDs, integer prices in minor units, currency and stock status, select one available offer per product in a requested currency. Break equal-price ties by offer ID; omit products without an eligible offer.

Approach
  1. Keep only the best (price, offer ID) pair per product. Do not compare prices across currencies.
  2. Validate price units before filtering, and make the tie-break independent of input order.
Worked solution 35 min

Select a deterministic cheapest offer

Implement the one-currency offer-selection contract above. Input offer IDs are unique; prices are non-negative integer minor units.

  1. Track the best price/ID tuple per product.
  2. Skip unavailable offers and currencies outside the request.
  3. Test ties and stock state before discussing database indexing.
Python
def cheapest_available(offers, currency="GBP"):
    best = {}
    for offer in offers:
        price = offer["price_minor"]
        if type(price) is not int or price < 0:
            raise ValueError("price must be non-negative integer minor units")
        if not offer["in_stock"] or offer["currency"] != currency:
            continue
        product = offer["product_id"]
        candidate = (price, offer["offer_id"])
        if product not in best or candidate < best[product]:
            best[product] = candidate
    return {product: offer_id
            for product, (_, offer_id) in sorted(best.items())}

Scroll sideways to view long lines.

EXPECTED RESULTEqual-price offers select the lexicographically smaller ID. Products without an available offer in the requested currency are omitted.
Follow-up
  • How would you support a retailer-specific exclusion without reprocessing the full catalog?

Detect a price crossing without duplicate alerts

medium
State machinesEvents

Process versioned prices for one product. Emit an alert when the price moves from above a subscriber’s threshold to at or below it. Ignore older versions and exact replays; a later rise above the threshold makes a new crossing eligible.

Approach
  1. Track the highest accepted version and the previous side of the threshold.
  2. Distinguish an initial observed low price from a crossing; choose that contract before coding.
Follow-up
  • Where would you place a durable idempotency key for the notification?

Find missing pages in a partner export

medium
SetsPagination

An export declares page IDs 1 through N. Page deliveries can repeat and arrive out of order. Return missing IDs in ascending order and reject IDs outside the declared range.

Approach
  1. Use a set or bitmap for received pages and calculate the complement only after the export closes.
  2. Treat repeated pages as deliveries of the same page; different content at one page ID needs a separate conflict policy.
Follow-up
  • How would you change the representation when N is too large for memory?

A PracHub practice schedule: complete one pair of related tasks per session and keep the result you can explain or run. Adjust the pace to your experience; this is not an employer hiring timeline.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the partner-data role
  • Read the opening and sketch input, storage and consumer boundaries.
  • Specify price units, availability and deterministic tie-breaking.

Deliverable: A one-page role map; Five boundary cases

Practice prompt ↗
02Implement offer selection
  • Run the coding solution and add one adversarial input.
  • Solve threshold crossings and distinguish replay from a new event.

Deliverable: Tested Python selection; A state-transition table

Practice prompt ↗Worked solution ↗
03Complete a partner export
  • Identify missing pages and explain the close-of-export signal.
  • Predict fixture totals by hand before running the query.

Deliverable: A completeness contract; A correct report and a bad-join counterexample

Practice prompt ↗Worked solution ↗
04Review versioned stock
  • Test a latest update that removes availability.
  • Separate candidate validation from changing the visible pointer.

Deliverable: A query with an anti-regression case; A publication diagram

Practice prompt ↗Worked solution ↗
05Reproduce a duplicate
  • Run replay and rollback tests for conversion ingestion.
  • Define assignment, metric, guardrail and a competing explanation.

Deliverable: An idempotent transaction; An experiment decision note

Practice prompt ↗Worked solution ↗
06Explain measured impact
  • Rehearse a real decision where evidence changed your mind.
  • Explain a data-quality tradeoff to a non-engineering listener.

Deliverable: A concise measurement story; An understandable acceptance check

Practice prompt ↗Practice prompt ↗
07Run an ownership walkthrough
  • Demonstrate a normal run, failed input and recovery.
  • Repeat the exercise with the least convincing evidence.

Deliverable: A reproducible service handoff; A revised solution and final review notes

Practice prompt ↗

Expand any day for tasks and deliverables. Your progress is saved on this device.

Use your own examples of measurement, stakeholder decisions and operating a service after release.

Explain a change whose value you measured

easy
JudgmentExperiments

Describe a feature where an initial result looked positive but a deeper measurement changed your conclusion.

Approach
  1. State the decision, the metric and the population being measured.
  2. Explain the conflicting evidence and the action you took rather than presenting only the favorable number.
Follow-up
  • What observation would have made the original conclusion credible?

Resolve a technical disagreement with a business partner

easy
CommunicationStakeholders

Describe a disagreement about data quality, delivery timing or feature scope with someone outside engineering.

Approach
  1. Explain the other person’s goal and the constraint your system had to respect.
  2. Show the smaller agreement, acceptance check and ownership of follow-up.
Follow-up
  • How did you make the outcome understandable without asking them to read your code?

Own a service after the feature ships

easy
ReliabilityOwnership

Describe a service you improved after observing it in production. Include an alert, an operational task and a lasting correction.

Approach
  1. Connect an actual symptom to a reproducible cause.
  2. Show how the fix reduced repeated work and how another engineer could operate the service afterward.
Follow-up
  • What did you intentionally leave manual and why?
  • 01

    Choose one business-facing decision and one production failure you can explain with concrete evidence.

Lyst — Software Engineer, Affiliate OperationsLyst Engineering — Our Engineering Culture (2021)
Which Lyst engineering role does this guide focus on?

The main track is the public Software Engineer — Affiliate Operations opening, covering partner integrations, product data and acquisition systems. Lyst’s careers page lists other engineering roles with different responsibilities.

Lyst — Software Engineer, Affiliate OperationsLyst — Careers
Should I prepare Python or frontend engineering?

For this opening, start with Python, Django and relational-data reasoning. The role also lists cloud, messaging and delivery tools; React and TypeScript are additional advantages rather than the main preparation track used here.

Lyst — Software Engineer, Affiliate Operations
Does Lyst publish a fixed interview loop for this role?

The reviewed opening does not specify interview rounds, their length or a technical-task format. The cards above organize preparation around the role’s responsibilities; they do not describe four confirmed interviews.

Lyst — Software Engineer, Affiliate Operations
Do these exercises reproduce Lyst interview questions?

They are original PracHub practice exercises built around partner data, measurement and reliability. Use the runnable fixtures to check your reasoning, then practise explaining the same decisions in your own language and stack.

Sources & methodology 5 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.