كانت مقابلاتنا التقنية تطرد أفضل المواهب: كيف أنقذنا ‘الاختبار المنزلي الواقعي’ عملية التوظيف؟

يا جماعة الخير، اسمحوا لي أن أروي لكم قصة حصلت معي قبل سنوات، قصة لا زالت محفورة في ذاكرتي. كنا نبحث عن مطور برمجيات خبير (Senior Developer) لينضم لفريقنا. تقدم لنا شاب اسمه “خالد”، سيرته الذاتية كانت أشبه بقصيدة فنية: مشاريع مفتوحة المصدر قوية، مساهمات في مكتبات برمجية معروفة، وخبرة في شركات تحلم بالعمل فيها. قلنا “بس، لقيناه!”.

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

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

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

لماذا فشلت مقابلات السبورة البيضاء التقليدية؟

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

ضغط غير واقعي وأداء مسرحي

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

التحيز ضد أنماط التفكير المختلفة

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

ألغاز لا تعكس العمل اليومي

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

تجربة سيئة للمرشح

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

الحل: ‘الاختبار المنزلي الواقعي’ – بوابتنا للمواهب الحقيقية

بعد حادثة خالد، قررنا التخلص من السبورة البيضاء تماماً. واستبدلناها بما أسميه “الاختبار المنزلي الواقعي” (Realistic Take-home Assignment). الفكرة ليست جديدة، لكن تطبيقنا لها كان هو سر النجاح.

ما هو الاختبار المنزلي الواقعي؟

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

مبادئ تصميم اختبار منزلي ناجح (من مطبخ أبو عمر)

لكي ينجح هذا النهج، يجب أن تتبع بعض المبادئ الأساسية:

1. الواقعية فوق كل شيء: يجب أن تكون المهمة نسخة مبسطة من مشكلة حقيقية واجهها فريقك. مثال: “ابنِ واجهة برمجية (API) بسيطة لجلب بيانات منتجات وعرضها”. هذا أفضل ألف مرة من “حل سودوكو برمجياً”.
2. احترام وقت المرشح: هذا أهم مبدأ. يجب أن يكون الاختبار قصيراً. نحن نحدد بوضوح أن “هذه المهمة يجب ألا تستغرق أكثر من 3-4 ساعات من العمل الفعلي”. ونعطي المرشح عدة أيام لإنجازها (مثلاً، عطلة نهاية الأسبوع). إذا كان اختبارك طويلاً جداً، فإنك تقول للمرشحين الموهوبين (الذين لديهم وظائف والتزامات) أن وقتهم لا قيمة له.
3. تعليمات واضحة كعين الشمس: لا تترك مجالاً للتخمين. قدم ملف README.md مفصلاً يشرح المطلوب بالضبط، كيفية تشغيل المشروع، ومعايير النجاح. كلما كانت التعليمات أوضح، كانت النتائج التي تحصل عليها أكثر قابلية للمقارنة.
4. حرية الإبداع (ضمن حدود): اسمح للمرشح باستخدام المكتبات والأدوات التي يفضلها (مثلاً، يمكنك تحديد اللغة “Node.js” ولكن تترك له حرية اختيار إطار العمل Express أو Fastify). هذا يريك كيف يفكر وما هي الأدوات التي يجيدها.
5. التقييم الشامل: لا تنظر فقط إلى النتيجة النهائية. نحن نقيم كل شيء: جودة الكود، بنية المشروع، استخدام Git، جودة الاختبارات، ووضوح التوثيق.

مثال عملي: تصميم اختبار لوظيفة مطور Backend

لنجعل الأمر عملياً. هذا مثال على اختبار كنا نرسله لمرشحي وظيفة مطور Backend (Node.js).

وصف المهمة

الهدف: بناء واجهة برمجية (API) بسيطة لإدارة قائمة “ملاحظات”.

المتطلبات التقنية:

• استخدام Node.js و TypeScript.
• بناء نقطتي نهاية (Endpoints):
  • POST /notes: لإنشاء ملاحظة جديدة (تحتوي على title و content).
  • GET /notes: لجلب كل الملاحظات.
• لا حاجة لاستخدام قاعدة بيانات حقيقية، يمكنك استخدام مصفوفة في الذاكرة (in-memory array) لتخزين الملاحظات.
• كتابة اختبارات الوحدات (Unit Tests) لنقطتي النهاية باستخدام Jest.
• تضمين ملف README.md يشرح كيفية تثبيت الاعتماديات وتشغيل المشروع وتشغيل الاختبارات.

ما نبحث عنه: كود نظيف ومنظم، اختبارات جيدة، وتوثيق واضح.

ماذا يكشف لنا هذا الاختبار البسيط؟

قد يبدو الاختبار بسيطاً، ولكنه يكشف الكثير:

• جودة الكود: هل يستخدم المرشح مبادئ مثل SOLID؟ هل الكود مقروء ومنظم في ملفات ووحدات منطقية؟
• فهم الـ API: هل يفهم كيفية تصميم RESTful API بشكل صحيح؟ هل يتعامل مع رموز الحالة (Status Codes) والمدخلات الخاطئة (Error Handling)؟
• ثقافة الاختبارات: هل يكتب اختبارات مفيدة تغطي الحالات الأساسية (Happy Path) والحالات الحرجة (Edge Cases)؟ أم أنه كتبها فقط لتلبية المتطلبات؟
• الاحترافية: هل استخدم Git بشكل جيد (commits ذات رسائل واضحة)؟ هل كتب ملف README.md احترافي؟ هذه التفاصيل الصغيرة تدل على مطور محترف ومنظم.

هذا مثال بسيط لكود قد يقدمه مرشح لنقطة النهاية POST /notes باستخدام إطار العمل Express:

// src/routes/notes.ts
import { Router, Request, Response } from 'express';

// In-memory store
const notes: { id: number; title: string; content: string }[] = [];
let currentId = 1;

const router = Router();

router.post('/notes', (req: Request, res: Response) => {
  const { title, content } = req.body;

  if (!title || !content) {
    return res.status(400).json({ error: 'Title and content are required' });
  }

  const newNote = {
    id: currentId++,
    title,
    content,
  };

  notes.push(newNote);

  return res.status(201).json(newNote);
});

export default router;

هذا الكود البسيط يعطينا مادة دسمة لمناقشتها لاحقاً.

المقابلة التالية: ليست استجوابًا، بل حوارًا تقنيًا

أهم جزء في هذه العملية هو ما يأتي بعد تسليم الاختبار. المقابلة التالية ليست لاستجواب المرشح، بل هي جلسة “مراجعة كود” (Code Review) تعاونية.

نبدأ الجلسة بسؤال بسيط: “شغل مرتب! ممكن تمشي معنا في الكود وتشرح لنا قراراتك التصميمية؟”.

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

• “لماذا اخترت استخدام هذه المكتبة بدلاً من تلك؟”
• “لاحظنا أنك لم تعالج الحالة X، كيف كنت ستتعامل معها لو كان لديك المزيد من الوقت؟”
• “هذا الحل يعمل بشكل رائع لـ 100 مستخدم. كيف يمكننا تطويره ليدعم 100,000 مستخدم؟” (سؤال عن قابلية التوسع – Scalability).
• “لو انضممت لفريقنا غداً، ما هي أول خطوة ستقوم بها لتحسين هذا الكود؟”

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

النتائج: كيف تغير كل شيء؟

بعد تطبيق هذا النظام، النتائج كانت مذهلة:

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

خلاصة أبو عمر ونصيحة من القلب 💡

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

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

لا تخافوا من التغيير، ففي التغيير تكمن الفرصة لجذب العقول التي ستبني مستقبل شركتكم. بالتوفيق!