مقابلات الألغاز أم المشاريع العملية؟ كيف أنقذتنا “المشاريع المنزلية” من توظيف كوارث برمجية

السلام عليكم يا جماعة الخير، معكم أبو عمر.

خليني أحكيلكم قصة صارت معي قبل كم سنة، لما كنا لسا شركة ناشئة والواحد فينا بيشتغل شغل ثلاثة. كان عنا شاغر لمبرمج “باك-إند”، وتقدم شب اسمه “أمجد”. السيرة الذاتية تبعته كانت إشي مرتب، مشارك في مسابقات برمجة عالمية، وحسابه على LeetCode كله أخضر في أخضر. قلنا “بس! لقينا الكنز”.

دخل أمجد المقابلة التقنية، وكانت عبارة عن جلسة على السبورة البيضاء (Whiteboard). سألته سؤال خوارزميات من العيار الثقيل، إشي إله علاقة بالـ Dynamic Programming. يا عمي، الشب ما أخذ نفسين إلا وهو راسم الحل ومحلله تحليل رياضي كامل. كلنا انصدمنا من سرعته وذكائه. ما في داعي أحكيلكم، ثاني يوم كان العقد على مكتبه.

أول أسبوعين، كان أمجد مثل “السمكة اللي طلعت من المي”. طلبنا منه يبني API endpoint بسيط، إشي بستقبل بيانات، بخزنها في قاعدة البيانات، وبرجع استجابة. مهمة ما بتاخذ من المبرمج المتوسط أكثر من ساعتين ثلاث. أمجد ضل فيها ثلاث أيام! الكود اللي سلمه كان عبارة عن ملف واحد فيه 500 سطر، كل إشي ببعضه، لا validation ولا error handling ولا أي إشي من أساسيات كتابة الكود النظيف. ولما زميله عمله Code Review وطلب تعديلات، أمجد ما فهم شو يعني “Refactoring” أو “Separation of Concerns”.

هنا ضربت إيدي على راسي وقلت: “شو هالحكي يا أبو عمر؟ إحنا وظفنا آلة حاسبة بشرية، مش مبرمج يبني منتج!”. كانت هاي الصفعة اللي صحتني، وخلتني أعيد التفكير بكل عملية التوظيف من أولها لآخرها.

لماذا فشلت مقابلات الألغاز؟ (أو “سباق الخيل”)

المشكلة في المقابلات اللي بتعتمد على حل الألغاز وخوارزميات السبورة البيضاء إنها بتقيس مهارة محددة جدًا: القدرة على حل مشكلة مجردة، معزولة، وتحت الضغط. هذا إشي رائع لو كنت بتوظف باحث أكاديمي في علوم الحاسوب، لكنه مقياس فاشل جدًا لقياس مهارة المبرمج في بيئة العمل الحقيقية.

مقابلات الألغاز التقليدية كانت تفشل للأسباب التالية:

• تقييم الذاكرة لا المهارة: أغلب المرشحين “الناجحين” هم اللي حافظين حلول أشهر 100 سؤال على LeetCode، مش بالضرورة اللي فاهمين المبادئ الأساسية.
• لا تعكس الواقع اليومي: أنا كمبرمج، يومي عبارة عن قراءة كود قديم، كتابة كود جديد، البحث في جوجل و Stack Overflow، التعامل مع Git، ومناقشة الحلول مع زملائي. ولا مرة احتجت أعمل “invert a binary tree” على سبورة قدام مديري.
• تخلق بيئة قلق مصطنعة: التوتر اللي بحس فيه المرشح وهو واقف على السبورة ممكن يخليه ينسى أبسط الأمور، وهذا لا يعني أنه مبرمج سيء.
• تُقصي المواهب الحقيقية: هناك مبرمجون “بنّاؤون” رائعون، قادرون على بناء أنظمة معقدة ومستقرة، لكنهم لا يتفوقون في مسابقات السرعة والألغاز. هؤلاء كنا نخسرهم.

باختصار، كنا ندير “سباق خيل” ونختار أسرع حصان، وبعدين نتفاجأ إنه ما بعرف يحرث الأرض!

الحل: “المشروع المنزلي” كاشف الحقيقة

بعد قصة أمجد وغيره، قررنا نغير النهج 180 درجة. استبدلنا مقابلة الألغاز بمفهوم “المشروع المنزلي” أو الـ Take-Home Assignment. الفكرة بسيطة: نعطي المرشح مهمة صغيرة، محددة، تشبه تمامًا نوع الشغل اللي راح يشتغله معنا، ونعطيه يومين أو ثلاثة يشتغل عليها براحته في بيته.

هذا النهج قلب الموازين. صرنا نشوف المرشح على حقيقته، بدون ضغط المقابلة، وباستخدام نفس الأدوات اللي بستخدمها كل يوم (محرر الكود، الإنترنت، إلخ). المشروع المنزلي هو المحاكاة الأقرب للواقع.

كيف تصمم مشروعًا منزليًا فعالًا؟ (مش أي إشي والسلام)

مش كل المشاريع المنزلية بتعطي نفس النتيجة. عشان يكون فعال، لازم يكون مدروس صح. هاي نصايحي من تجربتي:

1. احترم وقت المرشح: المشروع لازم ما ياخذ أكثر من 3-4 ساعات عمل فعلية. إحنا بنطلب مبرمجين، مش عمال سخرة. إذا مشروعك بيحتاج يومين شغل كامل، فأنت تستغل الناس. الهدف هو أخذ عينة من شغلهم، مش بناء ميزة كاملة في منتجك على حسابهم.
2. اجعله ذا صلة بالوظيفة: إذا بتوظف مبرمج واجهات أمامية (Frontend)، اطلب منه يبني Component صغير ويتعامل مع API. إذا بتوظف مبرمج خلفية (Backend)، اطلب منه يبني API بسيطة مع قاعدة بيانات. لا تطلب من مبرمج موبايل يحلل بيانات!
3. وضوح المتطلبات: اكتب ملف README.md واضح جدًا. اشرح فيه المطلوب بالتفصيل، معايير القبول (Acceptance Criteria)، وأي تفاصيل مهمة. كل ما كنت أوضح، كل ما كانت النتائج اللي بتوصلك قابلة للمقارنة.
4. أعطِ حرية (معقولة): اسمح للمرشح يستخدم المكتبات والإطارات اللي برتاح معها (إلا إذا كانت وظيفتك تتطلب إطار عمل معين بشكل حصري). هذا بيعطيك فكرة عن الأدوات اللي بفضلها وكيف بستخدمها.

نصيحة من أبو عمر: أفضل مشروع منزلي هو نسخة مصغرة جدًا من مشكلة حقيقية واجهتكم في فريقكم وحليتوها. هذا لا يجعله واقعيًا فحسب، بل يسهل عليكم تقييمه لأنكم تعرفون تمامًا شكل الحل الجيد.

ما وراء الكود: كيف نقيم المشروع المقدم؟

جمال المشروع المنزلي إنه بيعطيك فرصة تقيّم أشياء مستحيل تشوفها في مقابلة السبورة البيضاء. إحنا ما بنطلع بس على “هل الكود شغال؟”. إحنا بنبحث عن علامات الاحترافية:

علامات خضرا (Green Flags) تدل على محترف: ✅

• نظافة الكود وهيكلته: هل الكود مقروء؟ هل المتغيرات أسماؤها واضحة؟ هل المشروع منظم في مجلدات وملفات منطقية (e.g., controllers, services, models)؟
• وجود الاختبارات (Tests): حتى لو اختبار واحد بسيط (Unit Test). المرشح اللي بيكتب اختبارات بدون ما نطلب منه، هذا شخص يفهم معنى الجودة والاحترافية. هذا بالنسبة إلي علامة فارقة.
• ملف README واضح: هل كتب المرشح شرحًا بسيطًا عن قراراته التقنية؟ وهل أضاف تعليمات واضحة لتشغيل المشروع؟ هذا يدل على اهتمامه بالتواصل والتعاون.
• استخدام Git بشكل سليم: هل عنده تاريخ commits نظيف ورسائل واضحة (e.g., “feat: add user creation endpoint”, “fix: handle null values”)؟ أم أنه commit واحد “Final version”؟ الأول يدل على مبرمج منظم، والثاني يدل على فوضى.
• معالجة الحالات الهامشية (Edge Cases): هل فكر في ماذا يحدث لو أرسل المستخدم بيانات خاطئة؟ هل هناك معالجة للأخطاء؟

علامات حمرا (Red Flags) تستدعي الحذر: 🚩

• كود “سباغيتي”: كل شيء في ملف واحد، دوال طويلة جدًا، كود مكرر في كل مكان.
• لا يوجد أي اختبارات: مؤشر خطير على عدم الاهتمام بجودة المنتج النهائي.
• صعوبة تشغيل المشروع: إذا احتجت ساعة كاملة بس عشان تشغل المشروع بسبب نقص التعليمات أو وجود أخطاء، هذه مشكلة.
• تجاهل المتطلبات الأساسية: إذا طلبت منه شيء محدد وهو لم يقم به، فهذا يدل على عدم الانتباه للتفاصيل.

مثال بسيط: هيكلة الكود

لما يجينا مشروع، أول إشي بنطلع عليه هو هيكل الملفات. شوف الفرق:

الهيكل السيء (كل شيء في ملف واحد):

/project
└── index.js  // (يحتوي على كل شيء: السيرفر, الروابط, لوجيك قاعدة البيانات)

الهيكل الجيد (فصل المسؤوليات):

/project
├── /src
│   ├── /controllers  // (يحتوي على لوجيك الطلب والاستجابة)
│   │   └── user.controller.js
│   ├── /services     // (يحتوي على لوجيك العمل "Business Logic")
│   │   └── user.service.js
│   ├── /routes       // (يحتوي على تعريف الروابط)
│   │   └── user.routes.js
│   └── app.js        // (نقطة بداية التطبيق)
├── package.json
└── README.md

مجرد النظر للهيكل الثاني يعطيك انطباعًا فوريًا أن هذا الشخص منظم ويفهم مبادئ هندسة البرمجيات.

المقابلة التالية: من “حل اللغز” إلى “بناء الحل”

المشروع المنزلي ليس نهاية المطاف. المرشحون اللي بيقدموا مشاريع ممتازة، بنعمل معهم مقابلة أخيرة. لكن هذه المقابلة مختلفة تمامًا.

بدلًا من السبورة البيضاء، بنفتح الكود اللي هو سلمه وبنعمل عليه “Code Review” مباشر معه. هذه الجلسة تتحول من استجواب إلى نقاش تقني ثري:

• “شرحلنا ليش استخدمت هاي المكتبة (library) بدلًا من تلك؟”
• “لو عندك وقت إضافي، شو أول إشي بتحسنه في هذا الكود؟”
• “كيف ممكن نطور هذا الحل عشان يتحمل عدد مستخدمين أكبر بـ 100 مرة؟” (سؤال عن الـ Scalability)
• “لاحظت إنك ما عملت validation للـ input هنا، هل كان هذا مقصودًا؟”

هذا النقاش يكشف لنا عن عمق فهم المرشح، قدرته على تقبل النقد، وطريقة تفكيره في حل المشاكل على المدى الطويل. من الآخر، بنشوف إذا كان “زلمة شغل” وبنقدر نشتغل معه كل يوم أو لا.

الخلاصة: وظّف البنّاء، لا لاعب الشطرنج ♟️

الانتقال من مقابلات الألغاز إلى المشاريع المنزلية كان أفضل قرار اتخذناه في عملية التوظيف. صحيح أنه يتطلب مجهودًا أكبر في البداية لإنشاء وتقييم المشاريع، لكن العائد كان هائلًا. انخفضت نسبة التوظيف الخاطئ بشكل كبير، وارتفعت جودة الفريق وثقته في كل عضو جديد ينضم إليه.

نصيحتي الأخيرة:

• لمدراء التوظيف والفرق التقنية: توقفوا عن اختبار قدرة الناس على حل الألغاز المجردة، وابدأوا في اختبار قدرتهم على البناء. ابحثوا عن الحرفيين، عن البنائين، عن الذين يجدون متعة في كتابة كود نظيف ومستدام.
• للمبرمجين الباحثين عن عمل: استثمروا في بناء مشاريع شخصية حقيقية. حسابكم على GitHub هو سيرتكم الذاتية الجديدة. أظهروا قدرتكم على بناء منتج من الألف إلى الياء، مع كود نظيف واختبارات وتوثيق. هذا ما يبحث عنه أصحاب العمل الجادون، وليس كم حليت من مسائل على LeetCode.

في النهاية، نحن نبني منتجات برمجية، لا نحل ألغاز شطرنج. فلنوظف الأشخاص الذين يتقنون فن البناء. يعطيكم العافية.