Коли заважає TS, що таке архітектура React-застосунку, «у мене на компі все працює» — питання до Tech Lead

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Доброго всім здоровʼя, шановне товариство! Цього чудового хмарного пʼятничного ранку пропоную вашій увазі мої роздуми щодо співбесід високого рівня. До прикладу — на роль Tech Lead. Ці роздуми засновані на кількох обраних питаннях, що прозвучали учора під час публічної співбесіди з Олегом Дутченко у мене на ютуб-каналі «Сергій Бабіч та Дивовижний світ веброзробки».

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

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

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

Питання на такі ролі мають бути максимально відкриті і давати можливість кандидату розповісти саме про свій досвід, своє розуміння, свою компетентність в темі. Тут немає правильних відповідей, взагалі. Є лише точка зору людини, її експертність, її глибина знайомства з темою. І ви, як інтервʼюєр, маєте лише уважно слухати та визначати, наскільки це все відповідає вимогам позиції, вашим очікуванням, маєте розуміти, чи зможе людина опанувати нову для себе галузь, до прикладу, новий стек чи нові обовʼязки.

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

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

(не)Душні питання

Чи були випадки, коли TypeScript заважав? Як ти це вирішував?

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

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

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

І, поки ми тут, пропоную вам пригадати такий випадок та розповісти про нього в коментарях.

Як ти розумієш поняття «архітектура React-застосунку»?

Суворі не фронтендери засміялись, джуни жахнулись, а фронтенд-техліди сумно зітхнули. Так, я знаю, що на цю тему зламано немало списів — чи взагалі є на фронтенді поняття «архітектура». Особисто я вважаю, що є, тому й питаю. І у відповідь я хочу почути роздуми про те, що це таке взагалі, яким чином це поняття потрапило у фронтенд, і з якого боку там клеїти React. Або Angular. Або будь-що інше.

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

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

А на вашу думку, чи можна взагалі говорити про «архітектуру {JS}-застосунку». Поділіться вашим баченням!

Уяви, що продакшн-застосунок почав падати у користувачів, але на dev усе працює. Як ти діятимеш?

Ще одна моя улюблена категорія питань — «рольові ігри». Я ставлю кандидата перед певною ситуацією, і просто прошу описати його кроки. Що мені це дає?

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

Наприклад, в цій ситуації може спливати або не спливати моніторинг в продукті, аналіз скарг користувачів, процеси тестування, якісь «аварійні» протоколи на кшталт відкочування до останньої стабільної версії та багато чого іншого. Ну або «у мене на компі все працює». Може бути й таке.

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

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

А у вас як, виникала колись ця класична ситуація, коли у вас все чудово працює, а у клієнта — креш на креші? Розповідайте в коментарях!

На завершення

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

Що ж, ось такі були учора питання, але це далеко не повний їх перелік, тож запрошую вас до перегляду запису учорашнього стриму, під час якого Олегом Дутченко ділився своїм досвідом, а мій улюблений і не такий уже й таємний експерт зі Svitla Systems Павло Зубенко надав чудовий та детальний фідбек, який я раджу переглянути особливо уважно та прискіпливо.

Тож приємного перегляду, і не забудьте підписатися на канал, поставити відео вподобайку та обовʼязково поділитися своїми думками щодо питань та відповідей, озвучених під час етеру. Дякую!

N.B. Автор дуже недоброзичливо ставиться до коментарів російською мовою.