Grokking System Design interview for Front-end engineer [ukr]

Всім привіт, так, мене звати Олексій Левжинський, я техліт команди в Grammarly, яка розробляє Grammarly Browser Extension і вже більше 7 років працюю в цій компанії. Також приймаю участь у тому числі в процесі інтерв'ю. І саме сьогодні хочу вам розказати про одну таку, одне такий цікавий тип інтерв'ю, як саме систем дизайн.

В двох словах про взагалі яка мета, чому я вирішив про це розказати. Насправді, якось у нас не завжди люди розуміють, що саме це інтерв'ю, про що саме це інтерв'ю. І хочеться сьогодні трошки таку розвіяти якісь міфи. Насправді це не якийсь там Rocket Science, ви все вже знаєте, просто треба зрозуміти саме про що воно, що від вас очікується, і все буде окей. Тобто ніякої магії нема, про це сьогодні поговоримо.

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

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

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

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

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

На цьому інтерв'ю ми, зазвичай, вважаємо, що бекенд – це такий чорний ящик, який може зробити взагалі будь-що. Тобто, будь-яке API зробити – там все вже умовно реалізовано. А саме, на що ми звертаємо увагу – це на фронтенд. Це архітектура клієнта, тобто, які там модулі, яка взаємодія, як ми управляємо станом, взагалі, які взаємозв'язки, що куди йде. Звичайно, це буде про API, тобто, все ж таки важливо, як ми будемо комунікувати з бекендом, які протоколи, можливо, що ми будемо пересилати, як воно буде працювати, помилки, як ми їх оброблюємо. Це може бути про перформанс, тобто, це все ж таки важливо на фронтенді. Ну, і якісь такі чисто типові для фронтенду питання, як доступність, інтернаціоналізація, можливо, ще щось, чого нема тут у списку. І цікаво, на що звертають увагу кандидат і люди, які проводять це.

Ну, по-перше, так, звичайно, систем дизайн – це таке дуже відкрите питання, тобто, і зазвичай, ідея такого, скажімо, практичного інтерв'ю – це зрозуміти, як людина буде вже працювати, скажімо так, кожен день зі своїми задачами. Тобто, не завжди задачи зрозумілі, часто це якісь доволі, там, щось треба зробити, і вам треба піти і розібратися, як це буде робитися. Ну, і саме ідея, на що звертаєте увагу – це, по-перше, вирішення цих задач, тобто, дивляться, наскільки людина взагалі може зрозуміти завдання, звичайно, ніхто не може, скажімо тому мовно, якщо скажуть «зробіть Фейсбук», ну, за 60 хвилин його ніхто не зробить, ну, і, звичайно, взагалі, там тисячі людей над ним працюють, тобто, проте тут ідея, що людина розуміє, взагалі, що від неї треба, і, як зазвичай, ділиться на якісь маленькі частини, і вже маленькі частини можна більш-менш якось зрозуміти, як вирішувати, в цілому так це і працює на практиці. Для цього потрібно, звичайно, задавати правильні питання, і, так, звичайно, що ще важливо, що людина буде розуміти, що будь-яке рішення, воно не універсальне, тобто, завжди будуть якісь обмеження, і це треба теж розуміти, які можуть бути нюанси.

Наступне, це умовно, що важливо, що, скажімо так, ми не застріємо десь посередині, а все ж таки ми намагаємося вирішити все ж таки нашу проблему, тобто, від початку до кінця, тому що так і в реальному житті, так ми можемо стикатися з якимись дуже важко вирішуємими питаннями, проте ми можемо якось обійти, і це теж тут важливо. Ну і, звичайно, це якісь розуміння таких технічних речей, наприклад, як банальні принципи проєктування, паттерни, ну і, звичайно, розуміння фронтенду. Добре, більш-менш розібралися. Про що це? Тепер давайте подивимося на щось більш-менш таке реальне.

Сьогодні, наприклад, на прикладі Твіттера подивимося, як взагалі, яка послідовність того, що можна робити на цьому інтерв'ю, і як це теоретично може виглядати. Перед тим, як почнемо, тут, звичайно, можна умовно для себе можна розділити процес цього інтерв'ю на декілька частин. Ну, звичайно, саме перша частина вам розказують завдання. Завдання може будь-яке. Тобто, насправді, це може бути щось дуже загальне, як зробіть, будь ласка, Твіттер, зробіть, будь ласка, Фейсбук. Або може бути більш детально, коли вам вже розказують про обмеження чи обмеження, які треба, обмеження, скажімо так, задачі. Тобто, якийсь конкретний там частину, наприклад, того ж Твіттера. Все ж таки, після того, як ви побачили завдання, вам потрібно, якось, більш детально зрозуміти, що ж саме потрібно, особливо, якщо це дуже загальне питання. Тобто, і зрозуміти, що саме сьогодні ми будемо вирішувати. Тобто, звичайно, ми не будемо будувати увесь Твіттер. Далі, скажімо так, основну частину інтерв'ю займає саме фаза дизайну. Ну, і якесь таке завершення. Це, можливо, якісь там додаткові питання, які запитає той, хто проводить інтерв'ю, або вже поглиблення у ці модулі, які були побудовані, скажімо так, під час фази дизайну. Одразу хочу сказати, що той приклад, який сьогодні буде, він такий більш, скажімо, загальний, і він, звичайно, хочу сказати, що це не буде, скажімо так, золота пуля, або єдине рішення, яким треба проходити системний дизайн інтерв'ю. Це більш таке щось загальне, яке має допомогти зрозуміти, а взагалі, що потрібно робити і в яку сторону потрібно двигатися під час цього інтерв'ю. Ось, тому давайте почнемо.

Ну, звичайно, по-перше, у нас дуже відкрите завдання. Тобто, зробіть Твіттер. Ну, що таке зробіть Твіттер? Звичайно, ми не можемо, як я казав, вже зробити його за 60-50 хвилин. Тобто, нам треба зрозуміти, що ж взагалі ми будемо робити.Ну, і починаємо збирати наші вимоги. Тобто, а що ми маємо робити? Чим маємо ми починати, наприклад, умовно, з авторізації? Нам взагалі про це треба думати? Ну, умовно відповідає нам інтерв'ює, ні, давайте не будемо вважати, що воно вже реалізовано. Добре, що наступне?

Що перше має побачити покористувач? Окей, він має побачити, умовно, нашу стрічку. Добре, він має мати можливість робити пости. Добре, ще щось ми хочемо? Наприклад, ми хочемо, щоб людина могла побачити реплай нашого конкретно будь-якого поста, Твіта в нашій стрічці. Добре, а як? Чи важливо, як ця людина побачить наші реплайи? Ну, тобто, чи може це бути поп-ап або окрема сторінка? Тут теж можуть бути відповіді, наприклад. Ну, вирішіть самі.

Добре, давайте подумаємо. Ну, нам в цілому воно, як краще зробити? Ну, поп-ап це може бути незрозуміло, якщо людина там перегружає сторінку, якось нам треба підгружати всю стрічку на фоні десь. Як це має? Чи потрібні нам ці додаткові запити? Ну, давайте не будемо, давайте зробимо окрему сторінку. В цілому це наче логічно. А що має бути всередині? Що саме має бути в Твіті? Ну, давайте з простого почнемо, це буде просто строка. Ми не будемо брати там відео або картинки, спростимо. Валідація? Так, зробимо валідацію. Що стосовно нагрузки? Це теж треба зрозуміти. Взагалі, наскільки багато даних може бути?

Тобто це мільйони, не мільйони? Якщо так, то це буде впливати на вирішення нашого завдання. Тобто, окей, ми, скоріш за все, кажемо, що буде щось там 50 твітів на сторінку, тобто ми розуміємо, що так, нам потрібно буде подумати про багінацію, тобто, значить, нам треба буде подумати, який API нам для цього потрібен. Ну і, можливо, щось таке завершуюче, а взагалі, як, що у нас має бути? Чи хочемо ми це в реалтаймі? Ну, наче нам не потрібен реалтайм, тобто ми, окей, там раз на, умовно, 10 секунд робити запити і все. Ну і, звичайно, а що хочемо кешування? Офлайн-мод, щось таке? Ну, давайте без офлайн-моду, це вже складнє завдання, а нас немає на цей час, наприклад. А про те, аби хочемо, щоб коли людина почала писати твіт, то і потім пішла на якусь іншу сторінку, то у нього зберігся цей статус. Тобто, повернулися, побачили, продовжили, запостили. Ну і останнє таке загальне щось, типу, а ми хочемо щось конкретне по фронтенду, наприклад. Чи якийсь фреймворк. Ну, тут, скажімо, давайте подивимось на помилки і подивимось на, що ми можемо робити з accessibility. Все. Всього достатньо. Далі є такий доволі простий фреймворк, як це можна все записати, умовно у нас є функціональні, не функціональні вимоги. Що таке функціональні, це фактично те, що має робити система, а не функціональні, це саме, можливо, як вона має це робити. Щось про, скажімо так, перформанс її системи.

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

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

Ну, і наприкінці ви будете буде зрозуміло, взагалі, до чого ми дійшли, тому що все, що слова, вони можуть бути забуті, а конкретна схема, яка намальована, вона буде як результат. Умовно, це в цілому не треба малювати, це більше для пояснення, тобто умовно, так звичайно, будь-який додаток можна намалювати так, у нас є клієнт-сервер, яка між ними взаємодіє, і тут саме питання як почати? Тобто тут можна сказати, чи має сенс взагалі я казав, що сервер це в цілому блекбокс, такий чорний ящик, проте ви можете якщо, наприклад, десь під час питань було важливо про якусь оптимізацію або перформанс, ви можете сказати, добре, ми в цілому, я от, наприклад, пропоную, щоб було у нас там сервер-сайрендеринг условно, чи потрібно нам зараз про нього говорити, чи не потрібно. Ну, в даному випадку ми про нього не будемо говорити, будемо вважати, що у нас таке типове single-page класичне аплікейшн, добре, давайте почнемо з клієнта, тобто тут важливо взагалі постійно, постійно, періодично, питати інтерв'ювера, чи взагалі ми на правильному шляху, тобто, чи саме то, це те, куди ми йдемо.

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

Тут все доволі просто. Починаємо. Що в нас є? Ну, у нас фронтенд, будуть у нас якісь view. Далі, у нас буде якась логіка, скажемо так, application логіка, яка буде, скажемо, допомагати рендеритися цим view. Тобто, де ми її будемо розміщати. Тут, умовно, я додаю контролер, проте хочу одразу сказати, що це більше для прикладу, тобто в реальному житті тут дуже важливо. Саме на цьому етапі ви можете запропонувати, окей, а я буду використовувати такий фреймворк, або у мене ця логіка буде, умовно, ми зробимо її на хоках, або я все ж таки пропоную зробити, у нас буде якась додаткова логіка, яка буде обслуговувати view, вона буде view моделі, презентер, що завгодно.

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

Що робити зі стейтом? Чи потрібно як? Чи має бути це один стейт? Чи має бути це декілька окремих стейтів, які будуть для кожної сторінки свої? Тут гарне питання, і це має сенс саме зараз і проговорити. По-перше, скоріше за все, ми захочемо, щоб у нас була доволі швидка взаємодія з нашими додатками. Тобто ми переходимо, скажімо так, з однієї сторінки на іншу; ми бачимо нашу стрічку, переходимо в якийсь окремий твіт, повертаємося назад. Скоріше за все, було б краще з точки зору юзер-експірінг, щоб ми одразу щось показали, а вже потім у нас був лоадінг, або оновлення. Тому, скоріше за все, ми захочемо мати якийсь глобальний стейт, який у нас буде використовуватися між нашими сторінками.

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

Добре, вважаємо, що ми на правильному шляху, продовжуємо. Що далі? Ми вже казали, у нас буде декілька стрінок. Скоріше за все, у нас буде роутер. Тобто нам десь треба розуміти, що ми перемикаємося з однієї стрінки на іншу, наприклад. А також, скоріше за все, нам десь треба, хоч ми казали, що нам авторизація не потрібна, але нам все ж таки потрібно, буде певно, ми захочемо десь аватарку користувача, наприклад, показати, або, я не знаю, його ім'я написати. Тобто ця логіка має бути десь. Наприклад, ми її помістимо в наш умовний аплікейшн контрол. Теж в лапках, тому що це все залежить від фреймворку, який ви виберете. Ну і, звичайно, взаємодія з бекендом. Взаємодія з бекендом, так звичайно, для фідів у нас буде свій набір запитів. Для відправки, для показу реплаїв у нас буде інший API. Можливо, у нас ще буде API, як ми отримуємо інформацію про користувача. І, грубо кажучи, все це буде взаємодія з сервером.

Ще раз перепитали, чи ми робимо те, що очікувалось. Можливо, тут можуть бути відповіді коли як за. А от уточніть, будь ласка, а що ми будемо робити у тому варіанті. А там, наприклад, а уточніть, будь ласка, я не зовсім розумію, можливо, моделі якісь треба прояснити. А як стейт? Якщо так, ми повертаємося до цього, уточнюємо нашу діограму. Якщо ні, ну, продовжуємо. Наприклад, що наступне, давайте поговоримо, а що у нас в нашому стейті буде, тобто, нашу, умовно, модель даних. Тобто, взагалі, що ми там будемо зберігати, як воно буде виглядати, можливо, якісь деталі хочемо тут проговорити. Ну, по-перше, користувачи. Тут все доволі просто, інформація, юзернейм, URL, нічого складного. Ми йдемо далі, стрічка. А що має бути в стрічці? Ну, в стрічці, скоріше за все, будуть наші твіти. Ми казали, що у нас буде контент тільки з строка. Можливо, кількість лайків нам треба показати. Ну, звичайно, ID. Ми будемо клікати на них, відкривати стрінку. Тобто, ми, скоріше за все, цю ID будемо використовувати, звичайно, для отримання саме конкретного твіта. Що ще ми можемо зберігати? Ну, ми можемо тут, наприклад, ми казали про пагінацію. Тобто, пагінацію як ми будемо робити? Ну, давайте, звичайно, зробимо інфініті скрол. Тобто, користувач це скролить, і у нього підгружається якась інформація.

Ну, тут ми можемо як зробити? Щоб, скажімо так, денормалізувати наші дані і використовувати, наприклад, таймстамп останнього твіта. Тобто, нам тут пейдж-каунтер не дуже підходить, тому що, насправді, поки там юзер щось читав, поки вирішив поскролити, скоріш за все, ми вже знаходимося на першій стрінці. Це взагалі, якщо у нас твіти будуть відсортовані за часом створені. Ані, ще буде якась окрема додаткова логіка. Ну, так як ми про це нічого не казали, то будемо вважати, що якщо людина скролить, наш користувач скролить місць, то ми просто будемо робити запит на, а що там було перед останнім, який ми бачили. Далі ми казали, що нам потрібен режим драфту, тобто, скоріш за все, ми теж хочемо це зберігати.

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

Добре, є ще, якщо ми проговорили, що все добре, тоді логічно, що ми треба переключатися на наступний етап, це у нас API. Тут, насправді, дуже важливо зрозуміти, а яка саме у нас буде взаємодія. Чи потрібна нам двостороння взаємодія, чи потрібно нам в реалтаймі це робити, я не знаю, можу використовувати вебсокет, лонгпоринг, http, ес, звичайно, все має бути сек'юрно, або нам це, під час реквайерментів ми це проговорили, тому, насправді, тут нам особливо можна не думати, тобто ми казали, що з періодичністю в 10 секунд ми будемо ходити і питати, що ж там відбувається. Теж двостороння, та наче не потрібно нам нічого туди слати, щоб отримувати у відповідь. І тоді давайте проговоримо, а взагалі що ми будемо туди-сюди пересилати. Взагалі це може бути оформлено дуже по-різному, ви можете це написати просто списком в якомусь текстбоксі, ви можете намалювати це, скоріше це буде списком написати взагалі, які у нас буде інпоінти і що вони будуть робити. Проте саме тут для наглядності у нас є такі два прямокутники, клієнт-сервер, у нас тут будуть стрілечки, які будуть показувати наші запити. Значить перше, що нам потрібно? Користувач відкрив сторінку, ми пам'ятаємо, нам треба загрузити список наших твітів, щось показати. Яке тут може бути API? По-перше, певно, що це буде простий get-запит. Можливо, ми можемо сюди додати кількість, яку ми хочемо.

Ми казали, що там буде 50. Можемо зазамовчувати до 50, проте вдруг ми захочемо якось цим експериментувати чи це вираховувати на клієнті. Хай буде count. І, як ми казали, для пагінації нам потрібен таймстамп. Тут він має бути опціональним, тому що зазвичай ми можемо використовувати один тай самий інпоінт для різних цілей. Тобто, зазамовчуванням це буде останній, наприклад. А якщо ми передамо таймстамп, то це будуть з початку, від цього таймстампу в минуле. У відповідь ми отримуємо наш масив твітів. Наступне. Окрема сторінка. Так, ми клікуємо на твіт. І в нас має відкритися сторінка. Тут звичайний get-запит, який нам достатньо ID, і він буде нам повертати інформацію про кількість наших запитів.

Вибачте, кількість наших твітів. І, я не знаю, масив цих наших відповідей. Йдемо далі. Що нам потрібно? Скоріше за все, у нас тут теж буде такий інфініті скрол. Тому, скоріше за все, ми захочемо додавати ці реплай, якщо їх більше, наприклад, 50, які були у нас в початковому масиві. Відповідно, будемо використовувати той самий API, як і для підгрузки наших твітів. І, певно, що останнє, що ми хочемо – це пост, в якому ми будемо створювати новий твіт. Тут у відповідь нам просто буде приходити твіт, і ми його дадемо до нашої стрічки, наприклад, зверху. Більш-менш проговорили тут все. Ще раз перепитали, чи нічого ми не пропустили, чи, можливо, ми хочемо ще про щось поговорити, чи, я не знаю, якесь додаткове, потрібно більш складне API.

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

Наприклад, запропонувати, а я хочу, я знаю багато про accessibility. Давайте ми поговоримо цей, я вважаю, що це важливо, давайте про це поговоримо. Добре, в нашому випадку дві теми. Error handling, тобто, звичайно, всі розуміють, що у нас нетворк, наш інтернет з'єднання може бути нестабільне, тобто, нам треба щось з цим робити, якось обробляти. Тобто, тут які варіанти, там, 500, 404, retry, як ми будемо це робити. Якщо у нас retry не виходять, то ми, звичайно, покажемо notification, якесь сповіщення, що, вибачте, зараз не працює. Можемо запропонувати щось більш складне, наприклад, а як ми хочемо offline, онлайн, ми казали, що ми не хочемо робити офлайн режим, тому нам потрібно, якось, я не знаю, закривати оверлей і казати, вибачте, ви зараз не можете користуватися нашим сайтом.

Тут вже можна сказати, що можемо зробити якийсь там мідлвар, який буде слухати всі запити, якщо він розуміє, що запит повертає помилку, то він перевіряє, чи ми офлайн, не онлайн, наприклад, і щось показує, а може ще просто це окремий сервіс, який буде просто моніторити браузер на API і слухати, а може це комбінація, тобто, тут можна вже заходити в будь-які глибини і, головне, періодично перепитати, чи має сенс заходити так глибоко, чи, можливо, у інтерв'ює якісь інші питання. Наступне, наприклад, accessibility, тут головне питання, що ми взагалі, як ми хочемо це, наскільки глибоко ми хочемо залурюватись в цю тему і взагалі, що ми хочемо, який рівень доступності ми хочемо для нашого сайта, тобто, і тут, якщо це відкрите питання, тоді конкретно по темах ми пропонуємо, ми починаємо з якогось простого семантичної верстки, з табордеру, контрасти, далі шрифти, далі питання, ми хочемо далі, добре, далі, давайте, скрінрідери, тобто, якщо ми хочемо підтримувати скрінрідери, це вже зовсім інша історія, це вже більше на рівні компанії, тобто, тут нам вже потрібно, можливо, і ручне тестування, звичайно, не буде вистачати, ну, і таке інше, і таке інше, тобто, ми ходимо далі вже перепитуючи, чи потрібно ще розповідати, ну, і дивлячись на час. В цілому, закінчується у нас діп-дайв, ми таки ще раз перепитали, чи хочемо ми щось ще обговорити, якщо ні, якщо все добре, ну, чи просто, звичайно, у нас є вже діаграма, нам інтерв'юр каже, що дякую, все добре, ми все вирішили, ми закінчуємо.

Ну, і що ми в фіналі отримуємо? Ми отримуємо нашу діаграму, API, можливо, якісь уточнення нашої діаграми, тут тільки Error Page з'явилася, наприклад, і ми ще у нас є наші вимоги, тобто, у нас таке зрозуміло, до чого ми дійшли. І так, ми могли десь щось пропустити, десь щось не зрозуміло, але тим не менше у нас є якесь розуміння того, взагалі, куди ми рухаємося з цією задачою. Ну, і, як під кінець, якесь таке певно рекомендації, на що має сенс звернути увагу, тобто, по-перше, ще раз, дуже важливо зрозуміти завдання, тому що завдання можуть бути дуже різні. Тут ще такий нюанс, що намагайтеся не думати, навіть якщо ви щось подібне вже колись вирішували на своїй практиці, все одно намагайтеся подивитися на це завдання як на щось нове, тому що може бути якийсь один маленький нюанс, який зробить вашу, скажімо, архітектуру, яку ви використовували, взагалі, непридатною для конкретного цього випадка.

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

Ну і, звичайно, використовуйте ваші знання, готуйтеся, нічого тут складного немає, все доволі буденно. Не дуже багато є ресурсів по систем дизайн інтерв'ю для фронтендів, проте декілька корисних посилань і, наприклад, друге посилання декілька років тому на FWD з присвяченому архітектурі була дуже цікава доповідь про те, як проходити, чи як виглядає таке саме інтерв'ю тільки для бекенда. Теж раджу подивитися трішки з іншого боку на це інтерв'ю. Ну і, звичайно, думаю, нікому не треба нагадувати, Stand with Ukraine, допомагайте, пам'ятайте, кожен донат важливий. Дякую, на цьому це все.