Area to focus !

Modules	Sub-Topics
Core Java	OOPs, classes, interfaces, inner classes, Generics etc
	Serialization, custom serialization
	Collections (Linked HashSet, HashMap, TreeMap etc)
	Multithreading (volatile, ThreadPool, Locks etc)
Data Structures	Lists, Trees, Graphs, Queues, Stacks etc
	Problem Solving, Time complexity analysis
Design	Design principles and data structures in context of some real time problem
SQL	Basic SQL Queries
	DB modelling, Query Tuning, Indexes, Qry Plans etc
Spring/ Other frameworks	Spring Core, Dependency Injection, Transaction Management etc
Soft Skills	Communication Skills, Adaptable, Never say die attitude

Interview Process :

·  Online Test

·  Coding Exercise

·  Technical Interview

·  Attributes Interview

Skills to be focused are mentioned below :

·         Core Java

·         OOPS Concepts

·         Immutability & Mutability of Class

·         Inner Classes

·         Serialization

·         Collections

·         JDK 1.5 (enums, generics, annotations, wild cards, compile time/ run rime, type-erasure)

·         Exception Handling

·         Garbage Collection

·         Multithreading

·         Synchronization

·         Concurrent Hashmaps

·         Concurrency APIs(CountdownLatch, Cyclic Barrier & Semaphores)

·         Design patterns

·         DataStructures

·         Algorithms

·         Collections

·         J2EE

·         Spring

·         Hibernate(Any ORM apart from Hibernate will also work)

JMS

·         JSP, Servlets

·         Databases

Marut and Girls : bookmyshow

https://www.hackerearth.com/bookmyshowhiringchallenge/problems/

Question : https://www.hackerearth.com/bookmyshowhiringchallenge/algorithm/marut-and-girls/

package com.thread.dp;

importjava.io.BufferedReader;

importjava.io.InputStreamReader;

import java.util.*;

class TestClass {

       public static void main(String args[] ) throws Exception {

              /* Read input from stdinand provide input before running */

              int count = 0;

              BufferedReader br = new BufferedReader(newInputStreamReader(System.in));

              String line = br.readLine();

              int N = Integer.parseInt(line);

              Set<String> qualitiesNds = new HashSet<String>();

              String line1 = br.readLine();

              for(String str : line1.split(" ")) {

                     qualitiesNds.add(str);

              }

              line1 = null;

              int proposals = Integer.parseInt(br.readLine());

              for (int i = 0; i<proposals; i++) {

                     String[] qualities = br.readLine().split(" ");

                     Set<String> quality = new HashSet<String>();

                     for(String itm : qualities) {

                           if(qualitiesNds.contains(itm)) {

                                  quality.add(itm);

                           }

                           if(N==quality.size()) {

                                  break;

                           }

                     }

                     if(N==quality.size()) {

                           ++count;

                     }

              }

              System.out.println(count);

       }

}

BeanFactory vs ApplicationContext

org.springframework.beans.factory.BeanFactory and 

org.springframework.context.ApplicationContext interfaces acts as the IoC container.

The ApplicationContext interface is built on top of the BeanFactory interface.

It adds some extra functionality than BeanFactory such as simple integration with Spring's AOP, message resource handling (for I18N), event propagation, application layer specific context (e.g. WebApplicationContext) for web application. So it is better to use ApplicationContext than BeanFactory.

Using BeanFactory

The XmlBeanFactory is the implementation class for the BeanFactory interface.

Resource resource = new ClassPathResource("applicationContext.xml");  

BeanFactory factory = new XmlBeanFactory(resource); 

Employee s=(Employee) factory.getBean("e");

The constructor of XmlBeanFactory class receives the Resource object so we need to pass the resource object to create the object of BeanFactory.

Using ApplicationContext

The ClassPathXmlApplicationContext class is the implementation class of ApplicationContext interface.

ApplicationContext context=new ClassPathXmlApplicationContext("applicationContext.xml");  

HelloWorld obj = (HelloWorld) context.getBean("helloWorld");

Spring Injection with @Resource, @Autowired and @Inject

Annotations

Annotation	Package	Source
@Resource	javax.annotation	Java
@Inject	javax.inject	Java
@Qualifier	javax.inject	Java
@Autowired	org.springframework.bean.factory	Spring

Spring 3.0.5.RELEASE

The Code

I wanted to know how ‘@Resource’, ‘@Autowired’, and ‘@Inject’ resolved dependencies. I created an interface called ‘Party’ and created two implementations classes. This allowed me to inject beans without using the concrete type. This provided the flexibility I needed to determine how Spring resolves beans when there are multiple type matches.

public interface Party { }

‘Person’ is a component and it implements ‘Party’.

package com.sourceallies.person; ... @Component public class Person implements Party {  }

‘Organization’ is a component and it implements ‘Party’.

package com.sourceallies.organization; ... @Component public class Organization implements Party { }

I setup a Spring context that scans both of these packages for beans marked with ‘@Component’.

<context:component-scan base-package="com.sourceallies.organization"/> <context:component-scan base-package="com.sourceallies.person"/>

Tests

Test 1: Ambiguous Beans

In this test I injected a ‘Party’ bean that has multiple implementations in the Spring context.

@Resource private Party party;

@Autowired private Party party;

@Inject private Party party;

In all three cases a ‘NoSuchBeanDefinitionException’ is thrown. While this exception’s name implies that no beans were found, the message explains that two beans were found. All of these annotations result in the same exception.

org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [com.sourceallies.Party] is defined: expected single matching bean but found 2: [organization, person]

Test 2: Field Name

In this test I named the Party field person. By default beans marked with ‘@Component’ will have the same name as the class. Therefore the name of the class ‘Person’ is person.

@Resource private Party person;

@Autowired private Party person;

@Inject private Party person;

‘@Resource’ can also take an optional ‘name’ attribute. This is equivalent to the ‘@Resource’ code above. In this case the field variable name remains ‘party’. There is no equivalent syntax for ‘@Autowired’ or ‘@Inject’. Instead you would have to use a ‘@Qualifier’. This syntax will be covered later.

@Resource(name="person") private Party party;

All four of these styles inject the ‘Person’ bean.

Test 3: Field Type

In this test I changed the type to be a ‘Person’.

@Resource private Person party;

@Autowired private Person party;

@Inject private Person party;

All of these annotations inject the ‘Person’ bean.

Test 4: Default Name Qualifier

In this test I use a ‘@Qualifier’ annotation to point to the default name of the ‘Person’ component.

@Resource @Qualifier("person") private Party party;

@Autowired @Qualifier("person") private Party party;

@Inject @Qualifier("person") private Party party;

All of these annotations inject the ‘Person’ bean.

Test 5: Qualified Name

I added a ‘@Qualifier’ annotation to the ‘Person’ class

package com.sourceallies.person; ... @Component @Qualifier("personBean") public class Person implements Party { }

In this test I use a ‘@Qualifier’ annotation to point to the qualified name of the ‘Person’ component.

@Resource @Qualifier("personBean") private Party party;

@Autowired @Qualifier("personBean") private Party party;

@Inject @Qualifier("personBean") private Party party;

All of these annotations inject the ‘Person’ bean.

Test 6: List of Beans

In this test I inject a list of beans.

@Resource private List<Party> parties;

@Autowired private List<Party> parties;

@Inject private List<Party> parties;

All of these annotations inject 2 beans into the list. This can also be accomplished with a ‘@Qualifier’. Each bean marked with a specific qualifier will be added to the list.

Test 7: Conflicting messages

In this test I add a bad ‘@Qualifier’ and a matching field name.

@Resource @Qualifier("bad") private Party person;

@Autowired @Qualifier("bad") private Party person;

@Inject @Qualifier("bad") private Party person;

In this case the field marked with ‘@Resource’ uses the field name and ignores the ‘@Qualifier’. As a result the ‘Person’ bean is injected.

However the ‘@Autowired’ and ‘@Inject’ field throw a ‘NoSuchBeanDefinitionException’ error because it can not find a bean that matches the ‘@Qualifier’.

org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching bean of type [com.sourceallies.Party] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true), @org.springframework.beans.factory.annotation.Qualifier(value=bad)}

Conclusions

With the exception of test 2 & 7 the configuration and outcomes were identical. When I looked under the hood I determined that the ‘@Autowired’ and ‘@Inject’ annotation behave identically. Both of these annotations use the ‘AutowiredAnnotationBeanPostProcessor’ to inject dependencies. ‘@Autowired’ and ‘@Inject’ can be used interchangeable to inject Spring beans. However the ‘@Resource’ annotation uses the ‘CommonAnnotationBeanPostProcessor’ to inject dependencies. Even though they use different post processor classes they all behave nearly identically. Below is a summary of their execution paths.

@Autowired and @Inject

1.     Matches by Type

2.     Restricts by Qualifiers

3.     Matches by Name

@Resource

1.     Matches by Name

2.     Matches by Type

3.     Restricts by Qualifiers (ignored if match is found by name)

While it could be argued that ‘@Resource’ will perform faster by name than ‘@Autowired’ and ‘@Inject’ it would be negligible. This isn’t a sufficient reason to favor one syntax over the others. I do however favor the ‘@Resource’ annotation for it’s concise notation style.

@Resource(name="person")

@Autowired @Qualifier("person")

@Inject @Qualifier("person")

You may argue that they can be equal concise if you use the field name to identify the bean name.

@Resource private Party person;

@Autowired private Party person;

@Inject private Party person;

True enough, but what happens if you want to refactor your code? By simply renaming the field name you’re no longer referring to the same bean. I recommend the following practices when wiring beans with annotations.

Spring Annotation Style Best Practices

1.     Explicitly name your component [@Component(“beanName”)]

2.     Use ‘@Resource’ with the ‘name’ attribute [@Resource(name=”beanName”)]

3.     Avoid ‘@Qualifier’ annotations unless you want to create a list of similar beans. For example you may want to mark a set of rules with a specific ‘@Qualifier’ annotation. This approach makes it simple to inject a group of rule classes into a list that can be used for processing data.

4.     Scan specific packages for components [context:component-scan base-package=”com.sourceallies.person”]. While this will result in more component-scan configurations it reduces the chance that you’ll add unnecessary components to your Spring context.