Interview guides · Artsy

Artsy Software Engineer Interview Guide

Artsy Software Engineer interview guide: the three reported rounds, behavioral answers, technical deep-dive prep and a 7-day plan.

The 60-second brief

Artsy runs a platform for discovering, learning about and collecting art, used by collectors and by galleries. Candidates describe the engineering work as search, marketplace transactions and internal tools for partners, all sitting between art-world data and the screens collectors see. As a Software Engineer you would write and review code for that platform and, as candidates describe the role, follow your changes from the first idea through release and monitoring.

This guide is for engineers preparing for the Artsy Software Engineer loop. It covers the three reported stages (Recruiter Screen, Technical Deep-Dive, Management Conversations), gives worked approaches for the ten reported questions (five about technical experience, five about collaboration and motivation), and sets out a seven-day plan.

Candidates report three stages over roughly three to five weeks: a Recruiter Screen, a Technical Deep-Dive, and Management Conversations. Some also describe meeting several team members in one block.

Focus areas

Interview communication
Technical resume storytelling
Engineering manager interview

Overview

The reported questions are about your own work rather than puzzles. You are asked about a hard problem you solved, the languages and frameworks you know best, how you keep code maintainable and scalable, the architecture of a project you are proud of, and how you learn new technology. Nobody can answer those from a cram sheet. The preparation is choosing two or three projects from your history and knowing them well enough to defend every decision in them: the data model, the API shape, what you tested, what failed, and what you would change.

Candidates describe the work as search, marketplace transactions and partner-facing internal tools, owned from the first idea through release and monitoring, with frequent contact with product and design. Requirements they list are a modern web framework, relational databases and RESTful API design, with AWS, microservices and consumer-facing high-traffic experience as extras, and reports of 3+ years among successful candidates. Reported example scenarios include handling a traffic spike for a popular auction, refactoring legacy code safely, and pushing back on a product requirement. Rehearse each of these with concrete mechanisms: caching and queueing for the spike, characterisation tests for the refactor, a cost-and-alternative argument for the pushback.

The behavioral side carries real weight. Five of the ten reported questions are about disagreements, explaining technology to non-engineers, juggling deadlines, motivation for Artsy, and code review feedback, and the last stage is described as a conversation with management about long-term impact and alignment with business strategy. Prepare stories with decisions and results in them, use the situation-task-action-result shape that candidates recommend, and read whatever Artsy has published about its engineering and process before you talk to anyone, since candidates say details have been shared publicly.

The Artsy interview process

Candidates describe three stages, from a recruiter conversation to technical discussions to talks with management. The stages are described by candidates, not published by the company.

Recruiter Screen

Candidates describe a first conversation with a recruiter about your background and your fit for the role. Treat it as the first spoken test of your story: a clear account of what you have built, which of the listed technologies (web frameworks, relational databases, REST APIs) you have used in production, and a concrete reason for choosing Artsy. Candidates also advise keeping in touch with the recruiter and following up politely if you hear nothing.

What to demonstrate

Your background and fit for the role, as the stage is described
How clearly you summarise your experience out loud
Whether your reason for wanting Artsy is specific rather than generic

How to prepare

Write a short career narrative that names two projects, your part in each and the stack you used, then say it aloud until it is short and smooth.
Prepare a specific answer to what draws you to Artsy beyond the technical challenge, based on something you have read or used.
Make a list of questions about the remaining stages and ask the recruiter for them in writing.

Technical Deep-Dive

Candidates describe in-depth technical discussions about engineering skills and problem-solving, and report conversation-based assessments that resemble day-to-day work more than abstract puzzles. Areas candidates list include design patterns in your preferred stack, trade-offs between database structures or API designs, and testing strategy, with scenarios such as a traffic spike on a popular auction and a risky refactor of legacy code. Expect to be asked for reasons as well as facts. Pick projects where you can explain why you chose a design and what you rejected.

What to demonstrate

Hands-on engineering skill and problem-solving, as the stage is described
Command of your main language and framework, including the trade-offs of tools you have used in production
Architectural reasoning about databases, APIs and testing

How to prepare

Choose one project and prepare a whiteboard-style walk-through: components, data store, API boundaries, failure modes, and one decision you would now make differently.
Rehearse the auction traffic spike scenario: separate reads from writes, say what you would cache, what you would queue, and what must stay strongly consistent.
Prepare a refactor story with its risks: how you pinned existing behavior with tests, how you shipped in small steps and how you could roll back.

Management Conversations

Candidates describe discussions with management about your long-term impact and how your goals line up with the business. This stage reads as less about code and more about judgment: how you set priorities, work with product and design, handle disagreement, and what you want to grow into. Come with a point of view on the problems a marketplace and search team would face and with questions of your own about the team's current challenges, which candidates recommend asking.

What to demonstrate

Long-term impact and alignment with business direction, as the stage is described
Communication and collaboration with product, design and other engineers
How you set priorities and argue for things like technical debt repayment

How to prepare

Prepare a prioritisation story in which you cut or deferred something and told stakeholders why.
Prepare a story where you pushed back on a product requirement for technical reasons, including the alternative you offered.
Write three questions about the team's current problems and what success looks like for a new engineer in the first months.

Where candidates lose points

Answering the complex-challenge or proud-architecture question with a list of technology names instead of decisions

Choose one project and prepare its story as problem, constraints, two options considered, the one you chose, the result and one regret. Be ready to draw the components and the data flow from memory.

Preparing only for algorithm puzzles when candidates describe conversation-based technical stages that resemble real work

Spend most of your time on trade-offs you can defend: relational schema choices, REST API shape, pagination, caching, testing strategy and refactoring risk. Keep a small amount of coding practice, but do not let it displace this.

Giving slogans for the maintainability and scalability question, such as clean code, SOLID and microservices, with no mechanism

Name what you actually did: module boundaries, tests that pin behavior, review rules, monitoring and alerts, and one case where you measured a bottleneck before changing anything.

Giving a generic answer to what draws you to Artsy

Read what Artsy has published about its engineering and process, use the product, and pick specific things to mention. Tie them to the search, marketplace and partner-tool work candidates describe.

Telling collaboration stories in which you are always right, or that end without a result

Present the other side's reasoning fairly, say what evidence settled it, state the outcome and add what you would do differently. Do this for the disagreement, priorities and code review stories alike.

Questions & practice

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Describe a complex technical challenge you faced in a previous role and how you resolved it.

Medium · Technical and Domain Experience

Approach

Pick one problem with a measurable symptom and a cause that was not obvious at first (a p95 latency regression, inconsistent data between two services, a race condition under concurrent writes), and state the constraint that made it hard in two sentences.
Walk the diagnosis in order: how I reproduced it, what evidence narrowed it (logs, traces, a query plan from EXPLAIN ANALYZE, a profiler), the hypothesis I formed, and at least one hypothesis I ruled out and why.
Name two or three fixes I considered and the trade-off that decided it, for example an index (faster reads, slower writes) versus denormalising (duplicate data to keep in sync) versus a cache (staleness and invalidation).
Give the result as a before/after number and say how I verified it (load test, production metric), plus how I shipped it safely: feature flag, staged rollout, a rollback path.
Close with what stopped it recurring: a regression test, an alert on the symptom, or a runbook entry.

Follow-up

Which hypothesis did you rule out, and what evidence ruled it out?
What would you have done if the fix had not moved the metric?
Looking back, what would you do differently?

Which programming languages and frameworks are you most proficient in, and why?

Medium · Technical and Domain Experience

Approach

Lead with the one or two languages and frameworks I have shipped production code in, and back the claim with evidence: what I built, at what scale, and the hardest bug I fixed in that stack.
Show depth with internals rather than a list: for a web framework, the request lifecycle and how its ORM turns an association lookup into SQL (and how I catch N+1 queries with eager loading); for JavaScript or TypeScript, the event loop and how async/await schedules work on it.
Answer the why with trade-offs: dynamic typing speeds early iteration but makes large refactors riskier without tests or type hints; a batteries-included framework is fast to start but its conventions cost more to bend.
Give one case where my preferred tool was the wrong choice and what I used instead.
Map honestly to the requirements candidates describe for this role (web frameworks, relational databases, RESTful API design, with AWS and microservices as extras), name any gap and how I would close it.

Follow-up

What is a real weakness of your main framework, and how have you worked around it?
How would you become productive in a stack you have not used before?
Walk through the SQL your ORM generates for a list page that shows each item with its owner.

How do you ensure your code is maintainable and scalable?

Medium · Technical and Domain Experience

Approach

Separate the two words. Maintainable: small modules with one clear responsibility, names that state intent, and tests at the right level (unit tests for logic, integration tests for database queries and API contracts) running in CI with linting or type checks.
Scalable: measure before optimising, keep app servers stateless so they scale horizontally behind a load balancer, and move slow work (emails, image processing, third-party calls) onto a background queue.
On the database, match indexes to the actual query patterns, remove N+1 queries, and page large lists with keyset pagination (WHERE id > last_seen ORDER BY id LIMIT n), since OFFSET still reads and discards every skipped row.
For APIs, prefer additive, backward-compatible changes, version when a breaking change is unavoidable, and accept an idempotency key on writes that clients may retry.
Name the cost of overdoing it: premature abstraction and premature optimisation both make code harder to change, so I tie each investment to a measured need, and I illustrate with one example from my own work with numbers.

Follow-up

What breaks first if traffic on that endpoint grows tenfold, for example during a sudden spike such as an auction closing?
Which test would you write first for a legacy module that has none?
How do you decide when duplicated code is worth extracting?

Can you walk me through the architecture of a project you are particularly proud of?

Medium · Technical and Domain Experience

Approach

Open with the problem, the users and the scale (requests per second, data size, team size), then say exactly what I owned versus what the team built.
Trace the components along a request: client, API layer, services, datastores, cache, queue and workers, third-party integrations; describe the read path and the write path separately because their bottlenecks differ.
Explain two or three decisions with the alternative I rejected: a relational database for transactional consistency versus a document store, a synchronous REST call versus an async queue, one deployable versus several services.
Cover failure handling and operations: timeouts and retries with exponential backoff on dependencies, idempotent writes so retries are safe, the dashboards and alerts that told me it was healthy, and how it was deployed and rolled back.
End with what I would change today and the evidence behind it, which shows I evaluated the design after it shipped.

Follow-up

Where is the bottleneck at ten times the current load?
What happens to an in-flight write if a worker crashes halfway through?
Which design decision would you reverse, and what would the migration cost?

How do you stay updated with emerging technologies and apply them to your work?

Medium · Technical and Domain Experience

Approach

Name concrete, regular sources rather than 'I read a lot': changelogs and release notes of the tools I use daily, upgrade guides, RFCs or language proposals, engineering blogs, and source code of open-source libraries I depend on.
Describe a filter that starts from a problem, not from novelty: I adopt something only when it removes a pain I can name, and I check maturity, maintenance activity, licence, team familiarity and the cost of backing out.
Explain the adoption path: a time-boxed spike, a trial in a non-critical service or behind a feature flag, a comparison against a baseline metric, and a short decision record the team can review.
Give one example where I adopted a tool and measured the payoff, and one where I decided against something popular and why; the second shows judgement.

Follow-up

Tell me about a technology you chose not to adopt, and what made you decide.
How did you persuade the rest of the team to adopt it?
How did you measure whether the change paid off?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.

Approach

Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.

Follow-up

The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?

Suggested practice checklist

The week follows the three reported stages: you build your project stories first, then your stack and design reasoning, then your collaboration and management-round material, and finish with a full spoken run.

Day 1 — Map the loop and inventory your projects

Write the three reported stages (Recruiter Screen, Technical Deep-Dive, Management Conversations) and one line on what each is described as covering.
List four projects or incidents from your last roles, with your own part, the stack and a measurable result for each.
Mark which project best fits each of the technical and behavioral prompts you have been given.

Deliverable: A one-page loop map plus a project inventory with each project mapped to the prompts it can answer.

Day 2 — Hard problem and architecture walk-through

Write the complex-challenge story: symptom, diagnosis steps, fix, how you verified it, what you changed afterwards.
Sketch the architecture of your proudest project from memory: components, datastore, API boundaries, failure modes, and one decision you would revisit.
Say both answers aloud and tighten them until each stands on its own.

Deliverable: A written challenge story and an architecture sketch, each rehearsed aloud once.

Day 3 — Your stack and how you keep learning

For your main language and framework, write why you chose them, one strength, one real weakness and the situation where you would pick something else.
Write a short account of a technology you evaluated: why, how you tried it, and whether you adopted it.
Prepare a sentence on how your experience maps to web frameworks, relational databases and REST API design.

Deliverable: A stack-and-trade-offs answer and a technology-evaluation story, both ready to say aloud.

Day 4 — Maintainability, scale and the database side

List the practices that keep your code maintainable (tests, boundaries, reviews, monitoring) with one example of each from your own work.
Walk through a popular-auction traffic spike on paper: reads versus writes, caching, queueing, and what must stay consistent.
Write a legacy refactor story including how you protected existing behavior.

Deliverable: A maintainability answer with examples, a one-page spike plan, and two lessons from the practice exercises.

Day 5 — Collaboration stories

Write the technical disagreement story, covering both positions, the evidence and the outcome.
Write the story of explaining a technical concept to a non-technical colleague, ending in a decision.
Write your code review approach with one giving example and one receiving example.
Record yourself telling all three and cut anything that does not carry a decision or a result.

Deliverable: Three rehearsed stories in a situation-task-action-result shape.

Day 6 — Priorities, motivation and the management conversation

Write the competing-deadlines story with the ranking method, the thing you cut and who agreed.
Read what Artsy has shared publicly about its engineering and process, and write three specific reasons you want to work there.
Write a pushback-on-a-product-requirement story and three questions about the team's current challenges.

Deliverable: A prioritisation story, a motivation answer with three specific reasons, and three questions for management.

Day 7 — Full spoken dry run

Run all three stages back to back with a friend or a recording: career narrative, project walk-through, then management-style questions.
Take two practice items to refresh weak spots, for example the denormalise-and-backfill exercise on live data.
Review the recording and fix the two weakest answers.

Deliverable: A recorded full run, a short list of fixes, and your final question list.

Collaboration, priorities and motivation stories

Candidates describe these conversations as covering collaboration, communication with product and design, cultural fit and, in the management stage, long-term impact. For this role, show how you make and explain technical decisions with other people involved. Each story needs a decision, the reasoning and the result. Reported prompts come first.

Describe a time you had to push back on a product requirement due to technical constraints.