Stripe Software Engineer Interview Experience — A Fuzzy User-Matching Screen, Then a Three-Part VO

I recently interviewed at Stripe. The overall process was clear, so I wanted to share it for anyone else prepping for Stripe. I felt like I did so-so on the second round.

Phone Screen (Coding, 45min)

You're given a bunch of user data, where each row represents a user record. Each record has:

• id
• name
• email
• company

Each field has its own similarity weight, for example:

• name weight = 0.2
• email weight = 0.5
• company weight = 0.3

You're given a threshold. If the total similarity score between two records is ≥ threshold, the two records are considered to belong to the same person (a "linked user").

Input

• rows = list of user records
• weights = map(field → weight)
• threshold
• target_user_id

Output
All record ids that belong to the same person as the target user.

Example Input

rows = [
  { id: 1, name: "Alice", email: "email1", company: "Stripe" },
  { id: 2, name: "Alicia", email: "email1", company: "Stripe" },
  { id: 3, name: "Alice", email: "email2", company: "Google" },
  { id: 4, name: "Bob",   email: "email3",   company: "Stripe" }
]
weights = {
  name: 0.2,
  email: 0.5,
  company: 0.3
}
threshold = 0.5
target_user_id = 1

Follow-up 1
Don't just find directly-matching users — also find users that are indirectly matched (one hop away). For example:

• 1 matches 2
• 2 matches 3
• but 1 does not directly match 3

The output needs to include both 2 and 3.

Follow-up 2
Instead of just one hop, if you want to find all indirectly-matched users regardless of how many hops away, you need to return the entire linked component.

VO (Coding 45min, debug 50min, integration 50min)

Coding:

Implement an AccountScheduler class that determines whether a given account is available at a given point in time.

Input includes:

• a list of account ids (which accounts exist in the system)
• a dict: { account_id : locked_until_timestamp }, representing the time until which that account is locked.

Requirement: provide an interface is_available(account_id, t) that returns whether the account is available at time t. All queries happen sequentially — you can assume no concurrency.

Example Input

accounts = [1, 2, 3, 4]
locked_until = {
  1: 10,
  2: 5,
  3: 0,
  4: 20
}
# queries
is_available(1, 8)   -> False
is_available(2, 8)   -> True
is_available(3, 1)   -> True
is_available(4, 21)  -> True

Follow-up 1
Add a new method to the class: acquire(account_id, duration), which locks the account for duration starting from the current query time. For example, if the current time is t and you call acquire(2, 5), then you update locked_until[2] = t + 5.

Follow-up 2
Extend acquire to follow LRU logic: if acquire is called without specifying an account id, the system should automatically pick an available account itself — and it must pick the account that was least recently used (LRU). After acquiring, that account's locked_until gets updated.

The integration and debug rounds were bikemap and mako, respectively.

I felt like I did so-so on the second round, and I'm guessing I failed it.