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

معظم المرشحين يستعدون لأسئلة SQL بحفظ القواعد والسينتاكس. هذه مقاربة خاطئة. اللي يبحث عنه المحاورون في شركات البيانات الكبيرة - مثل Stripe وCareem وفرق البيانات في SABIC - مو أنك تعرف تكتب JOIN. يريدون يشوفون كيف تفكر في البيانات وسط الغموض، وكيف تلتقط edge cases قبل ما يطلبونها، وكيف تدافع عن نهجك لما يضغطون عليك.

لو كنت تحل مسائل على LeetCode وحاسس إنك جاهز، ربما ما تكون كذلك. هذا ما تختبره هذه الأسئلة فعلاً.

أسئلة SQL في مقابلات محلل البيانات وعالم البيانات تختبر ثلاثة أشياء: المهارة التقنية (JOINs والتجميع وwindow functions)، وفهم نمذجة البيانات (معرفة grain الجدول والتعامل مع قيم NULL والتفكير في fan-out)، والتواصل تحت الغموض (إعادة صياغة الافتراضات قبل الكتابة والسؤال عن الحالات الاستثنائية). بحسب تحليل DataLemur لأكثر من 200 تقرير مقابلة، تظهر window functions في 40% تقريباً من مسائل SQL في مستوى محلل البيانات المتوسط والمتقدم، لكنها الفئة اللي يستعد لها أغلب المرشحين بشكل أقل من غيرها. أنواع الأسئلة الأكثر شيوعاً: التجميع وGROUP BY، وJOINs متعددة الجداول، وwindow functions مثل ROW_NUMBER وRANK وLAG، ومسائل متعددة الخطوات تستخدم CTEs. للتحضير: أسبوعان للأساسيات، وأسبوع لـ window functions تحديداً، وأسبوع للتدريب المختلط الموقّت. قل افتراضاتك بصوت عالٍ. واعرف SQL dialect الخاص بالشركة التي تتقدم لها، لأن Snowflake وBigQuery وRedshift وPostgres كلها تختلف في السينتاكس.

ما أنواع أسئلة SQL اللي تظهر فعلاً في مقابلات البيانات؟

سؤال SQL في المقابلة هو مسألة query منظّمة تطلب منك استخراج البيانات أو تجميعها أو تحويلها، عادةً تحت ضغط الوقت ومواصفات ناقصة عن قصد. تقع في أربعة أقسام رئيسية: التجميع وتقسيم البيانات، وJOINs وعلاقات الجداول، وwindow functions والاستعلامات التحليلية، والمسائل متعددة الخطوات باستخدام CTEs. معظم المرشحين يشعرون بالراحة مع القسمين الأولين ويعثرون في القسمين الأخيرين.

تظهر window functions في 40% تقريباً من مسائل SQL في المستوى المتوسط والمتقدم، بحسب تحليل DataLemur لأكثر من 200 تقرير مقابلة، لكن معظم المرشحين يخصصون لها أقل من 20% من وقت تحضيرهم.

المواصفات اللي تحصل عليها في المقابلة تكون ناقصة دائماً. جدول اسمه "users" بأعمدة مثل user_id وcreated_at وstatus لا يخبرك إذا كانت user IDs مكررة ممكنة، ولا إذا كانت قيمة status يمكن أن تكون NULL، ولا ما هو grain الجدول. معرفة ما تسأل عنه قبل ما تكتب هي أول كفاءة يتم تقييمها.

ما الأخطاء اللي يقع فيها معظم المرشحين في أسئلة SQL؟

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

النهج الصح هو معاملة كل سؤال SQL كمحادثة قصيرة عن نمذجة البيانات قبل أي كتابة كود.

ابدأ بإعادة صياغة المسألة بلغة البيانات بصوت عالٍ. "يعني أحتاج أجد المستخدمين اللي طلبوا أكثر من 3 مرات في أول 30 يوماً، أفترض إن كل صف هو طلب واحد وإن created_at هو timestamp الطلب مو إنشاء الحساب، صح؟" هذا يكشف الافتراضات قبل ما تكون في منتصف query خاطئة، ويُظهر للمحاور إنك تفكر كمحترف بيانات.

ثلاثة أخطاء محددة تعثر فيها حتى المرشحون ذوو الخبرة:

1. نسيان قيم NULL. COUNT(column) يتجاهل قيم NULL، لكن COUNT(*) يعد كل الصفوف. في سياق المقابلة، قد يحتوي dataset على قيم NULL غير متوقعة. هذا الخطأ وحده يغير إجابتك.
2. استخدام window function في جملة WHERE. WHERE ROW_NUMBER() OVER (...) = 1 يعطي خطأ. الحل هو التضمين في CTE أو subquery، وهو بسيط، لكن نسيانه تحت الضغط يُظهر إنك ما شغّلت هذا الكود في بيئة إنتاج فعلية.
3. الإفراط في الJOINs. لو تجمع 5 جداول لعملية تجميع كان يكفيها جدولان، المحاور يلاحظ مستوى فهمك لنمذجة البيانات مو السينتاكس فقط.

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

كيف يتم اختبار window functions وCTEs فعلاً؟

window functions هي نوع الأسئلة المميّز، مو لأنها صعبة بعد ما تتقنها، بل لأنها تكشف إذا كان تمرينك على SQL أكاديمياً أو حقيقياً.

الاختبار النموذجي لـ window functions: "أوجد الطلب الثاني الأعلى قيمةً لكل عميل."

الجواب الصح يستخدم ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY amount DESC) داخل CTE ثم يفلتر على rn = 2. لو مديت إيدك لـ subquery مع MAX وNOT IN، قد ينجح أحياناً، لكنه يُظهر تفكيراً قديماً. PARTITION BY مع ORDER BY هو ما يجب أن تصله أولاً.

أسئلة CTE تختبر البنية مو السينتاكس فقط. أحياناً يقدّم المحاور مسألة متعددة الخطوات - تحليل cohort أو drop-off في funnel أو معدل retention الشهري - حيث يتطلب الحل الأنظف 3 أو 4 CTEs بأسماء واضحة. الفرق بين من يكتب query طويلاً متشابكاً وبين من يقسّمه لمراحل مقروءة واضحة ظاهر فوراً. الكود القابل للقراءة إشارة على مستوى الإنتاج.

وجد تقرير LinkedIn للقوى العاملة 2024 إن SQL هو المهارة التقنية الأكثر طلباً في وظائف محلل البيانات عالمياً، يظهر في 63% من الإعلانات متفوقاً على Python بنسبة 57%.

أمثلة عملية من ثلاثة مجالات مختلفة

ما يجعل هذه الأمثلة مفيدة هو السؤال السابق للكتابة لا الـ query نفسها - هذا هو النمط الذي يجب استيعابه.

مثال 1 - التجارة الإلكترونية (Careem / Noon)

المحاور: "عندنا جدول orders: order_id, customer_id, driver_id, amount, completed_at. اكتب query لإيجاد أعلى 10% من العملاء إنفاقاً خلال آخر 90 يوماً."

WITH customer_totals AS (
  SELECT customer_id, SUM(amount) AS total_spend
  FROM orders
  WHERE completed_at >= CURRENT_DATE - INTERVAL '90 days'
    AND status = 'completed'
  GROUP BY customer_id
),
ranked AS (
  SELECT *, NTILE(10) OVER (ORDER BY total_spend DESC) AS spending_decile
  FROM customer_totals
)
SELECT * FROM ranked WHERE spending_decile = 1;

المرشح الجيد، قبل الكتابة: "هل الطلبات الملغاة موجودة في هذا الجدول؟ هل أحتاج أفلتر حسب status؟ والـ 90 يوماً نافذة متحركة من اليوم أم من تاريخ محدد؟"

هذا السؤال المسبق هو الإشارة الحقيقية. الـ query نفسها ثانوية بالمقارنة.

مثال 2 - التقنية المالية (Tabby / Tamara)

المحاور: "عندك جدول transactions: user_id, transaction_date, status, amount - أوجد المستخدمين اللي أجروا معاملة ناجحة واحدة على الأقل كل شهر خلال الستة أشهر الماضية."

الفخ: تجميع المستخدمين وعد الصفوف يفوّت الأشهر الفارغة. المنطق الصح هو عد مجموعات شهر-سنة المميزة لكل مستخدم والتحقق من أن العدد يساوي ستة. لكن قبل الكتابة:

المرشح الجيد: "هل تقصد ستة أشهر ميلادية قبل اليوم، أم نافذة متحركة 180 يوماً؟ بنية الـ query ستختلف اختلافاً كبيراً."

مثال 3 - التحليلات المؤسسية (SABIC / أرامكو)

المحاور: "عندك جدول employee_performance. اكتب query تُظهر درجة كل موظف مقارنةً بمتوسط قسمه، مع تحديد من هو أكثر من انحراف معياري واحد أدنى من المتوسط."

الحل يستخدم STDDEV() OVER (PARTITION BY dept_id) وAVG() OVER (PARTITION BY dept_id) كـ window functions، ثم جملة CASE لتحديد المتطرفين. لكن السؤال المميّز:

المرشح الجيد: "هل أستخدم الانحراف المعياري للمجتمع أم للعينة؟ STDDEV بشكل افتراضي للعينة. لو كان هذا مجموع موظفي كل قسم، فـ STDDEV_POP سيكون أدق."

هذا السؤال وحده يُظهر إن المرشح استخدم SQL الإحصائي في بيئة إنتاج حقيقية.

ما الفرق بين الإجابة العادية والإجابة من مستوى senior؟

المرشحون في المستوى المتقدم يعاملون أسئلة SQL كمحادثة عن نمذجة البيانات، مو كتمرين كتابة كود.

الإجابة العادية: query صحيحة على dataset الاختبار، منجزة في الوقت المحدد.

الإجابة من مستوى senior: query صحيحة، بالإضافة لسؤال واحد عن جودة البيانات، وملاحظة واحدة عن الأداء على النطاق الكبير، ونهج بديل مذكور ومرفوض بوضوح.

عملياً، هذه الإضافات تبدو كالتالي:

• "كتبت هذا كـ chain من CTEs لأنه أسهل في القراءة، لكن لو كان هذا الجدول 100 مليون صف ستحتاج تنزّل الفلتر في وقت أبكر لتجنب materialization كامل البيانات."
• "هذا الـ JOIN يفترض عدم وجود مكررات في جدول العملاء. لو كان فيه مكررات، سيخلق الـ JOIN row fan-out ويتضخم الـ SUM. هل أضيف خطوة deduplication؟"
• "هذا السينتاكس يعمل في Postgres؛ في Snowflake، QUALIFY ستكون أنظف. ما هو SQL dialect الخاص بـ data warehouse عندكم؟"

هذه الأنواع الثلاثة من التعليقات - الوعي بالأداء وفحص جودة البيانات والوعي بـ dialect - تفرق بين المستوى المتوسط والمستوى المتقدم. والخبر الجيد إنك تقدر تتمرن عليها متى ما عرفت إنها موجودة.

SQL مقابل Python: ما اللي يقيسه المحاورون فعلاً؟

بعض المحاورين يسألون مباشرةً: "هل ستفعل هذا بـ SQL أم Python؟" والبعض الآخر يلاحظ ما تمد إيدك له أولاً. في كلتا الحالتين، هذه المقارنة تظهر في مقابلات أدوار البيانات.

اختر SQL حين تتعلق المهمة بتجميع جدول في قاعدة بيانات أو فلترته. اختر Python حين تتعلق المهمة بإعادة تشكيل البيانات أو بناء نماذج أو التكرار التحليلي.

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

كيف تتمرن على SQL لمقابلات البيانات؟

أربعة أسابيع كافية لو كنت منضبطاً.

• الأسبوع الأول: التجميع وGROUP BY وHAVING وJOINs متعددة الجداول. حل 20 مسألة على DataLemur أو Mode Analytics مع توقيت كل واحدة.
• الأسبوع الثاني: Window functions - ROW_NUMBER وRANK وDENSE_RANK وNTILE وLAG وLEAD والمجاميع المتراكمة بـ SUM OVER. ركّز على فهم PARTITION BY قبل ORDER BY.
• الأسبوع الثالث: CTEs والمسائل التحليلية متعددة الخطوات. أعد كتابة 5 على الأقل من queries الأسبوع الأول لتكون أوضح. تمرن على تحليل cohort ومسائل funnel.
• الأسبوع الرابع: تدريب مختلط موقّت. حدّ كل مسألة بـ 25 دقيقة. قل افتراضاتك بصوت عالٍ قبل الكتابة. اكتشف الحالات الاستثنائية بنفسك قبل أن تطلب مساعدة.

الشيء اللي تتجاهله معظم الأدلة: تعلّم SQL dialect الخاص بالشركة قبل المقابلة. جملة QUALIFY في Snowflake، وUNNEST في BigQuery، وLISTAGG في Redshift، وGENERATE_SERIES في Postgres مختلفة بما يكفي لتوقفك في منتصف الإجابة. 15 دقيقة على cheat sheet للـ dialect تستحق الاستثمار.

لو كنت تستعد للتقديم في شركات MENA - Careem أو Tabby أو SABIC أو البنوك الإقليمية - فرق البيانات تعمل عادةً على Snowflake أو BigQuery. جلسات IntervYou التجريبية تتضمن أسئلة SQL من هذه البيئات حتى تتمرن على الـ dialect الحقيقي مو على مسائل Postgres الأكاديمية فقط.

سؤال SQL مو بس اختبار للـ SQL. يختبر كيف تفكر في البيانات وكيف تتعامل مع الغموض وكيف تتواصل مع زملاء تقنيين. هذه العادات تستحق البناء الحقيقي.

ابدأ جلسة تجريبية مجانية ←

مقالات ذات صلة

• اختبار Data Science المنزلي: كيف تتعامل معه وتقدّمه بثقة
• أسئلة مقابلة Data Scientist وكيف تبني إجاباتك
• كيف تتحضر لمقابلة Case Interview في شركات MBB