أسئلة مقابلة العمل في Angular المتوقعة

سطح API الخاص بـ Angular واسع جدًا، وتتعامل قوائم الأسئلة المنشورة مع كل decorator وكأنه بنفس احتمال الظهور. لكنها ليست كذلك. يغطي هذا القسم المجالات التي تحدد فعليًا نتيجة معظم الجولات، بحيث يتوافق تدريبك مع التوزيع الحقيقي. تهيمن أربع مجموعات:

• Change detection: ما الذي يُشغّل الفحص، وكيف يقوم Zone.js بتصحيح واجهات API غير المتزامنة، وما الذي يغيّره OnPush، وكيف تتيح signals لـ Angular تخطي العمل.
• Dependency injection: injectors هرمية، وprovidedIn، ورموز injection، ودالة inject() مقابل معاملات الconstructor.
• RxJS: observables مقابل promises، واختيار العامل الصحيح، وتنظيف subscriptions قبل تدمير المكون.
• بنية المكونات: مكونات standalone، وinputs وoutputs، وcontent projection، وlifecycle hooks.

الوعي بالإصدار يهم هنا أكثر من معظم جولات الأطر الأخرى، لأن Angular غيّر اتجاهه. وصلت مكونات standalone، وكتل control flow المدمجة @if و@for، وdeferrable views، وsignals جميعها في الإصدارات الرئيسية الأخيرة، لذا كثيرًا ما يسأل القائمون على المقابلات عمّا كنت ستكتبه اليوم مقارنة بما تستخدمه قاعدة كود أقدم. معرفة الاثنين معًا، ومعرفة سبب تغيّر الإطار، تترك انطباعًا أفضل من اختيار جانب واحد.

أعمق من مجرد أسماء العوامل. سؤال RxJS الذي يفصل بين المستويات هو أي عامل flattening يناسب الموقف: يُلغي switchMap الطلب الداخلي السابق ويناسب typeahead، ويشغّل mergeMap كل شيء بالتوازي، ويحافظ concatMap على الترتيب، ويتجاهل exhaustMap الأحداث الجديدة طالما أن حدثًا واحدًا لا يزال قيد التنفيذ، ولهذا يناسب زر الإرسال. ثم يطرح القائمون على المقابلات سؤال التسريب: ماذا يحدث لـ subscription يدوي عند تدمير المكون، ولماذا تزيل 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 وmكون child، ثم رفعها إلى service.
• إضافة route مع مكون lazy-loaded وguard.

على سبيل المثال، قد يبني مهندس front-end يجري مقابلة لدور منتج متوسط المستوى typeahead، ثم يُضغط عليه بشأن ما يحدث عندما تصل الاستجابات خارج الترتيب، وكيفية إظهار حالة تحميل، وما الذي يجب أن يحدث عندما يمسح المستخدم الإدخال. هذه الإضافات هي ما يحدد نتيجة الجولة، لذا تدرّب على الأسئلة الإضافية وليس المسار السهل. المجموعات المجاورة التي لا تزال جولات Angular تفتح بها غالبًا، بما في ذلك أساسيات JavaScript وTypeScript الخالصة، موجودة في مركز بنوك الأسئلة.

قراءة قائمة أسئلة تبني التعرّف، لا الاستدعاء، والجولة تختبر الاستدعاء بينما يراقبك أحدهم. الحل هو التكرار في الشكل الحقيقي للجولة: ابنِ التمارين المعتادة من مشروع فارغ، واسرد قراراتك المتعلقة بـ change detection وsubscription بصوت عالٍ أثناء الكتابة، واستوعب المقاطعات دون أن تفقد الخيط. تشغيل هذه المجموعة كبروفة منطوقة، سؤالًا واحدًا في كل مرة مع أسئلة إضافية، هو بالضبط ما تُستخدم من أجله ممارسة المقابلة التجريبية.

هناك قيد يستحق أن يُذكر بوضوح: تُجرى جولات Angular الحية دائمًا تقريبًا في محرر مشترك أو مع شاشتك مرئية، وكل ما يظهر على تلك الشاشة يراه القائم على المقابلة. المساعد مكانه في التحضير وفي الجولات القائمة على المحادثة، لا على شاشة مشتركة. أي التنسيقات تسمح بماذا مشروح في أنواع المقابلات.