Ik had een interview met GS op hun kantoor in Bengaluru. Ik heb 4 jaar ervaring met full-stack ontwikkeling met behulp van Java. Ik werd gebeld door een adviseur.
Ronde 1
Met welke concepten voel je je comfortabel binnen Java? Ik zei collecties. Hij vroeg welke verzamelklassen heb je gebruikt? Ik zei HashMap ArrayList en HashSet.
Wanneer zou je Set gebruiken en wanneer een lijst? Ik zei dat Set unieke niet-null-elementen ondersteunt en List heeft die beperking niet. Dus als ik unieke elementen wil, zal ik Set gebruiken. Hij vroeg nog een andere overweging? Ik zei het type zoekopdrachten dat op de collectie moest worden uitgevoerd. Zoals zoeken. Hij vroeg een voorbeeld? Ik zei – werknemersdatabase. Werknemers moeten uniek zijn, zodat we List kunnen gebruiken en zoeken via binaire zoekopdrachten of een vergelijkbare techniek, omdat ze over het algemeen in een bepaalde volgorde worden gesorteerd. Maar ik denk dat hij het O(1) opzoektijdantwoord of Set had verwacht. Ik legde de werking van HashMap en HashSet uit en hoe dat een ontwikkelaar zou helpen om gemakkelijk het unieke karakter van elementen te bereiken, maar de interviewer was niet overtuigd van mijn antwoord op zijn oorspronkelijke vraag.
Wat is het contract van equals() en hashCode()? Wat als de ene overschreven wordt, maar de andere niet?
Zoek het tweede minimum in een gegeven array .
Zoek het draaipunt in een gesorteerde en geroteerde array.
Heeft u een vraag voor mij?
Ronde 2
Geef een korte introductie over uw werkervaring.
Geef een overzicht van het ontwerp van uw recente project.
Stel dat ik een gebruikersinterface heb met een lijst of tabel met artikelen en elk artikel een winstkenmerk, een kortingskenmerk enz. heeft. Hoe zorg ik ervoor dat meerdere gebruikers de status van een artikel niet inconsistent laten? De gebruiker kan de kenmerken bijwerken of een andere webservice kan hetzelfde doen. Ik stelde voor om de instelmethoden van het item te synchroniseren. Hij vroeg hoe hij de spullen moest sorteren. Ik zei dat de items in een arraylijst zouden staan en implementeerde de vergelijkbare interface. Hij vroeg om een werkende code. Toen ik de expressie in de methode CompareTo() schreef, zei hij dat het ontwerp niet flexibel is omdat er harde codering van sorteercriteria bestaat. Hij zei dat wanneer iemand op een ander attribuut wil sorteren, het onmogelijk zou worden om zoveel dubbele objecten te beheren. Ik zei dat we het kunnen doen met het Factory Method Pattern. Hierop beëindigde hij feitelijk de interviewronde. Ergens tussendoor had hij de Comparator-interface genoemd en ik legde hem uit hoe deze werkt. Ik zei dat het een goede keuze is als je de bestaande klassen niet wilt wijzigen. Ik denk dat hij de implementatie van de Compare()-methode verwachtte, omdat daarvoor geen dubbele objecten nodig zijn en het sorteren op verschillende criteria kan worden gedaan door simpelweg Comparator in verschillende klassen te implementeren, één klasse voor elk sorteercriterium en vervolgens de sort()-methode van de Collections-klasse aan te roepen met die Comparator-implementatie.
Heeft u een vraag voor mij?
Werd verteld om voor vandaag te vertrekken. Advies: Probeer geen ontwerppatronen ter sprake te brengen, tenzij u daarom wordt gevraagd, of als u ervaring hebt met het oplossen van problemen met ontwerppatronen. Luister naar de interviewer en wees alert. Ze geven tips. Ook in ronde 1 had ik een fout gemaakt bij de geroteerde array-vraag. Hij gaf een testcase waarbij mijn code zou falen. Ik heb de valkuil gecorrigeerd. Zorg voor voldoende slaap vóór de dag van het sollicitatiegesprek. Alle oefenproblemen voor Goldman Sachs ! Quiz maken