Jeg hadde et intervju med GS på deres Bengaluru-kontor. Jeg har 4 års erfaring i full stack utvikling ved bruk av Java. Jeg ble oppringt av en konsulent.

Runde 1

1. Hvilke konsepter er du komfortabel med i Java? Jeg sa samlinger. Han spurte hvilke samlingsklasser har du brukt? Jeg sa HashMap ArrayList og HashSet.
2. Når vil du bruke Set og når en liste? Jeg sa at Set støtter unike ikke-null-elementer og List har ikke den begrensningen. Så hvis jeg vil ha unike elementer vil jeg bruke Set. Han spurte om andre hensyn? Jeg sa hvilken type søk som skal utføres på samlingen. Som søk. Han spurte om et eksempel? Jeg sa – ansattes database. Ansatte må være unike slik at vi kan bruke List og søke med binært søk eller en lignende teknikk, da de vanligvis er sortert i en eller annen rekkefølge. Men jeg tror han hadde ventet O(1)-oppslagstidssvaret eller Set. Jeg forklarte hvordan HashMap og HashSet virket og hvordan det ville hjelpe en utvikler til å enkelt oppnå unike elementer, men intervjueren ble ikke overbevist med svaret mitt på det opprinnelige spørsmålet.
3. Hva er kontrakten til equals() og hashCode()? Hva om den ene er overstyrt, men den andre ikke?
4. Finn andre minimum i en gitt matrise .
5. Finn pivotpunktet i en sortert og rotert matrise.
6. Noen spørsmål til meg?
Runde 2

1. Gi en kort introduksjon om din arbeidserfaring.
2. Gi en oversikt over det siste prosjektets design.
3. Anta at jeg har et brukergrensesnitt der det er en liste eller tabell over varer og hver vare har et profittattributt et rabattattributt osv. Hvordan sikre at flere brukere ikke forlater tilstanden til en vare inkonsekvent. Brukeren kan oppdatere attributtene eller en annen nettjeneste kan gjøre det samme. Jeg foreslo å synkronisere settermetodene for elementet. Han spurte hvordan man skulle sortere varene. Jeg sa at elementene ville ligge i en matriseliste og implementerte Comparable-grensesnittet. Han ba om en fungerende kode. Da jeg skrev uttrykket inne i compareTo()-metoden sa han at designet ikke er fleksibelt da det finnes hard koding av sorteringskriterier. Han sa at når noen ønsker å sortere etter en annen egenskap, ville det bli umulig å administrere så mange dupliserte objekter. Jeg sa at vi kan gjøre det med Factory Method Pattern. Dermed avsluttet han intervjurunden. Et sted i mellom hadde han nevnt Comparator-grensesnittet, og jeg forklarte ham hvordan det fungerer. Jeg sa at det er et godt valg hvis man ikke ønsker å endre de eksisterende klassene. Jeg tror han forventet compare()-metodens implementering, da det ikke ville kreve dupliserte objekter, og sorteringen etter forskjellige kriterier kan gjøres ved ganske enkelt å implementere Comparator i forskjellige klasser en klasse for hvert sorteringskriterium og deretter påkalle sort()-metoden til Collections-klassen med den Comparator-implementeringen.
4. Noen spørsmål til meg?
Fikk beskjed om å dra for dagen. Råd: Prøv å ikke ta opp designmønstre med mindre du blir bedt om det eller du har erfaring med å løse problemer med designmønstre. Lytt til intervjueren og vær på vakt. De gir hint. Også i runde 1 hadde jeg gjort en feil i spørsmålet om rotert array. Han ga en testsak der koden min ville mislykkes. Jeg rettet opp fallgruven. Ta nok søvn før intervjudagen. Alle øvingsproblemer for Goldman Sachs ! Lag quiz