Onderzoek naar vragen en antwoorden van een sollicitatiegesprek voor een functie als Java-ontwikkelaar. Deel 1

Hoi! CodeGym heeft een diverse groep mensen bij elkaar gebracht. Sommigen van ons willen niets liever dan Java-ontwikkelaar worden, en we investeren veel tijd en moeite in ontwikkeling. Anderen zijn al Java-ontwikkelaars. In beide gevallen moet u klaar zijn om getest te worden in technische interviews. Deze zijn niet gemakkelijk. Ze vereisen zowel emotionele als technische voorbereiding. Ik kwam onlangs een paar grote lijsten met sollicitatievragen tegen voor Java-ontwikkelaarsposities. De vragen zijn onderverdeeld in verschillende niveaus: junior, mid-level en senior. Schrik niet: niet alle vragen zijn eenvoudig, maar vragen met een sterretje worden zelden gesteld. De vragen zijn goed, en ik zou graag proberen de meeste ervan te beantwoorden. Het is duidelijk dat dit niet allemaal in één artikel past. Er zijn immers veel vragen. Dat betekent dat er een hele reeks artikelen komt met antwoorden op deze interviewvragen. Laat me meteen een paar punten benadrukken: de antwoorden zullen kort zijn, omdat antwoorden die tot in detail zijn geschreven, in een apart artikel kunnen worden opgenomen. Ook zijn bij interviews super gedetailleerde en volumineuze antwoorden niet gewenst, omdat je interviewer maar een uur heeft om je te interviewen over essentiële onderwerpen (en,

Vraag en antwoord voor een positie als junior ontwikkelaar

Algemene vragen

1. Welke ontwerppatronen ken je? Vertel ons over twee ontwerppatronen die u in uw werk hebt gebruikt.

Er is een grote verscheidenheid aan patronen. Voor wie zich grondig wil verdiepen in design patterns, raad ik aan om het boek "Head First. Design Patterns" te lezen. Het helpt u gemakkelijk de details van de meest elementaire ontwerppatronen te leren. Wat betreft ontwerppatronen die je in een sollicitatiegesprek zou kunnen noemen, denk je aan het volgende:

• Builder — een veelgebruikte sjabloon, een alternatief voor de klassieke benadering van het maken van objecten;
• Strategie - een patroon dat in wezen polymorfisme vertegenwoordigt. Dat wil zeggen, we hebben één interface, maar het gedrag van het programma verandert afhankelijk van de specifieke interface-implementatie die aan de functie wordt doorgegeven (het strategiepatroon wordt nu vrijwel overal in Java-toepassingen gebruikt).

Als dat nog niet genoeg voor je is, let dan op Spring (als je er al bekend mee bent), want het is een heel platform van kaders, die op hun beurt van begin tot eind doordrongen zijn van patronen. Hier zijn een paar voorbeelden van waar ik het over heb:

• Factory — dit patroon is te vinden in ApplicationContext (of in BeanFactory);
• Singleton — alle bonen zijn standaard singletons;
• Proxy - eigenlijk gebruikt alles in Spring dit patroon op de een of andere manier, bijvoorbeeld AOP;
• Keten van verantwoordelijkheid — een patroon dat ten grondslag ligt aan Spring Security;
• Sjabloon — gebruikt in Spring JDBC.

Java-kern

2. Welke gegevenstypen zijn er in Java?

Java heeft de volgende primitieve gegevenstypen:

• byte — gehele getallen variërend van -128 tot 127, neemt 1 byte in beslag;
• short — gehele getallen variërend van -32768 tot 32767, neemt 2 bytes in beslag;
• int — gehele getallen variërend van -2147483648 tot 2147483647, neemt 4 bytes in beslag;
• lang — gehele getallen variërend van 9223372036854775808 tot 9223372036854775807, neemt 8 bytes in beslag;
• float — getallen met drijvende komma variërend van -3,4E+38 tot 3,4E+38, nemen 4 bytes in beslag;
• double — getallen met drijvende komma variërend van -1,7E+308 tot 1,7E+308, nemen 8 bytes in beslag;
• char — enkele tekens in UTF-16, neemt 2 bytes in beslag;
• Booleaanse waar/onwaar-waarden, neemt 1 byte in beslag.

En er zijn referentiegegevenstypen die verwijzen naar objecten op de heap.

3. Hoe verschilt een object van primitieve gegevenstypen?

Het eerste verschil is de hoeveelheid geheugen die in beslag wordt genomen: primitieven nemen heel weinig in beslag omdat ze alleen hun eigen waarde bevatten, maar objecten kunnen veel verschillende waarden bevatten - zowel primitieven als verwijzingen naar andere objecten. Een tweede verschil is dit: Java is een objectgeoriënteerde taal, dus alles wat in Java werkt, is een interactie tussen objecten. Primitieven passen hier niet zo goed. Daarom is Java in feite geen 100% objectgeoriënteerde taal. Het derde verschil, dat volgt uit het tweede, is dat omdat Java gericht is op objectinteracties, er veel verschillende mechanismen zijn voor het beheren van objecten. Bijvoorbeeld constructors, methoden, uitzonderingen (die voornamelijk met objecten werken), enz. En om primitieven op de een of andere manier in deze objectgeoriënteerde omgeving te laten werken, bedachten de makers van Javawrappers voor de primitieve typen ( Integer , Character , Double , Boolean ...)

4. Wat is het verschil tussen het doorgeven van argumenten op basis van referentie en op waarde?

Primitieve velden slaan hun waarde op: als we bijvoorbeeld int i = 9 instellen; , dan slaat het veld i de waarde 9 op. Als we een verwijzing naar een object hebben, betekent dit dat we een veld hebben met een verwijzing naar het object. Met andere woorden, we hebben een veld dat het adres van het object in het geheugen opslaat.

Cat cat = new Cat();

Dit betekent dat velden met een verwijzing naar een object ook waarden opslaan . Hun waarden zijn geheugenadressen. Dat wil zeggen, cat slaat het geheugenadres van het nieuwe object Cat() op . Wanneer we een argument doorgeven aan een methode, wordt de waarde ervan gekopieerd. In het geval van een primitief wordt de waarde van de primitief gekopieerd. Dienovereenkomstig werkt de methode met de kopie. Wanneer de kopie wordt gewijzigd, wordt het origineel niet beïnvloed. Bij een referentietype wordt de waarde van het geheugenadres gekopieerd. Dienovereenkomstig zullen beide referentievariabelen adressen opslaan die naar hetzelfde object wijzen. En als we deze nieuwe referentie gebruiken om het object te wijzigen, dan zullen we zien dat deze ook is gewijzigd voor de oude referentie. Ze wijzen immers allebei naar hetzelfde object.

5. Wat is JVM, JDK en JRE?

JVM staat voor Java Virtual Machine , die Java-bytecode uitvoert die vooraf is gegenereerd door de compiler. JRE staat voor Java Runtime Environment . Kortom, het is een omgeving voor het uitvoeren van Java-toepassingen. Het bevat de JVM, standaardbibliotheken en andere componenten voor het uitvoeren van applets en applicaties die zijn geschreven in de Java-programmeertaal. Met andere woorden, de JRE is een pakket met alles wat nodig is om een ​​gecompileerd Java-programma uit te voeren, maar het bevat geen tools en hulpprogramma's zoals compilers of debuggers voor het ontwikkelen van applicaties. JDK staat voor Java Development Kit , wat een uitbreiding is van de JRE. Dat wil zeggen, het is niet alleen een omgeving voor het uitvoeren van Java-applicaties, maar ook voor het ontwikkelen ervan. De JDK bevat alles van de JRE, plus verschillende extra tools — compilers en debuggers — die nodig zijn om Java-applicaties te maken (inclusief Java-documenten).

6. Waarom de JVM gebruiken?

Zoals hierboven vermeld, is de Java Virtual Machine een virtuele machine die Java-bytecode uitvoert die vooraf is gegenereerd door de compiler. Dit betekent dat de JVM de Java-broncode niet begrijpt. Dus, eerst compileren we .java- bestanden. De gecompileerde bestanden hebben de .classextensie en zijn nu in de vorm van bytecode, wat de JVM begrijpt. De JVM is voor elk besturingssysteem anders. Wanneer de JVM bytecode-bestanden uitvoert, worden deze aangepast voor het besturingssysteem waarop het draait. Omdat er verschillende JVM's zijn, verschillen de JDK (of JRE) ook voor verschillende besturingssystemen (elke versie heeft zijn eigen JVM nodig). Laten we onthouden hoe ontwikkeling werkt in andere programmeertalen. Je schrijft een programma, dan wordt de code gecompileerd tot machinecode voor een specifiek besturingssysteem, en dan kun je het uitvoeren. Met andere woorden, u moet voor elk platform verschillende versies van het programma schrijven. Maar Java's dubbele verwerking van de code (compilatie van broncode in bytecode en vervolgens verwerking van bytecode door de JVM) laat u genieten van de voordelen van een platformonafhankelijke oplossing. We maken de code eenmalig en compileren deze in bytecode. Dan kunnen we het naar elk besturingssysteem brengen en kan de native JVM het uitvoeren. En dit is precies Java's legendarischeenmaal schrijven, overal uitvoeren .

7. Wat is bytecode?

Zoals ik hierboven al zei, converteert de compiler Java-code naar intermediaire bytecode (we gaan van bestanden met de extensie .java naar bestanden met de extensie .class). In veel opzichten is bytecode vergelijkbaar met machinecode, behalve dat de instructieset niet voor een echte processor is, maar voor een virtuele. Dat gezegd hebbende, kan het secties bevatten die zijn ontworpen voor een JIT-compiler, die de uitvoering van opdrachten optimaliseert voor de eigenlijke processor waarop het programma draait. JIT-compilatie, ook wel on-the-fly-compilatie genoemd, is een technologie die de prestaties van een bytecodeprogramma verbetert door de bytecode in machinecode of een ander formaat te compileren terwijl het programma wordt uitgevoerd. Zoals je misschien al geraden hebt, gebruikt de JVM de JIT-compiler wanneer hij bytecode uitvoert. Laten we eens kijken naar een voorbeeld van een bytecode: Niet al te leesbaar, hè? Het goede nieuws is dat deze instructie niet voor ons is bedoeld. Het is voor de JVM.

8. Wat zijn de kenmerken van een JavaBean?

Een JavaBean is een Java-klasse die bepaalde regels volgt. Hier zijn enkele regels voor het schrijven van een JavaBean :

1. De klasse moet een lege (geen argument) constructor bevatten met de public access modifier. Deze constructor maakt het mogelijk om zonder onnodige problemen een object van de klasse te maken (zodat er geen onnodig gehannes met argumenten is).

2. Interne velden zijn toegankelijk via get- en set- instantiemethoden, die de standaardimplementatie zouden moeten hebben. Als we bijvoorbeeld een naamveld hebben, dan zouden we getName en setName moeten hebben , enz. Hierdoor kunnen verschillende tools (frameworks) zonder problemen automatisch de inhoud van beans ophalen en instellen.

3. De klasse moet de methodes equals() , hashCode() en toString() overschrijven.

4. De klasse moet serialiseerbaar zijn. Dat wil zeggen, het moet de Serialiseerbare markeringsinterface hebben of de Externaliseerbare interface implementeren. Dit is zodat de toestand van de boon betrouwbaar kan worden opgeslagen, opgeslagen en hersteld.

9. Wat is een OutOfMemoryError?

OutOfMemoryError is een kritieke runtime-fout gerelateerd aan de Java Virtual Machine (JVM). Deze fout treedt op wanneer de JVM een object niet kan toewijzen omdat er niet genoeg geheugen voor is en de vuilnisman niet meer geheugen kan toewijzen. Een paar soorten OutOfMemoryError :

• OutOfMemoryError: Java-heapruimte — het object kan niet worden toegewezen aan de Java-heap vanwege onvoldoende geheugen. Deze fout kan worden veroorzaakt door een geheugenlek of door een standaard heapgrootte die te klein is voor de huidige toepassing.

• OutOfMemoryError: GC Overhead-limiet overschreden — omdat de gegevens van de toepassing nauwelijks in de hoop passen, draait de vuilnisophaler de hele tijd, waardoor het Java-programma erg langzaam werkt. Als gevolg hiervan wordt de overheadlimiet van de Garbage Collector overschreden en crasht de toepassing met deze fout.

• OutOfMemoryError: aangevraagde arraygrootte overschrijdt de VM-limiet — dit geeft aan dat de toepassing heeft geprobeerd geheugen toe te wijzen voor een array die de heapgrootte overschrijdt. Nogmaals, dit kan betekenen dat er standaard onvoldoende geheugen is toegewezen.

• OutOfMemoryError: Metaspace — de heap had geen ruimte meer toegewezen voor metadata (metadata zijn instructies voor klassen en methoden).

• OutOfMemoryError: verzoek grootte bytes om reden. Geen swapruimte meer — er is een fout opgetreden bij het toewijzen van geheugen uit de heap, met als gevolg dat de heap onvoldoende ruimte heeft.

10. Wat is een stacktracering? Hoe krijg ik het?

Een stacktracering is een lijst van de klassen en methoden die tot nu toe zijn aangeroepen tijdens de uitvoering van een toepassing. U kunt de stacktracering op een specifiek punt in de toepassing krijgen door dit te doen:

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

Dit levert ons een reeks StackTraceElements op, gerangschikt in de volgorde Last In First Out (LIFO) . Als mensen in Java praten over een stacktrace, bedoelen ze meestal een stacktrace die op de console wordt weergegeven wanneer er een fout (of uitzondering) optreedt. U kunt de stacktracering ophalen uit uitzonderingen zoals deze:

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

En als we de stacktracering van een uitzondering op de console willen weergeven:

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

Bovendien, als er een fout, ongecontroleerde uitzondering of onverwerkte gecontroleerde uitzondering optreedt, krijgen we automatisch de stacktracering van de uitzondering op de console wanneer de toepassing crasht. Hier is een klein voorbeeld van een stacktracering op de console: En daarmee sluiten we onze bespreking van dit onderwerp vandaag af.