Trainline · Software Engineer
Updated · 2026-09-20

Trainline Software Engineer
Interview Questions & Guide 2026

THE 60-SECOND BRIEF

Trainline operates a rail and coach travel platform.

Prepare for travel software with reliable booking flows, explicit time boundaries and resilient carrier integrations.

Practise the engineering decisions below, then map them to the format specified for your opening.

Booking correctnessAPI resilienceTime and money

11 min read

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

A fast search is useful only if the traveller can trust the result. Work through a journey from search to booking confirmation. Separate a displayed offer, an inventory hold, a payment and an issued ticket: they can fail independently.

Trainline’s official technology overview describes a .NET/C# platform on AWS with microservice patterns, plus React, TypeScript and Node on the web. Match your preparation to the specific team; these broad stack facts do not establish its interview questions or format.

State the clock and currency contract before coding. A departure displayed in local time is not an elapsed duration. A price in minor units is not a floating-point approximation. The exercises use synthetic data, UTC instants and explicit currencies so that you can test boundaries without guessing business rules.

Explain the unhappy path in traveller terms. After a network timeout, can the person safely book again? Which record proves whether a ticket exists? Start with that question before choosing queues, caches or database technology. This is editorial preparation for booking systems, not Trainline’s internal design.

01

Define the booking contract

editorial

Follow a single itinerary. Name the offer identity, its expiry and the currency. A search result is not a guarantee that a later booking attempt will succeed. Explain how your system communicates a changed price before accepting a commitment.

What to demonstrate

  • Distinguish cached discovery data from authoritative booking state.
  • Make time and amount units explicit.

How to prepare

  • Attempt the offer-selection exercise.
  • Create an offer expiring exactly when the booking starts.
Read the source
02

Isolate unreliable dependencies

editorial

A carrier API can be slow, unavailable or ambiguous after accepting a request. Put deadlines around calls and preserve a durable operation identity. Decide which reads may return partial results and which writes require reconciliation.

What to demonstrate

  • Explain retry safety separately for reads and writes.
  • Keep one unhealthy carrier from consuming all capacity.

How to prepare

  • Draw the booking operation state machine.
  • List retryable, terminal and unknown outcomes.
Read the source
03

Show maintainable engineering

editorial

Use small interfaces around time, inventory and payment so you can simulate failures. Dependency injection earns its place when it creates a testable boundary, not when it merely adds layers.

What to demonstrate

  • Connect abstraction to a real test or substitution.
  • Explain the effect of a release on travellers.

How to prepare

  • Reproduce the inventory race with two buyers.
  • Prepare an example of improving an API without breaking its callers.
Read the source

PracHub editorial advice for the preparation topics above.

01

Treating a timeout as a rejected booking

Keep the outcome unknown until a durable record or reconciliation resolves it. A new request key can create an unintended second booking.

02

Summing money after a one-to-many join

Payment attempts multiply ticket rows. Aggregate value at the ticket identity before combining it with operational metrics.

03

Comparing local time strings

Convert explicit timezone-aware instants before ordering. State how ambiguous timetable inputs are resolved.

04

Retrying without a budget

Bound time, attempts and concurrency. Writes need an operation identity and a known retry contract, not just exponential backoff.

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 valid offer per journey

mediumWorked solution
Hash mapsOrderingValidation

Given offers with journey_id, offer_id, currency, price_minor and expires_at, select one per journey in a requested currency at UTC instant now. Expiry is exclusive; break equal-price ties by offer_id. Reject negative or noninteger prices.

Approach
  1. Validate the record contract, then discard the wrong currency and any offer with expires_at <= now.
  2. Track the best (price_minor, offer_id) tuple per journey. Return results in journey-ID order. Explain O(n + j log j) time and O(j) retained state.
Worked solution 35 min
  1. Validate monetary types before comparing prices. Boolean values are rejected even though Python treats them as integers.
  2. Ignore expired offers and currency mismatches. Choose by a deterministic tuple so input order cannot change the result.
  3. This selects a candidate offer; booking still needs authoritative validation.
Python
def choose_offers(offers, currency, now):
    best = {}
    for o in offers:
        price = o["price_minor"]
        if type(price) is not int or price < 0:
            raise ValueError("nonnegative integer minor units required")
        if o["currency"] != currency or o["expires_at"] <= now:
            continue
        key = o["journey_id"]
        if key not in best or (price, o["offer_id"]) < (best[key]["price_minor"], best[key]["offer_id"]):
            best[key] = o
    return [best[k] for k in sorted(best)]

Scroll sideways to view long lines.

EXPECTED RESULTAt now=10, offer a wins the tie for journey j1; offers expiring at 10 are excluded.
Follow-up
  • How would stale availability affect the decision to book the selected offer?

Validate a chain of connections

medium
Time boundariesSequences

Given ordered legs with origin, destination, departure and arrival as UTC seconds, check that places connect and each transfer leaves at least the required minimum connection time. Arrival cannot precede departure.

Approach
  1. Validate each leg independently, then compare each arrival with the next departure. Equality at the required minimum is valid.
  2. Return the first failing leg or connection with a useful reason. Treat an empty itinerary according to an explicit caller contract.
Follow-up
  • How would daylight-saving changes enter when converting local timetable values to UTC?

Count recent carrier responses

medium
Sliding windowQueuesBoundaries

Given nondecreasing integer timestamps, count events in (now − 10, now]. Each event counts once. The clock can advance without a new event; an event at the lower boundary has expired.

Visual walkthrough

Which events still count?

ROLLING TOTAL+2units
(0, 10]Events in window: 2
In windowExpiredNot arrived

The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.

See the event values
  • At 0s: +1expired
  • At 5s: +1in window
  • At 10s: +1in window
  • At 14s: +1not arrived
  • At 19s: +1not arrived

Synthetic carrier responses at 0, 5, 10, 14 and 19 seconds, each with weight one. Drag the clock: at 10 seconds only 5 and 10 count; at 30 seconds none remain. The lower boundary is excluded.

Approach
  1. Keep a deque and remove timestamps at or before now − 10 before reporting a count. Equal timestamps represent distinct events unless a separate event ID says otherwise.
  2. Expose both add(time) and count(now). Reject a backward clock and document the O(k) retained-event memory cost. Each event is inserted and removed once, giving amortized O(1) updates.
Follow-up
  • How would late arrivals, multiple producers or a per-customer limit change the contract?

A PracHub practice schedule with one outcome per session. Adjust the pace to your experience and interview date; it is not a company 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
01Trace a traveller journey
  • Draw search, offer, booking, payment and ticket states.
  • Mark where authority moves to an external service.

Deliverable: A state map

02Choose offers correctly
  • Implement offer selection.
  • Test ties, currency and expiry.

Deliverable: A tested selection function

Practice prompt ↗
03Verify reporting grain
  • Run the ticket-value fixture.
  • Add payment attempts and prove no total inflation.

Deliverable: A stable SQL report

Practice prompt ↗
04Design the uncertain outcome
  • Walk the booking flow through a lost carrier response.
  • Define a reconciliation action and the user-visible status.

Deliverable: A recovery contract

Practice prompt ↗
05Reproduce the last-place race
  • Run the conditional update fixture.
  • Explain the transaction needed for reservation identity.

Deliverable: A concurrency timeline

Practice prompt ↗
06Practise resilient integration
  • Sketch deadlines and carrier capacity limits.
  • Prepare an API-change story.

Deliverable: An integration review sheet

Practice prompt ↗Practice prompt ↗
07Review aloud
  • Solve connection validation and inspect the event clock.
  • Explain one unresolved limitation in your design.

Deliverable: A focused next-practice list

Practice prompt ↗Practice prompt ↗

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

Use a real project. Explain your responsibility, the decision you made, the evidence you used and what you would change.

Evolve an integration safely

medium
CollaborationOwnership

Describe an API change where you protected existing callers while introducing a better contract.

Approach
  1. State the constraint and your decision, including what another reasonable engineer might have chosen.
  2. Describe how you verified the result and kept affected people informed. Use actual evidence from your own work.
Follow-up
  • What would you monitor to know the decision should be revisited?

Negotiate a safer release scope

medium
CollaborationOwnership

Explain a deadline decision where you narrowed a feature to preserve correctness.

Approach
  1. State the constraint and your decision, including what another reasonable engineer might have chosen.
  2. Describe how you verified the result and kept affected people informed. Use actual evidence from your own work.
Follow-up
  • What would you monitor to know the decision should be revisited?

Communicate during an outage

medium
CollaborationOwnership

Describe how you explained a dependency outage and uncertainty to a nontechnical partner.

Approach
  1. State the constraint and your decision, including what another reasonable engineer might have chosen.
  2. Describe how you verified the result and kept affected people informed. Use actual evidence from your own work.
Follow-up
  • What would you monitor to know the decision should be revisited?
  • 01

    Choose examples you can discuss without sharing confidential customer data.

Which language should I prioritize?

The official teams page describes .NET/C# on the platform and React, TypeScript and Node on the web. Prioritize the exact role. Python here is only the reference language for a small algorithm.

Trainline — official engineering and product context
Are these verified company interview questions?

These are PracHub practice exercises informed by the supplied guide themes and official product context. They include original constraints and worked solutions; they are not an independently verified list of questions asked by the employer.

Why include SQL alongside coding and design?

SQL is supplemental practice for inspecting system state and checking invariants. Its inclusion does not mean every role has a SQL interview. Prioritize the skills in your exact opening.

How should I use the seven-day checklist?

Attempt each task before opening its solution. Save one artifact per session, such as a tested function, fixture or failure timeline. Repeat weak areas and adjust the pace instead of treating seven days as a readiness guarantee.

Sources & methodology 3 sources ↗

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