Jeg havde et interview med GS på deres kontor i Bengaluru. Jeg har 4 års erfaring med fuld stack udvikling ved hjælp af Java. Jeg blev ringet op af en konsulent.

Runde 1

1. Hvilke begreber er du fortrolig med i Java? Jeg sagde samlinger. Han spurgte, hvilke indsamlingsklasser har du brugt? Jeg sagde HashMap ArrayList og HashSet.
2. Hvornår vil du bruge Set og hvornår en liste? Jeg sagde, at Set understøtter unikke ikke-null-elementer, og List har ikke den begrænsning. Så hvis jeg vil have unikke elementer, vil jeg bruge Set. Han spurgte om andre overvejelser? Jeg sagde, hvilken type forespørgsler, der skal udføres på samlingen. Som søgning. Spurgte han om et eksempel? Jeg sagde – medarbejderdatabase. Medarbejdere skal være unikke, så vi kan bruge List og søge ved binær søgning eller en lignende teknik, da de generelt er sorteret i en eller anden rækkefølge. Men jeg tror, ​​han havde forventet O(1)-opslagstidssvaret eller Set. Jeg forklarede, hvordan HashMap og HashSet fungerer, og hvordan det ville hjælpe en udvikler til nemt at opnå det unikke ved elementer, men intervieweren var ikke overbevist med mit svar på sit oprindelige spørgsmål.
3. Hvad er kontrakten for equals() og hashCode()? Hvad hvis den ene er tilsidesat, men den anden ikke er det?
4. Find det andet minimum i en given matrix .
5. Find omdrejningspunktet i et sorteret og roteret array.
6. Nogen spørgsmål til mig?
Runde 2

1. Giv en kort introduktion om din erhvervserfaring.
2. Giv et overblik over dit seneste projekts design.
3. Antag, at jeg har en brugergrænseflade, hvor der er en liste eller tabel over varer, og hver vare har en fortjenesteattribut, en rabatattribut osv. Hvordan man sikrer, at flere brugere ikke forlader tilstanden for en vare inkonsekvent. Brugeren kan opdatere attributterne, eller en anden webservice kan gøre det samme. Jeg foreslog at synkronisere sætter-metoderne for elementet. Han spurgte, hvordan man sorterede tingene. Jeg sagde, at emnerne ville ligge i en array-liste og implementerede den sammenlignelige grænseflade. Han bad om en arbejdskode. Da jeg skrev udtrykket inde i compareTo()-metoden sagde han, at designet ikke er fleksibelt, da der findes hårde kodningskriterier. Han sagde, at når nogen ønsker at sortere efter en anden egenskab, ville det blive umuligt at håndtere så mange duplikerede objekter. Jeg sagde, at vi kan gøre det med Factory Method Pattern. Hermed afsluttede han reelt interviewrunden. Et sted imellem havde han nævnt Comparator-grænsefladen, og jeg forklarede ham, hvordan det fungerer. Jeg sagde, at det er et godt valg, hvis man ikke ønsker at ændre de eksisterende klasser. Jeg tror, ​​han forventede implementeringen af ​​compare()-metoden, da det ikke ville kræve duplikerede objekter, og sorteringen efter forskellige kriterier kan udføres ved blot at implementere Comparator i forskellige klasser en klasse for hvert sorteringskriterium og derefter påberåbe sort()-metoden for Collections-klassen med den Comparator-implementering.
4. Nogen spørgsmål til mig?
Fik besked på at tage afsted for dagen. Råd: Prøv ikke at tage designmønstre op, medmindre du bliver bedt om det, eller du har erfaring med at løse problemer med designmønstre. Lyt til intervieweren og vær opmærksom. De giver hints. Også i runde 1 havde jeg lavet en fejl i spørgsmålet om roteret array. Han gav en testcase, hvor min kode ville fejle. Jeg korrigerede faldgruben. Tag nok søvn før interviewdagen. Alle øvelsesproblemer for Goldman Sachs ! Opret quiz