Exploration des questions et réponses d'un entretien d'embauche pour un poste de développeur Java. Partie 1

Salut! CodeGym a réuni un groupe diversifié de personnes. Certains d'entre nous ne veulent rien de plus que devenir développeurs Java, et nous investissons beaucoup de temps et d'efforts dans le développement. D'autres sont déjà des développeurs Java. Dans les deux cas, vous devez être prêt à être testé lors d'entretiens techniques. Ce n'est pas facile. Ils nécessitent à la fois une préparation émotionnelle et technique. Je suis récemment tombé sur quelques grandes listes de questions d'entretien pour des postes de développeur Java. Les questions sont divisées en différents niveaux : junior, intermédiaire et senior. Ne vous inquiétez pas : toutes les questions ne sont pas faciles, mais celles avec un astérisque sont rarement posées. Les questions sont bonnes, et j'aimerais essayer de répondre à la plupart d'entre elles. De toute évidence, tout cela ne tiendra pas dans un seul article. Après tout, il y a beaucoup de questions là-bas. Cela signifie qu'il y aura toute une série d'articles avec des réponses à ces questions d'entrevue. Permettez-moi d'insister sur quelques points tout de suite : les réponses seront courtes, car les réponses écrites de manière très détaillée peuvent être extraites dans un article séparé. De plus, lors des entretiens, des réponses super détaillées et volumineuses ne sont pas souhaitées, car votre interlocuteur n'a qu'une heure pour vous interroger sur des sujets essentiels (et,

Q&A pour un poste de développeur junior

Questions générales

1. Quels modèles de conception connaissez-vous ? Parlez-nous de deux modèles de conception que vous avez utilisés dans votre travail.

Il existe une grande variété de motifs. Pour ceux d'entre vous qui souhaitent se familiariser avec les modèles de conception, je recommande la lecture du livre "Head First. Design Patterns". Cela vous aidera à apprendre facilement les détails des modèles de conception les plus élémentaires. En termes de modèles de conception que vous pourriez mentionner lors d'un entretien d'embauche, les éléments suivants vous viennent à l'esprit :

• Builder - un modèle fréquemment utilisé, une alternative à l'approche classique de la création d'objets ;
• Stratégie - un modèle qui représente essentiellement le polymorphisme. Autrement dit, nous avons une interface, mais le comportement du programme change en fonction de l'implémentation d'interface spécifique transmise à la fonction (le modèle de stratégie est maintenant utilisé à peu près partout dans les applications Java).

Si cela ne vous suffit pas, faites attention à Spring (si vous le connaissez déjà), car il s'agit d'une plate-forme complète de frameworks, qui, à leur tour, sont imprégnés de modèles du début à la fin. Voici quelques exemples de ce dont je parle :

• Factory — ce modèle peut être trouvé dans ApplicationContext (ou dans BeanFactory) ;
• Singleton — tous les beans sont des singletons par défaut ;
• Proxy - en gros, tout dans Spring utilise ce modèle d'une manière ou d'une autre, par exemple, AOP ;
• Chaîne de responsabilité - un modèle qui sous-tend Spring Security;
• Modèle — utilisé dans Spring JDBC.

Java Core

2. Quels types de données existe-t-il en Java ?

Java possède les types de données primitifs suivants :

• octet — nombres entiers allant de -128 à 127, occupe 1 octet ;
• court — entiers allant de -32768 à 32767, occupe 2 octets ;
• int — entiers allant de -2147483648 à 2147483647, occupe 4 octets ;
• long — entiers allant de 9223372036854775808 à 9223372036854775807, occupe 8 octets ;
• float — nombres à virgule flottante allant de -3.4E+38 à 3.4E+38, occupe 4 octets ;
• double — nombres à virgule flottante allant de -1,7E+308 à 1,7E+308, occupent 8 octets ;
• char — caractères uniques en UTF-16, occupe 2 octets ;
• valeurs booléennes vrai/faux, occupe 1 octet.

Et il existe des types de données de référence qui pointent vers des objets sur le tas.

3. En quoi un objet diffère-t-il des types de données primitifs ?

La première différence est la quantité de mémoire occupée : les primitives occupent très peu de place car elles ne contiennent que leur propre valeur, mais les objets peuvent contenir de nombreuses valeurs différentes — à la fois des primitives et des références à d'autres objets. Une deuxième différence est la suivante : Java est un langage orienté objet, donc tout ce qui fonctionne en Java est une interaction entre objets. Les primitifs ne s'intègrent pas très bien ici. En fait, c'est pourquoi Java n'est pas un langage 100% orienté objet. La troisième différence, qui découle de la seconde, est que, comme Java se concentre sur les interactions d'objets, il existe de nombreux mécanismes différents pour gérer les objets. Par exemple, les constructeurs, les méthodes, les exceptions (qui fonctionnent principalement avec des objets), etc. Et pour permettre aux primitives de fonctionner d'une manière ou d'une autre dans cet environnement orienté objet, les créateurs de Java ont proposéwrappers pour les types primitifs ( Integer , Character , Double , Boolean ...)

4. Quelle est la différence entre passer des arguments par référence et par valeur ?

Les champs primitifs stockent leur valeur : par exemple, si nous définissons int i = 9 ; , alors le champ i stocke la valeur 9. Lorsque nous avons une référence à un objet, cela signifie que nous avons un champ avec une référence à l'objet. En d'autres termes, nous avons un champ qui stocke l'adresse de l'objet en mémoire.

Cat cat = new Cat();

Cela signifie que les champs avec une référence à un objet stockent également des valeurs . Leurs valeurs sont des adresses mémoire. C'est-à-dire que cat stocke l'adresse mémoire du nouvel objet Cat() . Lorsque nous passons un argument à une méthode, sa valeur est copiée. Dans le cas d'une primitive, la valeur de la primitive est copiée. En conséquence, la méthode fonctionne avec la copie. Lorsque la copie est modifiée, l'original n'est pas affecté. Dans le cas d'un type référence, la valeur de l'adresse mémoire est copiée. En conséquence, les deux variables de référence stockeront des adresses pointant vers le même objet. Et si nous utilisons cette nouvelle référence pour modifier l'objet, nous constaterons qu'elle est également modifiée pour l'ancienne référence. Après tout, ils pointent tous les deux vers le même objet.

5. Qu'est-ce que JVM, JDK et JRE ?

JVM signifie Java Virtual Machine , qui exécute le bytecode Java pré-généré par le compilateur. JRE signifie Java Runtime Environment . Fondamentalement, c'est un environnement pour exécuter des applications Java. Il comprend la JVM, des bibliothèques standard et d'autres composants pour exécuter des applets et des applications écrites dans le langage de programmation Java. En d'autres termes, le JRE est un package de tout ce qui est nécessaire pour exécuter un programme Java compilé, mais il n'inclut pas d'outils et d'utilitaires tels que des compilateurs ou des débogueurs pour développer des applications. JDK signifie Java Development Kit , qui est une extension du JRE. C'est-à-dire qu'il s'agit d'un environnement non seulement pour exécuter des applications Java, mais également pour les développer. Le JDK contient tout dans le JRE, ainsi que divers outils supplémentaires - compilateurs et débogueurs - nécessaires pour créer des applications Java (y compris les documents Java).

6. Pourquoi utiliser la JVM ?

Comme indiqué ci-dessus, la machine virtuelle Java est une machine virtuelle qui exécute le bytecode Java qui a été pré-généré par le compilateur. Cela signifie que la JVM ne comprend pas le code source Java. Donc, d'abord, nous compilons les fichiers .java . Les fichiers compilés ont le .classextension et sont maintenant sous la forme de bytecode, que la JVM comprend. La JVM est différente pour chaque système d'exploitation. Lorsque la JVM exécute des fichiers de bytecode, elle les adapte au système d'exploitation sur lequel elle s'exécute. En fait, comme il existe différentes JVM, le JDK (ou JRE) diffère également selon le système d'exploitation (chaque version a besoin de sa propre JVM). Rappelons-nous comment fonctionne le développement dans d'autres langages de programmation. Vous écrivez un programme, puis son code est compilé en code machine pour un système d'exploitation spécifique, puis vous pouvez l'exécuter. En d'autres termes, vous devez écrire différentes versions du programme pour chaque plate-forme. Mais le double traitement du code par Java (compilation du code source en bytecode, puis traitement du bytecode par la JVM) permet de profiter des avantages d'une solution multiplateforme. Nous créons le code une fois et le compilons en bytecode. Ensuite, nous pouvons l'utiliser sur n'importe quel système d'exploitation et la JVM native est capable de l'exécuter. Et c'est précisément le légendaire de Javaécrire une fois, exécuter n'importe où .

7. Qu'est-ce qu'un bytecode ?

Comme je l'ai dit plus haut, le compilateur convertit le code Java en bytecode intermédiaire (on passe des fichiers avec l'extension .java aux fichiers avec l'extension .class). À bien des égards, le bytecode est similaire au code machine, sauf que son jeu d'instructions n'est pas destiné à un processeur réel, mais à un processeur virtuel. Cela dit, il peut inclure des sections conçues pour un compilateur JIT, qui optimise l'exécution des commandes pour le processeur réel sur lequel le programme s'exécute. La compilation JIT, également appelée compilation à la volée, est une technologie qui augmente les performances d'un programme de bytecode en compilant le bytecode en code machine ou dans un autre format pendant l'exécution du programme. Comme vous l'avez peut-être deviné, la JVM utilise le compilateur JIT lorsqu'elle exécute le bytecode. Jetons un coup d'œil à un exemple de bytecode : Pas trop lisible, hein ? La bonne nouvelle est que cette instruction ne nous est pas destinée. C'est pour la JVM.

8. Quelles sont les fonctionnalités d'un JavaBean ?

Un JavaBean est une classe Java qui suit certaines règles. Voici quelques-unes des règles d'écriture d'un JavaBean :

1. La classe doit contenir un constructeur vide (sans argument) avec le modificateur d'accès public . Ce constructeur permet de créer un objet de la classe sans aucun problème inutile (afin qu'il n'y ait pas de manipulation inutile d'arguments).

2. Les champs internes sont accessibles via les méthodes d'instance get et set , qui doivent avoir l'implémentation standard. Par exemple, si nous avons un champ de nom , alors nous devrions avoir getName et setName , etc. Cela permet à divers outils (frameworks) d'obtenir et de définir automatiquement le contenu des beans sans aucune difficulté.

3. La classe doit remplacer les méthodes equals() , hashCode() et toString() .

4. La classe doit être sérialisable. Autrement dit, il doit avoir l'interface de marqueur sérialisable ou implémenter l' interface externalisable . C'est ainsi que l'état du bean peut être enregistré, stocké et restauré de manière fiable.

9. Qu'est-ce qu'une erreur OutOfMemory ?

OutOfMemoryError est une erreur d'exécution critique liée à la machine virtuelle Java (JVM). Cette erreur se produit lorsque la JVM ne peut pas allouer un objet car il n'y a pas assez de mémoire pour celui-ci, et le ramasse-miettes ne peut pas allouer plus de mémoire. Quelques types d' OutOfMemoryError :

• OutOfMemoryError : espace de tas Java — l'objet ne peut pas être alloué sur le tas Java en raison d'une mémoire insuffisante. Cette erreur peut être causée par une fuite de mémoire ou par une taille de segment par défaut trop petite pour l'application en cours.

• OutOfMemoryError : Limite de surdébit GC dépassée — parce que les données de l'application tiennent à peine dans le tas, le ramasse-miettes s'exécute tout le temps, ce qui ralentit l'exécution du programme Java. Par conséquent, la limite de temps système du ramasse-miettes est dépassée et l'application se bloque avec cette erreur.

• OutOfMemoryError : La taille de la baie demandée dépasse la limite de la machine virtuelle : cela indique que l'application a tenté d'allouer de la mémoire pour une baie qui dépasse la taille du tas. Encore une fois, cela peut signifier qu'une mémoire insuffisante a été allouée par défaut.

• OutOfMemoryError: Metaspace - le tas a manqué d'espace alloué pour les métadonnées (les métadonnées sont des instructions pour les classes et les méthodes).

• OutOfMemoryError : taille de la requête en octets pour la raison. Espace d'échange insuffisant - une erreur s'est produite lors de la tentative d'allocation de mémoire à partir du tas et, par conséquent, le tas manque d'espace suffisant.

10. Qu'est-ce qu'une trace de pile ? Comment puis-je l'obtenir ?

Une trace de pile est une liste des classes et des méthodes qui ont été appelées jusqu'à présent dans l'exécution d'une application. Vous pouvez obtenir la trace de la pile à un point spécifique de l'application en procédant comme suit :

StackTraceElement[] stackTraceElements =Thread.currentThread().getStackTrace();

Cela nous donne un tableau de StackTraceElements disposés dans l'ordre Last In First Out (LIFO) . En Java, lorsque les gens parlent d'une trace de pile, ils font généralement référence à une trace de pile affichée sur la console lorsqu'une erreur (ou une exception) se produit. Vous pouvez obtenir la trace de la pile à partir d'exceptions comme celle-ci :

StackTraceElement[] stackTraceElements;
try{
                ...
} catch (Exception e) {
   stackTraceElements = e.getStackTrace();
}

Et si nous voulons afficher la trace de la pile d'une exception sur la console :

try{
                ...
} catch (Exception e) {
  e.printStackTrace();
}

De plus, si une erreur, une exception non vérifiée ou une exception vérifiée non gérée se produit, nous obtenons automatiquement la trace de la pile de l'exception sur la console lorsque l'application plante. Voici un petit exemple d'une trace de pile sur la console : Et sur cette note, nous conclurons notre discussion sur ce sujet aujourd'hui.