Чому «я вже рік працюю» — не аргумент, коли варто фіксити PR і як пояснити debounce без debounce? Розбір співбесіди на Middle Frontend

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

Мої вітання, шановна громадо! Цікаві досліди зі співбесідами продовжуються, і вчора, вперше на каналі Сергій Бабіч та Дивовижний світ веброзробки, відбулося не просто інтервʼю, а так зване evaluation-interview. В чому різниця?

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

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

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

Що змусило тебе вирішити, що ти готова претендувати на позицію Middle?

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

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

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

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

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

Звичайно ж, без практичних питань нікуди. І, оскільки я не дуже не люблю запитань «Що таке Х», то й формулюю я такі речі «від задачі». Це, насправді, дуже просте питання, і на нього дуже легко відповісти правильно.

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

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

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

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

Якби ти побачила pull request, у якому все працює, але код дуже неакуратний, що б ти зробила?

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

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

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

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

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

Підсумовуючи думки з прикладів, я можу окреслити наступні висновки:

Підвищення — це не питання стажу, а питання рівня мислення. Людина не стає мідлом просто через те, що працює більше року. Вона має усвідомлювати свою роль, нести відповідальність за код, розуміти, як її робота впливає на команду та продукт.

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

Soft skills — не менш важливі, ніж технічні. Кандидат, який не може пояснити джуну, чому його код варто покращити, або той, хто категорично відкидає чужий PR без аналізу контексту — не готовий до рівня Middle.

А наскільки добре справилась з цими питаннями Христина, яким був вердикт таємного експерта та чому пів етеру чат сперечався про useEffect, ви зможете дізнатися, переглянувши запис стриму з оцінювальною співбесідою на рівень Middle Frontend з Христиною Гаранчук.

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

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

>> Що змусило тебе вирішити, що ти готова претендувати на позицію Middle?

котики жерти хочуть 😺

Ну тебе ця мотивація і до СТО довести може)

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

P.S. До питання про рев’ю PR — ще один важливий момент, який допомагає уникнути конфліктів у команді, це уточнення контексту змін. Іноді те, що здається «кривим» кодом, має під собою певні причини.

Про ревʼю PR я якраз це і писав, що треба розуміння контексту, бо шо в одній ситуації гімнокод і фуфуфу, в інший — рятівна соломинка.

А коли ви дізналися про різницю між denounce та throttling?

Звісно що вчора, ну що за питання, чого б ми тоді ходили на твої етери.😅

дивись, суто про всяк випадок — небо синє через розсіювання короткохвильового (синього) світла молекулами атмосфери більше, ніж довгохвильового (червоного)

Підписатись на коментарі