Собеседование в Order Capital. Часть 2

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

1️⃣ Первая задача касалась дизайна API на C++. Задание формулировалось так: "создайте наилучший интерфейс для не буду раскрывать чего именно". Сейчас, уже работая в компании, я вижу, что умение грамотно проектировать код напрямую влияет на результаты компании.

Многие разработчики, сталкиваясь с подобным заданием, стараются сразу применить все знания о принципах SOLID и шаблонах проектирования «Банды четырёх». К сожалению, это часто приводит к оверинженирингу и созданию громоздких конструкций, далёких от реальных потребностей бизнеса.

Я же подошёл к задаче с другой стороны. Я спросил интервьюера о конкретных юзкейсах проектируемого API. Мне предложили самому определить потенциальные сценарии использования, так что я выбрал несколько наиболее типичных, на мой взгляд, задач. Я начал разрабатывать примеры кода, который бы использовал мой API для их решения. Это позволило мне лучше понять, какие функции и классы необходимы для создания действительно удобного и функционального интерфейса. И уже после этого я стал создавать сам API ☝️

2️⃣ Вторая задача была связана с работой с большой кодовой базой. Мне предстояло предложить способы внедрить новую функциональность в класс стандартной библиотеки, который активно используется по всему проекту. Здесь важно было не только продумать удобство использования нового кода, но и трудоемкость внедрения этого изменения во всю кодовую базу. Здесь мне помог опыт Яндекса: я видел там много масштабных рефакторингов, поэтому смог предложить несколько вариантов и перечислить плюсы и минусы каждого из них.

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

Жду ваших комментариев! Расскажите, сталкивались ли вы с похожими задачами и как вы подходили к их решению?