← Stripe Interview Insights

Stripe·Software Engineer·Technical Phone Screen·Senior

Senior
Jun 2026

Summary

Stripe technical screen for a software engineering role. One question, pretty focused on API chaining and runtime state management. Not a bad experience but the question had more depth than I expected going in.

Questions Asked (1)

Q1

You have a chain of 5 sequential API calls where the first two succeed but the last three fail because they reference a hard-coded ID instead of the one generated at runtime by the first request. You've already pulled the runtime ID from the first response. Write the substitution logic that replaces the hard-coded ID in both request URLs and request bodies before each downstream call is sent. Also discuss safe templating approaches versus naive string replacement, how to handle the ID appearing in nested JSON, and how you'd verify the substitution actually happened before sending.

API & IntegrationsTechnical Trade-offsSystem Design
Author's notes

I started with naive string replace and they immediately pushed back, which, fair.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by explaining that you would extract the runtime ID from the first response and use a templating mechanism (e.g., placeholders like {{id}}) in the downstream request definitions, then substitute the ID programmatically before each call. Emphasize that naive string replacement is error-prone and that you'd use a structured approach (e.g., JSON traversal or a templating library) to handle URLs and nested JSON bodies safely. Finally, describe verification steps such as logging the substituted values or asserting that the placeholder no longer exists before sending.

Pro tip: Mention that you'd centralize the substitution logic in a reusable function or middleware to avoid duplication and ensure consistency across all downstream calls, and that you'd write unit tests for edge cases like the ID appearing in unexpected places or as part of a larger string.

1. Extract and validate the runtime ID

Parse the first API response to extract the generated ID, and validate its format and presence to avoid propagating errors.

2. Define requests with placeholders

Represent downstream request URLs and bodies with explicit placeholders (e.g., {{id}}) instead of hard-coded values, making substitution intentional and traceable.

3. Implement safe substitution logic

Use a templating engine or recursive JSON traversal to replace placeholders only in string values, avoiding naive global string replacement that could corrupt data.

4. Verify substitution before sending

Assert that no placeholders remain and that the runtime ID appears in expected locations; log the final request for debugging.

5. Handle nested JSON and edge cases

Recursively traverse nested objects and arrays to substitute the ID, and consider cases where the ID might be part of a larger string or require URL encoding.

Key Points to Mention

  • Use of templating libraries (e.g., Mustache, Handlebars) or custom placeholder syntax for clarity and safety.
  • Risks of naive string replacement: accidental replacement in unrelated fields, injection, or partial matches.
  • Recursive traversal for nested JSON structures to ensure all occurrences are replaced.
  • Verification techniques: assertions, logging, and dry-run validation before sending requests.
  • Centralizing substitution logic in a reusable function or middleware to avoid duplication.
  • Handling URL encoding and special characters when substituting into URLs.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.