Transcription
Uh, hey guys, today we have Bjala, and she has a total of 3.5 years of experience in Java, Spring Boot, and microservices domains. And those who want to give the same framework interview, please fill out the form below in the description. So now, let's get started.
Hey, hello Jala, how are you?
>> Yeah, hi, I'm fine.
>> Yes. Shall we start?
>> Yeah, sure.
>> Okay. Okay. So Jala, can you please introduce yourself and your recent project in brief?
>> Yeah, sure. Uh, hey guys, uh, I'm Jala Chi. I graduated in 2021 in Electronic and Communication Engineering from Assam University, Silchar. Then I joined Cognizant. There, uh, there I was working as a Java developer. I was working for a company called Chubb, uh, like this was my client, and it was an insurance-based uh project. So I was working there, uh, as a Java developer, uh, focusing on backend services, APIs, uh, and some parts of production support using Java, Spring Boot, and Oracle database.
>> Okay. So currently, your day-to-day task is creating REST APIs, right? Uh, creating features from scratch, right? So can you tell me how OOPs are very important in our projects, in our development projects, especially?
>> Yeah, so OOPs are the basic, uh, like concepts of object-oriented programming, and Java is an object-oriented programming language. Everything in Java, like not purely object-oriented, but 99% of the things in Java is an object. So in object, we have four basic concepts. First one is polymorphism, second one is encapsulation, third abstraction, and fourth one is uh...
>> Okay. Okay. So let's say, uh, if class B extends class A, and both have constructors, which constructor is called first when creating an object of B?
>> Uh, it will call first the constructor of B and then A.
>> Okay. So it, you, so it...
>> Sorry, sorry, it will first call the constructor of A, like the parent class.
>> And the, uh, child class, right?
>> Yeah. Yeah. Yeah. Yeah. That's correct. Parent class constructor is always called first, then the child class constructor. Okay. So, yeah. Yeah.
What happens if the parent has no default constructor but only a parameterized constructor?
>> Uh, like Java, uh, default constructor, like by default, uh, so it has parameterized, uh, like if, like if we are calling the, like something we are not giving anything, uh, so it will directly call the inbuilt constructor, which has, which is the default constructor. Okay. And, uh, and if it has no constructor, then it will go to the second constructor, like child class constructor.
>> Okay. Okay. Yeah. And also, because Java has a parameterized constructor. Oh, sorry, B, uh, A class as parent class, as a parameterized constructor. So it means a child must explicitly call the parent constructor using `super`, otherwise, compilation will fail. Okay.
>> Yeah. Okay.
So suppose you have a system with a `Shape` class and subclasses `Circle` and `Square`.
>> Yeah.
>> How would you design it so that the client code can calculate the area without knowing the exact shape type?
>> Uh, can you repeat the question?
>> Uh, suppose you have a system with a `Shape` class and subclasses `Circle` and `Square`.
>> How would you design it so that the client code can calculate the area without knowing the exact shape type?
>> Uh, so I will, uh, create one method called `area` in the parent class, and both the child classes, like `Circle` and `Rectangle`, whatever. So they will have to override this method.
>> And also, we could define a common method in the parent class `Shape` as `abstract double area()`, something like that.
>> So we have to create an abstract class also, like...
>> Uh, and override it with its own implementation, something like that.
>> So abstract class, then, like you didn't mention that we have to create the abstract class. So if we are calling the abstract class, then the method will be, uh, empty. So...
>> Uh, the child class will have to override it by default.
>> Okay. Okay.
>> Otherwise, it will be clear.
>> Yeah. Yeah. Okay.
Uh, so Jala, I would like to share one important thing with you. Actually, we had launched complete interview preparation material, structured step-by-step, by myself, expert in MNC interviews. And the best part is that now no one needs to go anywhere else to prepare for interviews. There's a 99% chance that interviews will ask questions from this material. So, basically, it contains a lot of material categorized by experience level. Means, each experience level has different material with all possible interview questions and answers for Java, Spring Framework, Maven, Git, Spring Boot, Spring Security, Spring Data JPA, Kafka, Microservices, uh, Java coding questions, Stream API coding questions, and many more. I have provided the link to get this in the below description. And if someone needs this material plus two real enterprise client projects for reference, plus one-on-one lifetime doubt sessions, and reference to the big MNCs, then they should check the interview preparation kit. I will provide the link for this as well in the description below.
So now, moving to our interview. Uh, so Jala, as we were discussing about OOPs, and you already told me there are four pillars: encapsulation, abstraction, inheritance, and polymorphism, right? So, uh, can you tell me how abstraction differs from encapsulation?
So, uh, the basic difference between abstraction and encapsulation is, encapsulation means we are, uh, restricting, uh, through, like we are restricting our, uh, to access, uh, like we are encapsulating everything in one, uh, thing. Like we use access modifiers, public, private, default, to prevent the access. Uh, and in, in abstraction, what we do, in abstraction, we hide the unnecessary implementation details to the user. Like we only show what is necessary.
>> Okay.
>> This is the difference between abstraction and encapsulation.
Okay. So in method overloading and method overriding, what happens if we change only the return type in method overloading?
>> Method overloading?
>> Yes. Yes. Method overloading.
>> Okay. So let me repeat the question again. What happens if we change only the return type in method overloading?
>> Uh, we cannot change the, uh, return type in method overloading. Like if we change it, it will be, uh, another method.
>> Yes, it will cause a compile-time error, right?
>> Yeah.
>> Actually, in method overloading, uh, we can change the, uh, input type, like the arguments, not the return type.
>> Okay. Okay.
So, uh, can we override static methods in Java?
>> Uh, no. Static methods belong to the class, not to any individual object. So we cannot override it.
>> Okay.
Can we call both `super` and `this` method in the same constructor?
>> Uh, `super` and `this`. Yeah, we call...
>> Okay.
>> `super` will call the parent class object, like the reference from the parent class, and `this` will refer to the current object.
>> Okay. Okay. So I think, uh, the answer is no, because, um, both must be the first statement in the constructor. So, but you can only use one of them.
>> Okay. I didn't know that.
>> Yeah. Okay.
Uh, so tell me the difference between an abstract class and an interface with a real-world scenario.
>> So in an abstract class, we have abstract methods, or we can have non-abstract methods also. Abstract methods are basically methods which have no implementation. It has only the definition. And interfaces are same. So, inter, in interfaces, till Java 7, we didn't have, uh, any, like we could have only abstract methods with no implementation. Uh, but after Java 8, we can have default and static methods also. Uh, the same with, uh, goes with the abstract class. But the major, uh, need of interfaces is, like we cannot have multiple inheritance in Java. So we need interfaces. So in interfaces, uh, it is the same thing. We define the structure. And in abstract classes, we can have, uh, like non-abstract methods also. We can have methods with implementation, which was not possible in Java, but in Java 8, it is possible.
>> Okay. Okay.
So since Java 8 introduced default and static methods in interfaces, right?
>> Uh, so when should we still prefer abstract classes?
>> Uh, when we should, uh, still prefer, like, uh, if we have, uh, one class in which we want certain methods, uh, which should be implemented in all the, uh, like, we don't need to override it. It is, it is common for all the methods, uh, all the classes which are going to inherit it, like the child classes. And the child classes do not need to implement multiple inheritance. They need to implement just one class, then I think abstract classes are fine to use.
>> Okay. Okay. Got it.
Uh, so moving ahead. What happens internally when you create an object in Java?
>> Uh, what happens internally when you create an object in Java? So when we create one object, uh, we, uh, we get memory, uh, the reference, uh, in the heap memory, the object is created in memory, and the reference, uh, is kept.
>> And...
>> Okay.
>> We get, uh, storage.
>> Mhm.
>> And when we need that, it has a, like there will be class loading, memory allocation, default initialization, constructor call.
>> The class loading is done, like when, when we create an object, the class is loaded first in JVM. It is, uh, the memory is assigned in the heap memory.
>> Okay.
>> So, can constructors be overridden in Java?
>> Uh, yeah, constructor. We have, uh, like default constructor. Java, uh, says, uh, we can have, uh, another constructor also, like different constructors. We can have multiple, uh, constructors.
>> No, no. We can have multiple constructors. That means, uh, that is overloading. Constructor overloading. Can we override constructor?
>> Override constructor?
>> Uh, yeah, I think yes.
>> Okay.
>> Uh, so yes, I think no, because constructors cannot be overridden because they are not inherited by child classes. Uh, okay. So constructors are meant to initialize objects of their own class. If they allow overriding, it would break the object creation chain, since child constructors are not supposed to redefine parent construction. Okay.
>> Okay.
So what will happen if you call a method inside its own body without a terminating condition?
>> Uh, can you repeat? Sorry.
>> What will happen if you call a method inside its own body without a terminating condition?
>> Uh, it will be an infinite loop because we don't have a termination.
>> Okay. It will be an infinite loop.
>> Infinite loop. Yes, that is correct. And, and once in memory is, uh, like it will be stack overflow.
>> Yes. Uh, so since this is an infinite recursion, method is calling its own method again and again, and it will lead to stack overflow. That's correct.
So tell me, how is recursion different from iteration?
>> Uh, in iteration, uh, we have one loop, like for loop, while loop, do loop. But in recursion, uh, we call this, like this, the method calls itself.
>> Uh, like one, like we have one method `add`, and inside its body, it is calling itself.
>> That is recursion.
>> Okay.
>> Uh, okay, got it.
So can you explain the different types of class loaders in Java?
>> Yeah. Uh, we have, uh, application loader.
>> Uh, uh, we have one, uh, sorry, it is a class, class loader.
>> Mhm.
>> And, uh, we have one more. We have three types of loaders. I'm not able to recall the name exactly, but one is class loader, one is application loader, and there's one more thing.
>> Bootstrap loader.
>> Bootstrap. Yeah.
>> And extension loader.
>> So, yes, that's correct. There are three types of, uh, class loaders: Bootstrap, Extension, and Application. Bootstrap is the core part of JVM, loads, uh, Extension loads classes from the JRE.
>> Yeah. And we can also define the class loading, uh, in Spring Boot, uh, application context or class loader class.
>> I just exactly forgot the syntax, but I know the concepts.
>> Yeah. Yeah. It's fine.
So can you tell me the difference between loading and linking?
>> Loading and linking.
>> Uh-huh.
>> Uh, like when we create one object, it is, uh, uh, it is getting loaded. That is application. That is, uh, loading.
>> Uh, linking, I, I don't, I'm not very sure. But maybe, uh, it is somehow linked to the autowired, uh, concept, injection, maybe. I'm not very sure.
>> Uh, okay. Okay. No, I, it's actually, it's not from the context of Spring Boot. Uh, it's, it's, I mean, I was asking from the core Java itself. Uh, so yes, uh, loading is correct. But in linking, the class is prepared for execution. Actually, there are three steps: verification, preparation, resolution. When we are linking the class, okay.
>> Yeah. Yeah. Okay.
So, can you tell me the difference between JDK, JRE, and JVM?
>> Okay. So the JDK, uh, stands for Java Development Kit. Uh, JDK, in JDK, we have JVM and JRE. Uh, JVM is the Java Virtual Machine, uh, which has all the things, which has JRE, and which has the application libraries, libraries also. And, uh, JRE is Java Runtime Execution, which actually executes the program. So in JVM, JVM, we have JRE and library, uh, which is, like, the, which is needed to execute the programs. And JRE actually executes the program. Uh, it converts it into bytecode, like .class.
>> Okay.
What's the role of JIT, Just-In-Time compiler?
>> Uh, JIT converts the byte, like we have JIT inside the JRE. So it converts the dot, like we have the .java, it converts it into byte, byte code, which is .class. And after that, we can, once we compile it, we can run it in different machines also, like, as we know, Java is, uh, platform independent. So once we convert it into dot, we can run it anywhere.
>> Okay. Okay.
Uh, all right. So, uh, despite there is a garbage collection collector in Java, so why, uh, we might see memory leaks?
>> Uh, sometimes, uh, what happens is that the, the object which is, like, not in use, but it is still referring to some point. The null object is still referring to some point. Uh, so it, it leads to memory leak.
>> Uh, uh, this is the main reason.
>> Okay.
So can you tell me the difference between heap memory and stack memory?
>> Yeah, in Java, we have two types of memory: heap memory and stack memory. So when we create any object, it goes into heap memory. And stack memory is used for function, like the flow of the functions. We have, when we call something, it goes in stack, and the program gets executed by the, you know, stack memory.
>> Okay. Okay. Okay.
So moving to the Spring Boot part, tell me, what is IOC (Inversion of Control) and how does it differ from traditional object creation?
>> So, uh, in traditional object creation, we use the `new` keyword. So we create the object by ourselves. But in Spring, on Spring Boot, what happens is that the Spring framework, it takes care of the creation of the object and the lifecycle of the, uh, sorry, lifecycle of the, uh, object. So we don't need to worry about that. We don't need to create the object by ourselves. It is the inversion of control, like the Spring, Spring framework is taking care of the creation and lifecycle of the object.
>> Okay. Okay. Okay.
So how does the IOC container know which beans to create and manage?
>> Uh, we have to, like, in Spring Boot, first of all, uh, we have, in classes, we use the, uh, annotation for component, called `@Component` or `@Service`, `@Repository`, `@Controller`. So it creates, uh, that. And if we want to specifically create a bean of...
>> So do you know about metadata? Metadata?
>> Uh, I have heard about it.
>> Okay. Okay. So actually, IOC containers use metadata.
>> Yeah. Based on this metadata, Spring creates and wires beans at runtime.
>> So, but we have to give the annotation of `@Bean`, right?
>> Yes. Yes. Yes. Yes. So all this data gets stored in the metadata. Bean creation configuration. We just give the annotations, uh, and these are things, I mean, these things get stored in the metadata, and then IOC container looks at the meta, looks at the metadata and just takes help and just does things. Okay.
So can you tell me the difference between `@Component`, `@Service`, and `@Repository` annotations?
>> Yeah, so `@Component` is the, uh, basic generic, uh, generic annotation, and it tells the class that it is, uh, component. And `@Service`, `@Controller`, and `@Repository` are basically, uh, like we use to define that is the, the service class of the business logic, `@Controller` is taking care of the API calls, and the `@Repository` level is dealing with the database.
>> Okay.
>> Like it is to specify what is the purpose of this.
>> So can we interchange the `@Repository` annotation and `@Service` annotation?
>> Uh, we can, but it is not a good practice.
>> Okay. Okay.
Moving ahead. Can you tell me the difference between field injection, setter injection, and constructor injection?
>> Uh, yeah. So basically, uh, you say annotations of injection, like, like as I already told that the Spring takes care of the, uh, lifecycle of the, uh, creation and lifecycle of the beans, which is like the method, sorry, objects. So, we sometimes we need to use that, also. So we don't need to, uh, link it automatically. We used to, we need to use the annotation `@Autowired`. So it automatically injects the dependency, which is called dependency injection. We have, uh, different types of, uh, injection, like setter injection. Uh, in that, we need to use some, we need to write a method to, uh, set the injection, and generally, we do it by the `@Autowired` annotation, so it automatically injects that.
>> Okay.
>> Okay.
So tell me, why is constructor injection considered the recommended approach?
>> Um, sorry, I don't know that. Like, I have heard about that, but I just forgot that.
>> Uh, okay, okay. Because it supports immutability. It, I mean, easier for unit testing. It helps avoid circular dependencies.
>> Okay.
>> Okay. Yeah. Okay.
So how does Spring resolve dependencies when multiple beans of the same type exist?
>> Okay. So it will give an error if we, if we don't, uh, use any, uh, annotation called `@Primary` or `@Qualifier`.
>> We have to use, uh, already predefined it, like `@Primary`. By using `@Primary` annotation, it will give, it will get the precedence, like preference. And we can also use `@Qualifier` annotation. And if we don't use anything, so it will give an error.
>> Okay. Okay. Got it.
Uh, so tell me the difference between `@Autowired` and manual bean wiring in XML configuration.
>> Uh, XML configuration, right?
>> Mhm.
>> So in `@Autowired`, we just use the annotation when we create, or don't create, we just define the, uh, object, then, uh, on top of that, we use `@Autowired` annotation. And in external configuration, we, we have to, like, in earlier, uh, Spring things, not in Spring Boot, we have, we had to write the configuration in XML file, that is XML configuration.
>> Okay.
>> Uh, okay. Got it.
So do you know about `NoSuchBeanDefinitionException`?
>> Uh, yeah, I have got this.
>> Yes. Yes. So what's that? Why did you get it?
>> Uh, `NoSuchBeanDefinitionException`. Uh, like sometimes we try to create any bean which is, like, does not exist, such type, then, uh, it gives the error, "No such bean found."
>> Okay.
>> Uh, it has got this exception, but...
>> Okay, okay.
So moving ahead, how can you create custom annotations? Did you try this?
>> Custom annotation?
>> Mhm.
>> Uh, no, I have not.
>> Okay. Yes, actually there are ways. Uh, we should use `@Target`, `@Retention` these annotations. Uh, okay. Uh, we can define a custom annotation and meta-annotate it with `@Component` or other Spring types.
>> Okay. Okay. I have not.
>> Yeah. Yeah. It's fine.
Uh, do you know about the Spring Bean scopes?
>> Yeah.
>> Yeah. Yeah. Please go ahead.
>> Uh, Spring beans, like in, uh, methods, sorry, the objects which are created by Spring, we call them beans.
>> Mhm.
>> Uh, scope, that is annotation, `@...`
>> No, no. Scopes, uh, means, uh, there are multiple scopes: singleton, prototype, request, session, of the Spring.
>> Yes. Yes. The singleton one, I know that, uh, it, it will have only one object, like at, at one given time, it will only, it will have only one object, that is, uh, um, singleton. Prototype, uh, I just forgot, but singleton...
>> New instance every time it's requested.
>> Always. Yeah, every time requested, it will give a new object.
>> Mhm. Yes. Okay.
Uh, so moving ahead. Do you know the difference between `ApplicationContext` and `BeanFactory`?
>> `ApplicationContext`, uh, we use in the, uh, the main method, we call the `run` method by `ApplicationContext`.
>> Mhm.
>> Uh, `BeanFactory`, sorry.
>> Yeah, okay. So it's fine. So `BeanFactory` is nothing, it's a basic DI container. Uh, it is, uh, it works on lazy initialization and it's lightweight. Uh, yes, it's a kind of `ApplicationContext`. I mean, `ApplicationContext` is a subset of `BeanFactory`.
>> Okay. But...
>> Mhm.
>> Yes. Yes. H sorry, it's a superset of `BeanFactory`. `ApplicationContext` is a superset of `BeanFactory`. Okay. Okay. And there might be questions like, in what scenarios would you prefer `BeanFactory` over `ApplicationContext`? So, in memory-constrained environments where fully `ApplicationContext` features are not needed for simple standalone applications. Right.
>> Okay.
>> Yeah. Okay.
So can you tell me about logging frameworks in Spring Boot?
>> Yeah. So for logging, uh, we use log, we have logback, uh, which, uh, like by default, the Spring Boot uses logback.
>> Uh, we have, uh, one, we have two more, I think, log4j.
>> Mhm.
>> Uh, and one more. But, uh, in our project, we use logback.
>> I just know about that logback.
>> Okay. Yeah. Yeah. So there are multiple, like logback, log4j2, Java Util Logging. So by default, Spring Boot uses logback because it's lightweight, performant, and it, uh, integrates well with Spring. Okay.
So, can you tell me how you debug any defect by looking through logs?
>> Yeah. So basically, we have logging levels. So we have to, in `application.properties` file, we have to set the level to the log level to `debug`. Then, it will give the, like, we have error, debug, info, uh, warning. These are the levels. So when we set it to debug, it will give all the logs of the debug level, and we have to look at the logs that what is the error in that.
>> Okay. Okay.
And do you know the different logging levels?
>> Uh, yeah. So the, the base, like, error is the topmost. Then we have, uh, warnings. Okay. Then we have info, debug, and, uh, the last one is, there's one more below the debug.
>> Uh, what was that?
>> Uh, trace. Debug, info, warn, error.
>> Okay.
>> Yeah. The error is the topmost. And in general, we get the, the debug level is at info level.
>> We get the logs, info level.
>> Okay. Okay. Okay.
So can you tell me the difference between `application.yml` and `properties` file?
>> Uh, yeah, uh, so we use `application.properties` file, and we also have `application.yml` file. So in `application.yml` file, we have the, like indentation. We don't have to repeat everything. But in `application.properties`, let's say we are writing `spring.datasource.url`, it is, and then we have to write `spring.datasource.password`, `username`, but in YAML, we have to write `spring.datasource` only one time, and after that, we can write URL, username, password, like that. Okay.
>> That's different.
>> Okay.
So what are the best practices while writing or creating REST APIs?
>> Writing REST API?
>> Yes.
>> So we have to use the controller. We have to use different classes, like service for the logic, business logic, controller for handling the REST APIs. So we, uh, in the class level, we write the annotation `@RestController`, and, uh, for every method, we write the code. Uh, and we use the annotation `@GetMapping`, `@PostMapping`, uh, like that.
>> Okay.
>> Okay. Okay.
So tell me the status codes for the REST APIs.
>> So, uh, 4xx is for errors. 404 Not Found. 401. 200 is for success. Like, two things are success. Uh, 501 or something like that is for client error.
>> I don't exactly remember the code. I remember 200 is for success, 404 Not Found.
>> Uh, there is one more client error, uh, which is like client side.
>> Okay. Okay. Yeah. They are 400 series, 500 series, right?
>> Yeah.
>> Okay.
So, tell me the difference between `ResponseEntity` and returning data from API through an object.
>> `ResponseEntity`, uh, in `ResponseEntity`, we get the data in JSON format.
>> Okay. Uh, like you're also talking. And, uh, in normal, like, we get the view, complete view, when we, uh, use the `ResponseEntity`. And, uh, the other one, we don't get the data in the JSON format.
>> And also, `ResponseEntity` returns with the status codes and headers also. Sorry, forgot that.
>> Yes, yes.
>> Yeah, it returns the status code.
>> Okay.
>> Uh, I have that is completely, please set my mind.
>> Yeah. Yeah. It's fine. Fine.
Uh, okay. So moving ahead. Uh, tell me, uh, how you guys are utilizing Git in your project?
>> So we use Git, uh, for, uh, like everything is based on Git also. Uh, when we make any changes, uh, we first create a feature branch. When we are working on any thing, uh, we, like our main branch is the `develop` branch. So we create one branch, feature branch, from the `develop` branch. Uh, then we push all the changes we do.
>> And, uh, then, uh, uh, we have to do the code review from our CL. And one of our team members, we need to, uh, approve. And after two approvals, like code review, uh, it gets merged to the `develop` branch, and then we deploy it.
>> Okay. Okay.
So tell me a few Git commands that you use in your day-to-day task.
>> Yeah. In day-to-day task, mostly we use `git pull`, `git push`, `git merge`, `git stash`.
>> Mhm.
>> So where we can use `git rebase`?
>> `rebase`.
>> Uh, sorry, I have never used it, but maybe.
>> `git cherry-pick`. Yeah, `cherry-pick` is, uh, used. It was used in my previous project a lot. Uh, when we want to cherry-pick from a particular branch, we use this command, `git cherry-pick`.
>> M. Correct. Correct. Okay.
Why do we use Maven in our project? Why?
>> Maven is a build tool.
>> Build tool. Okay. So what if we don't use Maven? What will happen?
>> Uh, if we don't use Maven, uh, we have, sorry, we use Maven and Gradle as a build tool. Otherwise, we have to take care of everything, like building everything, builds everything.
>> Uh, we will not be having dependencies. We need to do everything from scratch.
>> Yes. Yes. Okay.
So Jala, it's done from my end, and it was a very nice interview.