Питання, пов'язані з проектом OO в технічних інтерв'ю [закрито]

Нещодавно я відвідував досить багато інтерв’ю, і компанії мене просили відповісти на питання "спроектувати [вставити модель]" більше ніж кілька разів.

1. Чи нормально це зараз у галузі? Я працював у світі програмного забезпечення більше двох десятиліть і відвідував свою частку інтерв'ю, але я бачу, що ця модель в інтерв'ю з'являється зовсім недавно.
2. Я відчуваю, що питання дуже відкрите. Наприклад: Мене попросили намалювати схему класу на тему "Дизайн парковки". Я не впевнений, якого рівня деталізації очікує інтерв'юер. Це було в онлайн-тесті, де я повинен був приєднати візіо-діаграму, тому я не міг запитати їх, які їх очікування.
3. Чи використовуєте ви такі запитання в процесі співбесіди? Чи пов'язані вони лише з діаграмами класів або ви також запитуєте послідовність, блок-схеми та ERD (звичайно, виходячи з характеру посади) Чи були вони ефективними у вашому процесі найму?

* Редагувати для відповіді Кевіна *

Наприклад: Повним питанням може бути "Створення системи управління парковкою, яка може бути використана для пошуку вільних слотів"

Я можу зробити з 2 - ма класами, ParkingLotі Slotчи я міг би піти на додати IVehicleі Vehicleта Carі Motorcycleкласи. Де я малюю лінію?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Певною мірою, так. Будь-хто може декламувати синтаксис або скопіювати / вставити їх через рішення. Ми хочемо найняти людей, які можуть вирішити проблеми.

2. Вони очікують, що ви достатньо документуєте дизайн, щоб вони могли його зрозуміти (і не більше того).

3. Я запитую людей, як вони вирішили б проблему XYZ, так. Зазвичай вони просто описують це усно. Я хочу побачити, чи задають вони питання для уточнення вимог. Хочу побачити, як вони спілкуються з іншими програмістами. Я хочу подивитися, чи можуть вони думати на ногах.

Це було мені корисно. Я не хочу кодових мавп, я хочу інженерів програмного забезпечення.

Ці питання я вважаю досить дурними. Справжня відповідь - "які випадки використання?" Без випадків використання немає необхідності в будь-якій конструкції. Наприклад, ось ідеально розумна відповідь на питання про паркування:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Це задовольняє один очевидний випадок використання.

Ви фактично демонструєте одне використання цього питання у своїй редакції, де ви не спроектували працюючу модель.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Ви також згадуєте створення Carта Motorcycleзаняття, що не має великого сенсу без подальшого розгляду. Ваш дизайн не піде на користь від підкласу Vehicle. Якщо ви представите Motorcycleбез будь-яких відмінностей у поведінці Vehicle, я вважаю це невдалим.

Якщо ви не помітили жодної Vehicleпроблеми, то ми б майже все зробили в прямому інтерв'ю. Якщо ви це виправили (можливо, зробивши це a List<IVehicle>), я б використав це як вихідну точку, щоб подивитися на еволюцію вашого дизайну. Існує причина, що вимоги є основними, і немає чітко визначених випадків використання - це майже так, як працює світ.

Я можу накинути на вас нову вимогу, що "два мотоцикли можуть припаркуватися в одному слоті", щоб побачити, як ви розвинете свій дизайн, щоб впоратися з ним. Тоді, можливо, ми ведемо розмову про одночасність (Що робити, якщо у нас два входи, і дві машини піднімуться одночасно - чи буде ваша конструкція невдалою? Як? Що ми можемо зробити, щоб її виправити?). Іншими можливими напрямками, які слід вивчити, було б, як запровадити призначене паркування, стягнути плату за паркування, тарифи за ряд (можливо, ближчі ряди повинні платити більше), обмежену часом паркування та як знайти правопорушників тощо, тощо.

Я також вважаю, що ваш роздум навколо паркінгів є свідченням вашої загальної здатності інтелектуально аналізувати проблему. Якщо вам доведеться попросити мене про основні випадки використання та / або придумати незвичайні (наприклад, 2 на 1 спец. Про паркування), я починаю сильно перейматися тим, що ви ніколи раніше не користувались парковкою і що ми буде важко спілкуватися з чим-небудь трохи складним.

Я питав це - ще коли ми створювали діаграми класів для генерації коду. Я все ще роблю при нагоді, але не буденно. Мені подобається питання, тому що воно дозволяє мені бачити людину думкою.

Він призначений відкритим способом. Гаразд. Немає однієї правильної відповіді. Я не маю відповіді в думці; Я хочу побачити, куди це веде. Я думаю, що краще запитати особисто, а не "електронною поштою у відповідь". Йдеться про спілкування, припущення та взаємодію; не просто відповідь!

1. Я бачив такий тип інтерв'ю щонайменше 12 років тому. Це підхід, який я використовував останні 6 років. Досвід показує, що він відбирає кращих кандидатів на роботу, ніж ставити 20 питань і дає їм оцінку з 20 підходу.

2. Знову ж таки, я б і дуже відкритим закінчився. Мета - забезпечити кандидату простір для демонстрації здібностей. Наявність кандидата, який на цьому етапі задавав відповідні питання, було б плюсом. Як і кандидат, який робить хороші припущення, але відзначає, що вони були припущеннями, і їх потрібно переглянути перед реалізацією.

3. Я вимагаю від усіх потенційних співробітників продемонструвати навички, необхідні для роботи під час співбесіди. Для програмістів їм потрібно буде реалізувати якийсь код і поговорити про їх розробку для цього. Це дуже ефективно для запобігання поганому найму, але будьте готові до 90% відмов на співбесіді.

Створення невеликої системи насправді є дуже актуальною вправою, яку потрібно задати в інтерв'ю. Це показує ваші навички, коли ви знайдете хороше програмне рішення для доменної проблеми.

Однак мені здається дивним просто попросити розмістити схему класів в Інтернеті без взаємодії з людьми:

• Вони пропустять найважливіше - міркування за діаграмою та те, що призвело до того, що ви спроектували речі таким чином.
• Немає жодного "парапету", який не міг би заявнику зайти занадто далеко. Якщо ви відображаєте остаточну реалізацію на діаграмі, напевно, у вас будуть десятки класів та нечитабельна схема.
• Вміти малювати діаграму класів UML насправді не є важливим вмінням, це лише одне позначення OO серед інших. Можливість створення міцних конструкцій є.

У прямому інтерв'ю ідеальними кроками, які я б очікував від кандидата, були б:

• Поговоріть про проблему з рекрутером і починайте висловлювати основне рішення усно, задаючи питання та коригуючи, оскільки рекрутер дає більш точні потреби.
• Встаньте та накресліть загальний вигляд системи та способів взаємодії компонентів. Це може бути найчистіший стиль UML, це можуть бути просто поля та кола.
• Напишіть тест, або тест на прийняття високого рівня, або одиничний тест для одного з компонентів / класів.
• Почніть писати відповідну реалізацію.

Сподіваємось, в якийсь момент рекрутер зібрає достатньо інформації про навички кандидата і зателефонує йому щодня. Мета - не реалізувати повноцінне робоче рішення (якщо тільки це не є одним із таких неоплачених послуг у маскувальних інтерв'ю).

Питання ООП є відкритими. Немає правильної чи неправильної відповіді, але є деякі принципи, які очікують побачити інтерв'юери (наприклад, використання конструктора для ініціалізації змінних, збереження ваших методів невеликим, використовуючи інкапсуляцію / композицію / поліморфізм / успадкування, коли це застосовується тощо).

Завжди очікуйте, що питання інтерв'ю щодо структури даних, ООП та баз даних вони дуже поширені. Книги на кшталт "розбиття інтерв'ю з кодуванням" та "викриття інтерв'ю програмування" можуть допомогти вам підготуватися.

Мене не так давно попросили розробити дизайн парковки. В першу чергу мені не було надано жодних випадків використання, але згадувалося пару пізніше. Я вважаю, що моя конструкція не відповідала тому, що мав на увазі інтерв'юер. Я погоджуюся, що будь-яка розробка програмного забезпечення діє лише для певного випадку використання. Повертаючись до цього питання про інтерв'ю, я вважаю, що мій інтерв'юер не мав реального досвіду дизайну у світі. Ці люди вірять, що вони знають, про що вони просять. Це вже інша історія, справді це правда чи ні.