Shopify

Shopify is the canonical example of the open-ended, Bring-Your-Own-Environment format. They tell you to use whatever you'd normally use at work — your IDE, your AI tools, your whole setup — and share your screen.

What that means

The upside is that you're working with tools you already know: no unfamiliar interface under pressure, and you can fall back on workflows you've built over time. The downside is that the interviewer sees everything — your prompts, your fumbling between tools, the moment you paste something into the wrong window. There's no hiding behind a platform.

The problems are greenfield

You might get an empty repository and a problem statement, or just a README describing what to build. You start from nothing and build a working application. The emphasis shifts from "can you navigate existing code" to "can you design and build something from scratch with AI as your accelerator."

That tends to pull in low-level design skills: modeling your entities before writing logic, making the system functional and extensible, even when the majority of the implementation is handled by the AI. Decomposition matters more here than in any other format, because there's no existing code to keep you honest.

The pairing vibe

Interviewers at Shopify specifically want the session to feel like a pairing session — not like watching someone chat with a bot. That's a communication directive: talk through what you're doing as you do it, the way you would with a pair partner. You wouldn't silently type at a partner for five minutes and then show them the result.

The rhythm that lands: state intent → prompt → review the output aloud → move on. When the AI pauses, use the wait time to talk through your approach instead of staring at the spinner.

How to prepare

Tactical checklist

1. Model the entities and data structures before touching the AI.
2. Write tests against your intended interface first — agree on the cases with the interviewer.
3. Decompose into 3–5 prompt-and-verify steps; don't ask for the whole app at once.
4. Narrate intent before each prompt and review output aloud.
5. Commit frequently so you can roll back bad generations.
6. Run the tests after every meaningful change.