Forem: Aniket Vaishnav

What If the OOD Interview Doesn’t Go as Planned?

Aniket Vaishnav — Sun, 04 Jan 2026 20:33:44 +0000

No matter how well you prepare, real interviews rarely follow a perfectly linear path. You might face curveballs such as shifting requirements, unexpected deep dives, or even a disengaged interviewer. The key is to stay adaptable, communicate clearly, and remain focused on delivering a thoughtful design.

This section explores common challenges during OOD interviews and how to handle them with confidence and grace.

1. Shifting Requirements and Expanding Scope

In some interviews, the scope of the problem may expand as you go. You might be halfway through a design when the interviewer introduces new requirements or constraints. Don’t panic. This is often intentional.

✅ What to do:

Acknowledge the new requirement and briefly assess its impact.
Explain how your current design can accommodate the change, or what trade-offs might be required.
Be flexible but strategic. Adapt your solution without overhauling it unnecessarily.
If the interviewer keeps expanding on a specific area, it’s likely that flexibility and scalability are part of what they’re testing.
In some cases, the shifting scope may be a subtle hint that your current design has a blind spot. Take a moment to re-evaluate and be one step ahead by recognizing potential design flaws.

2. Being Pulled into a Deep Dive Too Early

Sometimes, the interviewer may want to dive into details before you’ve mapped out the broader structure. If you go too deep too soon, you risk losing sight of the big picture and running out of time.

✅ What to do:

Set expectations early: “I’ll start with a high-level overview, then we can dive deeper where needed.”
Periodically check in on time and structure.
If you’re stuck in one area, say: “Here’s the direction I’d take for now. Completing the rest of the system will give me the context to refine this.”
Don’t forget to circle back to that part later. It shows follow-through.
Avoid premature optimization or over-specificity early in the interview, as these can derail your momentum.

3. Struggling to Communicate Your Thought Process

Clear communication is as important as solid design. If your thoughts feel jumbled or hard to explain, it can weaken the impact of your solution.

✅ What to do:

Begin with a high-level summary of your system before diving into class-level details.
“The system has three main components: A, B, and C. Here’s how they interact.”
Use visuals. A class diagram or code skeleton can anchor the conversation.
Focus on why you made design decisions rather than just describing what they are.
Choose intuitive names for classes and methods. Good naming reduces the need for lengthy explanations and reinforces clarity.

4. Dealing with a Disengaged Interviewer

Not every interviewer will give active feedback. If they appear disinterested, confused, or silent, don’t let it throw you off.

✅ What to do:

Politely ask for feedback to re-engage them: “Would it be helpful if I clarified anything or focused on a specific part of the design?”
If that doesn’t work, let your work speak for itself. Focus on delivering clean diagrams or runnable code.
Especially in code-heavy interviews, executing working code can demonstrate your competence more effectively than conversation alone.

5. When Your Design Decisions Are Challenged

It’s common for interviewers to challenge your choices. This isn’t a bad sign. It’s a chance to demonstrate your reasoning and adaptability.

✅ What to do:

Stay calm and explain your thought process.
Use concrete examples or real-world analogies to support your point.
If relevant, reference trade-offs using terms like time complexity, extensibility, or maintainability.
Offer alternatives: “I considered both inheritance and composition. I chose inheritance here because…”
If you’re unsure, it’s okay to pause or ask for clarification: “Would you mind giving a specific case where you see this approach falling short?”

6. Encountering Unfamiliar Terminology

If the interviewer uses a term or concept you’re not familiar with, it’s better to clarify than to guess.

✅ What to do:

Ask politely: “Could you clarify what you mean by that term?”
Or show partial understanding and align: “My understanding of this concept is X. Please let me know how it differs in your context.”
This approach shows humility and professionalism without undermining your credibility.

7. Struggling with the Right Level of Abstraction

Not sure how much detail to go into? This is a common tension in OOD interviews. Going too broad can make your solution feel vague; going too deep too early wastes time.

✅ What to do:

Start with a general structure and layer in details as needed.
Ask the interviewer what level of depth they’d like you to go into:
“Would you prefer a high-level architecture here or a more detailed class breakdown?”
Stay flexible, and be prepared to zoom in or out depending on the interviewer’s cues.
Each OOD problem has its own natural complexity, whether it’s in abstraction, data modeling, or behavior logic. Over time, you’ll develop a sense for what to emphasize.

8. Addressing Concurrency in OOD Interviews

Concurrency is an advanced topic that interviewers may bring up, often by asking how your system handles multiple users or processes accessing the same resources at the same time.

A classic example is a ticket booking system, where the key concern is preventing double-bookings when multiple users attempt to select the same seat. This scenario is a great opportunity to demonstrate techniques like locking, optimistic locking, or using language-specific synchronization mechanisms and concurrent data structures.

Keep your explanation concise and your implementation simple. In most interviews, a high-level description of your concurrency strategy, along with a brief code snippet to illustrate how you prevent race conditions, is more than enough.

In some cases, your system itself may need to run concurrently. If you’re coding in Java, understanding classes like Thread, Runnable, Callable, and ExecutorService is valuable, as it helps you avoid reinventing concurrency from low-level primitives.

Final Thoughts

The object-oriented design interview is about more than just technical skills. It’s about thinking clearly under pressure, communicating effectively, and applying OOP principles to build maintainable, scalable solutions.

By breaking the process into manageable steps and learning how to navigate unexpected challenges, you’ll be well-prepared to handle even the most unpredictable interviews. With practice and the right mindset, you can turn curveballs into opportunities and leave a lasting impression.

Use Case Diagram

Aniket Vaishnav — Thu, 01 Jan 2026 20:58:04 +0000

Use case diagrams describe a set of actions (called use cases) that a system should or can perform in collaboration with one or more external users of the system (called actors). Each use case should provide some observable and valuable result to the actors.

Use Case Diagrams describe the high-level functional behavior of the system.
It answers what system does from the user point of view.
Use case answers ‘What will the system do?’ and at the same time tells us ‘What will the system NOT do?’.

A use case illustrates a unit of functionality provided by the system. The primary purpose of the use case diagram is to help development teams visualize the functional requirements of a system, including the relationship of “actors” to the essential processes, as well as the relationships among different use cases.

To illustrate a use case on a use case diagram, we draw an oval in the middle of the diagram and put the name of the use case in the center of the oval. To show an actor (indicating a system user) on a use-case diagram, we draw a stick figure to the left or right of the diagram.

The different components of the use case diagram are:

System boundary: A system boundary defines the scope and limits of the system. It is shown as a rectangle that spans all use cases of the system.
Actors: An actor is an entity who performs specific actions. These roles are the actual business roles of the users in a given system. An actor interacts with a use case of the system. For example, in a banking system, the customer is one of the actors. Use Case: Every business functionality is a potential use case. The use case should list the discrete business functionality specified in the problem statement.
Include: Include relationship represents an invocation of one use case by another use case. From a coding perspective, it is like one function being called by another function.
Extend: This relationship signifies that the extended use case will work exactly like the base use case, except that some new steps will be inserted in the extended use case.

This was about usecase diagram, for Class diagram: https://dev.to/obrutus/class-diagram-cmg

Class Diagram

Aniket Vaishnav — Thu, 01 Jan 2026 20:57:30 +0000

Class diagram is the backbone of object-oriented modeling - it shows how different entities (people, things, and data) relate to each other. In other words, it shows the static structures of the system.

A class diagram describes the attributes and operations of a class and also the constraints imposed on the system. Class diagrams are widely used in the modeling of object-oriented systems because they are the only UML diagrams that can be mapped directly to object-oriented languages.

The purpose of the class diagram can be summarized as:

Analysis and design of the static view of an application;
To describe the responsibilities of a system;
To provide a base for component and deployment diagrams; and,
Forward and reverse engineering.

A class is depicted in the class diagram as a rectangle with three horizontal sections, as shown in the figure below. The upper section shows the class’s name (Flight), the middle section contains the properties of the class, and the lower section contains the class’s operations (or “methods”).

These are the different types of relationships between classes:

1. Association

If two classes in a model need to communicate with each other,
there must be a link between them. This link can be represented by an association. Associations can be represented in a class diagram by a line between these classes with an arrow indicating the navigation direction.

By default associations are always assumed to be bi-directional; this means that both classes are aware of each other and their relationship. In the diagram below, the association between Pilot and FlightInstance is bi-directional, as both classes know each other.
By contrast, in a uni-directional association, hence it is a uni-directional association

2. Multiplicity

Multiplicity indicates how many instances of a class participate
in the relationship. It is a constraint that specifies the range of permitted cardinalities between two classes. For example, in the diagram below, one FlightInstance will have two Pilots, while a Pilot can have many FlightInstances. A ranged multiplicity can be expressed as “0…*” which means “zero to many" or as “2…4” which means “two to four”.

We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association. The below diagram, demonstrates that a FlightInstance has exactly two Pilots but a Pilot can have many FlightInstances.

3. Aggregation

Aggregation is a special type of association used to model a “whole to its parts” relationship. In a basic aggregation relationship, the lifecycle of a PART class is independent of the WHOLE class’s lifecycle. In other words, aggregation implies a relationship where the child can exist independently of the parent. In the above diagram, Aircraft can exist without Airline.

4. Composition

The composition aggregation relationship is just another form of the aggregation relationship, but the child class’s instance lifecycle is
dependent on the parent class’s instance lifecycle. In other words,
Composition implies a relationship where the child cannot exist independent of the parent. In the above example, WeeklySchedule is composed in Flight which means when Flight lifecycle ends, WeeklySchedule automatically gets destroyed

5. Generalization

Generalization is the mechanism for combining similar classes of objects into a single, more general class. Generalization identifies commonalities among a set of entities. In the above diagram, Crew, Pilot, and Admin, all are Person.

6. Dependency

A dependency relationship is a relationship in which one class, the client, uses or depends on another class, the supplier. In the above diagram, FlightReservation depends on Payment.

7. Abstract class: An abstract class is identified by specifying its name in italics. In the above diagram, both Person and Account classes are abstract classes.

For sequence diagram: https://dev.to/obrutus/sequence-diagram-3nk8

Sequence diagram

Aniket Vaishnav — Thu, 01 Jan 2026 20:57:02 +0000

Sequence diagrams describe interactions among classes in terms of an
exchange of messages over time and are used to explore the logic of complex operations, functions or procedures. In this diagram, the sequence of interactions between the objects is represented in a step-by-step manner. Sequence diagrams show a detailed flow for a specific use case or even just part of a particular use case. They are almost self-explanatory; they show the calls between the different objects in their sequence and can explain, at a detailed level, different calls to various objects.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages in the chronological order that they occur; the horizontal dimension shows the object instances to which the messages are sent.

A sequence diagram is straightforward to draw. Across the top of your
diagram, identify the class instances (objects) by putting each class instance inside a box (see above figure). If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance and place the name of the message above the line. Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the returned value above the dotted line.

What is Activity Diagram know here : https://dev.to/obrutus/activity-diagram-1obc

Activity Diagram

Aniket Vaishnav — Thu, 01 Jan 2026 20:56:37 +0000

We use Activity Diagrams to illustrate the flow of control in a system. An activity diagram shows the flow of control for a system functionality; it emphasizes the condition of flow and the sequence in which it happens. We can also use an activity diagram to refer to the steps involved in the execution of a use case.

Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operations.

Following is an activity diagram for a user performing online shopping:

What is the difference between Activity diagram and Sequence
diagram?

Activity diagram captures the process flow. It is used for functional modeling. A functional model represents the flow of values from external inputs, through operations and internal data stores, to external outputs.

Sequence diagram tracks the interaction between the objects. It is used for dynamic modeling, which is represented by tracking states, transitions between states, and the events that trigger these transitions.

OO Analysis and Design

Aniket Vaishnav — Wed, 31 Dec 2025 18:28:45 +0000

OO Analysis and Design is a structured method for analyzing and designing a
system by applying object-oriented concepts. This design process consists of
an investigation into the objects constituting the system. It starts by first
identifying the objects of the system and then figuring out the interactions
between various objects.

The process of OO analysis and design can be described as:

Identifying the objects in a system;
Defining relationships between objects;
Establishing the interface of each object; and,
Making a design, which can be converted to executables using OO languages.

We need a standard method/tool to document all this information; for this purpose we use UML. UML can be considered as the successor of object-oriented (OO) analysis and design. UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design.

UML diagrams are a representation of object-oriented concepts only. Thus, before learning UML, it is essential to understand OO concepts.
Let’s find out how we can model using UML.

Get to know UML here : https://dev.to/obrutus/what-is-uml-29p4

What is UML?

Aniket Vaishnav — Wed, 31 Dec 2025 18:28:16 +0000

UML stands for Unified Modeling Language and is used to model the Object-Oriented Analysis of a software system. UML is a way of visualizing and documenting a software system by using a collection of diagrams, which helps engineers, businesspeople, and system architects understand the behavior and structure of the system being designed.

Benefits of using UML:

Helps develop a quick understanding of a software system.
UML modeling helps in breaking a complex system into discrete pieces that can be easily understood.
UML’s graphical notations can be used to communicate design decisions.
Since UML is independent of any specific platform or language or technology, it is easier to abstract out concepts.
It becomes easier to hand the system over to a new team.

Get to know types of UML diagrams here : https://dev.to/obrutus/types-of-uml-diagrams-40o8

Types of UML Diagrams

Aniket Vaishnav — Wed, 31 Dec 2025 18:26:23 +0000

The current UML standards call for 14 different kinds of diagrams.
These diagrams are organized into two distinct groups:

structural diagrams and
behavioral or interaction diagrams.

As the names suggest, some UML diagrams analyze and depict the structure of a system or process, whereas others describe the behavior of the system, its actors, and its building components.

The different types are broken down as follows:

Structural UML diagrams

Class diagram
Object diagram
Package diagram
Component diagram
Composite structure diagram
Deployment diagram
Profile diagram

Behavioral UML diagrams

Use case diagram
Activity diagram
Sequence diagram
State diagram
Communication diagram
Interaction overview diagram
Timing diagram

Well the most commonly is debatable, but the must known for anyone should be:

Use Case Diagram: Used to describe a set of user scenarios, this diagram, illustrates the functionality provided by the system.
Class Diagram: Used to describe structure and behavior in the use cases, this diagram provides a conceptual model of the system in terms of entities and their relationships.
Activity Diagram: Used to model the functional flow-of-control between two or more class objects.
Sequence Diagram: Used to describe interactions among classes in terms of an exchange of messages over time.

The four principles of object-oriented programming

Aniket Vaishnav — Wed, 31 Dec 2025 18:03:52 +0000

The four principles of object-oriented programming are encapsulation,
abstraction, inheritance, and polymorphism.

1. Encapsulation

Encapsulation is the mechanism of binding the data
together and hiding it from the outside world. Encapsulation is achieved
when each object keeps its state private so that other objects don’t have
direct access to its state. Instead, they can access this state only through a
set of public functions.

2. Abstraction

Abstraction can be thought of as the natural extension of
encapsulation. It means hiding all but the relevant data about an object
in order to reduce the complexity of the system. In a large system, objects
talk to each other, which makes it difficult to maintain a large code base;
abstraction helps by hiding internal implementation details of objects
and only revealing operations that are relevant to other objects.

Inheritance

Inheritance is the mechanism of creating new classes from existing ones.

Polymorphism

Polymorphism (from Greek, meaning “many forms”)
is the ability of an object to take different forms and thus, depending
upon the context, to respond to the same message in different ways. Take
the example of a chess game; a chess piece can take many forms, like
bishop, castle, or knight and all these pieces will respond differently to
the ‘move’ message.

Words and Letters: Take your side

Aniket Vaishnav — Thu, 18 Dec 2025 16:57:09 +0000

Hate has 4 letters so does Love
Enemies has 7 letters so does Friends
Lying has 5 letters so does Truth
Failure has 7 letters so does Success
Cry has 3 letters so does Joy
and
Negativity has 10 letters so does Positivity

You always have a choice so choose the better side of it!

Cosine Similarity Explained — Intuitively and Practically

Aniket Vaishnav — Sat, 14 Jun 2025 11:46:25 +0000

Ever wondered what cosine similarity really means and how it works?

Let’s break it down in a way that’s simple, intuitive, and practical — so the next time you hear it in a machine learning conversation, you won’t just nod along, you’ll own it.

🚀 What Is Cosine Similarity?

According to Wikipedia:

Cosine similarity is a measure of similarity between two non-zero vectors defined in an inner product space.

It is the cosine of the angle between the vectors.

That’s technically correct — but what does it really mean?

Let’s interpret this with real-world clarity.

🎯 Understanding the Intuition

Similarity metrics (like Euclidean or Manhattan distance) typically measure how far apart two data points are. The closer they are, the more similar they’re considered.

Cosine similarity, however, takes a different approach.

Imagine vectors as arrows from the origin in space. Instead of looking at their length (magnitude), cosine similarity compares their direction.

So, even if two vectors have different lengths, if they point in the same direction, they’re considered similar.

This makes cosine similarity perfect for text data, high-dimensional data, and preference vectors, where pattern matters more than size.

🧠 Quick Refresher: Vectors and Angles

When two vectors point in the same direction, the angle between them is 0°, and cosine similarity is 1 (perfect match).
When the angle is 90°, cosine similarity is 0 (no similarity).
If they point in opposite directions, cosine similarity becomes -1.

It’s all captured in this elegant formula:

$$
\text{cosine_similarity}(A, B) = \frac{A \cdot B}{|A| |B|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}}
$$

Where:

( A \cdot B ) is the dot product
( |A| ), ( |B| ) are vector magnitudes
( n ) is the number of dimensions

🔍 Cosine Similarity Range and Interpretation

Cosine similarity values range from -1 to +1:

Value	Interpretation
`+1`	Identical direction (highly similar)
`~0`	No directional similarity (orthogonal)
`-1`	Opposite direction (completely dissimilar)

In most real-world applications (especially with non-negative vectors like text frequencies), values fall between 0 and 1.

🧪 Real-World Examples

✅ Documents

Two documents with similar topics will have high cosine similarity between their word embeddings or TF-IDF vectors.

✅ Recommendations

Two users with similar viewing habits will have profile vectors pointing in similar directions — cosine similarity helps recommend new content.

🔧 Where Is Cosine Similarity Used?

1. 🗣️ Natural Language Processing (NLP)

Comparing documents and sentences
Search ranking and semantic similarity
Identifying duplicates or near-duplicates

2. 🎯 Recommendation Engines

User-item similarity
Collaborative filtering
Finding similar products or users

3. 🧠 Machine Learning Algorithms

Clustering (e.g., k-Means)
Classification (e.g., k-NN)
Embedding similarity (e.g., BERT, Word2Vec)

4. 🖼️ Computer Vision

Comparing image embeddings (e.g., face recognition)

👥 Who Uses Cosine Similarity?

Data Scientists & ML Engineers: for modeling similarity
Search Engineers: for information retrieval
Recommender System Developers: for user-item matching
Researchers: in NLP, biology, social networks
Software Engineers: in chatbots, personalization, vector DBs

🎵 Final Analogy: Music Taste

Imagine your and your friend's music preferences as vectors.

Even if your friend listens to more music, you both love jazz and dislike metal. Your preferences point in the same direction — that’s what cosine similarity captures: shared taste, not quantity.

✅ TL;DR — Why Cosine Similarity Rocks

Ignores magnitude, focuses on directional similarity
Perfect for text, embeddings, user behavior
Ranges from -1 to +1, intuitive and fast
Used everywhere: NLP, recommendation, clustering

💬 Over to You

Have you used cosine similarity in a project or algorithm? Drop a comment or share your experience!

📈 Best Time to Buy and Sell Stock (LeetCode 121)

Aniket Vaishnav — Mon, 09 Jun 2025 10:24:15 +0000

🧠 Problem Statement

Video Explain

You are given an array prices where prices[i] represents the price of a given stock on the i-th day.

Your goal is to maximize profit by choosing a single day to buy one stock and a different future day to sell that stock.

If no profitable transaction is possible, return 0.

🧾 Examples

Example 1:

Input: prices = [7, 1, 5, 3, 6, 4]
Output: 5
Explanation: Buy on day 2 (price = 1), sell on day 5 (price = 6). Profit = 6 - 1 = 5.

Example 2:

Input: prices = [7, 6, 4, 3, 1]
Output: 0
Explanation: No future price is higher than the earlier prices.

🔍 Constraints

1 <= prices.length <= 10^5
0 <= prices[i] <= 10^4

💡 Intuition

We need to buy low and sell high, but with a key restriction:

We must buy before we sell.

So we’re looking for the maximum difference between two prices prices[j] - prices[i] where j > i.

🪜 Step-by-Step Approach

🔁 One-Pass Greedy Algorithm

Track the minimum price so far as you iterate.
For each price, calculate the profit if you bought at the minimum and sold today.
Keep updating the maximum profit found.

✅ Why this works

We always look backward to see the best time we could have bought the stock before today.

This ensures we never violate the "buy before sell" rule.

🧮 Dry Run

Let's walk through prices = [7, 1, 5, 3, 6, 4]

Day	Price	Min Price So Far	Profit if Sold Today	Max Profit
1	7	7	0	0
2	1	1 ✅	0	0
3	5	1	4	4 ✅
4	3	1	2	4
5	6	1	5 ✅	5 ✅
6	4	1	3	5

🧑‍💻 C++ Code

#include <vector>
#include <algorithm>
using namespace std;

int maxProfit(vector<int>& prices) {
    int minPrice = INT_MAX;
    int maxProfit = 0;

    for (int price : prices) {
        minPrice = min(minPrice, price); // Track lowest price so far
        maxProfit = max(maxProfit, price - minPrice); // Check today's profit
    }

    return maxProfit;
}

🧑‍💻 Java Code

public class Solution {
    public int maxProfit(int[] prices) {
        int minPrice = Integer.MAX_VALUE;
        int maxProfit = 0;

        for (int price : prices) {
            minPrice = Math.min(minPrice, price); // Track lowest price so far
            maxProfit = Math.max(maxProfit, price - minPrice); // Check today's profit
        }

        return maxProfit;
    }
}

📌 Time & Space Complexity

Metric Value
Time Complexity O(n)
Space Complexity O(1)

🔚 Final Thoughts

This problem is a classic sliding window or greedy pattern.

It teaches a powerful lesson: Track the best "buy" dynamically, rather than trying every pair.

Let me know if you'd like
https://www.youtube.com/watch?v=COJ-KY7DIOs