Fiverr Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at Fiverr, you will play a critical role in shaping the future of the world’s leading marketplace for freelance services. Fiverr operates at a massive global scale, connecting millions of active buyers and sellers across thousands of digital service categories. This requires a highly sophisticated, low-latency, and resilient technical infrastructure that can handle millions of concurrent transactions, real-time communication, complex search queries, and secure payment processing. In this role, you will be responsible for building, optimizing, and maintaining the core services that power the Fiverr platform. Your work will directly impact how users discover talent, collaborate on projects, and conduct business globally.

This guide is scoped to a Software Engineer candidate at Fiverr.

Focus areas

• JavaScript
• System Design
• Algorithms

The Fiverr interview process

Fiverr candidates report 5 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

HR Screening Call

Initial call to discuss your background and expectations.

What to demonstrate

• Initial call to discuss your background and expectations
• Depth in JavaScript

How to prepare

• Be able to walk your CV end to end in two minutes, and say why this company specifically.
• Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Live Coding Session

Technical round with a team lead or senior engineer focusing on coding skills.

What to demonstrate

• Technical round with a team lead or senior engineer focusing on coding skills
• Depth in JavaScript

How to prepare

• Answer aloud and timed: Given a list of strings, write an algorithm to find the shortest unique prefix for each word in the array.
• Answer aloud and timed: Given an array of integers and a target sum, determine if there is a pair of numbers that sum up to the target.

System Design Session

Assessment of your system design capabilities in a technical interview.

What to demonstrate

• Assessment of your system design capabilities in a technical interview
• Depth in JavaScript

How to prepare

• Answer aloud and timed: Implement a function to map a random number generator from rand5 to rand7.
• Answer aloud and timed: Implement the debounce design pattern in vanilla JavaScript to optimize high-frequency event handling.

Architectural Interviews

Deeper discussions on architectural concepts with group managers and directors.

What to demonstrate

• Deeper discussions on architectural concepts with group managers and directors
• Depth in JavaScript

How to prepare

• Answer aloud and timed: Build a functional, real-time chat component using React or vanilla JavaScript that calls a mock API, displays incoming responses, and handles message submissions.
• Answer aloud and timed: Create a fully responsive "To-Do" web application within a strict time limit, demonstrating clean layout structure using HTML and CSS.

Final Interview

Concluding interview with an executive or HR representative.

What to demonstrate

• Concluding interview with an executive or HR representative
• Depth in JavaScript

How to prepare

• Answer aloud and timed: Explain how you would optimize a large-scale web application for search engine optimization (SEO) and fast initial page loads.
• Answer aloud and timed: Solve a series of CSS styling challenges, including complex element alignment, flexbox/grid layouts, and responsive design adjustments.

Where candidates lose points

Understand the Fiverr Marketplace

Take the time to explore the Fiverr platform as both a buyer and a seller. Understanding the core user flows—such as searching for a gig, messaging a seller, placing an order, and managing a project—will give you invaluable context during system design and product-related questions.

Clarify Framework Constraints

In frontend coding challenges, clarify your technical options early. While some interviewers might have a preference, you generally have the right to choose your preferred framework (such as React or Vanilla JS) for building UI components like chat apps or to-do lists.

During frontend tasks, clarify your technical constraints early

While some interviewers may have a preference, you generally have the right to choose your preferred framework (such as React or Vanilla JS) for building UI components like chat apps or to-do lists.

Questions & practice

Implement a Power Set algorithm to generate all possible subsets of a given set of numbers.

Medium · Coding & Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Given a list of strings, write an algorithm to find the shortest unique prefix for each word in the array.

Medium · Coding & Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Given an array of integers and a target sum, determine if there is a pair of numbers that sum up to the target

Medium · Coding & Algorithms

Given an array of integers and a target sum, determine if there is a pair of numbers that sum up to the target.

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Implement a function to map a random number generator from rand5 to rand7.

Medium · Coding & Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Explain how you would optimize a large-scale web application for search engine optimization (SEO) and fast ini

Medium · Frontend & UI Engineering

Explain how you would optimize a large-scale web application for search engine optimization (SEO) and fast initial page loads.

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Design and implement an LRU (Least Recently Used) Cache data structure with efficient lookup and insertion tim

Medium · Coding & Algorithms

Design and implement an LRU (Least Recently Used) Cache data structure with efficient lookup and insertion times.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Implement the debounce design pattern in vanilla JavaScript to optimize high-frequency event handling.

Medium · Frontend & UI Engineering

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

Build a functional, real-time chat component using React or vanilla JavaScript that calls a mock API, displays

Medium · Frontend & UI Engineering

Build a functional, real-time chat component using React or vanilla JavaScript that calls a mock API, displays incoming responses, and handles message submissions.

Approach

1. Say who the caller is and what they do when the call fails halfway.
2. Define the identity of a request so a retry cannot double-apply it.
3. Separate accepted, pending, failed and confirmed; they are different facts.
4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

• What happens if the caller retries after a timeout?
• How does a client discover it is on an old version of this contract?

Create a fully responsive "To-Do" web application within a strict time limit, demonstrating clean layout struc

Medium · Frontend & UI Engineering

Create a fully responsive "To-Do" web application within a strict time limit, demonstrating clean layout structure using HTML and CSS.

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

Solve a series of CSS styling challenges, including complex element alignment, flexbox/grid layouts, and respo

Medium · Frontend & UI Engineering

Solve a series of CSS styling challenges, including complex element alignment, flexbox/grid layouts, and responsive design adjustments.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Design a URL shortening service (like TinyURL), explaining your choice of database, caching strategy, and API

Medium · System Design & Architecture

Design a URL shortening service (like TinyURL), explaining your choice of database, caching strategy, and API design.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Architect a real-time messaging and chat system capable of supporting millions of active users with minimal la

Medium · System Design & Architecture

Architect a real-time messaging and chat system capable of supporting millions of active users with minimal latency.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Walk through the system architecture of a complex project you previously led, detailing your technology choice

Medium · System Design & Architecture

Walk through the system architecture of a complex project you previously led, detailing your technology choices, scaling challenges, and lessons learned.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Explain how you would design a rate-limiting system to protect Fiverr APIs from abuse and distributed denial-o

Medium · System Design & Architecture

Explain how you would design a rate-limiting system to protect Fiverr APIs from abuse and distributed denial-of-service (DDoS) attacks.

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

Build a functional backend service or a short URL application in under 90 minutes using Claude or Anthropic AP

Medium · AI-Assisted Development & Practical Task

Build a functional backend service or a short URL application in under 90 minutes using Claude or Anthropic APIs, and be prepared to explain every line of generated code in detail.

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

Create a full-stack mini-app within a provided sandbox environment (React + Node.js boilerplates), implementin

Medium · AI-Assisted Development & Practical Task

Create a full-stack mini-app within a provided sandbox environment (React + Node.js boilerplates), implementing specific business logic and extra features on top of existing code.

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

• The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
• Where should the 10-second timeout number actually come from?

Suggested practice checklist

Built from the rounds and topics Fiverr candidates report.

Day 1 — Map the Fiverr loop

• Write out the reported sequence: HR Screening Call, Live Coding Session, System Design Session, Architectural Interviews, Final Interview.
• For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 5 reported rounds, with the weakest marked.

Day 2 — Work JavaScript

• Spend the session on JavaScript, which Fiverr candidates report being tested on.
• Write one worked example in JavaScript and time yourself on it.

Deliverable: One timed worked example in JavaScript.

Day 3 — Work System Design

• Spend the session on System Design, which Fiverr candidates report being tested on.
• Write one worked example in System Design and time yourself on it.

Deliverable: One timed worked example in System Design.

Day 4 — Work Algorithms

• Spend the session on Algorithms, which Fiverr candidates report being tested on.
• Write one worked example in Algorithms and time yourself on it.

Deliverable: One timed worked example in Algorithms.

Day 5 — Answer out loud: Coding & Algorithms

• Answer aloud, timed: Implement a Power Set algorithm to generate all possible subsets of a given set of numbers.
• Answer aloud, timed: Design and implement an LRU (Least Recently Used) Cache data structure with efficient lookup and insertion times.

Deliverable: Spoken answers to 2 reported Coding & Algorithms question(s), under time.

Day 6 — Answer out loud: Frontend & UI Engineering

• Answer aloud, timed: Implement the debounce design pattern in vanilla JavaScript to optimize high-frequency event handling.
• Answer aloud, timed: Build a functional, real-time chat component using React or vanilla JavaScript that calls a mock API, displays incoming responses, and handles message submissions.

Deliverable: Spoken answers to 2 reported Frontend & UI Engineering question(s), under time.

Day 7 — Answer out loud: System Design & Architecture

• Answer aloud, timed: Design a URL shortening service (like TinyURL), explaining your choice of database, caching strategy, and API design.
• Answer aloud, timed: Architect a real-time messaging and chat system capable of supporting millions of active users with minimal latency.

Deliverable: Spoken answers to 2 reported System Design & Architecture question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

• How would you detect a consumer that reads the field only during a monthly export?
• One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?