Shopify Software Engineer Interview Guide 2026: Pair Programming, Craft Assessment, Life Story, and Team Match

Shopify software engineer interview preparation needs more than a list of stages. You should be able to solve a small problem with another engineer, explain a decision in a project you owned, and describe what changed your thinking. This guide turns those goals into a worked pairing session, a tested implementation, and a practical debrief.

The CSV exercise, dialogue, and Life Story excerpt below are original fictional practice material. They are not Shopify's private assessment, candidate testimony, or hiring rubric. Use your recruiting invitation to confirm the actual tasks and tool permissions.

What does Shopify publicly confirm about interviews?

Shopify's Careers FAQ says the number and order of interviews vary by role and team. Its public outline includes an initial call, Craft Assessment, Life Story, and meetings with prospective coworkers. For R&D applicants, it describes going directly to pair programming before Life Story.

Publicly described conversation	Typical published length
Initial call, when applicable	15–30 minutes
Craft Assessment	60–75 minutes; also a brief predictive assessment
Life Story	30–60 minutes
Meet the team	3–5 coworkers, up to an hour each

These ranges do not establish your total timeline or a universal SWE exercise. Ask recruiting about your sequence, language, editor, preparation materials, and AI permissions. The public FAQ does not specify one tool policy for every coding session. Shopify's workplace use of AI is not permission to use it in an assessment.

The mock here supplies its own precise contract; compare it with the question you receive rather than silently importing assumptions.

Pairing mock: turn a CSV into a valid gift assignment

Set aside 45 minutes for this practice session. That is our rehearsal timebox, not a claimed Shopify interview duration. One person implements; the other asks questions, changes a requirement, and checks whether the discussion stays collaborative.

Initial task: read participants from CSV and return a mapping from giver ID to recipient ID. Everyone gives once, everyone receives once, and nobody gives to themselves. The result should be repeatable for the same input. Randomness, email delivery, and a user interface are outside this first slice.

id,name,household
a,"Ana, Jr.",red
b,Bo,red
c,Chen,blue
d,Dia,green

Clarify what identifies a person. Names can contain commas and need not be unique; IDs must be unique. Ask whether reciprocal pairs are allowed, whether one large cycle is required, and what happens when no assignment exists. For this mock, reciprocal pairs are allowed and a single cycle is not required. Invalid input or an impossible complete assignment raises ValueError instead of returning partial results.

At minute 18, the partner adds: people in the same household cannot exchange gifts. Ana and Bo therefore cannot receive from each other. A solution that merely rotates a sorted list may stop satisfying the contract. The useful response is to reassess the model, preserve valid parsing, and introduce a targeted test.

What a useful collaboration exchange sounds like

Candidate: “I'll use IDs as keys and a CSV parser for quoted fields. Before assigning recipients, can two people give to each other?”

Partner: “Yes. Repeatable output matters more than randomness.”

Candidate: “Then a deterministic matching is enough. I'll test that recipient IDs form the same set as giver IDs and that every pair is non-self.”

Partner: “Now exclude people in the same household.”

Candidate: “That changes the allowed edges, not the parser. A greedy recipient choice could paint us into a corner. I'll let a later giver reassign an earlier giver through an alternating path. Can we return an error if no complete assignment exists?”

Partner: “Yes. Show me a case where it is impossible.”

Candidate: “Two participants from one household have no allowed edge. I'll add that test before adjusting the implementation.”

The dialogue makes decisions visible without narrating every keystroke. It also gives the partner room to disagree. If they prefer a simpler initial cycle, implement that slice and explain why the household follow-up warrants a different algorithm.

A complete implementation for the agreed contract

Python's standard CSV reader handles quoted commas and quoted newlines. Do not split a row on commas. Here we require the exact three-column header, trim surrounding field whitespace, reject duplicate IDs or empty fields, and accept 2–200 people. Blank records are skipped; malformed nonblank records fail.

import csv
import io

def parse_people(text):
    if type(text) is not str:
        raise ValueError("CSV must be text")
    try:
        rows = list(csv.reader(io.StringIO(text, newline=""), strict=True))
    except csv.Error as exc:
        raise ValueError("malformed CSV") from exc
    if not rows or rows[0] != ["id", "name", "household"]:
        raise ValueError("expected id,name,household header")
    people = {}
    for row in rows[1:]:
        if not row:
            continue
        if len(row) != 3:
            raise ValueError("expected three fields")
        ident, name, household = (field.strip() for field in row)
        if not ident or not name or not household or ident in people:
            raise ValueError("blank field or duplicate id")
        people[ident] = (name, household)
    if not 2 <= len(people) <= 200:
        raise ValueError("expected 2 to 200 people")
    return people

def assign(people, avoid_household=False):
    if type(avoid_household) is not bool:
        raise ValueError("avoid_household must be boolean")
    ids = sorted(people)
    owner = {}  # receiver id -> giver id

    def augment(giver, seen):
        for receiver in ids:
            if receiver == giver or receiver in seen:
                continue
            if avoid_household and people[giver][1] == people[receiver][1]:
                continue
            seen.add(receiver)
            if receiver not in owner or augment(owner[receiver], seen):
                owner[receiver] = giver
                return True
        return False

    for giver in ids:
        if not augment(giver, set()):
            raise ValueError("no complete assignment")
    result = {giver: receiver for receiver, giver in owner.items()}
    return {giver: result[giver] for giver in ids}

Call assign(parse_people(csv_text), avoid_household=True) for the follow-up. assign expects the validated participant dictionary. Sorting IDs makes iteration repeatable even when CSV row order changes. It does not create a uniformly random gift exchange.

Think of givers and receivers as separate sides of a bipartite graph. An allowed edge joins a giver to an eligible receiver. owner records the current matching. If a receiver is taken, an augmenting search attempts to move its current giver elsewhere. A fresh seen set for each search prevents repeatedly exploring the same receivers.

For the four-person fixture, the actual results were:

Giver	Initial contract	Household restriction enabled
a: Ana	c: Chen	d: Dia
b: Bo	d: Dia	c: Chen
c: Chen	b: Bo	b: Bo
d: Dia	a: Ana	a: Ana

Other complete assignments can also be valid. Explain the invariants rather than claiming this particular arrangement is uniquely correct. If one large cycle becomes a requirement, this bipartite matching alone is insufficient: it permits multiple cycles, including reciprocal pairs.

What was tested?

The local Python suite passed 1,111 checks. It compared the household-aware matcher with an independent brute-force permutation oracle for 1,089 household configurations, covering 2–6 people and three household labels. That verifies both valid assignments and correct rejection when a complete assignment is impossible.

Other checks covered quoted commas, quoted newlines, CRLF input, blank records, malformed quotes, wrong headers, missing fields, duplicate IDs, deterministic output after row-order reversal, and invalid option types. This is small-instance functional testing, not a performance benchmark or a proof that a real import service is production-ready.

In a dense graph, this straightforward augmenting-path approach takes O(n³) worst-case time. Matching state and recursive depth use O(n) space; we generate possible edges rather than storing an O(n²) adjacency matrix. The parser reads the whole CSV into memory. A production import needs input-byte and row limits before full materialization, privacy controls, and an explicit response for invalid batches.

Debrief the session with observable evidence

Use this original practice scorecard. It is not Shopify's hiring scorecard. Award 0 for absent evidence, 1 for incomplete evidence, and 2 for clear evidence in each row.

Dimension	Evidence worth two points
Contract	Clarified identity, cycles, invalid data, impossible output
Implementation	Produced complete assignments without violating eligibility
Verification	Used expected outputs and an independent feasibility check
Adaptation	Added the household rule without damaging CSV handling
Collaboration	Invited feedback and explained the changed model
Limits	Named deterministic behavior, cycle limits, and import boundaries

A total out of 12 helps track your own practice; it predicts no hiring outcome. Record one moment when your partner's question changed the solution. If you completed the code but missed the single-cycle assumption, practice contract questions again before increasing task difficulty.

How should you prepare for the Craft Assessment?

Prepare two projects where you can move from a brief overview to technical depth. For each, draw the boundary, identify a constraint, compare alternatives, explain your individual contribution, and describe how the change was tested and operated.

Shopify's Careers page emphasizes product thinking and craft. Connect your technical decisions to a merchant, buyer, developer, or operational need. For example, explain why an import should report errors before sending gifts, rather than celebrating a matching algorithm while ignoring user mistakes.

Keep backend, frontend, and infrastructure examples relevant to your role. A frontend discussion might cover accessible validation and upload progress; a backend discussion might cover idempotent processing and delivery failures; infrastructure could focus on resource limits and isolation. These are rehearsal routes, not claims about the exact assessment you will receive.

Build a Life Story around decisions and learning

Choose six to eight real turning points. For each, note what you wanted, what you decided, what happened, and what changed afterward. Include a difficult outcome you can discuss without blaming colleagues. Keep factual results separate from what you hoped would happen.

This fictional model excerpt illustrates reflection; replace every fact with your own experience:

“On a small team, I rushed an import feature because the first customers needed it quickly. I chose a simple synchronous implementation. It worked for our test files, but larger customer files exposed weak error reporting. I owned the validation change and worked with support to make failures actionable. That taught me to ask about real input shapes before committing to the happy path. In my next project, I wrote the failure cases into the design review before implementation.”

The useful material is the decision, cost, ownership, and changed behavior. A follow-up could ask why you chose synchronous processing, which evidence justified changing it, or what your teammates contributed. Have honest answers rather than a polished story that collapses under questions.

Use team match to evaluate the work

Bring a consistent introduction and questions that reveal operating conditions. Ask which problem the team owns, how designs are reviewed, how incidents are handled, and what strong performance looks like after six months. Ask how distributed colleagues pair and resolve disagreement.

Listen for concrete examples. “We move fast” tells you less than a recent tradeoff and its consequences. Differences in perspective can be normal; unresolved ownership or conflicting success criteria deserve a follow-up.

A seven-day preparation plan with finished outputs

Day	Task	Output
1	Confirm the loop and allowed tools	Questions for recruiting and a stage-specific schedule
2	Pair on the initial CSV contract	Parser, assignment, and boundary tests
3	Introduce the household follow-up	Revised matcher and an impossible-case check
4	Discuss a production hardening scenario	Prioritized risks, tests, and a rollout decision
5	Rehearse craft and Life Story	Two project diagrams and real turning-point notes
6	Practice team conversations	Questions for a peer, manager, and partner
7	Repeat the mock and review	Scorecard evidence and three specific next actions

Additional rehearsal topics include rover movement, a URL-caching service, product-photo uploads, and an in-memory filesystem. Use them to practice state transitions, failure handling, API boundaries, and modeling. None is a prediction of your assigned problem. Repeat a task after feedback so you can see whether the improvement survives a changed constraint.

Common questions

Is the pairing exercise in this guide a Shopify question? It is an original mock with an explicit contract, informed by transferable CSV and matching practice. No private assessment is claimed.

Should I optimize for algorithm speed? Finish a correct slice, test it, and communicate decisions. Speed is useful when it leaves time for verification rather than hiding unexamined assumptions.

Does the matcher produce random assignments? No. It is deterministic. A fairness or random-sampling requirement needs a separate design and verification plan.

What if I receive a hint? Explain which assumption it changes, revise the smallest affected part, and test the new behavior. Treat the hint as collaboration, then show the resulting reasoning.

Sources and scope

Reviewed October 8, 2026. Public guidance establishes broad process details; your invitation establishes your assessment. All code, dialogue, diagrams, and scores in the mock are original practice material.

• Shopify Careers FAQ — public stages, typical lengths, and variation.
• Shopify Careers — product thinking, craft, and working context.
• How Shopify scales development teams — historical September 26, 2019 context on pairing and engineering collaboration; not a current format guarantee.
• Python CSV documentation — quoting, reader behavior, and newline handling.