أسئلة مقابلة Spring Boot
بقلم Aaron Cao · آخر تحديث
توقع أسئلة حول autoconfiguration وstarters، وdependency injection وbean scope، وprofiles والتهيئة الخارجية، وSpring Data JPA، وREST controllers ومعالجة exception، وtesting slices، وActuator. تضيف مقابلات senior حدود المعاملات transaction وcaching وكيف تتصرف الخدمة بعد إعادة التشغيل.
بماذا يسأل القائمون على المقابلات حول autoconfiguration وstarters؟
على الأرجح تستخدم Spring Boot يوميًا دون قراءة سجل بدء التشغيل startup log الخاص به، والقائمون على المقابلات يعرفون ذلك، ولهذا يبدؤون من هنا. يغطي هذا القسم الأسئلة التي تتحقق مما إذا كنت تفهم الإطار framework أو فقط إعداداته الافتراضية.
- ما الذي يجمعه
@SpringBootApplicationفعليًا، وما الذي سينكسر لو أزلت جزءًا منه؟ - كيف يقرر autoconfiguration ما الذي سيُهيَّأ، وما دور conditional annotations في ذلك؟
- ما هو starter، وماذا يوجد بداخله إلى جانب dependencies؟
- كيف تتجاوز override أو تعطّل autoconfiguration معينًا؟
- من أين يأتي embedded server، وكيف يمكنك استبداله؟
الإجابة الجيدة تربط الآلية بشيء فعلته حقًا: bean اضطررت إلى استبعاده exclude، أو starter استبدلته، أو خطأ بدء تشغيل تتبعته عبر condition evaluation report.
ما الأسئلة الأساسية حول container والبيانات التي تظهر؟
- dependency injection. constructor مقابل field injection، ولماذا يُفضَّل constructor injection، وكيف تحل مشكلة وجود مرشحَي bean من النوع نفسه.
- دورة حياة bean وscopes. لماذا singleton هو الافتراضي، ومتى يكون request أو prototype scope صحيحًا، وما الذي يجعل مشاركة bean من نوع singleton غير آمنة.
- التهيئة Configuration. أولوية property، وprofiles لكل بيئة، و
@ConfigurationPropertiesمقابل value injection المتناثر. - Spring Data JPA. طرق query المشتقة، ومشكلة N plus 1، وlazy مقابل eager fetching، ومتى تنزل إلى native query.
- المعاملات Transactions. ما الذي يعترضه فعليًا proxy الخاص بـ
@Transactional، ولماذا يتخطى self-invocation المعاملة بصمت، وكيف تعمل قواعد rollback مع checked exceptions.
سؤال proxy المعاملات هو المكان الأكثر شيوعًا الذي تنهار فيه إجابة واثقة، لذا كن مستعدًا لشرح حدود proxy بدلاً من مجرد ذكر اسم annotation.
كيف تتحدث عن تصميم REST وtesting والعمليات؟
بخلاف container، يريد القائمون على المقابلات رؤية الأجزاء التي تظهر في الإنتاج production. على طبقة الويب: اختيارات status code، والتحقق validation، ومعالجة الأخطاء المركزية باستخدام @ControllerAdvice بدلاً من try-catch في كل controller. في testing: الفرق بين @SpringBootTest كامل وslice مثل اختبار طبقة الويب، ولماذا يُعد تشغيل السياق context بأكمله لاختبار controller واحد عادة بطيئة. في العمليات: ما الذي يكشفه Actuator، وأي endpoints يجب ألا تكون عامة، وكيف تغذي health checks عملية deployment.
تخيل مهندسة backend تُجري مقابلة لوظيفة mid-level في شركة لوجستيات. تُسأل لماذا كانت job مجدولة تكتب أحيانًا بيانات جزئية. بدلاً من التخمين، تشرح حدود المعاملة، وتلاحظ أن job استدعت طريقة method من نوع transactional على نفسها، وتوضح سلوك proxy الذي تجاوز ذلك. انتقل القائم على المقابلة مباشرة إلى محادثة عرض العمل offer، لأن الإجابة أظهرت عادة تصحيح أخطاء debugging لا تعريفًا محفوظًا.
مجموعات الأسئلة للغات وframeworks أخرى مجمعة تحت question banks.
كيف يجب أن تتدرب، وأين يناسب مساعد مباشر live؟
اقرأ سجل بدء تشغيل خدمتك الخاصة مرة واحدة وكن قادرًا على سرده. ثم تدرب بصوت مسموع، لأن الفجوة بين معرفة مفهوم وشرحه في أربعين ثانية هي ما يحسم هذه المقابلات. يمكن لقائم مقابلة AI على صفحة /mock-interview أن يطرح أسئلة المتابعة التي لن تطرحها على نفسك.
أثناء مقابلة فيديو منطوقة، ينسخ SubcueAI سؤال القائم على المقابلة ويعرض على جانبك بنية مقترحة، في الطبقة العلوية لسطح المكتب desktop overlay على macOS وWindows أو في اللوحة الجانبية لإضافة متصفح Chromium. لا ينضم أي meeting bot إلى المكالمة، ولا يُحقن أي شيء في صفحة الاجتماع. الحد الصريح هو جولة البرمجة: إذا انتقلت إلى منصة مراقَبة بالشاشة أو proctored، فإن المساعدة المباشرة خارج النطاق، وإذا شاركت شاشتك، يصبح كل ما عليها مرئيًا.