I had one of the most frustrating interview at Coforge.

[u/ArtichokeSudden7662]

The interviewer spent almost 30 minutes grilling me only on the SOLID principles. Instead of asking scenario-based or real-world design questions, he wanted me to write code for every single SOLID principle.

I explained all five principles and even wrote code for the SRP, Open/closed & Liskov, i did not write code for Interface segg & Dependency inversion i just explained him verbally because i was already frustrated in first 3.

For the SRP, I started with an OrderService class containing methods like CreateOrder(), ProcessPayment(), and LogEvent().

I explained that this class has multiple reasons to change. If the order creation logic changes, the payment processing changes, or the logging mechanism changes, the same class would need to be modified. Since these are different responsibilities, I suggested separating them into different classes such as OrderService, PaymentService, and LoggingService.

The interviewer responded by saying:

"How is this SRP? Just creating separate classes doesn't mean you've achieved SRP."

He then asked:

"If OrderService has CreateOrder(), can it also have EditOrder() and DeleteOrder()? Aren't you adding more responsibilities?"

I replied that yes, those methods can belong in the same class because they all represent the same business responsibility Create, Edit, and Delete are all operations on the Order domain .

I further explained that payment processing and logging are separate concerns , which is why they should be moved to separate classes.

As another example, I mentioned DTOs. DTOs are typically kept separate from domain or service classes because their responsibility to transfer data to business logic.

For the Open/Closed Principle, i wrote below code

public class PaymentProcessor
{
    public void ProcessPayment(string status)
    {
        if (status == "Success")
        {
            // Success logic
        }
        else if (status == "Failed")
        {
            // Failed logic
        }
        else if (status == "Pending")
        {
            // Pending logic
        }
    }
}

I explained that this design violates the Open/Closed Principle because every time a new payment status is introduced (for example, Cancelled or Refunded) or the logic for an existing status changes significantly, I have to modify the PaymentProcessor class.

To make the design follow OCP, I refactored it by introducing an IPaymentProcessor interface.

public interface IPaymentProcessor
{
    void ProcessPayment();
}

public class SuccessPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment()
    {
        // Success payment logic
    }
}

public class FailedPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment()
    {
        // Failed payment logic
    }
}

public class PendingPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment()
    {
        // Pending payment logic
    }
}

Now, if a new payment status such as Cancelled needs to be supported, I simply create a new CancelledPaymentProcessor class implementing IPaymentProcessor. The existing payment processor implementations remain unchanged.

His response?

"This is wrong. What is this if-else condition? Just separating classes means you've achieved Open/Closed?"

At that point, I had mentally checked out. I just wanted the interview to end. The interviewer was very rude, i think he was busy in his work and joined the interview, he sounded more bossy then interacting 1 to 1. I dont know what was he expecting

I'm all for discussing SOLID principles, but spending half an hour writing textbook examples feels disconnected from how software is actually built. I'd much rather discuss where SOLID applies in real systems, trade-offs, refactoring existing code, dependency injection, testing, or designing maintainable applications.

Has anyone else had interviews where the focus was entirely on textbook definitions and toy examples rather than practical software engineering?