Структура интервью

ООП интервью проходят очень динамично. У вас есть примерно 45 минут на то, чтобы уточнить требования, определить объектную модель, спроектировать API классов и описать основную логику. Это не так уж много времени, и большинство кандидатов теряют баллы просто потому, что не умеют грамотно им распоряжаться.

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

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

Вот сама структура:

1. Требования (~5 минут)

Каждое ООП интервью начинается с вводной задачи, обычно это всего одно предложение, описывающее систему, которую вам предстоит спроектировать.

"Спроектируйте крестики-нолики"

"Спроектируйте систему для парковки"

"Спроектируйте кофемашину"

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

Придумывать вопросы с нуля может быть непросто. Чтобы направить свои мысли в нужное русло, пройдитесь по следующим темам:

• Основные возможности: какие операции должна поддерживать эта система?
• Правила и завершение: какие условия означают успешное выполнение, ошибку или момент, когда система останавливается либо меняет свое состояние?
• Обработка ошибок: как система должна реагировать на некорректные входные данные или действия?
• Границы ответственности: что входит в задачу (основная логика, бизнес-правила), а что явно выходит за ее рамки (пользовательский интерфейс, хранение данных, сеть, конкурентность, расширяемость)?

Эти темы универсальны и подходят для любой предметной области: будь то игры, устройства или транзакционные системы. Задав несколько точных вопросов по этим пунктам, вы быстро поймете, какого именно поведения системы ожидает от вас интервьюер.

Используйте полученные ответы, чтобы сформировать четкую спецификацию, и согласуйте ее с интервьюером. Если вы наткнетесь на функционал, который от вас не требуется реализовывать, тоже запишите это - так вы сохраните фокус и избежите разрастания масштабов задачи.

Например, если вам поручили "Спроектировать крестики-нолики", ваш итоговый список требований может выглядеть так:

Требования:
1. Два игрока по очереди ставят X и O на поле 3x3.
2. Игрок побеждает, если заполняет целиком строку, столбец или диагональ.
3. Игра заканчивается вничью, если все девять клеток заполнены, а победителя нет.
4. Недопустимые ходы должны отклоняться (ход в уже занятую клетку, попытка сделать ход после завершения игры).
5. Система должна предоставлять способ узнать текущее состояние игры и сбросить ее для начала новой.
 
Вне рамок задачи:
- Пользовательский интерфейс / отрисовка
- Компьютерный оппонент (AI) или подсказки для ходов
- Многопользовательская игра по сети
- Игровое поле произвольного размера (NxN)
- Функционал отмены/возврата ходов

2. Сущности и связи (~5 минут)

Как только требования зафиксированы, следующий шаг - перевести их в набор ключевых сущностей с четко определенными границами ответственности. Вы формируете каркас системы еще до того, как начнете думать о деталях какого-либо конкретного класса.

Определение сущностей

Начните с того, что пробегитесь глазами по вашим требованиям и выделите значимые существительные. Это "объекты", которые совершенно точно должны присутствовать в вашей системе. Ваша задача - определить те элементы, которые отвечают за состояние и поведение, а не пытаться смоделировать каждое существительное из спецификации.

Здесь полезно применить простой фильтр:

• Если что-то поддерживает меняющееся состояние или следит за выполнением правил, скорее всего, это должно стать отдельной сущностью.
• Если это просто какая-то информация, относящаяся к чему-то другому, то, скорее всего, это просто поле внутри другого класса.

Такой подход предотвратит разрастание вашего дизайна до огромного множества микрообъектов, но при этом обеспечит необходимую структуру.

Определение связей

После того как вы выделили сущности, подумайте о том, как они будут взаимодействовать. На этом этапе вы формируете очертания вашей системы:

• Какая сущность является "оркестратором" — тем, кто управляет основным рабочим процессом?
• Какие сущности хранят в себе долгоживущее состояние?
• Как они зависят друг от друга? (содержит, использует, включает в себя)
• Где логически должны находиться те или иные правила?

Эти решения дают вам ясную ментальную модель ответственности, что делает следующий шаг - проектирование классов - намного проще.

Как это изобразить на доске

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

Для крестиков-ноликов ваша доска может выглядеть так:

Сущности:
- Game (Игра)
- Board (Игровое поле)
- Player (Игрок)
 
Связи:
- Game -> Board
- Game -> Player (2x)

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

3. Проектирование классов (~10-15 минут)

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

Пройдитесь по каждой сущности, одна за другой. Начните с оркестратора (для крестиков-ноликов это класс Game), а затем переходите к вспомогательным сущностям (Board, Player и т.д.).

Для каждой сущности вы должны ответить на два вопроса:

1. Состояние: что этот класс должен хранить, чтобы обеспечивать выполнение требований?
2. Поведение: что этот класс должен уметь делать, то есть какие операции или запросы он поддерживает?

Если вы дисциплинированно связываете состояние и поведение с требованиями к системе, вы не гадаете и не раздуваете дизайн.

Как выводить состояние из требований

Вернитесь к списку требований и для каждой сущности задайте себе вопрос:

• За какие именно требования отвечает эта сущность?
• Какую информацию она должна держать в памяти, чтобы выполнять эти обязанности?

Вы можете в прямом смысле составить небольшую табличку в уме (или набросать ее на доске):

Требование -> Что должен отслеживать этот класс

Для крестиков-ноликов вот как это работает для класса Game:

Исходя из этого, вы можете выписать состояние для класса:

Game:
- board: Board
- playerX: Player
- playerO: Player
- currentPlayer: Player
- state: GameState (IN_PROGRESS, WON, DRAW)
- winner: Player? (null, если победителя нет)

Затем проделайте то же самое для остальных сущностей вашей системы.

Как выводить поведение из требований

Как только с состоянием все стало ясно, переходите к поведению. Для каждого класса задайте вопрос: какие операции нужны внешнему миру и какие требования эти операции закрывают? Вы должны стремиться к компактному, сфокусированному API, где каждый метод соответствует реальному действию или запросу, вытекающему из задачи.

Для крестиков-ноликов требования к классу Game трансформируются в следующее:

Вам нужно повторить этот процесс для каждой сущности в вашей системе, пока вы не выведете состояние и поведение для всех них.

Собирая все воедино: к моменту завершения этого этапа интервью вы набросаете состояние и поведение для всех классов вашей системы примерно в таком виде:

class Game:
  - board: Board
  - playerX: Player
  - playerO: Player
  - currentPlayer: Player
  - state: GameState (IN_PROGRESS, WON, DRAW)
  - winner: Player? (null, если победителя нет)
 
  + makeMove(player, row, col) -> bool
  + getCurrentPlayer() -> Player
  + getGameState() -> GameState
  + getWinner() -> Player?
  + getBoard() -> Board

А как же UML-диаграммы?

Возможно, вы читали другие материалы по подготовке к интервью, которые настаивают на использовании UML-диаграмм (Unified Modeling Language) с формальными обозначениями композиции, видимости и кардинальности.

В наших разборах вы не встретите UML. Он устарел и крайне редко используется в реальных проектах. Инженеры в современных компаниях проектируют прямо в коде - они делают заглушки классов, используют интерфейсы при обсуждении архитектуры или поручают ИИ моделям заполнить детали. Разработчики умеют свободно читать код, поэтому именно код является наиболее естественной средой для проектирования. В качестве доказательства этого тренда можно привести тот факт, что еще в 2016 году Microsoft удалила инструменты UML из Visual Studio, поскольку ими практически никто не пользовался.

UML был создан для другой эпохи, когда читать и запускать код было дорого. Сейчас этот компромисс потерял свою актуальность. На собеседовании, где вы рассуждаете вслух, итеративно дорабатываете дизайн и реагируете на обратную связь в реальном времени, излишняя формальность только замедляет вас, не добавляя при этом ясности.

Формата описания классов, который мы рассмотрели ранее, более чем достаточно. Он демонстрирует структуру, взаимосвязи и основные методы без лишних формальностей.

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

4. Реализация (~10-15 минут)

Как только дизайн ваших классов стал понятен, последний важный шаг - реализовать основные методы спроектированных вами классов.

Если не оговорено иное, реализуйте основные методы с помощью псевдокода, что мы и будем делать здесь.

Начните с "happy path" - нормального хода выполнения, когда все идет по плану. Это сделает цель и структуру метода понятными до того, как вы начнете обрабатывать граничные случаи.

1. Happy Path - пройдитесь по методу линейно: какие входные данные он получает, какую последовательность шагов выполняет, какие внутренние вызовы делает к другим классам, и что возвращает или как изменяет состояние.
2. Edge Cases - после этого перечислите варианты сбоев: неверные входные данные, недопустимые операции, значения вне допустимого диапазона, вызовы, которые нарушают текущее состояние системы - все, что должно быть отклонено или обработано по-особому. Это важный шаг, демонстрирующий, что вы мыслите как разработчик, который пишет код для производственной системы, а не просто игрушечную логику.

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

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

Например:

makeMove(player, row, col)
    if state != IN_PROGRESS
        return false
    if player != currentPlayer
        return false
    if !board.canPlace(row, col)
        return false
 
    board.placeMark(row, col, player.mark)
 
    if board.checkWin(row, col, player.mark)
        state = WON
        winner = player
    else if board.isFull()
        state = DRAW
    else
        currentPlayer = (player == playerX) ? playerO : playerX
 
    return true

Выберите только самые важные методы, которые показывают, как ваши классы взаимодействуют друг с другом, как происходят переходы из одного состояния в другое, как вы аккуратно обрабатываете граничные случаи, и как логика распределена по нужным классам. Часто интервьюер сам прямо скажет, какие именно методы он хочет увидеть в вашей реализации, так что просто следуйте его указаниям.

Проверка: прохождение через конкретный сценарий

После реализации ваших ключевых методов, уделите 1-2 минуты, чтобы проверить вашу логику, шаг за шагом прогнав через нее конкретный пример. Ваша цель здесь не в том, чтобы найти синтаксические ошибки, а в том, чтобы отловить логические недочеты раньше, чем это сделает интервьюер, и продемонстрировать свою способность проверять собственный код. Многие интервьюеры имеют специальный пункт "умение проверять код" в своих критериях оценки.

Выберите простой, но не слишком примитивный сценарий, и пройдитесь по нему шаг за шагом, показывая:

• Начальное состояние
• Что происходит при каждой операции
• Как изменяется состояние на каждом шаге
• Граничные случаи или переходы, например переход от состояния "IN_PROGRESS" к "WON"

Например, для крестиков-ноликов вы можете разобрать такой сценарий:

Начало: board empty, currentPlayer = X
makeMove(X, 0, 0) → board[0][0] = X, currentPlayer = O
makeMove(O, 1, 1) → board[1][1] = O, currentPlayer = X
...

Это поможет выявить такие проблемы, как:

• Забыли передать ход другому игроку
• Определение победы не срабатывает
• Переходы состояний происходят в неправильном порядке
• Обработка граничных случаев ломает общий процесс

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

5. Расширяемость (~5-10 минут, если позволяет время и уровень)

Если после того, как вы разобрали вашу базовую реализацию, у вас еще осталось время, интервью часто переходит к обсуждению возможных расширений системы или к дополнительным (follow-up) вопросам. Эта часть обычно полностью направляется интервьюером. Он предложит какое-нибудь усложнение, чтобы посмотреть, сможет ли ваш дизайн при добавлении требований естественно эволюционировать, а не обрастать костылями.

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

• Junior-кандидатам могут вообще не задавать вопросов на расширяемость.
• Middle-кандидаты могут получить один или максимум два небольших дополнительных вопроса.
• Senior-кандидаты должны быть готовы к серии вопросов в духе "а что, если...".

Дополнительные требования зависят от предметной области, но суть всегда одна: интервьюер предлагает внести изменения, а вы показываете, как ваш дизайн справляется с ними без масштабной переработки.

Например, если вас спросят: "Как бы вы добавили функцию отмены хода?", вы можете указать на то место, где происходит изменение состояния, и объяснить:

"Все переходы состояний проходят через один единственный метод — в данном случае makeMove. Чтобы добавить функцию отмены, я бы внедрил стек истории команд. Каждое успешное действие сохраняет предыдущее состояние до внесения каких-либо изменений. Метод undo() извлекает данные из стека, возвращает систему к этому состоянию, и при этом остальную часть системы менять не нужно."

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

На этом этапе вам следует оставаться на высоком уровне абстракции. Вы не переписываете код, а лишь указываете на те части вашего дизайна, которые позволяют внедрить изменения максимально элегантно.

Главная цель таких дополнительных вопросов - продемонстрировать, что ваш первоначальный дизайн является расширяемым и надежным. Иными словами, он способен выдержать новые требования, не рассыпаясь на части и не превращаясь в нагромождение костылей и особых случаев.