Stripe SDE VO | How the Integration Round Works

What the integration interview is

From Intern to Senior, Stripe uses almost the same integration question bank — the difference is the interviewer's expectations and how far you get. The interview is usually an hour and looks nothing like a traditional LeetCode interview:

• You clone a public GitHub repository and open it in your own IDE.
• The instructions live in a GitHub issue — you can't download or copy them, so you keep switching between the browser and your IDE.

That's intentional: it simulates real development, constantly switching between reading code, debugging and checking docs, and shows how well you manage your pace under time pressure.

The interview doesn't test algorithm derivations. It's entirely about real-world integration skills:

• Can you understand existing code quickly?
• Can you extend features without breaking the structure?
• Can you read docs, make requests and parse data?
• Can you think clearly while debugging?

There are usually five parts, and almost nobody finishes all of them. Stripe knows time is tight and cares more about implementation quality, clean code, and how you react to unknown requirements. Each part moves closer to production conditions.

A frequent question: Bikemap

The context is a cycling route visualization system; you gradually build the whole pipeline from parsing data to rendering a map.

Language tip: multiple languages are supported, but past experience shows Python saves more than half the time. JSON parsing and HTTP requests are very verbose in Java or C++.

Part 1: Parse JSON and extract coordinates

Given ride-simple.json in GeoJSON format with about 500 GPS points, parse the file, extract the first ten coordinates, and print them in the required format.

Sounds simple, but the interviewer watches for:

• Sensible file-reading logic, e.g. a configurable file path
• Exception handling for robustness
• Recognizing the data hierarchy: Feature → Geometry → Coordinates

Plenty of people lose time here because the JSON is nested deeper than expected.

import json
import logging
import sys

def load_coordinates(path):
    """Read the GeoJSON file and return the route's [lon, lat] coordinates"""
    try:
        with open(path, encoding="utf-8") as f:
            data = json.load(f)
    except (OSError, json.JSONDecodeError) as e:
        logging.error("failed to read %s: %s", path, e)
        raise
    # Support both FeatureCollection and Feature at the top level
    features = data["features"] if data.get("type") == "FeatureCollection" else [data]
    for feature in features:
        geometry = feature.get("geometry") or {}
        if geometry.get("type") == "LineString":
            return geometry["coordinates"]
    raise ValueError("no LineString geometry found")

if __name__ == "__main__":
    path = sys.argv[1] if len(sys.argv) > 1 else "ride-simple.json"
    for lon, lat, *_ in load_coordinates(path)[:10]:
        print(f"{lat:.6f}, {lon:.6f}")

Common pitfall: GeoJSON coordinates are [longitude, latitude] (lon, lat) — the reverse of the usual "lat, lon" — so it's easy to flip them when printing or plotting.

Part 2: HTTP requests

Send a POST request to a given URL with a JSON body (usually similar to Part 1's output). The server returns a PNG map image, which you need to save locally.

The interviewer looks at whether you:

• Know common HTTP libraries (such as requests)
• Set headers correctly and serialize the JSON
• Log sensibly when something fails

Many people get stuck here not because of logic errors but because they're not fluent with third-party libraries, or forget to handle network errors and file paths.

import logging
import os
import requests

def fetch_map(url, coordinates, out_path="map.png", timeout=10):
    """POST the coordinates to the map service and save the returned PNG"""
    try:
        resp = requests.post(url, json={"coordinates": coordinates}, timeout=timeout)
        resp.raise_for_status()
    except requests.RequestException as e:
        logging.error("request to %s failed: %s", url, e)
        raise
    if "image/png" not in resp.headers.get("Content-Type", ""):
        raise ValueError(f"unexpected content type: {resp.headers.get('Content-Type')}")
    os.makedirs(os.path.dirname(out_path) or ".", exist_ok=True)
    with open(out_path, "wb") as f:
        f.write(resp.content)
    logging.info("saved map to %s (%d bytes)", out_path, len(resp.content))
    return out_path

The json= argument serializes the JSON and sets Content-Type: application/json for you.

Part 3: Draw the map with staticmap

Switch to the staticmap library and render the map locally: draw the route as a polyline and produce an image. The key is reading the library's docs — create a map object, add the route coordinates as a line, then render and save. Note that it also uses (lon, lat) order.

Part 4: Landmarks and the nearest point

You're given a set of landmark coordinates to mark on the map, and you need to find the landmark closest to the route.

No complex algorithm is required, but the interviewer watches whether you use data structures sensibly — plain brute force, or a more efficient spatial structure.

import math

def haversine_km(a, b):
    """Great-circle distance between two (lon, lat) points, in km"""
    lon1, lat1, lon2, lat2 = map(math.radians, (*a, *b))
    h = math.sin((lat2 - lat1) / 2) ** 2 + math.cos(lat1) * math.cos(lat2) * math.sin((lon2 - lon1) / 2) ** 2
    return 2 * 6371 * math.asin(math.sqrt(h))

def nearest_landmark(route, landmarks):
    """landmarks: {name: (lon, lat)}; returns (name, distance in km to the closest point on the route)"""
    best = None
    for name, pos in landmarks.items():
        d = min(haversine_km(pos, p[:2]) for p in route)
        if best is None or d < best[1]:
            best = (name, d)
    return best

Brute force is O(landmarks × route points). For this data size (around 500 points) it's plenty — write it first, then discuss optimizations: with more data, index the route points in a KD-tree or bucket them by geohash so each lookup only checks nearby points.

Prep tips

This interview really tests engineering thinking and real development habits, not optimal algorithms. So don't grind LeetCode — get comfortable with these Python basics:

• I/O and the file system, JSON, HTTP (requests)
• Exception handling and logging
• Modular design

Showing clean code, clear layering, solid logging and good naming often matters more than an efficient algorithm.