Java Technology Lead

Microservice architectures consist of the following components : 

1) Clients: Different users send requests from various devices. 
2) Identity Provider: Validate a user's or client's identity and issue security tokens. 
3) API Gateway: Handles the requests from clients. 
4) Static Content: Contains all of the system's content. 
5) Management: Services are balanced on nodes and failures are identified. 
6) Service Discovery: A guide to discovering the routes of communication between microservices. 
7) Content Delivery Network: Includes distributed network of proxy servers and their data centers. 
8) Remote Service: Provides remote access to data or information that resides on networked computers 
and devices.

Communication between microservices can take place through: 

1) HTTP/REST with JSON or binary protocol for request-response 
2) Websockets for streaming. 
3) A broker or server program that uses advanced routing algorithms. 

RabbitMQ, Nats, Kafka, etc., can be used as message brokers; each is built to handle a particular message semantic. You can also use Backend as a Service like Space Cloud to automate your entire backend.

Generally speaking, OAuth (Open Authorization Protocol) enables users to authenticate themselves with third-party service providers. With this protocol, you can access client applications on HTTP for third-party providers such as GitHub, Facebook, etc. Using it, you can also share resources on one site with another site without requiring their credentials.

Spring Boot application scans all the beans and package declarations when the application initializes. You need to add the @ComponentScan annotation for your class file to scan your components added to your project.

The primary annotations that Spring Boot offers reside in its "org.springframework.boot.autoconfigure" and its sub-packages. Here are a couple of basic ones:

@EnableAutoConfiguration – to make Spring Boot look for auto-configuration beans on its classpath and automatically apply them.

@SpringBootApplication – used to denote the main class of a Boot Application. This annotation combines @Configuration, @EnableAutoConfiguration, and @ComponentScan annotations with their default attributes.

It is a combination of @Controller and @ResponseBody, used for creating a restful controller. It converts the response to JSON or XML. It ensures that data returned by each method will be written straight into the response body instead of returning a template.

Approach :
1) If the head is NULL, we simply return HEAD.
2) If there is only one element in the linked list, we simply return it as it is the midpoint.
3) Otherwise, we initialise 2 pointers ‘fast’ and ‘slow’ both poiniting to head initially.
4) We traverse the linked list until fast is the last element or fast is beyond the linked list i.e it points to NULL.
5) In each iteration, the ‘fast’ pointer jumps 2 times faster as compared to ‘slow’ pointer.
6) Finally, once the loop terminates, ‘slow’ pointer will be pointing to the middle element of the linked list, hence we return the ‘slow’ pointer.


TC : O(N), where ‘N’ denotes the number of elements in the given Linked list.
SC : O(1)

According to ConcurrentHashMap Oracle docs,

The constructor of ConcurrentHashMap looks like this :

public ConcurrentHashMap (int initialCapacity, float loadFactor, int concurrencyLevel)

So the above line creates a new, empty map with the specified initial capacity, load factor and concurrency level.
where,
Important Parameters to consider from ConcurrentHashMap Constructor :

initialCapacity - the initial capacity. The implementation performs internal sizing to accommodate this many elements.

concurrencyLevel - the estimated number of concurrently updating threads. The implementation performs internal sizing to try to accommodate this many threads.

In the ConcurrentHashMap Api , you will find the following constants.

static final int DEFAULT_INITIAL_CAPACITY = 16;
static final int DEFAULT_CONCURRENCY_LEVEL = 16;

initial capacity parameter and concurrency level parameters of ConcurrentHashMap constructor (or Object) are set to 16 by default.

Thus, instead of a map wide lock, ConcurrentHashMap maintains a list of 16 locks by default ( number of locks equal to the initial capacity , which is by default 16) each of which is used to lock on a single bucket of the Map.This indicates that 16 threads (number of threads equal to the concurrency level , which is by default 16) can modify the collection at the same time , given ,each thread works on different bucket. So unlike hashtable, we perform any sort of operation ( update ,delete ,read ,create) without locking on entire map in ConcurrentHashMap.

Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset.

The allowed concurrency among update operations is guided by the optional concurrencyLevel constructor argument (default 16), which is used as a hint for internal sizing. The table is internally partitioned to try to permit the indicated number of concurrent updates without contention. Because placement in hash tables is essentially random, the actual concurrency will vary. Ideally, you should choose a value to accommodate as many threads as will ever concurrently modify the table. Using a significantly higher value than you need can waste space and time, and a significantly lower value can lead to thread contention

Below are the two significant features of the methods that are defined as the lambda expressions: 
1) Lambda expressions can be passed as a parameter to another method. 
2) Lambda expressions can be standalone without belonging to any class.

The process of injecting dependent bean objects into target bean objects is called dependency injection.

1) Setter Injection: The IOC container will inject the dependent bean object into the target bean object by calling the setter method.

2) Constructor Injection: The IOC container will inject the dependent bean object into the target bean object by calling the target bean constructor.

3) Field Injection: The IOC container will inject the dependent bean object into the target bean object by Reflection API.

1) PUT method is called when you have to modify a single resource while POST method is called when you have to add a child resource.

2) PUT method response can be cached but you cannot cache POST method responses.

3) You can use UPDATE query in PUT whereas you can use create query in POST.

4) In PUT method, the client decides which URI resource should have, and in POST method, the server decides which URI resource should have.

5) PUT works as specific while POST work as abstract.

6) If you send the same PUT request multiple times, the result will remain the same but if you send the same POST request multiple times, you will receive different results.

7) PUT method is idempotent whereas POST method is not idempotent.

The SOLID principle is an acronym of the five principles which is given below :

1) Single Responsibility Principle (SRP)
2) Open/Closed Principle
3) Liskov’s Substitution Principle (LSP)
4) Interface Segregation Principle (ISP)
5) Dependency Inversion Principle (DIP)

Uses of SOLID design principles :

1) The SOLID principle helps in reducing tight coupling.
2) Tight coupling means a group of classes are highly dependent on one another which we should avoid in our code.
3) Opposite of tight coupling is loose coupling and our code is considered as a good code when it has loosely-coupled classes.
4) Loosely coupled classes minimize changes in your code, helps in making code more reusable, maintainable,flexible and stable.


Explaining the 5 SOLID principles one by one :

1) Single Responsibility Principle : This principle states that “a class should have only one reason to change” which means every class should have a single responsibility or single job or single purpose.
Use layers in your application and break God classes into smaller classes or modules.


2) Open/Closed Principle : This principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” which means you should be able to extend a class behavior, without modifying it. Using this principle separates the existing code from the modified code so it provides better stability, maintainability and minimizes changes as in your code.


3) Liskov’s Substitution Principle : According to this principle “Derived or child classes must be substitutable for their base or parent classes“. This principle ensures that any class that is the child of a parent class should be usable in place of its parent without any unexpected behavior.
One of the classic examples of this principle is a rectangle having four sides. A rectangle’s height can be any value and width can be any value. A square is a rectangle with equal width and height. So we can say that we can extend the properties of the rectangle class into square class. In order to do that you need to swap the child (square) class with parent (rectangle) class to fit the definition of a square having four equal sides but a derived class does not affect the behavior of the parent class so if you will do that it will violate the Liskov Substitution Principle.


4) Interface Segregation Principle : This principle is the first principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle. It states that “do not force any client to implement an interface which is irrelevant to them“. Here your main goal is to focus on avoiding fat interface and give preference to many small client-specific interfaces.


5) Dependency Inversion Principle : Two key points are here to keep in mind about this principle
a) High-level modules/classes should not depend on low-level modules/classes. Both should depend upon
abstractions.
b) Abstractions should not depend upon details. Details should depend upon abstractions.

1) A C++ virtual function is a member function in the base class that you redefine in a derived class. It is declared using the virtual keyword.
2) It is used to tell the compiler to perform dynamic linkage or late binding on the function.
3) When the function is made virtual, C++ determines which function is to be invoked at the runtime based on the type of the object pointed by the base class pointer.

Some rules regarding virtual function :

i) Virtual functions must be members of some class.
ii) Virtual functions cannot be static members.
iii) They are accessed through object pointers.
iv) They can be a friend of another class.
v) A virtual function must be defined in the base class, even though it is not used.
vi) We cannot have a virtual constructor, but we can have a virtual destructor.

If you get this question, it's an opportunity to choose the most compelling information to share that is not obvious from your resume.

Example :

Strength -> I believe that my greatest strength is the ability to solve problems quickly and efficiently, which makes me unique from others.

Ability to handle Pressure -> I enjoy working under pressure because I believe it helps me grow and become more efficient.

Tip : Emphasize why you were inspired to apply for the job. You can also explain that you are willing to invest a great deal of energy if hired.

These are generally very open ended questions and are asked to test how quick wit a candidate is. So there is nothing to worry about if you have a good cammand over your communication skills and you are able to propagate your thoughts well to the interviewer.

Tip 1 : The cross questioning can go intense some time, think before you speak.

Tip 2 : Be open minded and answer whatever you are thinking, in these rounds I feel it is important to have opinion.

Tip 3 : Context of questions can be switched, pay attention to the details. It is okay to ask questions in these round, like what are the projects currently the company is investing, which team you are mentoring. How all is the work environment etc.

Tip 4 : Since everybody in the interview panel is from tech background, here too you can expect some technical questions. No coding in most of the cases but some discussions over the design can surely happen.