Google L4 Interview Experience & Timeline
- Posted
- 15 Jan 2026
Summary
I successfully completed a 60-minute phone interview for a Google L4 role, where I solved a multi-part coding question related to fraud detection, and subsequently advanced to virtual onsite rounds with Stripe.
How it went
I’d like to share a complete new coding question from a recent phone interview. I passed this round smoothly and advanced to the next three Stripe VO rounds.
The interview lasted 60 minutes. The introduction was very brief—just a couple of sentences were enough. The coding part took about 45 minutes and was structured into multiple parts/levels. Each new part was unlocked only after finishing the previous one. The interview focused on developing a fraud detection system incrementally through four distinct parts.
Questions asked (4)
- 01
Verify Transaction Data Integrity
Data Structures & Algorithms
This part focused on building the foundation of fraud detection by validating basic data integrity.
The problem description was quite long, but the logic itself was straightforward. We read six fields from a CSV file representing a transaction and verify that all fields are non-empty.
- 02
High-Risk Rule Validation
Data Structures & Algorithms
In the second part, two core risk-control rules were added on top of the basic transaction validation:
- Amount rule: the transaction amount must fall within a predefined valid business range.
- Payment method rule: the payment method must not appear in a blocked method list.
If any of these conditions is violated, the transaction is marked as SUSPICIOUS.
- 03
User Behavior Matching
Data Structures & Algorithms
The third part required validating whether the transaction matches the user’s behavioral baseline.
We needed to ensure that at least 50% of the transaction’s behavioral features (such as commonly used countries, typical time ranges, and average transaction amount ranges) matched the user’s historical behavior.
The implementation involved feature extraction, normalization, and calculating a match ratio.
If the match ratio was below 50%, the transaction was considered a behavior mismatch and marked as SUSPICIOUS.
- 04
Smart Fraud Error Reporting
Data Structures & Algorithms
The final part implemented smart error reporting, replacing the generic “SUSPICIOUS” label with specific error codes.
The system outputs up to two error codes, ordered by priority.
If no errors are detected, the output is “OK”.
The final report must maintain proper column alignment to ensure readability.