أسئلة مقابلة full stack developer

قد تقلق من أن مسار full stack يعني التحضير لمقابلتين كاملتين، frontend وbackend، في الوقت الذي يخصصه معظم المرشحين لمقابلة واحدة. هذا القلق منطقي، ويوضح هذا القسم لماذا المهمة أصغر مما تبدو. نادرًا ما يكرر القائمون بالمقابلات مسارًا متخصصًا في frontend أو backend؛ بل يفحصون النقاط التي تلتقي فيها الطبقات، لأن هناك يكتسب مهندسو full stack لقبهم.

تجمع معظم المسارات بين أربعة أنواع من الجولات:

• Coding: مسألة في بنى البيانات أو مهمة عملية مثل parsing أو التجميع أو pagination للسجلات، غالبًا بلغة JavaScript أو TypeScript أو Python أو Java.
• بناء ميزة: مهمة صغيرة من النوع end-to-end، مثل نموذج يحفظ البيانات في API ويعرض أخطاء التحقق، في editor مشترك أو مستودع take-home.
• Design عبر كامل الـstack: ارسم ميزة مثل التعليقات أو الإشعارات، وغطِّ السكيما وAPI وstate على client وما يحدث عند فشل الشبكة.
• سلوكي: تولي مسؤولية ميزة من ticket إلى production، وbug تتبعته عبر الطبقات.

لا يزال العمق الخاص بكل طبقة يظهر، وتوجد المجموعات المخصصة، بما فيها صفحات منفصلة لـfrontend developer وbackend developer، في مركز أسئلة المقابلات. تتناول هذه الصفحة ما يقع بينهما.

API هو العقد بين نصفي عملك، لذا يسأل القائمون بالمقابلات عنه من الجانبين:

• كيف تصمم endpoints لميزة، وماذا يُعيد كل منها عند النجاح وعند الفشل؟
• كيف تغيّر API دون كسر clients يعملون بالفعل في production؟ (Versioning، تعديلات إضافية، فترات deprecation.)
• Pagination بـoffset أو بـcursor: أيهما تستخدم لـactivity feed، ولماذا؟
• كيف تجعل POST آمنًا لإعادة المحاولة إذا واجه client انتهاء مهلة timeout؟ (Idempotency key.)
• REST أو GraphQL أو RPC لـclient معين: ماذا يتغير في caching وover-fetching ومعالجة الأخطاء؟
• أين يعيش التحقق، على client أم server أم كليهما، وأيهما المرجع؟
• كيف تتجنب استعلام N+1 عندما يُعيد endpoint من نوع list بيانات متداخلة؟

الإجابة القوية تسمي المقايضة trade-off، لا الاختيار فقط. "Cursor pagination، لأن الصفوف المُدرجة أثناء تمرير المستخدم ستُزيح offset وتُكرر عناصر" أفضل من سرد الخيارين والتوقف عند ذلك.

نوعان من الأسئلة يفصلان مرشحي full stack عن المتخصصين. الأول هو المصادقة الشاملة: اشرح ما يحدث من لحظة إرسال المستخدم لنموذج تسجيل الدخول إلى لحظة نجاح استدعاء API مصادق عليه. يستمع القائمون بالمقابلات إلى أين يعيش credential (cookie أو تخزين على client)، وكيف يتحقق منه server، ولماذا يقاوم cookie من نوع HttpOnly الوصول عبر script، وما حماية CSRF التي تحتاجها session قائمة على cookie، وكيف يؤثر CORS على front end على origin مختلف، وكيف يُعالَج logout وانتهاء صلاحية token.

الثاني هو التتبع: "ينقر المستخدم على Save ولا يحدث شيء. اشرح لي كيف ستقوم بعملية debug لهذا." الإجابة الجيدة تتحرك طبقة تلو طبقة، من console المتصفح وتبويب network، إلى request وresponse، إلى سجلات server، إلى الكتابة في قاعدة البيانات، بدلًا من التخمين.

مطورة full stack تُجري مقابلة في شركة SaaS متوسطة الحجم مثال نموذجي. عند سؤالها عن كيفية عمل ميزة التعليقات، بدأت من الجدول (تعليقات تحمل post ID وauthor ID وtimestamps، مفهرسة حسب المنشور)، وحدّدت endpoint من نوع list بـcursor pagination، ووصفت optimistic rendering على client مع rollback في حال فشل POST، وختمت بكيفية منعها نقرة مزدوجة من نشر المحتوى مرتين. حافظت على إيجاز كل طبقة، وذهبت أسئلة المتابعة من القائم بالمقابلة مباشرة إلى نقاط الالتقاء التي سمّتها.

تدرب على التتبع بصوت مسموع. اختر ميزة من تطبيق تستخدمه يوميًا، واشرحها من السكيما إلى الشاشة، ثم كرر ذلك مع إدخال عطل: API بطيء، الكتابة تنجح جزئيًا فقط، يُسجَّل خروج المستخدم في منتصف request. سجّل نفسك، أو نفّذ الأسئلة في AI mock interview، الذي يطرح أسئلة متابعة بناءً على إجاباتك المنطوقة.

في الجولات المباشرة، يمكن لتطبيق سطح المكتب من SubcueAI لأنظمة macOS وWindows أن يفرغ حديث القائم بالمقابلة نصيًا ويقترح بنية لإجابات design والأسئلة السلوكية حيث تسمح قواعد المقابلة بالمساعدة؛ ويغطي امتداد Chrome/Edge المكالمات داخل تبويب المتصفح، ويستمع تطبيق iPhone إلى مكالمة تُشغَّل على جهاز آخر. الحد الصادق هو الأهم في مسارات full stack: غالبًا ما تجري جولات بناء الميزة وcoding على shared screen، وكل ما يظهر على shared screen مرئي، لذا تكون المساعدة خارج النطاق هناك. كذلك تقع الاختبارات الإلكترونية proctored والأجهزة التي تديرها الشركة خارج النطاق. الإعداد موجود في tutorial.