У мене була співбесіда з GS у їхньому офісі в Бенгалуру. У мене 4 роки досвіду розробки повного стеку за допомогою Java. Мені подзвонив консультант.
раунд 1
Які концепції вам зручні в Java? Я сказав колекції. Він запитав, які класи збору ви використовували? Я сказав HashMap ArrayList і HashSet.
Коли б ви використовували Set, а коли список? Я сказав, що Set підтримує унікальні ненульові елементи, а List не має цього обмеження. Отже, якщо мені потрібні унікальні елементи, я буду використовувати Set. Він запитав про якісь інші міркування? Я сказав тип запитів, які потрібно виконувати до колекції. Як пошук. Він запитав якийсь приклад? Я сказав – база співробітників. Співробітники мають бути унікальними, щоб ми могли використовувати список і пошук за допомогою бінарного пошуку або подібної техніки, оскільки зазвичай вони сортуються в певному порядку. Але я думаю, що він очікував відповіді O(1) час пошуку або Set. Я пояснив роботу HashMap і HashSet і як це допоможе розробнику легко досягти унікальності елементів, але інтерв’юер не був переконаний моєю відповіддю на його початкове запитання.
Що таке договір equals() і hashCode()? Що робити, якщо один перевизначено, а інший ні?
Знайти другий мінімум у заданому масиві .
Знайдіть точку опори в відсортованому та повернутому масиві.
Є запитання до мене?
2 раунд
Коротко розкажіть про свій досвід роботи.
Дайте огляд дизайну свого нещодавнього проекту.
Припустімо, у мене є користувальницький інтерфейс, де є список або таблиця елементів, і кожен елемент має атрибут прибутку, атрибут знижки тощо. Як переконатися, що кілька користувачів не залишають стан будь-якого елемента неузгодженим. Користувач може оновити атрибути або інший веб-сервіс може зробити те саме. Я запропонував синхронізувати методи налаштування елемента. Він запитав, як сортувати речі. Я сказав, що елементи будуть знаходитися в списку масивів, і реалізував інтерфейс Comparable. Він попросив робочий код. Коли я написав вираз у методі compareTo(), він сказав, що дизайн не є гнучким, оскільки існує жорстке кодування критеріїв сортування. Він сказав, що коли хтось захоче сортувати за іншим атрибутом, стане неможливо керувати такою кількістю повторюваних об’єктів. Я сказав, що ми можемо зробити це за допомогою шаблону методу Factory. На цьому він фактично припинив інтерв’ю. Десь між ними він згадав інтерфейс компаратора, і я пояснив йому, як він працює. Я сказав, що це хороший вибір, якщо ви не хочете змінювати існуючі класи. Я думаю, що він очікував реалізації методу compare(), оскільки для цього не потрібні дублікати об’єктів, а сортування за різними критеріями можна виконати, просто реалізувавши Comparator у різних класах по одному класу для кожного критерію сортування, а потім викликавши метод sort() класу Collections із цією реалізацією Comparator.
Є запитання до мене?
Сказали залишити на день. Порада: намагайтеся не згадувати шаблони проектування, якщо цього не попросять або у вас є досвід вирішення проблем із шаблонами проектування. Слухайте співрозмовника та будьте уважні. Вони дають підказки. У раунді 1 я також зробив помилку в питанні обертаного масиву. Він навів тестовий приклад, де мій код не вийде. Я виправив підводний камінь. Висиптеся перед днем співбесіди. Усі практичні завдання для Goldman Sachs ! Створіть вікторину