Volt interjúm a GS-vel a bengalurui irodájukban. 4 éves tapasztalatom van teljes stack fejlesztésben Java használatával. Felhívott egy tanácsadó.

1. forduló

1. Milyen fogalmakat ismersz jól a Java-ban? Azt mondtam, gyűjtemények. Megkérdezte, milyen gyűjtési osztályokat használtál? Azt mondtam, HashMap ArrayList és HashSet.
2. Mikor használnád a Set-et és mikor a listát? Azt mondtam, hogy a Set támogatja az egyedi, nem nulla elemeket, és a List nem rendelkezik ezzel a megkötéssel. Tehát ha egyedi elemeket akarok, akkor a Set-et fogom használni. Kért más szempontot? Megmondtam a gyűjteményben végrehajtandó lekérdezések típusát. Mint a keresés. Kért példát? Azt mondtam – alkalmazottak adatbázisa. Az alkalmazottaknak egyedinek kell lenniük, hogy a Listát és a keresést bináris kereséssel vagy hasonló technikával tudjuk használni, mivel általában valamilyen sorrendben vannak rendezve. De azt hiszem, az O(1) keresési időre vagy a Set-re számított. Elmagyaráztam a HashMap és a HashSet működését, és azt, hogy ez hogyan segíti a fejlesztőt abban, hogy könnyen elérje az elemek egyediségét, de a kérdezőt nem győzte meg az eredeti kérdésére adott válaszom.
3. Mi az egyenlőség() és a hashCode() szerződése? Mi van, ha az egyik felül van írva, de a másik nem?
4. Keresse meg a második minimumot egy adott tömbben .
5. Keresse meg a forgáspontot egy rendezett és elforgatott tömbben.
6. Kérdés hozzám?
2. forduló

1. Röviden bemutassa szakmai tapasztalatait.
2. Adjon áttekintést legutóbbi projektje tervéről.
3. Tegyük fel, hogy van egy felhasználói felületem, ahol van egy cikklista vagy táblázat, és minden cikknek van egy profit attribútuma, egy diszkont attribútum stb. Hogyan biztosítható, hogy több felhasználó ne hagyja inkonzisztensen az egyes tételek állapotát. A felhasználó frissítheti az attribútumokat, vagy más webszolgáltatás is megteheti ugyanezt. Javasoltam az elem setter metódusainak szinkronizálását. Megkérdezte, hogyan kell szétválogatni a tárgyakat. Azt mondtam, hogy az elemek egy tömblistában lesznek, és megvalósítottam a Comparable felületet. Kért egy működő kódot. Amikor beírtam a kifejezést a összehasonlító() metódusba, azt mondta, hogy a tervezés nem rugalmas, mivel létezik a rendezési kritériumok kemény kódolása. Azt mondta, hogy ha valaki egy másik attribútum szerint szeretne rendezni, lehetetlenné válik ennyi ismétlődő objektum kezelése. Azt mondtam, hogy meg tudjuk csinálni a gyári módszer mintával. Ezzel gyakorlatilag befejezte az interjúkört. Valahol a kettő között említette a Comparator felületet, és elmagyaráztam neki, hogyan működik. Azt mondtam, hogy jó választás, ha valaki nem akarja módosítani a meglévő osztályokat. Azt hiszem, a összehasonlító metódus implementációjára számított, mivel ahhoz nem lesz szükség duplikált objektumokra, és a különböző kritériumok szerinti rendezést meg lehet tenni úgy, hogy egyszerűen implementálja a Comparator-t különböző osztályokban minden rendezési feltételhez egy osztályt, majd meghívja a Collections osztály sort() metódusát azzal a Comparator implementációval.
4. Kérdés hozzám?
Azt mondták, menjenek el a napra. Tanács: Ne hozzon létre tervezési mintákat, hacsak nem kérik, vagy ha van tapasztalata a tervezési mintákkal kapcsolatos problémák megoldásában. Hallgassa meg a kérdezőt, és legyen éber. Tippeket adnak. Az 1. körben is hibáztam az elforgatott tömbkérdésben. Adott egy tesztesetet, ahol a kódom meghibásodott. kijavítottam a buktatót. Aludjon eleget az interjú napja előtt. A Goldman Sachs összes gyakorlati problémája ! Kvíz létrehozása