Зламайте інтерв’ю щодо проектування системи: поради інженера-програміста Twitter

Нещодавно я писав про те, як отримував пропозиції від декількох найвищих технологічних компаній. Під час мого процесу підготовки до співбесіди я прочитав багато матеріалів і підготував набір приміток про те, як вирішувати проблеми проектування системи. У цій статті я хотів би поділитися цими порадами з усіма вами.

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

Оновлення (24.03.2019) : Якщо ви хочете приєднатися до групи студентів, щоб дізнатися більше про дизайн системи, я організовую невеликий клас разом! Ви можете перейти за цим посиланням, щоб дізнатись більше, або відвідати мій веб-сайт: zhiachong.com для отримання додаткової інформації.

Ця стаття розбита на такі чотири розділи:

  • Задайте роз’яснювальні запитання
  • Використовуйте тло
  • Систематично вирішуйте проблему
  • Ведіть власні нотатки

Задайте роз’яснювальні запитання

Основною метою співбесіди з проектування систем є надання кандидату можливості продемонструвати свої знання.

Тут немає суто правильних чи неправильних відповідей. Запитання про хороший дизайн системи зазвичай звучить дуже неоднозначно, і причиною цього є те, що воно має дати вам можливість продемонструвати наступне:

  • Як би ви думали про проблемний простір
  • Як ви думаєте про вузькі місця
  • Що ви можете зробити, щоб усунути ці вузькі місця.

Уявіть, що вас просять розробити чорний ящик. Як би ви вирішили проблему? Тут немає чітких вказівок щодо того, що вам потрібно побудувати, окрім того, що ящик вміщує в собі деякі предмети.

Однією з найкорисніших стратегій, яку я особисто використовую, є задавання уточнюючих питань. Які запитання щодо «хорошого» роз’яснення Ви ставите?

Хороше роз’яснювальне запитання допомагає досягти однієї чи кількох речей:

  1. Допомагає звузити сферу того, що ви повинні робити
  2. Допомагає з’ясувати, якими є сподівання користувачів на систему
  3. Дає вказівки щодо того, куди рухатися далі
  4. Повідомляє вас про можливі вузькі місця / проблемні зони

У прикладі чорного ящика ви можете запитати: „ну, що містить поле? Скільки предметів вміщує? А хто призначений користувач? "

На те, що я міг би сказати, давайте побудуємо жовту коробку зі смайликом, яка повинна містити не більше 1 тенісного м’яча. Однак це не звичайний тенісний м'яч. Він матиме радіус щонайменше 0,5 м і важить близько 1 кг. Він призначений для того, щоб його обіймати, а не тримати, тож я не хочу на ньому жодної ручки.

Ось, ось ця коробка.

Завжди задавайте роз’яснювальні запитання. Вас не судять про те, чи ставили ви конкретне запитання під час співбесіди, а за те, як ви думаєте про проблемний простір.

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

Якщо ви ще цього не усвідомили, кінцевий результат вправи вище дасть значно інші результати. Для мого власного досвіду я міг би поглибитись дуже глибоко в розробці API та серверній інфраструктурі. Я б, мабуть, також досліджував проблеми, пов'язані з iPhone, завдяки своєму досвіду. Я розповім про те, як клієнт взаємодіє з кінцевими точками середнього рівня, як працюватиме журналювання, як я буду розробляти серверну систему для забезпечення безвідмовної роботи тощо.

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

Використовуйте свій досвід на свою користь

Часто я бачу інженерів, які намагаються з’ясувати, що намагається запитати інтерв’юер, а потім підготують свої відповіді відповідно до очікувань.

Я насправді настійно рекомендую кожному робити це з кількох причин:

  1. Кожна людина має унікальний досвід. Під час співбесіди з проектування систем це можливість для вас продемонструвати, які ваші сильні сторони. Не витрачайте можливості, намагаючись зрозуміти, що хтось інший може чекати від вас.
  2. Можливо, інтерв'юер кивав головою на ваші відповіді, але вони могли знати, що ви просто блефуєте і не думаєте про проблему.

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

Вирішуйте проблему систематично

Тепер, маючи на увазі свій досвід, є кілька речей, про які я думаю, коли я займаюся новою системою. Я настійно рекомендую сформулювати набір критеріїв або кроків для себе також.

Деякі речі, про які я пам’ятаю, коли працюю над новою системою:

  • Яка мета системи?
  • Хто користувачі системи?
  • З якою шкалою ми працюємо?
  • Це нова / стара система? Як ми обробляємо версії?

Серед інших…

Дивіться, мій набір критеріїв буде відрізнятися від набору критеріїв інженера-розробника. Я використовую ці критерії, щоб сформулювати картину в своїй голові, і вони будуть керувати моїм процесом прийняття рішень.

Озброївшись відповідями на ці запитання, я можу почати вирішувати проблему, а потім систематично розбивати її на окремі компоненти.

Хороша вправа, яку я люблю робити, - це те, як розробити систему замовлення кави . Я подумав про це, коли одного дня сидів у Starbucks, і зрозумів, що було б непогано, якби я міг замовити коктейль на своєму телефоні та взяти його у своєму місцевому Starbucks.

Мій розум почав рухатись у різних напрямках:

  • Що робить ця машина для замовлення кави?
  • Якщо я будую його, чи можу я продати його Starbucks, або покласти його на білий ярлик і продати як послугу?
  • Скільки користувачів мені потрібно підтримати, якщо я продаю їх Starbucks?
  • Як варіант, якщо я позначаю його білими ярликами, чи можу я продати інтерфейс моїй службі замовлення кави, а потім допомогти клієнтам створити серверну систему, щоб вони могли зберігати замовлення на своїх локальних машинах?

Отримавши відповіді на ці запитання, я зможу нарешті скласти повне уявлення про те, що робить моя служба замовлення кави. Ось як би виглядала моя версія послуги замовлення кави:

Моя служба замовлення кави - це програмне забезпечення як послуга (SAAS). Він пропонує інтерфейс для підключення різних партнерів.

  • Він має API, який називається addCoffeeForMerchant , який включає назву кави, ціну кави та інгредієнти кави.
  • Він має GET API, який називається getCoffeesForMerchant , який повертає список кави для даного ідентифікатора продавця.
  • Ідентифікатор продавця - це унікальний ідентифікатор (UUID), який генерується за допомогою якогось механізму хешування, який можна додатково уточнити у клієнта.
  • Програмне забезпечення оптимізоване для операцій лише для читання, оскільки більшість моїх клієнтів створюють своє меню один раз і читають його кілька разів протягом дня.
  • Він має механізм кешування, який використовує стратегію виселення найменш нещодавно використовуваних (LRU), тому що якщо пункт меню не був замовлений протягом певного часу, моєму клієнту все одно, чи він повільніше відображається в меню.
  • У випадку, якщо один із сховищ даних самовивержеться, моя служба замовлення кави буде тиражувати дані в різних кластерах на західному та східному узбережжі США, оскільки я націлююсь на американський ринок поки що.

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

Ведіть власні нотатки

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

У моєму Evernote є блокнот із назвою „Програмування”. Кожного разу, коли я стикаюся з чимось новим або чимось цікавим, я записую це у своєму зошиті для подальшого довідкового дослідження.

Щомісяця або щокварталу я переглядаю та призначаю ярлики цим новим приміткам, щоб переконатися, що нотатки організовані. Наприклад, у мене є ярлик „Дизайн” для всього, що пов’язано з дизайном системи. Це може бути щось на зразок посилання на відео на YouTube, яке мені здалося цікавим, або цікавий аргумент, який мій колега виклав, про який я не думав.

Це зразок того, як виглядає одна з моїх нотаток:

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

Я розбиваю свої нотатки на:

  1. Конструкції систем
  2. Інтерв’ю (досвід + огляд різних співбесід, які я проходив раніше, згруповані за назвою компанії)
  3. Випадкові tid-біти, CS добре знати, як корисні скрипти Bash або хитрощі командного рядка
  4. Читання / відео YouTube

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

Як і кожен, хто мене знає на особистому рівні, я не надто організована людина. Таким чином, я зібрав лише 10 - 15% речей, тому там залишається набагато більше.

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

Ресурси, які я рекомендую

Вступ до: Архітектура та дизайн систем - чудовий підручник з Youtube від колишнього інженера Facebook про те, як підходити до проблем проектування систем.

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

Фіктивне інтерв’ю - імітоване середовище, що імітує власне інтерв’ю, надзвичайно допомагає під час підготовки до інтерв’ю. Якщо ви можете знайти друга, який зробить це за вас, то я настійно рекомендую це зробити. Я також веду фіктивне інтерв’ю, тому, якщо вам цікаво, не соромтеся зв’язуватися зі мною на zhiachong.com!

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

Evernote - найкращий? додаток для ведення записок, яким я користувався. Є багато підручників про те, як найкраще використовувати Evernote. Я їх ще не переглядав, просто тому, що використовую його просто як зошит. Я реєструю там все, про що дізнаюся, а потім час від часу переглядаю та реорганізую їх.

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

Pilot G2 (чорний) - це найкращі найкращі ручки, які я коли-небудь використовував, і єдині ручки, якими я буду користуватися. Я купую їх оптом у Amazon і зберігаю всюди, куди б я не пішов. У мене є один у рюкзаку, один в офісі та один у домашньому кабінеті, щоб завжди мати ручку навколо. Він чудово пише, чорнило плавно тече, і мені просто подобається відчуття того, що я ним пишу. У поєднанні з Moleskin, іноді я просто хочу взяти G2, щоб зафіксувати там випадкові речі, тому що ці два ідеально поєднуються.

Поглиблення інтерв’ю з дизайном системи - це рекомендація друзів. Це онлайн-курс, який вчить детально розробляти розподілену систему. Це, звичайно, 79 доларів. Існує командне ціноутворення. Якщо є якийсь інтерес, я зв’яжусь із ними, чи можливо створити групу для групової знижки.

Слідуйте за мною у Twitter, Facebook та LinkedIn. Зареєструйтесь у моєму списку розсилки, куди я регулярно надсилаю поради, підказки та знань у галузі.

Якщо вам сподобалась ця стаття, прокоментуйте нижче: яка порада для побудови масштабованої надійної системи?