منصة ويب متكاملة (full-stack) تربط بين الباحثين عن عمل والمُوظِّفين: ملفات تعريف لكلا الطرفين، وعروض عمل، وآلية مطابقة، ومراسلة داخل المنصة، ولوحة تحكم للمُوظِّفين لإدارة العروض والمتقدمين.
المشكلة والقيود
تضم منصة مطابقة التوظيف نوعين مختلفين تمامًا من المستخدمين (المرشحون والمُوظِّفون) يحتاجان إلى عروض مختلفة لبيانات متشابهة إلى حد كبير (الملفات التعريفية، العروض، الطلبات)، إضافة إلى مراسلة تُعطي إحساسًا بالوقت الفعلي دون المبالغة في هندسة نظام دردشة لما هو أساسًا تدفق طلب/استجابة.
النهج
- واجهة أمامية بـ React.js تستهلك خلفية Node.js/واجهة REST، مع MongoDB كقاعدة بيانات وثائقية — خيار طبيعي لبيانات الملفات التعريفية والعروض التي يختلف شكلها بين المرشحين والمُوظِّفين.
- تنفيذ منطق المطابقة كطبقة قائمة بذاتها بين العروض والملفات التعريفية للمرشحين، بدلًا من دمجه في الواجهة، بحيث يمكن لقواعد المطابقة أن تتطور بشكل مستقل عن طريقة عرض النتائج.
- عروض لوحة تحكم منفصلة للمرشحين (التصفح/التقديم) وللمُوظِّفين (إدارة العروض، مراجعة المتقدمين، مراسلة المرشحين)، مبنية على نفس واجهة البرمجة الأساسية بدلًا من تطبيقين منفصلين.
المفاضلات
Decision
MongoDB بدلًا من قاعدة بيانات علائقية: تتميز الملفات التعريفية للمرشحين والمُوظِّفين بأشكال مختلفة ومتطورة (المهارات، الخبرة، معلومات الشركة)؛ جنّبت قاعدة البيانات الوثائقية قدرًا كبيرًا من عبء ترحيل المخططات الذي كان تصميم علائقي سيتطلبه لتحقيق نفس المرونة.
Decision
واجهة REST مشتركة لكلا نوعي المستخدمين بدلًا من خلفيتين منفصلتين: أبقت النظام أبسط في التفكير والنشر، على حساب مزيد من المنطق الشرطي في طبقة الواجهة البرمجية لخدمة جمهورين مختلفين.
النتائج
منصة تعمل فعليًا وتغطي المسار الكامل: إنشاء الملف التعريفي، نشر العروض، مطابقة المرشحين بالعروض، المراسلة، ولوحة تحكم للمُوظِّفين لإدارة العملية من البداية إلى النهاية.
ما كنت سأفعله بشكل مختلف
إدخال استراتيجية فهرسة/بحث حقيقية على MongoDB في وقت أبكر (بدلًا من استعلامات ساذجة) بمجرد أن يزداد حجم العروض — فالمطابقة والبحث هما الميزتان الأكثر حساسية لحجم البيانات في هذا النوع من المنصات.