Питання на Співбесіді з Angular, яких Варто Очікувати

Поверхня API Angular велика, і опубліковані списки питань трактують кожен декоратор так, ніби він однаково ймовірний. Це не так. Цей розділ охоплює області, які насправді вирішують результат більшості раундів, тож ваша практика відповідає реальному розподілу. Домінують чотири кластери:

• Change detection: що запускає перевірку, як Zone.js патчить асинхронні API, що змінює OnPush і як signals дозволяють Angular пропускати роботу.
• Dependency injection: ієрархічні injector'и, providedIn, injection-токени та функція inject() проти параметрів конструктора.
• RxJS: observable проти promise, вибір правильного оператора та прибирання підписок перед знищенням компонента.
• Архітектура компонентів: standalone-компоненти, input і output, content projection та lifecycle-хуки.

Обізнаність про версії важить тут більше, ніж у більшості раундів з інших фреймворків, бо Angular змінив напрямок. Standalone-компоненти, вбудовані блоки control flow @if і @for, deferrable views та signals з'явилися саме в останніх мажорних версіях, тож інтерв'юери часто питають, що ви написали б сьогодні порівняно з тим, що використовує старіша кодова база. Знання обох підходів і розуміння, чому фреймворк змінився, справляє краще враження, ніж вибір однієї сторони.

Глибші, ніж просто назви операторів. Питання RxJS, яке розділяє рівні, полягає в тому, який flattening-оператор підходить: switchMap скасовує попередній внутрішній запит і підходить для typeahead, mergeMap запускає все паралельно, concatMap зберігає порядок, а exhaustMap ігнорує нові події, поки одна ще виконується, тому й підходить для кнопки відправки. Далі інтерв'юери ставлять питання про витік: що відбувається з ручною підпискою, коли компонент знищується, і чому async pipe або takeUntilDestroyed усувають цю проблему.

Питання про signals новіші і зазвичай починаються з мотивації, а не з API. Очікуйте пояснення, що таке signal, як computed виводиться з нього, для чого потрібен effect, і чому signals дають Angular точніший спосіб дізнатися, що змінилося, ніж повторна перевірка всього дерева компонентів. Сильна відповідь пов'язує обидві теми: signals і OnPush однаково скорочують роботу, яку виконує change detection, але signals роблять це, відстежуючи читання, а не звужуючи момент запуску перевірки.

Інтерв'юери не очікують, що ви вже використали кожну нову функцію. Вони очікують, що ви скажете, з якою версією працювали востаннє, і чітко міркуватимете про решту.

Більшість раундів Angular включають побудову чогось невеликого, поки інтерв'юер спостерігає. Повторювані вправи стабільні між компаніями:

• Викликати API із service та відрендерити результат за допомогою async pipe.
• Побудувати пошук typeahead із debounceTime, distinctUntilChanged і switchMap.
• Написати reactive form із власним validator і видимими станами помилок.
• Передати дані між parent- і child-компонентом, а потім підняти їх у service.
• Додати маршрут із lazy-loaded компонентом і guard.

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

Читання списку питань формує впізнавання, а не пригадування, а раунд перевіряє саме пригадування, поки хтось спостерігає. Рішення полягає в повторенні в реальній формі раунду: будуйте стандартні вправи з порожнього проєкту, промовляйте вголос рішення щодо change detection і підписок під час набору коду та поглинайте переривання, не втрачаючи нитку. Проходження цього набору як усної репетиції, по одному питанню за раз із додатковими питаннями, саме для цього потрібна практика mock-співбесіди.

Одне обмеження варто чітко назвати: живі раунди Angular майже завжди відбуваються у спільному редакторі або з видимим екраном, і все на цьому екрані видно інтерв'юеру. Асистент доречний під час підготовки та в раундах, що ведуться розмовою, а не на спільному екрані. Які формати що дозволяють, описано в типах співбесід.