OO Design связанные вопросы в технических интервью [закрыто]

Я недавно посещал довольно много интервью, и компании попросили меня ответить на вопросы «спроектировать [вставить модель]» несколько раз.

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проблемы, то мы бы в значительной степени об этом поговорили. Если бы вы исправили это (возможно, сделав это а List<IVehicle>), я бы использовал это как отправную точку, чтобы взглянуть на эволюцию вашего дизайна. Есть причина, по которой требования являются базовыми, и нет четко определенных вариантов использования - именно так устроен мир.

Я мог бы бросить вам новое требование: «два мотоцикла могут парковаться в одном слоте», чтобы увидеть, как вы будете развивать свой дизайн, чтобы справиться с ним. Тогда, может быть, у нас будет разговор о параллельности (что если у нас будет два входа и одновременно подъедут две машины - ваш проект рухнет? Как? Что мы можем сделать, чтобы это исправить?). Другими возможными путями, которые следует изучить, будет то, как реализовать назначенную парковку, взимать плату за парковку, тарифы за ряд (возможно, более тесные ряды должны платить больше), ограниченную по времени парковку и как найти нарушителей и т. Д. И т. Д. И т. Д.

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

Раньше я спрашивал об этом - когда мы создавали диаграммы классов для генерации кода. Я до сих пор делаю время от времени, но не обычно. Мне нравится вопрос, потому что он позволяет мне увидеть, как человек думает.

Он предназначен для открытого конца. Ничего страшного. Там нет одного правильного ответа. У меня нет ответа в моей голове; Я хочу увидеть, к чему это приведет. Я думаю, что лучше задать вопрос лично, а не «по электронной почте в ответ». Речь идет о связи, предположениях и взаимодействии; не просто ответ!

1. Я видел такие интервью по крайней мере 12 лет назад. Это подход, который я использовал в течение последних 6 лет. Опыт показывает, что он выбирает лучших кандидатов на работу, чем 20 вопросов и дает им оценку из 20 подходов.

2. Опять же, я бы тоже сделал это очень открытым. Цель состоит в том, чтобы предоставить кандидату место для демонстрации способностей. Наличие кандидата, который задавал соответствующие вопросы на этом этапе, было бы плюсом. Как и кандидат, делающий хорошие предположения, но отмечающий, что это были предположения, и их необходимо будет пересмотреть перед внедрением.

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

Проектирование небольшой системы на самом деле является очень уместным заданием для собеседования. Это показывает ваши навыки в поиске хорошего программного решения для проблемы домена.

Тем не менее, я нахожу странным просто попросить опубликовать диаграмму классов онлайн без участия человека:

• Они упустят самое важное - рассуждения за диаграммой и то, что привело вас к созданию таких вещей.
• Там нет "парапета", чтобы помешать заявителю зайти слишком далеко. Если вы отразите окончательную реализацию на диаграмме, вы, вероятно, будете иметь десятки классов и нечитаемую схему.
• Умение рисовать диаграмму классов UML на самом деле не является обязательным навыком, это всего лишь одна нотация ОО среди других. Способность создавать твердые конструкции есть.

В живом интервью идеальные шаги, которые я ожидал бы сделать от кандидата:

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

Надеемся, что в какой-то момент рекрутер соберет достаточно информации о навыках кандидата и сделает это за день. Цель состоит не в том, чтобы внедрить полноценное рабочее решение (если это не одно из этих бесплатных услуг при скрытых собеседованиях).

Вопросы ООП являются открытыми. Нет правильного или неправильного ответа, но есть некоторые принципы, которые собеседники ожидают увидеть (например, использование конструктора для инициализации переменных, сохранение небольших методов, использование инкапсуляции / композиции / полиморфизма / наследования, когда это применимо, и т. Д.).

Всегда ожидайте, что структура данных, ООП и вопросы, связанные с базой данных в интервью, они очень распространены. Такие книги, как «взлом собеседования по кодированию» и «разоблачение интервью по программированию», помогут вам подготовиться.

Меня не так давно просили придумать дизайн для парковки. Во-первых, мне не дали никаких вариантов использования, но я упомянул пару позже. Я считаю, что мой дизайн не соответствовал тому, что имел в виду интервьюер. Я согласен с тем, что любой дизайн программного обеспечения действителен только для данного варианта использования. Возвращаясь к этому вопросу интервью, я полагаю, что у моего интервьюера не было опыта проектирования в реальном мире. Эти люди верят, что знают, о чем просят. Это другая история, действительно ли это правда или нет.