Questions
22 of 24
1What are the SOLID principles? Explain each briefly.
2Explain the Single Responsibility Principle (SRP) with an example.
3Explain the Open/Closed Principle (OCP). How do you achieve it without modifying existing code?
4Explain the Liskov Substitution Principle (LSP). What happens if it's violated? (Square/Rectangle problem)
5Explain the Interface Segregation Principle (ISP). Why are fat interfaces bad?
6Explain the Dependency Inversion Principle (DIP). How does it relate to Dependency Injection?
7What is the difference between Aggregation and Composition?
8What is the Factory Pattern? How does it help in achieving OCP?
9What is the Abstract Factory Pattern? How does it differ from Factory Method?
10What is the Strategy Pattern? How does it replace complex conditional logic?
11What is the Observer Pattern? Where is it used in real life? (Event handling, Pub/Sub)
12What is the Decorator Pattern? How does it add functionality dynamically?
13What is a Singleton Pattern? What are the thread-safety concerns and how to handle them?
14What is an Anti-Pattern? Can you name a few? (God Object, Spaghetti Code, Golden Hammer)
15What is "Coupling" and "Cohesion"? Explain the relationship between them.
16What are Generics/Templates? How do they improve type safety and performance compared to casting?
17What is Type Erasure (Java) vs Reified Generics (C#)?
18What is Variance in Generics? (Covariance and Contravariance)
19What are Extension Methods (C#) or Default Methods (Java)? When should you use them?
20What is Reflection? How can it be used to break Encapsulation? What are the performance costs?
21What is the "Law of Demeter"? (Don't talk to strangers)
22Explain "Tell, Don't Ask" principle.
23What is the DRY principle? How does OOP help achieve it?
24What is the YAGNI principle?
22 / 24

Explain "Tell, Don't Ask" principle.

Difficulty: 5/10
encapsulation, object responsibility, design principles

Tell, Don't Ask

Tell, Don't Ask means that instead of retrieving an object's internal state and making decisions externally, we should tell the object to perform the operation that owns that decision. This keeps behavior close to the data and strengthens encapsulation. It is especially useful when external code contains conditionals based on another object's internal state. The principle does not mean getters are always wrong; querying is appropriate when the caller genuinely needs information.

javascript
  1. 1

    Keep business decisions near the state they govern.

  2. 2

    Reduce duplicated business rules in callers.

  3. 3

    Strengthens encapsulation.

  4. 4

    Can reduce coupling to object internals.

  5. 5

    Getters are not inherently bad; use them when exposing information is part of the abstraction.

Scenario Questions

0-2 years experience

  1. 1You have a User class with getAge() and a service that checks age to grant premium access. How would you refactor this to follow Tell, Don't Ask?
  2. 2A Cart object exposes getItems() and a function iterates over the items to compute total price. What change would you make to avoid the function asking the cart for its internal list?
  3. 3If code does if (order.getStatus() == Status.SHIPPED) { … }, how could you rewrite it respecting Tell, Don't Ask?

2-5 years experience

  1. 1Our order processing module calls order.getTotalAmount() then applies discounts in a separate utility, and it broke when new discount rules needed line‑item details. How would you redesign the interaction using Tell, Don't Ask?
  2. 2During a code review you see a UserProfile object being passed around and many places call profile.getEmail() to send notifications. What are the trade‑offs of moving the notification logic into UserProfile?
  3. 3Feature toggles are scattered as config.isFeatureEnabled() checks across services, leading to inconsistent behavior. How would you apply Tell, Don't Ask to centralize this decision?

5-8 years experience

  1. 1Our payment microservice receives a PaymentRequest DTO and multiple handlers query request.getAmount(), request.getCurrency() for validation, logging, and routing. At scale this is a maintenance headache. How would you restructure the component to respect Tell, Don't Ask, and what impact does it have on performance and testability?
  2. 2In a large e‑commerce platform, the inventory system frequently asks a Product object for its stockLevel and then decides whether to allocate stock, causing race conditions. How would you redesign responsibility distribution using Tell, Don't Ask, and what concurrency considerations arise?
  3. 3A reporting service pulls data from a ReportBuilder by calling many getters to assemble the final report. Explain how you would refactor this so the builder tells the service what to do, and discuss the effect on extensibility.

8+ years experience

  1. 1Our monolithic order management system heavily uses 'ask' patterns, exposing internal state across bounded contexts. How would you lead a migration to a microservice architecture that enforces Tell, Don't Ask at the architectural level, and what challenges do you expect with legacy data and cross‑team contracts?
  2. 2A cross‑team initiative wants to standardize business object APIs, but some teams argue getters are needed for flexibility. As a staff engineer, how would you convince them of the long‑term benefits of Tell, Don't Ask, and what metrics would you use to measure success?
  3. 3Design a policy for API contracts between services that enforces Tell, Don't Ask while allowing versioned extensions. Discuss how this impacts backward compatibility and deployment pipelines.

Follow-up Questions

  • Can you walk me through a concrete implementation of that refactor?
  • What trade‑offs might arise when you move logic into the object?
  • How would you verify that the new design still meets the original requirements?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.