How to Pass the CRED Machine Coding Round

If you're interviewing for a backend engineering role at CRED, you probably already know their code quality bar is incredibly high. They aren't just looking for someone who can invert a binary tree on a whiteboard. They want engineers who can take ambiguous business requirements and turn them into extensible, production-ready code—all in under two hours. The machine coding round acts as the ultimate filter in their hiring pipeline. You're dropped into an IDE with a complex domain problem, and you're expected to walk away having built a fully functional, object-oriented, thread-safe system. We're going to break down exactly how to survive and dominate this interview stage by tackling one of their most notorious prompts: the dynamic Payment Recommendation System.

Inside CRED's High-Bar SDE-2 Interview Process

CRED designs their interview process to simulate actual engineering challenges. They index heavily on low-level design, concurrency, and your ability to write code that handles future business rules without massive refactors. Before we jump into the payment system's architecture, let's look at where the machine coding round actually fits within the broader interview loop.

What happens in the CRED machine coding round?

This round typically lasts between 90 and 120 minutes. You get a problem statement and need to write working code in whatever language you prefer. You can't rely on external databases or frameworks like Spring Boot, meaning everything has to live in memory. The final 30 minutes are set aside for a code review. The interviewer will ask you to run your code, prove it handles edge cases, and defend your specific design patterns. They'll also frequently toss in a surprise requirement right at the end just to see if your architecture violates the Open/Closed Principle.

What is the Payment Recommendation System problem?

The prompt usually looks something like this: build a system that recommends the most relevant payment instruments to a user during checkout. A user might have multiple payment instruments tied to their account—Credit Cards, UPI, a CRED Coin Balance, or Debit Cards. Given a specific user ID and a cart value, your system needs to return a sorted list of payment methods based on a dynamic set of rules.

• Rule 1: If the cart value is greater than a specific limit, certain instruments (like a low-limit UPI) should be filtered out.
• Rule 2: If the user's CRED Coin balance covers at least 50% of the cart value, CRED Pay should be boosted to the very top.
• Rule 3: Credit cards with active partnerships or discounts for the current merchant should rank higher.
• Rule 4: Expired credit cards must be completely removed from the recommendation list.
• Rule 5: These rules must be configurable and easy to add or remove without touching the core recommendation engine.

How do I model the domain for a payment recommendation system?

Domain modeling is ultimately where you win or lose this round. If your entities are tightly coupled, or if you rely on primitive types to represent complex concepts, the interviewer is going to notice immediately. Start by identifying the nouns in the problem statement.

• User: Represents the customer. It contains a unique ID and a list of PaymentInstruments.
• PaymentInstrument: An abstract class or interface. Implementations include CreditCard, Upi, and CredCoinWallet. Each one has properties like 'isExpired', 'balance', or 'limit'.
• Cart / CheckoutContext: Encapsulates the current transaction. It contains the cart amount, the merchant ID, and the User.
• Recommendation: The output object containing the sorted list of PaymentInstruments, along with metadata explaining exactly why they were chosen.

What design patterns should I use for the rule engine?

The most common mistake candidates make here is hardcoding the business logic with massive if-else blocks inside a 'RecommendationService' class. That completely violates the Open/Closed Principle. If the interviewer asks you to add a new rule for 'Debit Cards', you'd have to modify the core service logic, which immediately risks regressions.

Instead, try architecting the system using a two-phase Rule Engine that combines the Strategy Pattern with the Chain of Responsibility. Phase 1 handles Filtering (removing invalid options), while Phase 2 handles Scoring (ranking the valid options).

• Create a 'PaymentFilter' interface with a method 'boolean isValid(PaymentInstrument, CheckoutContext)'. Implementations include 'ExpiryFilter' and 'LimitFilter'.
• Create a 'PaymentScorer' interface with a method 'int calculateScore(PaymentInstrument, CheckoutContext)'. Implementations include 'CredCoinScorer' and 'MerchantDiscountScorer'.
• Build a 'RecommendationEngine' class injected with a List<PaymentFilter> and a List<PaymentScorer>.
• During execution, the engine iterates over all available instruments. It applies every filter. If an instrument passes, the engine applies all scorers, aggregates the score, and sorts the final list.

This architecture is practically bulletproof. When the interviewer inevitably asks you to add a new rule during the review phase, you just create a new class implementing 'PaymentScorer', add it to the injected list in your main method, and run the code. You make zero changes to the core engine.

How should I handle concurrency and in-memory thread safety?

CRED expects backend engineers to understand concurrency on a deep level. Since you aren't using a database, your in-memory data stores (like a UserRepository) will be accessed by multiple threads if we assume a concurrent web server environment. You have to demonstrate how you'd prevent race conditions, especially around deducting balances or updating limits.

Don't just slap the 'synchronized' keyword on every single method. That creates a massive bottleneck. Instead, use 'ConcurrentHashMap' for your repositories. For entity-level locking—like when two concurrent checkout requests try to deduct CRED coins from the same user—use a 'ReentrantLock' inside the User entity. You could also leverage the atomic operations of ConcurrentHashMap, such as 'computeIfPresent', to handle thread-safe updates without explicit locking blocks. Just be prepared to explain the tradeoffs between pessimistic locking (ReentrantLock) and optimistic locking (using version numbers or atomic variables) during the review.

How do I write a test suite that passes the CRED bar?

Your beautiful architecture is completely useless if it can't be verified. You won't have time to write a massive JUnit suite, but you absolutely must write a robust driver class (a main method) that clearly shows the system working. Don't waste 30 minutes writing a command-line parser with Scanner. Hardcode the setup and execution flows to prove your logic works.

• Test Case 1: Happy Path. The user has a valid CC, UPI, and CRED coins. The cart is 500. Ensure CRED coins score the highest.
• Test Case 2: Expiry Filter. The user has an expired CC. Ensure it is completely absent from the final recommendation list.
• Test Case 3: Limit Filter. The cart is 10,000. The user's UPI limit is 5,000. Ensure UPI gets filtered out.
• Test Case 4: Tie-breaking. Two instruments get the exact same score. Ensure there's a deterministic fallback, like sorting by instrument ID or a default priority enum.

How do I drive the post-coding architecture review?

The 30-minute review is where you actually secure the offer. The interviewer will ask you to walk through your code. Start right from the domain models, explain your design patterns—like Strategy and Chain of Responsibility—and then run the driver code to prove it works. Own the narrative. Don't wait for them to find flaws; be proactive and point out the specific tradeoffs you made.

For example, you might say: 'Because I separated the filters and scorers, evaluating rules is currently O(F + S) per instrument, where F is filters and S is scorers. If the number of rules grew to thousands, I'd optimize this by introducing a caching layer for static rules or using a rete algorithm. For the current scale, though, this linear evaluation provides the best balance of simplicity and extensibility.' Explaining your thought process like this shows immense engineering maturity.

Final Thoughts on the CRED Machine Coding Round

Passing the CRED SDE-2 machine coding round really comes down to proving you can write code that survives the real world. By focusing on strong domain modeling, decoupling business logic with the Strategy pattern, ensuring thread safety with concurrent data structures, and proving your code with a deterministic driver, you'll stand out from the vast majority of candidates who just write massive procedural scripts. Practice building this exact system from scratch a few times, and you'll walk into the interview ready to crush it.