Frontend engineer backend interview questions

As asked

Shopify has two main APIs: the Admin API (REST and GraphQL) and the Storefront API (GraphQL only). Walk me through the key differences in authentication, data access, rate limits, and use cases. When would you specifically choose the Storefront API, and what cannot you do with it that you can do with the Admin API?

Sample answer outline

A strong answer covers: the Storefront API uses a public token safe to embed in client-side code, exposes only customer-facing data (products, collections, cart, checkout), and is designed for headless storefronts and mobile apps. The Admin API uses a private access token that must stay server-side, can access all merchant data including orders, customers, and financials, and must not be exposed to browsers. Key Storefront limitations: cannot access order history without a customer token, cannot modify fulfillment, cannot access raw metafields that are private. Rate limits are also different: Storefront has per-IP limits, Admin has per-shop bucket limits.

Expect these follow-ups

• A headless storefront needs to show a logged-in customer their order history. Which API do you use and how do you authenticate?
• You are building a mobile app for merchants to manage their shop. Which API do you use and how do you keep the token secure on a mobile device?

As asked

Shopify's Admin API is GraphQL. A merchant has 500,000 products. Write a GraphQL query that retrieves products with their first image and price, handles cursor-based pagination correctly, and explain why Shopify uses cursor-based rather than offset-based pagination at this scale.

Sample answer outline

A strong answer provides a correct cursor-based query using after and first arguments, reads the pageInfo.hasNextPage and pageInfo.endCursor from the response, and explains why offset pagination fails at scale: the database must skip N rows for each page, which becomes a full table scan at high offsets and produces drift when records are inserted or deleted mid-pagination. Cursor-based pagination is stable and O(1) to seek when the cursor field is indexed.

Reference implementation (graphql)

query GetProducts($cursor: String) {
  products(first: 50, after: $cursor) {
    edges {
      node {
        id
        title
        priceRangeV2 {
          minVariantPrice { amount currencyCode }
        }
        featuredImage { url altText }
      }
      cursor
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Expect these follow-ups

• What happens if a product is deleted between pages, and how does cursor pagination handle it compared to offset?
• How would you handle this in a client that needs to jump to page 200 without iterating through all prior pages?

As asked

X's live filtered feed (previously called the Streaming API) pushes matching tweets to clients in real time. For a new browser-based client, would you implement the connection as a WebSocket or as Server-Sent Events? Make a concrete recommendation and defend it.

Sample answer outline

A strong answer notes that SSE is simpler and natively auto-reconnecting, uses standard HTTP/2 multiplexing, and is sufficient when the client only reads (no upstream messages needed). WebSocket makes sense when the client also sends (e.g., typing indicators, collaborative features). For a read-only streaming API, SSE is the cleaner choice. The candidate should address browser limits (6 concurrent SSE connections per origin with HTTP/1.1, lifted with HTTP/2), proxy buffering issues with SSE, and back-pressure handling.

Expect these follow-ups

• Your SSE connections are being terminated by a corporate proxy after 30 seconds. How do you handle reconnection without missing tweets?
• How does the server know when to close the connection for a client whose browser tab was closed silently?