Имах интервю с GS в техния офис в Бенгалуру. Имам 4 години опит в разработването на пълен стек с помощта на Java. Обади ми се консултант.

Кръг 1

1. Какви концепции се чувствате комфортно в Java? Казах колекции. Той попита кои класове за събиране сте използвали? Казах HashMap ArrayList и HashSet.
2. Кога бихте използвали Set и кога списък? Казах, че Set поддържа уникални ненулеви елементи, а List няма това ограничение. Така че, ако искам уникални елементи, ще използвам Set. Той поиска някакво друго съображение? Казах вида на заявките, които трябва да бъдат извършени в колекцията. Като търсене. Той попита някакъв пример? Казах – база данни на служителите. Служителите трябва да са уникални, за да можем да използваме списък и търсене чрез двоично търсене или подобна техника, тъй като обикновено те са сортирани в някакъв ред. Но мисля, че той очакваше O(1) отговор за време за търсене или Set. Обясних работата на HashMap и HashSet и как това ще помогне на разработчика лесно да постигне уникалността на елементите, но интервюиращият не беше убеден с моя отговор на първоначалния му въпрос.
3. Какъв е договорът на equals() и hashCode()? Ами ако едното е отменено, но другото не е?
4. Намерете втори минимум в даден масив .
5. Намерете опорната точка в сортиран и завъртян масив.
6. Някакви въпроси към мен?
Кръг 2

1. Дайте кратко представяне за вашия трудов опит.
2. Дайте общ преглед на дизайна на скорошния си проект.
3. Да предположим, че имам потребителски интерфейс, където има списък или таблица с артикули и всеки артикул има атрибут за печалба, атрибут за отстъпка и т.н. Как да гарантирам, че множество потребители няма да напуснат състоянието на който и да е артикул непоследователно. Потребителят може да актуализира атрибутите или друга уеб услуга може да направи същото. Предложих синхронизиране на методите за настройка на елемента. Той попита как да сортира предметите. Казах, че елементите ще се намират в списък с масиви и внедрих интерфейса Comparable. Той поиска работещ код. Когато написах израза в метода compareTo(), той каза, че дизайнът не е гъвкав, тъй като съществува твърдо кодиране на критериите за сортиране. Той каза, че когато някой иска да сортира по друг атрибут, ще стане невъзможно да се управляват толкова много дублиращи се обекти. Казах, че можем да го направим с модела на фабричния метод. С това той ефективно прекрати интервюто. Някъде по средата той беше споменал интерфейса Comparator и аз му обясних как работи. Казах, че е добър избор, ако човек не иска да модифицира съществуващите класове. Мисля, че той очакваше изпълнението на метода compare(), тъй като това нямаше да изисква дублиращи се обекти и сортирането по различни критерии може да се направи чрез просто имплементиране на Comparator в различни класове, един клас за всеки критерий за сортиране и след това извикване на метода sort() на класа Collections с тази реализация на Comparator.
4. Някакви въпроси към мен?
Казаха му да напусне за деня. Съвет: Опитайте се да не повдигате шаблони за проектиране, освен ако не бъдете помолени да го направите или имате опит в решаването на проблеми с шаблони за проектиране. Слушайте интервюиращия и бъдете нащрек. Те предоставят съвети. В кръг 1 също бях направил грешка във въпроса за завъртяния масив. Той даде тестов случай, при който кодът ми щеше да се провали. Поправих клопката. Спете достатъчно преди деня на интервюто. Всички практически задачи за Goldman Sachs ! Създаване на тест