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.
Recruiter Screen
reportedCandidates 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
reportedCandidates 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.
- Use PracHub's keyset paging exercise and the listing-latency debugging exercise to keep relational and API reasoning sharp.
Management Conversations
reportedCandidates 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.
PracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Collapse a redelivered event batch into per-aggregate high-water marks
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
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
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
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
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.
Describe a complex technical challenge you faced in a previous role and how you resolved it.
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?
Which programming languages and frameworks are you most proficient in, and why?
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?
How do you ensure your code is maintainable and scalable?
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?
Can you walk me through the architecture of a project you are particularly proud of?
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?
How do you stay updated with emerging technologies and apply them to your work?
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
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?
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. PracHub's SQL and debugging exercises are used for the database and API side.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map 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.
02Hard 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.
Practice prompt ↗Practice prompt ↗03Your 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.
Practice prompt ↗Practice prompt ↗04Maintainability, 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.
- Work PracHub's keyset paging exercise and the listing-latency debugging exercise, then write the lesson from each in two sentences.
- 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Collaboration 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Priorities, 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.
Practice prompt ↗Practice prompt ↗07Full 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.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
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.
How do you handle disagreements with teammates regarding technical implementations?
How do you handle disagreements with teammates regarding technical implementations?
Approach
- Choose a real technical disagreement with a clear decision attached, such as schema design, a synchronous versus queued flow, or a library choice, not a personality clash. Give the situation in two sentences.
- State the other person's position fairly, in terms they would accept, then name the criteria you both cared about: latency, operational cost, how hard it is to reverse, delivery date.
- Show how you moved from opinion to evidence: a small spike, a benchmark, a look at an earlier incident, or a written comparison shared in the pull request or a design document.
- Say how the decision was made (agreement, a tech lead, a time-boxed trial), that you committed to it fully, and what happened afterwards, including if you turned out to be wrong.
- Avoid the story where you were right and a colleague learned from you. The strongest versions end with a decision better than either starting position.
Follow-up
- What would you have done if the evidence had been inconclusive?
- Tell me about a time you lost the argument. How did you act afterwards?
- How do you keep a disagreement from turning into a delay for the team?
Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder.
Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder.
Approach
- Pick a concept that mattered to a decision, for example why a price or availability value on screen can be briefly stale, why a migration pushes a launch date, or why a feature needs rate limiting. A concept with no consequence makes a weak story.
- Start from the listener's goal. Say who the stakeholder was (a product manager, gallery partner or executive), what they needed to decide, and what they already understood.
- Explain it with one analogy or a simple diagram, then translate the impact into their terms: money, risk, customer experience or date, with the options and your recommendation.
- Show how you checked understanding, for example by asking them to restate the trade-off or by following up in writing, and what decision resulted.
- The mistake that sinks this answer is either burying them in jargon or simplifying so far that no decision follows. Name what you deliberately left out.
Follow-up
- How did you know they understood and were not just nodding?
- What did you do when they disagreed with your recommendation?
- How would you explain the same thing to a new engineer, and what would change?
How do you prioritize your work when faced with competing deadlines?
How do you prioritize your work when faced with competing deadlines?
Approach
- Lead with the method, then show it on a real case. List everything competing, with deadline, impact on users or revenue, cost of delay, dependencies and who is waiting on it.
- Separate truly fixed dates from soft ones by asking stakeholders directly, then rank by cost of delay per unit of effort. A production defect on a checkout or bidding flow generally outranks a nice-to-have feature, and you should say why.
- Negotiate scope instead of working longer: split the work, ship a smaller first version, defer a piece, or ask for help. Tell affected people early and put the trade-off in writing.
- Finish with the result and what you changed afterwards, such as a shared priority list or a regular check with the product manager.
- Avoid answers that say you simply work harder or keep a to-do list. Show a deliberate decision to drop or delay something, and who agreed to it.
Follow-up
- Two stakeholders both say their request is top priority. How do you resolve it?
- How do you make room for technical debt when the roadmap is full of product work?
- Describe a time you misjudged priorities. What did you change?
What draws you to Artsy specifically, beyond the technical challenge?
What draws you to Artsy specifically, beyond the technical challenge?
Approach
- This is a motivation question, so a STAR story is not the right shape. Give two or three specific reasons, each backed by something you did or read, and keep the technical challenge out of it as the prompt requires.
- Ground the reasons in what you can verify: the product is a place to discover, learn about and collect art; candidates mention public repositories and an engineering blog. Name one thing you read or used and your honest reaction to it.
- Connect your own history to the subject, whether that is time spent with art, galleries or collecting, or experience with marketplaces and search. If you have none, say what you found interesting when you first used the product.
- Link it forward to the work: search, marketplace transactions and partner tools are the engineering areas candidates describe, so say which you want to work on and why.
- Avoid generic phrases about mission or passion that would fit any employer, and avoid reasons that are only about perks or stack.
Follow-up
- What have you used or read from Artsy, and what would you improve?
- Where would you like to be in two or three years, and how does this role get you there?
- What would make you leave an art-focused company for a larger tech employer?
How do you approach giving and receiving constructive feedback during code reviews?
How do you approach giving and receiving constructive feedback during code reviews?
Approach
- Cover both directions with one example each. For giving feedback: keep pull requests small to review, comment on behavior and risk rather than taste, say why, mark which comments block merging and which are optional, and offer a concrete alternative.
- Leave style to linters and formatters so human review time goes to correctness, edge cases, tests, naming and design.
- For receiving feedback: assume good intent, answer every comment (change, or explain), separate preference from defect, and push back with evidence such as a test or a measurement. Move long threads to a short call and write down the result.
- Use a story where a review changed the outcome, for example a reviewer caught a missing edge case or a migration risk, and say what you learned and what habit changed.
- Avoid saying you never disagree or that reviews are just a formality. A concrete example of a comment you disagreed with, and how you settled it, is more convincing.
Follow-up
- A reviewer blocks your pull request over a style point you disagree with. What do you do?
- How do you review a very large change from a colleague?
- How do you give hard feedback to someone more senior than you?
- 01
How do you handle disagreements with teammates regarding technical implementations?
- 02
Tell me about a time you had to explain a complex technical concept to a non-technical stakeholder.
- 03
How do you prioritize your work when faced with competing deadlines?
- 04
What draws you to Artsy specifically, beyond the technical challenge?
- 05
How do you approach giving and receiving constructive feedback during code reviews?
- 06
Describe a time you had to push back on a product requirement due to technical constraints.
How many rounds are there and how long does the process take?
Candidates report three stages, a Recruiter Screen, a Technical Deep-Dive and Management Conversations, spread over roughly three to five weeks. Some candidates say to budget one to two months from first screen to decision. If you go quiet for a while, candidates suggest a polite follow-up to your recruiter.
Artsy Software Engineer candidate reports ↗Is the technical interview algorithm-heavy?
Candidates describe it as conversational and close to real work rather than puzzle-based. Expect to discuss design patterns, database and API trade-offs, testing and scenarios such as a traffic spike or a legacy refactor. Prepare through your own projects, and keep light coding practice for confidence.
Artsy Software Engineer candidate reports ↗Which technologies should I prepare?
Requirements candidates describe are a modern web development framework, relational databases and RESTful API design, with AWS, microservices and experience on high-traffic consumer applications as extras. Specifics can vary by team, so be ready to discuss the stack you know best and why.
Artsy Software Engineer candidate reports ↗How should I answer what draws me to Artsy?
Use specifics: something you read in their public engineering material or used in the product, and the engineering area you want to work on, such as search, marketplace transactions or partner tools. Generic statements about art or mission are easy to spot.
Artsy Software Engineer candidate reports ↗Will I meet several people in one sitting?
Candidates say it is common to meet several team members in one block of time. Prepare a short, consistent project story you can repeat, and keep a few different examples ready so each conversation covers new ground.
PracHub Software Engineer practice ↗Is there public material I should read before interviewing?
Candidates report that Artsy has shared details of its interview process and engineering work through public repositories and an engineering blog. Read them before the technical stage, note anything you can discuss with real opinions, and ask questions about the team's current challenges.
Artsy Software Engineer candidate reports ↗What if I have under 3 years of experience?
Candidates describe successful applicants as typically having 3+ years, with growing responsibility. If you have less, choose projects where you made real decisions, can show ownership from design to monitoring, and can discuss trade-offs in depth.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Artsy Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Lambda Software Engineer Interview Guide
Failure-handling practice for Lambda software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.