مقابلاتنا التقنية كانت مسرحية: كيف أنقذتنا ‘البرمجة الثنائية’ من جحيم ألغاز السبورة البيضاء؟

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحوا لي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة غيرت نظرتي كلها لموضوع المقابلات التقنية والتوظيف. وقتها كنت مسؤول عن فريق تقني في شركة ناشئة، وكنا بدنا نعيّن مهندس برمجيات “سنيور” (خبير). تقدم لنا شب اسمه “سامي” (اسم مستعار طبعًا)، سيرته الذاتية كانت “بتفتح النفس” زي ما بنحكي، مشاريع قوية، خبرة في شركات محترمة، ومساهمات في مشاريع مفتوحة المصدر.

دخل سامي المقابلة، شب هادي وواثق. حكينا في كل شي، عن خبرته، عن مشاريعه، وكان واضح إنه “الزلمة” فاهم شغله مية بالمية. لكن، وصلت اللحظة المشؤومة… لحظة السبورة البيضاء.

طلبت منه طلب كلاسيكي سخيف: “سامي، بالله اكتب لنا دالة (function) بتعكس قائمة مترابطة (reversing a linked list)”. شفت التوتر بعيونه مباشرة. الشب اللي كان قبل دقيقة بناقش معي في تحديات الـ scalability لأنظمة موزعة، فجأة انربط لسانه قدام لوح أبيض وقلم. حاول يكتب، مسح، رجع كتب، لخبط بين المؤشرات (pointers)… باختصار، كانت تجربة مؤلمة له ولنا.

بعد ما روّح، صار نقاش حاد بالفريق. واحد من المهندسين قال: “إذا مش عارف يعمل reverse لـ linked list، كيف بدنا نوظفه؟”. وقتها، انفجرت أنا وحكيت: “يا جماعة، شو القصة؟ هل شغلنا اليومي هو عكس القوائم المترابطة على السبورة؟ هل عمره مر علينا يوم احتجنا فيه نكتب هاي الخوارزمية من الصفر تحت ضغط وواحد واقف فوق راسنا؟”.

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

لماذا كانت مقابلاتنا “مسرحية هزلية”؟

قبل ما أحكي عن الحل، خلينا نكون صريحين ونحلل ليش الطريقة القديمة كانت فاشلة. كانت المشكلة بتتلخص في ثلاث نقاط رئيسية:

جحيم السبورة البيضاء (The Whiteboard Hell)

البرمجة على السبورة البيضاء هي بيئة مصطنعة لا تشبه الواقع بأي شكل من الأشكال. المبرمج الحقيقي لا يعمل هكذا. المبرمج الحقيقي يستخدم:

• محرر أكواد (IDE) فيه إكمال تلقائي وتصحيح أخطاء.
• محرك بحث (Google) للبحث عن حلول وتذكر بناء الجمل (syntax).
• مواقع مثل Stack Overflow أو توثيقات اللغة الرسمية.
• أدوات لتشغيل الكود وتجربته (Debugger).

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

ألغاز لا تقيس شيئًا

الكثير من أسئلة المقابلات التقليدية كانت عبارة عن ألغاز وخوارزميات معقدة نادرًا ما تواجهنا في العمل اليومي. أن يعرف المبرمج كيف يجد أقصر مسار في متاهة باستخدام خوارزمية Dijkstra هو شيء جميل، لكن هل هذا يجعله قادرًا على بناء واجهة مستخدم متجاوبة، أو تصميم قاعدة بيانات قابلة للتوسع، أو كتابة اختبارات وحدة (unit tests) جيدة؟ غالبًا لا.

العمل الهندسي الحقيقي هو فن إدارة التعقيد، والتواصل الفعال، وكتابة كود نظيف ومفهوم للآخرين، وليس حل الألغاز بسرعة.

تجربة المرشح السيئة (The Awful Candidate Experience)

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

“البرمجة الثنائية” كطوق نجاة

بعد اعترافنا بفشل طريقتنا القديمة، بحثنا عن بديل. وجدنا ضالتنا في مفهوم “البرمجة الثنائية” (Pair Programming) المطبق في سياق المقابلات. الفكرة بسيطة لكنها عبقرية.

ما هي البرمجة الثنائية في سياق المقابلات؟

هي جلسة عمل تعاونية لمدة 45-60 دقيقة. نجلس فيها (أنا والمُرشح) معًا لحل مشكلة برمجية واقعية وصغيرة. لا يوجد “مُمتحِن” و “مُمتحَن”، بل زميلين يعملان معًا. نستخدم بيئة تطوير حقيقية (مثل VS Code Live Share أو Replit) ونعمل على نفس الكود في نفس الوقت.

الهدف ليس أن يكتب المرشح كودًا مثاليًا من أول مرة، بل أن نرى كيف يفكر، كيف يتواصل، كيف يتعاون، وكيف يتعامل مع مشكلة حقيقية.

من النظرية إلى التطبيق: كيف نبني جلسة برمجة ثنائية ناجحة؟

هنا تكمن الخبرة العملية. بناء جلسة ناجحة يتطلب تحضيرًا دقيقًا:

1. اختيار المشكلة: نختار مشكلة صغيرة من صميم عملنا اليومي. ليست خوارزمية معقدة، بل مهمة واقعية. مثلاً: “لدينا API يرجع قائمة منتجات، نريد كتابة دالة في الواجهة الأمامية (Frontend) لفلترة هذه المنتجات وعرضها”.
2. تجهيز البيئة: قبل المقابلة، نرسل للمرشح رابطًا لبيئة العمل (مثلاً على CodeSandbox) تحتوي على هيكل المشروع الأساسي. هذا يوفر الوقت ويجعل المرشح يشعر بالراحة لأنه يستخدم أدوات حقيقية.
3. تحديد الأدوار: في البداية، أوضح للمرشح: “أنا هنا لمساعدتك. اعتبرني زميلك في الفريق. فكر بصوت عالٍ، اسأل أي سؤال يخطر في بالك، وإذا احتجت تبحث عن شيء في جوجل، تفضل، فهذا ما نفعله جميعًا”.
4. التركيز على الحوار: أقضي معظم الوقت في طرح أسئلة مفتوحة مثل:
   • “جميل هذا الحل، هل هناك طريقة أخرى ممكن نفكر فيها؟”
   • “ما هي الحالات الحافة (Edge Cases) التي يجب أن ننتبه لها هنا؟”
   • “لو كبر هذا الجزء من الكود في المستقبل، كيف يمكننا أن نجعله أسهل للصيانة؟”

مثال عملي: فلترة المنتجات

لنفترض أن هذه هي المهمة. أبدأ الجلسة بالملف التالي جاهزًا للمرشح:

// مرحبًا بك! مهمتنا اليوم هي بناء دالة لفلترة قائمة المنتجات هذه
// بناءً على السعر والفئة.

const products = [
  { id: 1, name: 'لابتوب Dell XPS', category: 'إلكترونيات', price: 5500 },
  { id: 2, name: 'كتاب فن اللامبالاة', category: 'كتب', price: 70 },
  { id: 3, name: 'سماعات Sony WH-1000XM4', category: 'إلكترونيات', price: 1200 },
  { id: 4, name: 'آلة صنع القهوة', category: 'أدوات منزلية', price: 400 },
  { id: 5, name: 'رواية 1984', category: 'كتب', price: 50 },
];

/**
 * فلترة المنتجات بناءً على خيارات محددة
 * @param {Array} products - قائمة المنتجات
 * @param {Object} filters - كائن يحتوي على الفلاتر (مثال: { category: 'كتب', maxPrice: 80 })
 * @returns {Array} - قائمة المنتجات المفلترة
 */
function filterProducts(products, filters) {
  // يلا يا بطل، خلينا نبنيها سوا. كيف تقترح أن نبدأ؟
  let filteredResults = products;

  // ... أكمل هنا
  
  return filteredResults;
}

// مثال للاستخدام (يمكننا كتابة اختبارات لاحقًا)
const cheapBooks = filterProducts(products, { category: 'كتب', maxPrice: 80 });
console.log(cheapBooks);

من هنا، يبدأ الحوار. قد يقترح المرشح استخدام .filter(). سأسأله: “ممتاز، وكيف سنتعامل مع وجود فلاتر متعددة؟ هل نستخدم if لكل فلتر؟ أم هناك طريقة أفضل؟”. قد نصل معًا إلى حل يمر على الفلاتر بشكل ديناميكي. المهم هنا هو الرحلة، وليس فقط الوصول للوجهة.

ما الذي نقيسه حقًا في البرمجة الثنائية؟

الجمال في هذه الطريقة هو أنها تقيس المهارات التي تهم حقًا في بيئة العمل الجماعية:

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

نصائح من “أبو عمر” للمرشحين والشركات

من الآخر، هذه خلاصة تجربتي الطويلة مع هذا الأسلوب.

للمرشحين (للمهندسين والمهندسات)

1. تكلم! Think Aloud: أكبر خطأ هو أن تصمت وأنت تفكر. اشرح ما يدور في رأسك حتى لو لم تكن متأكدًا. “أنا أفكر الآن في استخدام دالة map، لكن ربما filter أفضل… دعنا نرى”.
2. كن شريكًا، لا تكن طالبًا: تعامل مع المقابِل كأنه زميلك. اطرح عليه أسئلة، اطلب رأيه. “ما رأيك لو تعاملنا مع هذه الحالة بهذه الطريقة؟”.
3. لا تخف من قول “لا أعرف”: من الطبيعي ألا تعرف كل شيء. الأهم هو ما تفعله بعد ذلك. “صراحة، لست متأكدًا من أفضل طريقة لعمل هذا، هل يمكننا البحث عنها سريعًا؟” هذا يظهر نضجًا وثقة.

للشركات وفرق التوظيف

1. دربوا المقابلين: إجراء مقابلة برمجة ثنائية هو مهارة بحد ذاتها. يجب تدريب المهندسين على كيفية التوجيه بدلاً من الحكم، وكيفية خلق بيئة آمنة ومريحة.
2. وحّدوا المعايير: ضعوا معايير واضحة لما تبحثون عنه (التواصل، جودة الكود، حل المشاكل) حتى لا يصبح التقييم شخصيًا.
3. اطلبوا التغذية الراجعة: بعد المقابلة، اسألوا المرشحين (حتى الذين لم يتم قبولهم) عن رأيهم في العملية. هذا سيساعدكم على تحسينها باستمرار.

الخلاصة: نحو توظيف أكثر إنسانية وفعالية ✅

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

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

في النهاية، نحن نبني فرقًا من البشر، وليس من آلات تنفيذ الخوارزميات. دعونا نجعل عمليات التوظيف تعكس هذه الحقيقة. بالتوفيق للجميع! 🚀