مع بداية شهور التوظيف، كثير من المطورين يشعروا بتوتر من المقابلات التقنية، خاصة الـ Frontend Developers.
لكن خلّينا نتفق من البداية على نقطة مهمّة جدًا:
المقابلة مش محكمة، ولا اختبار حفظ.
المقابلة نقاش يوضح طريقة تفكيرك.
الإنترفيوور مش جاي يصطادك، هو جاي يفهم:
كيف تفكّر؟
كيف تحلل المشكلة؟
وهل عندك أساس قوي، ولا مجرد حافظ حلول؟
في هذا المقال، سنمرّ على مواقف حقيقية جدًا تتكرر في أغلب مقابلات الـ Frontend، ونفهم كيف نجاوب عليها بطريقة ذكية ومهنية.
الموقف الأول: استلمت صفحة Login / Register من Figma… ماذا تفعل؟
هذا سؤال يتكرر كثيرًا، وقد يبدو بسيطًا في الظاهر، لكن في الحقيقة هو سؤال عميق.
الإنترفيوور لا يسأل:
هل تعرف تعمل form؟
هو يسأل:
كيف تفكّر قبل أن تكتب الكود؟
الخطوة الأولى: فهم السيناريو قبل الكود
قبل أي سطر كود، لازم تفهم الصورة كاملة.
ابدأ بطرح أسئلة واضحة مثل:
هل الصفحة Login فقط أم Login و Register؟
هل يوجد Error Messages؟ وما شكلها؟
هل يوجد Loading State؟
هل الزر Disabled في حالات معيّنة؟
هل الـ Validation من الواجهة فقط أم من الـ Backend أيضًا؟
هذه الأسئلة تبيّن أنك تفكّر كمطوّر حقيقي، وليس مجرد منفّذ تصميم.
الحل الشائع (ولكن الخاطئ)
كثير من المطورين يقترحوا:
نعمل Component واحدة تحتوي Login و Register
ونستخدم*ngIfللتبديل بينهم
هذا الحل قد يعمل، لكن هو حل سيئ معماريًا.
لماذا؟
Component واحدة مسؤولة عن أكثر من وظيفة
هذا يخالف مبدأ Single Responsibility Principle (SRP)
أي تعديل في Login أو Register قد يؤثر على الآخر
الكود يصبح صعب القراءة والصيانة
وهنا الإنترفيوور يبدأ يشك أنك لا تفهم أساسيات التصميم البرمجي.
الحل الأفضل: تقسيم المسؤوليات
الحل الصحيح يكون كالتالي:
Component خاص بالـ Login
Component خاص بالـ Register
Component أب (Parent) يتحكم في العرض
لكن هنا تظهر مشكلة جديدة…
مشكلة التكرار (DRY)
في Login و Register ستكرر:
Inputs
Buttons
Validation Styles
وهذا يخالف مبدأ:
DRY – Don’t Repeat Yourself
طيب… ما الحل؟
الحل الاحترافي: Content Projection
هنا يظهر الفرق بين مطوّر عادي ومطوّر فاهم.
نقوم بـ:
إنشاء Shared Components (مثل InputComponent و ButtonComponent)
استخدام
ng-contentلحقن المحتوى المختلف
بهذه الطريقة:
نفس المكونات تُستخدم في أي فورم
كل Component مسؤولة عن مهمة واحدة فقط
أي تعديل في Input أو Button ينعكس على كل الفورمات بدون كسر
وهكذا تكون:
طبّقت SRP
التزمت بـ DRY
وكتبت كود قابل للتوسعة والصيانة
الموقف الثاني: صفحة Dashboard تعتمد على أكثر من API
تخيل أن لديك Dashboard، ولن تظهر إلا بعد:
تحميل User Profile
تحميل Permissions
تحميل Notifications
الحل المنتشر (ولكن السيئ)
هذا الحل:
صعب القراءة
صعب التعديل
كارثي عند إضافة API جديدة
وغالبًا الإنترفيوور سيوقفك هنا.
الحل الصحيح باستخدام RxJS
بما أننا نعمل مع Observables،
فـ RxJS تعطينا أدوات قوية جدًا.
واحدة من أهمها:
forkJoin
forkJoin تقوم بـ:
انتظار جميع الـ Observables حتى تنتهي
ثم تعيد النتائج مرة واحدة
بكود واضح ونظيف
هذا يظهر أنك تفهم RxJS، وليس فقط تستخدمها.
السؤال المهم: متى نستخدم forkJoin ومتى لا؟
هذا سؤال يتكرر كثيرًا في المقابلات.
نستخدم forkJoin عندما:
كل الـ Observables يجب أن تنتهي
البيانات تُجلب مرة واحدة (HTTP Requests)
لا نستخدم forkJoin عندما:
يوجد Stream مستمر
WebSocket
Observable تتغير قيمها باستمرار
في هذه الحالات، نستخدم حلول أخرى مثل:
combineLatest أو switchMap حسب السيناريو.
الخلاصة
المقابلات التقنية لا تحتاج حفظ حلول جاهزة.
هي تحتاج:
فهم المبادئ
التفكير قبل الكود
القدرة على شرح قراراتك
عندما تفهم لماذا اخترت هذا الحل،
لن تخاف من أي سؤال.
