فيس كويز?فيس كويز
ابحث عن اختبار
الوظيفة:
محلل بيانات
المستوى:
خبير
عدد الأسئلة:
١٢ سؤالاً
الزمن:
٦ دقائق

أسئلة مقابلة محلل بيانات أول مع الإجابة

قرارات ومواقف صعبة يُسأل عنها الخبراء في مقابلات وظيفة محلل بيانات: Excel وجداول البيانات، واستعلامات SQL، والإحصاء الوصفي، وتصوير البيانات ولوحات المعلومات، وتنظيف البيانات، ومؤشرات الأداء والتفكير التحليلي. في آخرها تقرير بنقاط ضعفك.

المهارات: استعلامات SQL، Excel وجداول البيانات، الإحصاء الوصفي، مؤشرات الأداء والتفكير التحليلي، تصوير البيانات ولوحات المعلومات، تنظيف البيانات

تعليمات: لكل سؤال إجابة صحيحة واحدة. إن لم تعرف الإجابة فاختر «لا أعرف»، وسيدلّك التقرير على ما تراجعه.

السؤال الأول: طلب منك مدير المبيعات قائمة بكل العملاء وعدد طلبات كل منهم منذ بداية 2026، على أن يظهر من لم يطلب شيئاً بعدد صفر. كتبت الاستعلام التالي فاختفى هؤلاء العملاء من النتيجة تماماً: SELECT c.customer_id, COUNT(o.order_id) AS orders_2026 FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id WHERE o.order_date >= '2026-01-01' GROUP BY c.customer_id; ما السبب وما التعديل الصحيح؟

اختر إجابتك لتبدأ الاختبار

كل الأسئلة مع الإجابات (١٢ سؤالاً)

جرّب المقابلة أولاً، ثم افتح الإجابات لتراجعها مع الشرح.

  1. ١. طلب منك مدير المبيعات قائمة بكل العملاء وعدد طلبات كل منهم منذ بداية 2026، على أن يظهر من لم يطلب شيئاً بعدد صفر. كتبت الاستعلام التالي فاختفى هؤلاء العملاء من النتيجة تماماً: SELECT c.customer_id, COUNT(o.order_id) AS orders_2026 FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id WHERE o.order_date >= '2026-01-01' GROUP BY c.customer_id; ما السبب وما التعديل الصحيح؟

    • شرط WHERE يستبعد الصفوف التي قيمة order_date فيها NULL بعد الربط، والحل نقل الشرط إلى عبارة ON.
    • يجب استخدام RIGHT JOIN بدلاً من LEFT JOIN حتى يحتفظ الاستعلام بكل صفوف جدول العملاء.
    • الدالة COUNT(o.order_id) تتجاهل العملاء الذين ليست لهم طلبات، والحل استخدام COUNT(*) بدلاً منها مع إبقاء بقية الاستعلام كما هو.
    • السبب ترتيب الجدولين، والحل أن يبدأ الاستعلام بجدول orders ثم يُربط به جدول customers بعبارة LEFT JOIN.

    الشرح: بعد LEFT JOIN تكون قيمة o.order_date للعملاء بلا طلبات NULL، والمقارنة معها لا تتحقق فيحذفهم WHERE ويتحول الربط عملياً إلى INNER JOIN. أما وضع الشرط في ON فيقيّد الطلبات المربوطة وحدها ويُبقي كل العملاء فيعطي COUNT(o.order_id) صفراً لمن لا طلبات له، ويخطئ كثيرون لظنهم أن موضع الشرط لا يغيّر النتيجة.

  2. ٢. في جدول sales عدة عمليات بيع في اليوم الواحد، والعمود sale_date من نوع DATE. كتبت الاستعلام التالي لحساب رصيد تراكمي يزيد مع كل عملية: SELECT sale_id, sale_date, amount, SUM(amount) OVER (ORDER BY sale_date) AS running_total FROM sales; فوجدت أن كل عمليات اليوم الواحد تحمل الرصيد نفسه، وهو الرصيد في نهاية ذلك اليوم. ما السبب وما الحل؟

    • دالة SUM لا تحسب المجاميع التراكمية بدقة، والحل ترقيم العمليات بـ ROW_NUMBER() ثم جمعها في استعلام خارجي.
    • يجب إضافة PARTITION BY sale_date إلى النافذة حتى يُحسب الرصيد لكل عملية على حدة داخل يومها بدلاً من حسابه لليوم كاملاً دفعة واحدة.
    • تكرار التاريخ هو السبب، والحل تجميع العمليات أولاً بـ GROUP BY sale_date ثم حساب الرصيد التراكمي على مجاميع الأيام.
    • الإطار الافتراضي RANGE يضم كل الصفوف المتساوية في التاريخ، والحل استخدام إطار ROWS وإضافة sale_id إلى ORDER BY.

    الشرح: عند كتابة ORDER BY دون إطار صريح يكون الإطار RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW، وهو يضم كل الصفوف المساوية للصف الحالي في قيمة الترتيب، فتأخذ عمليات اليوم الواحد مجموع اليوم كله. يغفل كثيرون عن هذا الإطار الافتراضي، والحل إطار ROWS مع مفتاح ترتيب فريد مثل sale_id حتى يكون الناتج محدداً لا يتغير بين تشغيل وآخر.

  3. ٣. بنيت جدولاً محورياً PivotTable على بيانات مبيعات فيها عمودا Price وQuantity لكل عملية، ثم أضفت حقلاً محسوباً Calculated Field بالصيغة =Price*Quantity لعرض إيراد كل فرع، فظهرت أرقام أكبر بكثير من الإيراد الفعلي. ما السبب وما الحل الأنسب؟

    • تتكرر أسماء الفروع في البيانات المصدر فيُحسب كل فرع أكثر من مرة، والحل حذف الصفوف المكررة قبل إنشاء الجدول.
    • الحقل المحسوب يضرب مجموع Price في مجموع Quantity لكل فرع لا صفاً صفاً، والحل إضافة عمود للإيراد في البيانات المصدر وجمعه.
    • الجدول المحوري لم يُحدَّث بعد إضافة الحقل المحسوب، والحل الضغط على Refresh ليُعاد حساب الإيراد من جديد لكل فرع اعتماداً على البيانات الحالية في المصدر.
    • الحقل المحسوب لا يقبل ضرب حقلين مباشرة، والحل كتابة الصيغة =SUM(Price)*SUM(Quantity) بدلاً من الصيغة الحالية.

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

  4. ٤. فتحت مباشرة في Excel ملف CSV يحتوي على 2.5 مليون صف من سجلات المعاملات، فجاء مجموع المبيعات أقل بكثير من المجموع في النظام المصدر. ما السبب الأرجح وما الحل الأنسب إن أردت مواصلة التحليل في Excel؟

    • يحوّل Excel الأرقام في ملفات CSV الكبيرة إلى نصوص فتُستبعد من الجمع، والحل تحويل عمود المبيعات إلى أرقام بالأداة Text to Columns ثم إعادة الجمع.
    • دالة SUM لا تجمع أكثر من مليون خلية في المرة الواحدة، والحل تقسيم العمود إلى نطاقات وجمع نتائجها بدالة SUMPRODUCT.
    • يحذف Excel الصفوف المكررة تلقائياً عند فتح الملفات الكبيرة، والحل تعطيل هذا الخيار من إعدادات الاستيراد ثم فتح الملف من جديد.
    • الورقة الواحدة تتسع لـ 1,048,576 صفاً فقط فلم يُحمَّل باقي الملف، والحل تحميله عبر Power Query إلى نموذج البيانات Data Model.

    الشرح: تتسع ورقة Excel لـ 1,048,576 صفاً كحد أقصى، فيُقتطع ما بعدها عند الفتح المباشر مع رسالة تحذير يتجاهلها كثيرون. أما Power Query فيحمّل البيانات إلى نموذج البيانات Data Model الذي لا يخضع لهذا الحد، فيمكن تحليلها بجدول محوري دون فقد أي صف.

  5. ٥. تتابع المئين التسعين P90 لزمن تحميل صفحات التطبيق، ولديك قيمته لكل يوم من أيام الشهر الثلاثين، وتختلف أعداد القياسات من يوم لآخر. طلبت الإدارة قيمة P90 للشهر كله. ما الطريقة الصحيحة؟

    • حساب المتوسط المرجح للقيم اليومية بعدد القياسات في كل يوم، لأن الترجيح يعالج اختلاف حجم البيانات بين الأيام.
    • حساب متوسط القيم اليومية الثلاثين، لأن كل يوم يمثل جزءاً متساوياً من الشهر ولا يصح تفضيل يوم على آخر.
    • حساب P90 من جميع القياسات الخام للشهر دفعة واحدة، لأن المئينات اليومية لا تُجمَّع بالمتوسط.
    • اعتماد أعلى قيمة يومية للمؤشر خلال الشهر، لأن P90 يركز أصلاً على أسوأ تجارب المستخدمين.

    الشرح: المئين لا يُجمَّع بالمتوسط، فمتوسط مئينات الأيام، ولو كان مرجحاً بعدد القياسات، لا يساوي عموماً مئين الشهر الذي يعتمد على توزيع كل القياسات معاً. يخطئ كثيرون لأنهم يعاملونه كالمجموع أو العدد، والحل الحساب من البيانات الخام أو من بنية تقريبية مخصصة مثل t-digest.

  6. ٦. اختارت إدارة العمليات أضعف 20 فرعاً في رضا العملاء خلال الربع الماضي وألحقت موظفيها ببرنامج تدريبي، فارتفع متوسط رضا هذه الفروع 12% في الربع التالي. يريد الرئيس التنفيذي تعميم البرنامج على كل الفروع بناءً على هذه النتيجة. ما أهم ملاحظة تقدمها له؟

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

    الشرح: الفروع التي اختيرت لأنها سجلت أدنى القيم كان ضعف بعضها عارضاً، فتعود قيمها نحو المتوسط في الربع التالي حتى دون أي تدخل، وهو ما يُعرف بالارتداد نحو المتوسط Regression to the Mean. لذلك لا يتبين أثر التدريب إلا بالمقارنة مع مجموعة ضابطة من فروع ضعيفة مماثلة، ويغفل كثيرون عن ذلك فينسبون التحسن كله إلى البرنامج.

  7. ٧. أعدّ محلل في فريقك خريطة ملونة Choropleth Map تُظهر عدد شكاوى العملاء في كل منطقة، فظهرت الرياض بأغمق لون، فاستنتج مدير الجودة أنها الأسوأ خدمة. ما أهم تعديل قبل اعتماد الخريطة في لوحة المعلومات؟

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

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

  8. ٨. في اليوم العاشر من الشهر، تعرض بطاقة مؤشر KPI Card في لوحة المعلومات أن المبيعات أقل 68% من الشهر الماضي، فاتصل بك نائب الرئيس قلقاً. تبيّن أن البطاقة تقارن المبيعات منذ بداية الشهر MTD بإجمالي الشهر السابق كاملاً. ما التصميم الصحيح للمقارنة؟

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

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

  9. ٩. يخزّن نظام الطلبات وقت كل طلب بالتوقيت العالمي UTC، وتحسب لوحة المعلومات مبيعات كل يوم بأخذ الجزء التاريخي من هذا الوقت مباشرة. يشتكي فريق المبيعات في الرياض (UTC+3) من أن أرقام الأيام في اللوحة لا تطابق تقارير الفروع. ما السبب وما الحل؟

    • طلبات ما بين التاسعة مساءً ومنتصف الليل بتوقيت الرياض تُنسب إلى اليوم التالي، والحل إضافة ثلاث ساعات إلى التاريخ بعد استخراجه من الوقت.
    • طلبات ما بين منتصف الليل والثالثة فجراً بتوقيت الرياض تُنسب إلى اليوم السابق، والحل تحويل الوقت إلى توقيت الرياض قبل استخراج التاريخ.
    • قاعدة البيانات تقرّب الأوقات إلى أقرب ساعة فتنتقل بعض الطلبات بين الأيام، والحل تخزين وقت الطلب بدقة الثواني بدلاً من الساعات كما هو الآن.
    • الفروع تُدخل بعض الطلبات يدوياً بعد وقوعها بساعات، والحل الاعتماد على تقارير الفروع وحدها مصدراً رسمياً لأرقام المبيعات اليومية.

    الشرح: منتصف الليل في الرياض يوافق التاسعة مساءً بتوقيت UTC من اليوم السابق، فكل طلب بين 00:00 و03:00 محلياً يحمل تاريخ اليوم السابق إذا استُخرج التاريخ قبل التحويل. يغفل كثيرون عن ذلك لأن الفرق يقتصر على ساعات قليلة، والصواب تحويل الوقت إلى Asia/Riyadh أولاً ثم التجميع حسب اليوم.

  10. ١٠. في استبيان شمل 10,000 عميل، 30% من قيم الدخل الشهري فارغة، وتبيّن من بيانات أخرى أن أغلب من تركوا الحقل فارغاً من أصحاب الدخل المرتفع. اقترح زميلك ملء الفراغات بمتوسط الدخل المحسوب من بقية العملاء. ما المشكلة الأساسية في هذا الاقتراح؟

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

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

  11. ١١. اعتمدت إدارة مركز الاتصال متوسط مدة المكالمة Average Handle Time مؤشراً رئيسياً لتقييم الموظفين. بعد شهرين انخفض المؤشر 25%، لكن ارتفعت بوضوح المكالمات المتكررة من العملاء أنفسهم للمشكلة نفسها. بصفتك قائد فريق التحليل، ما أفضل توصية؟

    • رفع المستهدف وطلب انخفاض إضافي في متوسط مدة المكالمة بنسبة 10% في الربع القادم، للبناء على التحسن الذي تحقق.
    • الإبقاء على المؤشر كما هو، لأن انخفاض مدة المكالمة بنسبة 25% دليل واضح على تحسن كفاءة الموظفين، أما المكالمات المتكررة فمشكلة منفصلة.
    • استبدال المؤشر بعدد المكالمات التي يجيب عنها كل موظف يومياً، لأنه أسهل في القياس وأصعب في التلاعب من متوسط مدة المكالمة.
    • إضافة مؤشرات موازنة مثل نسبة الحل من أول اتصال First Contact Resolution ورضا العملاء إلى تقييم الموظفين.

    الشرح: حين يصبح مؤشر واحد أساس المكافأة يحسّنه الناس على حساب الهدف الحقيقي، وهو ما يُعرف بقانون غودهارت Goodhart's Law، فيُنهي الموظفون المكالمات سريعاً ويعود العملاء للاتصال. المؤشرات الموازنة تكشف هذا السلوك، ويخطئ من يرى انخفاض المدة نجاحاً لأنه يتجاهل جودة الحل.

  12. ١٢. في اجتماع مجلس الإدارة عرض قسم التسويق أن عدد المستخدمين النشطين في سبتمبر 120 ألفاً، بينما عرض قسم المنتج 85 ألفاً للشهر نفسه، وطلب منك الرئيس التنفيذي حسم الخلاف. ما أفضل تصرف بصفتك قائد فريق البيانات؟

    • اعتماد رقم قسم المنتج، لأنه مأخوذ مباشرة من قاعدة بيانات التطبيق، وأرقام التسويق تعتمد عادة على أدوات تتبع خارجية أقل دقة بكثير.
    • عرض متوسط الرقمين، أي 102,500 مستخدم، رقماً رسمياً مؤقتاً في تقارير مجلس الإدارة إلى أن تتضح الصورة وتنتهي المراجعة.
    • تحديد الفرق في تعريف «المستخدم النشط» ومصدر بيانات كل قسم، ثم الاتفاق معهما على تعريف موحد موثق تعتمده كل التقارير.
    • الإبقاء على الرقمين في التقارير كما هما، مع حاشية توضح أن كل قسم يحسب المستخدمين النشطين بطريقته الخاصة ولكل منهما مبرراته.

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

مقابلات أخرى: محلل بيانات

المزيد