SRP in Interviews: Common Questions and Machine Coding

Typical Interview Questions

Question 1: "Design a Library Management System following SOLID principles."

Approach: Identify actors first. Librarians manage inventory (add books, track copies). Members borrow and return books. Accountants calculate late fees. These are three responsibilities, so create InventoryManager, BorrowingService, and FeeCalculator. Explain that Book itself is a data entity and does not need splitting because it represents a single domain concept, not a behavior.

Question 2: "Your colleague created a User class that handles authentication, profile management, and notification preferences. What is wrong?"

Approach: Identify the three actors. Security team owns authentication (password policies, MFA). User Experience team owns profile (display name, avatar). Marketing team owns notification preferences (email frequency, channels). Changes from one team should not affect the others. Propose AuthenticationService, UserProfile, and NotificationPreferences as separate classes.

Question 3: "How do you decide if a class violates SRP?"

Approach: Use the "axis of change" test. List all reasons the class might change. If reasons come from different sources (different teams, stakeholders, or business processes), it violates SRP. Then use the "describe it in one sentence" test. If you need "and" to describe it ("manages inventory AND calculates fees"), it likely violates SRP.

Machine Coding Considerations

In timed machine coding rounds (45-90 minutes), you must balance SRP with delivery speed. Here is a pragmatic approach:

Phase 1 (First 20 minutes): Start with coarser classes. Create ParkingLot, Vehicle, Ticket as your core. Get basic park and exit functionality working. This proves you can deliver.

Phase 2 (Next 20 minutes): Identify the most volatile responsibility. Usually fee calculation because interviewers love asking "what if pricing changes?" Extract FeeCalculator as a separate class. Show you can refactor toward SOLID when time allows.

Phase 3 (Final 20 minutes): If time remains, extract one more responsibility like SpotManager. Document TODOs for others: "In production, I would extract PaymentProcessor and TicketValidator."

Common Follow-Up Questions

Follow-Up 1: "Your design has many classes. Is not this over-engineered?"

Answer: Acknowledge the concern, then explain benefits. "For a solo project, this might be excessive. But in a team setting, SRP allows the pricing team to deploy fee changes without waiting for the operations team to finish spot allocation features. It also simplifies testing because I can unit test FeeCalculator without mocking databases or payment gateways." Show you understand context matters.

Follow-Up 2: "What if FeeCalculator and SpotManager both need access to current occupancy?"

Answer: "Shared data does not violate SRP. Both classes can depend on a ParkingLotState or OccupancyTracker that provides read-only occupancy data. The key is that FeeCalculator does not modify spot allocation, and SpotManager does not calculate fees. They read shared state but own separate behaviors."

Follow-Up 3: "How does SRP relate to microservices?"

Answer: "SRP applies at multiple levels. At the class level, it means one responsibility per class. At the service level, it means one business capability per service. However, not every SRP class becomes a microservice. That would create distributed monolith issues. Microservices group related SRP classes (like FeeCalculator, DiscountEngine, and PricingPolicy) into a Pricing Service when they share data and change together." This shows you understand LLD is NOT system design, but can discuss the boundary.

Code Smells Interviewers Look For

Smell 1: Method names like saveAndCalculate() or processAndNotify(). The "and" indicates multiple responsibilities in one method or class.

Smell 2: Classes importing packages from unrelated domains. If ParkingSpot imports email libraries or database drivers, it is doing too much.

Smell 3: Many mocks in unit tests. If testing parkVehicle() requires mocking database, email service, payment gateway, and logger, the class has too many responsibilities.

Smell 4: Long classes (over 200 lines) with unrelated methods. While line count alone does not violate SRP, it is often a symptom.

Demonstrating SRP Understanding

When writing code, narrate your design decisions. Say: "I am creating a separate FeeCalculator class because pricing rules change frequently based on business strategy, while spot allocation is more stable. This isolates Finance team changes from Operations team changes." Interviewers want to hear your reasoning, not just see correct code.

Advanced Scenario: Handling Cross-Cutting Concerns

Interviewers sometimes ask about logging, security, or caching. These are cross-cutting concerns that seem to violate SRP if added to every class. The answer is Aspect-Oriented Programming (AOP) or decorators. Say: "Logging is not a business responsibility of FeeCalculator. In a real system, I would use a logging framework that intercepts method calls via decorators or proxies. This way, FeeCalculator remains focused on fee logic while logging happens transparently." If implementing from scratch is required, use the Decorator pattern to wrap classes with logging behavior without modifying them.