Senior Software Engineer

1. Optimal Substructure: Number of unique possibe path to reach cell (n,m) depends on the optimal solutions of the subproblems numberOfPaths(n, m-1) and numberOfPaths(n-1, m). By combining these optimal substrutures, we can efficiently calculate the total number of ways to reach the (n, m)th cell.
2. Overlapping Subproblems: While applying a recursive approach in this problem, we notice that certain subproblems are computed multiple times. For example, when calculating numberOfPaths(3, 3. we recursively calculate numberOfPaths(3, 2) and numberOfPaths(2, 3), which in turn will recursively compute numberOfPaths(2, 2) again from numberOfPaths(3, 2) and numberOfPaths(2, 3). This redundancy leads to overlapping subproblems.

Steps to implement the algorithm :
Step 1 – Find a candidate with the majority – Initialize a variable say i ,votes = 0, candidate =-1 
Traverse through the array using for loop
If votes = 0, choose the candidate = arr[i] , make votes=1.
else if the current element is the same as the candidate increment votes
else decrement votes.
Step 2 – Check if the candidate has more than N/2 votes – Initialize a variable count =0 and increment count if it is the same as the candidate.
If the count is >N/2, return the candidate.
else return -1.

Encapsulation: Bundles data and methods; achieved via private fields and public getters/setters.
Inheritance: Enables subclassing (e.g. class Dog extends Animal) so you can reuse and override behaviour.
Polymorphism: Allows treating subclasses as their base type; method overloading (compile-time) and overriding (runtime).
Abstraction: Hides complexity via interfaces or abstract classes, exposing only necessary methods.

DI Definition: A design pattern where an object’s dependencies are provided externally rather than created internally.
Spring Implementation: Constructor injection (@Autowired on constructor)
Setter injection (@Autowired on setter)
Field injection (less recommended, @Autowired on field)
Spring’s IoC container wires bean instances based on configuration, annotations, or XML.

Difference in annotations:

@Component: Generic stereotype for any Spring-managed bean.
@Service: Specialization of @Component for business-logic/service layer beans.
@Repository: Specialization of @Component for persistence layer; adds exception translation for database errors.

Using @Qualifier:

Context: I had two PaymentService implementations (PaypalPaymentService and StripePaymentService) both annotated @Component.

Problem: Spring threw NoUniqueBeanDefinitionException because it found two beans of type PaymentService.

Action: I annotated each class with @Qualifier("paypal") and @Qualifier("stripe").

Solution: In my OrderService constructor, I injected the desired bean using

public OrderService(@Qualifier("stripe") PaymentService svc) { … }
Result: Spring correctly wired the stripe bean, eliminating ambiguity and ensuring the right payment logic was executed.

LAZY: Associations are loaded on first access (proxy), reducing initial load time.
EAGER: Associations are loaded immediately with the parent entity, which can cause unnecessary joins and performance hits.

== vs equals(): == tests reference identity; equals() tests logical equality (can be overridden for content comparison).
final:
Variable: value can’t be reassigned.
Method: cannot be overridden.
Class: cannot be subclassed.
StringBuilder vs StringBuffer: StringBuilder is unsynchronized (faster, not thread-safe); StringBuffer is synchronized (slower, thread-safe).
Checked vs Unchecked Exceptions:
Checked: must be declared/handled (e.g., IOException).
Unchecked: extend RuntimeException, no declaration required (e.g., NullPointerException).

Root Cause Analysis (RCA) is the process of identifying the underlying reason behind an issue in production. It involves going through logs, debugging the code, checking recent changes or deployments, and tracing the complete flow to find the exact cause. The goal is to fix the root problem, not just the symptom.
I have worked on around 50+ production tickets so far. These included issues like API failures, data inconsistencies, performance bottlenecks, and integration errors. For each ticket, I performed RCA to ensure a proper and long-term fix.

Spring Boot handles 10 concurrent requests using its embedded servlet container, like Tomcat, Jetty, or Undertow, which manages a thread pool to process incoming HTTP requests.
By default, when using Spring Boot with Tomcat, each incoming request is handled by a separate thread from the pool. So if 10 requests come in at the same time, Spring Boot will assign each request to a free thread and handle them concurrently.
You can configure the max number of threads in application.properties:
server.tomcat.threads.max=200
server.tomcat.threads.min-spare=10
If all threads are busy and more requests come in, the extra requests will wait in a request queue until a thread becomes available or timeout occurs.

Step 1: Defined a Node class to store key, value, and a reference to the next node (for handling collisions).
Step 2: Created an array of Node objects to serve as the underlying storage (buckets).
Step 3: Implemented a hash() method to map a key to a specific index in the array.
Step 4: For the put() method, checked if the key already exists; if yes, updated the value, else inserted a new node at the index (with chaining if needed).
Step 5: For get(), retrieved the node by traversing the linked list at the hashed index.
Step 6: For remove(), found and removed the node from the list at the given index.
Step 7: Added logic to automatically resize the array (double its size) when the size exceeds the threshold.
Step 8: Included utility methods like size() and isEmpty() for completeness.

Tips to Solve this:
1. Think in terms of OOP: Identify objects like Elevator, Request, and Controller.
2. Start with basic functionality: Move elevator between floors, handle one request.
3. Handle directions and priorities: Elevators should group requests moving in the same direction.
4. Avoid overengineering initially: Skip optimization like load balancing or scheduling in first cut.

Steps to solve:-
Step 1: Define classes – Elevator, Request, and ElevatorController. Identify key attributes like currentFloor, direction, and status.
Step 2: Design request handling logic – separate internal (from inside elevator) and external (from floors) requests.
Step 3: Implement basic movement – elevator should move one floor at a time toward the next request in queue.
Step 4: Add a controller to manage multiple elevators and assign requests optimally (based on direction and distance).