CodeGym/Java Blog/Random/Exploring questions and answers from a job interview for ...
Konstantin
Level 36
Odesa

Exploring questions and answers from a job interview for a Java developer position. Part 1

Published in the Random group
members
Hi! CodeGym has brought together a diverse group of people. Some of us want nothing more than to become Java developers, and we're investing a lot of time and effort into development. Others are already Java developers. In either case, you need to be ready to be tested in technical interviews. These are not easy. They require both emotional and technical preparation. Exploring questions and answers from a job interview for a Java developer position. Part 1 - 1I recently came across a few large lists of interview questions for Java developer positions. The questions are divided into different levels: junior, mid-level, and senior. Don't be alarmed: not all the questions are easy, but those with an asterisk are rarely asked. The questions are good, and I would like to try to answer most of them. Clearly, this won't all fit in a single article. After all, there are a lot of questions there. That means there will be a whole series of articles with answers to these interview questions. Let me emphasize a few points right away: the answers will be short, because answers written in great detail may pulled out into a separate article. Also, at interviews super detailed and voluminous answers aren't wanted, because your interviewer only has an hour to interview you on essential topics (and, as you will recall, there are plenty of those).

Q&A for a junior developer position

General questions

1. What design patterns do you know? Tell us about two design patterns that you have used in your work.

There are a huge variety of patterns. For those of you who want to thoroughly familiarize yourselves with design patterns, I recommend reading the book "Head First. Design Patterns". It will help you easily learn the details of the most basic design patterns. In terms of design patterns that you could mention in a job interview, the following come to mind:
  • Builder — a frequently used template, an alternative to the classic approach to object creation;
  • Strategy — a pattern that essentially represents polymorphism. That is, we have one interface, but the program's behavior changes depending on the specific interface implementation passed to the function (the strategy pattern is now used just about everywhere in Java applications).
If that isn't enough for you, pay attention to Spring (if you are already familiar with it), because it is an entire platform of frameworks, which, in turn, are permeated with patterns from beginning to end. Here are a couple of examples of what I'm talking about:
  • Factory — this pattern can be found in ApplicationContext (or in BeanFactory);
  • Singleton — all beans are singletons by default;
  • Proxy — basically, everything in Spring uses this pattern in one way or another, for example, AOP;
  • Chain of responsibility — a pattern that underpins Spring Security;
  • Template — used in Spring JDBC.

Java Core

Exploring questions and answers from a job interview for a Java developer position. Part 1 - 2

2. What data types are there in Java?

Java has the following primitive data types:
  • byte — integers ranging from -128 to 127, takes up 1 byte;
  • short — integers ranging from -32768 to 32767, takes up 2 bytes;
  • int — integers ranging from -2147483648 to 2147483647, takes up 4 bytes;
  • long — integers ranging from 9223372036854775808 to 9223372036854775807, takes up 8 bytes;
  • float — floating point numbers ranging from -3.4E+38 to 3.4E+38, takes up 4 bytes;
  • double — floating point numbers ranging from -1.7E+308 to 1.7E+308, takes up 8 bytes;
  • char — single characters in UTF-16, takes up 2 bytes;
  • boolean true/false values, takes up 1 byte.
And there are reference data types that point to objects on the heap.

3. How does an object differ from primitive data types?

The first difference is the amount of memory occupied: primitives take up very little because they contain only their own value, but objects can contain lots of different values — both primitives and references to other objects. A second difference is this: Java is an object-oriented language, so everything in Java works is an interaction between objects. Primitives do not fit in very well here. In fact, that's why Java is not a 100% object-oriented language. The third difference, which follows from the second is that because Java is focused on object interactions, there are many different mechanisms for managing objects. For example, constructors, methods, exceptions (which work primarily with objects), etc. And to allow primitives to somehow work in this object-oriented environment, Java's creators came up with wrappers for the primitive types (Integer, Character, Double, Boolean...)

4. What is the difference between passing arguments by reference and by value?

Primitive fields store their value: for example, if we set int i = 9;, then the i field stores the value 9. When we have a reference to an object, that means we have a field with a reference to the object. In other words, we have a field that stores the address of the object in memory.
Cat cat = new Cat();
This means that fields with a reference to an object also store values. Their values are memory addresses. That is, cat stores the memory address of the new Cat() object. When we pass an argument to a method, its value is copied. In the case of a primitive, the value of the primitive is copied. Accordingly, the method works with the copy. When the copy is changed, the original is not affected. In the case of a reference type, the value of the memory address is copied. Accordingly, both reference variables will store addresses pointing to the same object. And if we use this new reference to change the object, then we will find that it is also changed for the old reference. After all, they both point to the same object.

5. What is JVM, JDK, and JRE?

JVM stands for Java Virtual Machine, which runs Java bytecode pre-generated by the compiler. JRE stands for Java Runtime Environment. Basically, it is an environment for running Java applications. It includes the JVM, standard libraries, and other components for running applets and applications written in the Java programming language. In other words, the JRE is a package of everything needed to run a compiled Java program, but it does not include tools and utilities such as compilers or debuggers for developing applications. JDK stands for Java Development Kit, which is an extension of the JRE. That is, it is an environment not only for running Java applications, but also for developing them. The JDK contains everything in the JRE, plus various additional tools — compilers and debuggers — needed to create Java applications (includes Java docs). Exploring questions and answers from a job interview for a Java developer position. Part 1 - 3

6. Why use the JVM?

As stated above, the Java Virtual Machine is a virtual machine that runs Java bytecode that has been pre-generated by the compiler. This means the JVM does not understand Java source code. So, first, we compile .java files. The compiled files have the .class extension and are now in the form of bytecode, which the JVM understands. The JVM is different for each OS. When the JVM runs bytecode files, it adapts them for the OS on which it is running. In fact, because there are different JVMs, the JDK (or JRE) also differ for different OS (each version needs its own JVM). Let's remember how development works in other programming languages. You write a program, then its code is compiled into machine code for a specific OS, and then you can run it. In other words, you need to write different versions of the program for each platform. But Java's double processing of the code (compilation of source code into bytecode, and then processing of bytecode by the JVM) lets you enjoy the benefits of a cross-platform solution. We create the code once and compile it into bytecode. Then we can take it to any OS, and the native JVM is able to run it. And this is precisely Java's legendary write once, run anywhere feature. Exploring questions and answers from a job interview for a Java developer position. Part 1 - 4

7. What is bytecode?

As I said above, the compiler converts Java code into intermediate bytecode (we go from files with the .java extension to files with the .class extension). In many ways, bytecode is similar to machine code, except that its instruction set is not for a real processor, but a virtual one. That said, it can include sections designed for a JIT compiler, which optimizes command execution for the actual processor the program is running on. JIT compilation, also called on-the-fly compilation, is a technology that increases a bytecode program's performance by compiling the bytecode into machine code or another format while the program is running. As you might have guessed, the JVM uses the JIT compiler when it runs bytecode. Let's take a look at some sample bytecode: Exploring questions and answers from a job interview for a Java developer position. Part 1 - 5Not too readable, eh? The good news is that this instruction isn't meant for us. It's for the JVM.

8. What are the features of a JavaBean?

A JavaBean is a Java class that follows certain rules. Here are some of the rules for writing a JavaBean:
  1. The class must contain an empty (no-argument) constructor with the public access modifier. This constructor makes it possible to create an object of the class without any unnecessary problems (so that there is no unnecessary fiddling with arguments).

  2. Internal fields are accessed via get and set instance methods, which should have the standard implementation. For example, if we have a name field, then we should have getName and setName, etc. This allows various tools (frameworks) to automatically get and set the content of beans without any difficulty.

  3. The class must override the equals(), hashCode(), and toString() methods.

  4. The class must be serializable. That is, it must have the Serializable marker interface or implement the Externalizable interface. This is so that the bean's state can be reliably saved, stored, and restored.

Exploring questions and answers from a job interview for a Java developer position. Part 1 - 6

9. What is an OutOfMemoryError?

OutOfMemoryError is a critical runtime error related to the Java Virtual Machine (JVM). This error occurs when the JVM cannot allocate an object because there is not enough memory for it, and the garbage collector cannot allocate more memory. A few types of OutOfMemoryError:
  • OutOfMemoryError: Java heap space — the object cannot be allocated on the Java heap due to insufficient memory. This error can be caused by a memory leak or by a default heap size that is too small for the current application.

  • OutOfMemoryError: GC Overhead limit exceeded — because the application's data barely fits in the heap, the garbage collector runs all the time, causing the Java program to run very slowly. As a result, the garbage collector overhead limit is exceeded and the application crashes with this error.

  • OutOfMemoryError: Requested array size exceeds VM limit — this indicates that the application tried to allocate memory for an array that exceeds the heap size. Again, this may mean that insufficient memory was allocated by default.

  • OutOfMemoryError: Metaspace — the heap ran out of space allocated for metadata (metadata are instructions for classes and methods).

  • OutOfMemoryError: request size bytes for reason. Out of swap space — some error occurred when trying to allocate memory from the heap, and as a result, the heap lacks sufficient space.

10. What is a stack trace? How do I get it?

A stack trace is a list of the classes and methods that have been called up to this point in the execution of an application. You can get the stack trace at a specific point in the application by doing this:
StackTraceElement[] stackTraceElements =Thread.currentThread().getStackTrace();
This gets us an array of StackTraceElements arranged in Last In First Out (LIFO) order. Exploring questions and answers from a job interview for a Java developer position. Part 1 - 7In Java, when people talk about a stack trace, they usually mean a stack trace displayed on the console when an error (or exception) occurs. You can get the stack trace from exceptions like this:
StackTraceElement[] stackTraceElements;
try{
                ...
} catch (Exception e) {
   stackTraceElements = e.getStackTrace();
}
And if we want to display an exception's stack trace on the console:
try{
                ...
} catch (Exception e) {
  e.printStackTrace();
}
Additionally, if an error, unchecked exception, or unhandled checked exception occurs, then we automatically get the exception's stack trace on the console when the application crashes. Here is a small example of a stack trace on the console: Exploring questions and answers from a job interview for a Java developer position. Part 1 - 8And on that note, we'll conclude our discussion of this topic today.Exploring questions and answers from a job interview for a Java developer position. Part 1 - 9
Comments (1)
  • Popular
  • New
  • Old
You must be signed in to leave a comment
ron_villela
Level 9 , Miami, United States
8 August 2021, 05:36
Keep it coming! Great article…Thank you!