Stripe·Software Engineer·Online Assessment (OA)·Intermediate

Intermediate

Jun 2026

Summary

Stripe SWE interview with a KYC verification logic problem. You get a set of business account records and a blocklist, and you have to implement a multi-rule validation pipeline that outputs VERIFIED or NOT_VERIFIED per record. Fairly involved for what sounds like a straightforward coding task.

Questions Asked (1)

Given a list of business account records, each containing 6 KYC fields including business_name, business_full_name, and full_statement_descriptor, plus a blocklist of generic descriptors, implement a function that outputs VERIFIED or NOT_VERIFIED for each record. The rules are: all 6 fields must be present and non-empty; full_statement_descriptor must be between 5 and 31 characters inclusive; full_statement_descriptor must not match any blocklist entry (case-insensitive); and at least 50% of the words in either business_name or business_full_name must appear in full_statement_descriptor (case-insensitive). Any rule violation means NOT_VERIFIED.

Algorithms & Data StructuresTechnical Trade-offsAPI & Integrations

Author's notes

The word overlap rule is where things get slippery.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and edge cases, then outline a validation pipeline that checks each rule in order, short-circuiting on failure. Discuss how to structure the code for readability and testability, and mention potential optimizations like pre-processing the blocklist for O(1) lookups.

Pro tip: Emphasize the importance of case-insensitive comparisons and precise word matching (e.g., using regex word boundaries) to avoid false positives/negatives, and suggest writing unit tests for each rule to ensure correctness.

1. Clarify requirements and edge cases

Ask questions to confirm field names, blocklist format, and how to handle special characters or multiple spaces. Clarify whether 'words' are split on whitespace and if punctuation should be ignored.

2. Design validation logic

Plan a function that iterates over records and applies rules sequentially: check all fields present and non-empty, validate descriptor length, check against blocklist, and compute word overlap. Use early returns for efficiency.

3. Implement helper functions

Create utilities for case-insensitive comparison, word extraction (e.g., splitting on non-alphanumeric characters), and percentage calculation. Pre-process the blocklist into a set for O(1) lookups.

4. Handle edge cases and test

Consider empty strings, whitespace-only fields, descriptors with punctuation, and words that appear as substrings. Write unit tests for each rule and integration tests for the overall function.

5. Discuss trade-offs and optimizations

Talk about time/space complexity, potential for parallel processing if the list is large, and whether to use regex for word matching vs. simple splitting. Mention maintainability and extensibility.

Key Points to Mention

Case-insensitive comparisons for blocklist and word matching
Word tokenization strategy (e.g., splitting on whitespace/punctuation)
Efficient blocklist lookup using a set or hash map
Short-circuit evaluation to avoid unnecessary checks
Handling of edge cases like empty fields, whitespace, and special characters
Unit testing each rule and the overall function

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