ما تختبره مقابلات مهندس البيانات فعلياً

من يكون في الغرفة فعلياً

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

الشركات الصغيرة غالباً تدمج كل شيء في جولتين: جلسة تقنية مباشرة ومحادثة مع مَن يمتلك منصة البيانات. الشركات الكبرى تقسّمها إلى فحص SQL/Python، جولة تصميم نظام أو خط بيانات، وجولة قيم أو تعامل مع أصحاب المصلحة مع شخص من الفريق الذي ستُزوّده بالبيانات — غالباً محلل أو مدير منتج، وهي الجولة التي يستعد لها المرشحون أقل لأنها تبدو حديث عابر وليست كذلك.

فحص SQL وPython

نادراً ما يكون هذا أسئلة تافهة. ستحصل على schema — غالباً شيء مثل طلبات، عملاء، أحداث — وسيُطلب منك كتابة استعلام باستخدام دوال النوافذ: المجاميع المتحركة، الترتيب داخل القسم، self-join لإيجاد الفجوات أو التداخلات في نطاقات التواريخ. النقطة ليست الصياغة، بل هل تصل للأداة الصحيحة دون أن يُرشدك أحد إليها. مرشح يحل "ابحث عن أول وثاني عملية شراء لكل عميل" باستعلام فرعي مترابط بينما LAG() تفي بالغرض بشكل أنظف يخبر المُقابل شيئاً عن كيف سيكتب SQL الإنتاج تحت ضغط الوقت.

في جانب Python، توقع معالجة بيانات مع pandas أو Python العادية — إزالة التكرار من مجموعة بيانات فوضوية، تحليل JSON مشوه، التعامل مع nulls تعني أشياء مختلفة في أعمدة مختلفة. بشكل متزايد سيُطلب منك التفكير في وظيفة Spark: لماذا تحويل بطيء، أين يحدث shuffle، هل إعادة التقسيم قبل join ستساعد. إذا كنت شغّلت Spark فقط عبر منصة مُدارة مثل Databricks ولم تضطر أبداً لشرح لماذا انسكبت وظيفة على القرص، هنا يظهر ذلك.

كيف تبدو الإجابة السطحية هنا: تلاوة أن الفهارس "تسرّع الاستعلامات" دون القدرة على قول ماذا يحدث لأداء الكتابة، أو شرح صياغة دالة نافذة بشكل صحيح لكن عدم القدرة على قول متى تستخدم ROW_NUMBER() على RANK() وما ينكسر إذا أخطأت على جدول بمفاتيح مكررة.

جولة تصميم خط البيانات أو النظام

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

المُقابل يستمع لمجموعة صغيرة من الأشياء، وتظهر في كل نسخة تقريباً من هذا السؤال:

• Idempotency. هل يمكن إعادة تشغيل خط البيانات على نفس البيانات دون إنتاج تكرارات أو مجاميع مضاعفة؟ إذا لم تذكر إجابتك كيف ستتعامل مع وظيفة تفشل في منتصف الطريق وتُعاد، هذه فجوة سيستكشفونها.
• تطور schema. ماذا يحدث عندما يضيف نظام مصدر عموداً، أو يغيّر نوعاً من int إلى string؟ هل تفشل بصوت عال، أم تُفسد الجداول النهائية بصمت؟ ذكر schema registry، أو كيف ستكتشف اختبارات dbt أو Great Expectations هذا، يشير أنك احترقت به من قبل.
• دفعات مقابل تدفق، ولماذا. ليس "التدفق أفضل" — هذه الإجابة السطحية. الإجابة الحقيقية تشرح المقايضة: Kafka أو Kinesis يمنحك زمن انتقال منخفض وتعقيد تملكه الآن، مقابل وظيفة دفعات مجدولة في Airflow أو Dagster أبسط للفهم والتصحيح لكن تعني بيانات قديمة طوال مدة الجدولة.
• التقسيم والتكلفة. إذا صممت جدولاً دون قول كيف ستقسّمه — حسب التاريخ عادة، في مستودع مثل BigQuery أو Snowflake — ودون إقرار أن فحص جدول كامل على جدول حقائق متعدد التيرابايت يكلف مالاً حقيقياً، المُقابل يلاحظ الإغفال حتى لو لم يقل ذلك.
• الأبعاد البطيئة التغيير. إذا كان السيناريو يشمل بُعداً يتغير بمرور الوقت (عنوان عميل، فئة منتج)، هل تكتب فوقه، أم تنسّخه بشيء مثل SCD Type 2؟ الخطأ في هذا لا يُفشلك تماماً، لكن عدم معرفة المصطلح عندما يقول المُقابل "كيف ستتعامل مع عميل يغيّر منطقة" علامة.

الإجابة السطحية على سؤال تصميم تبدو متمكنة من الأدوات وصامتة عن الفشل. "سأستخدم Airflow لتنظيمه وإيداعه في Snowflake" جملة بلا هندسة فيها — تسمي المزوّد وتتخطى القرار. إجابة قوية تقول لماذا: لماذا هذا المنسّق يتعامل مع الملء الخلفي بالطريقة التي تحتاجها، لماذا مفاتيح التجميع لهذا المستودع مهمة لنمط الاستعلام الذي يُجريه المحللون فعلاً.

الأسئلة التي تبدو حديث عابر

"أخبرني عن مرة انكسر فيها خط بيانات بنيته في الإنتاج" ليس كسر جليد. عادة هو السؤال الأكثر تشخيصاً في العملية كلها، لأن الإجابة السطحية تعطيك العرض ("لوحة البيانات كانت تُظهر أرقاماً خاطئة") والإجابة الحقيقية تعطيك الآلية: أي مراقبة أو نقصها عنى أنك اكتشفت من صاحب مصلحة بدلاً من تنبيه، ما كان السبب الجذري — ملف متأخر، خطأ منطقة زمنية، تغيير schema علوي لم يخبرك به أحد — وما غيّرته بعدها حتى لا يحدث بنفس الطريقة مرتين.

بالمثل، "كيف تقرر ما تختبره في خط بيانات" يُسأل لرؤية ما إذا كنت تكتب فحوصات جودة بيانات كعادة — عدّ صفوف، عتبات null، سلامة مرجعية بين جدول حقائق وأبعاده — أم أن الاختبار شيء تفعله بعد حادث لأن شخصاً أخبرك. ذكر ممارسة محددة، مثل التأكيد أن مفتاح أجنبي في جدول حقائق دائماً يحل إلى صف في البُعد، يهبط أفضل من قول "أكتب اختبارات لخطوط بياناتي"، الذي يمكن أن يصف أي وظيفة بكلمة pipeline فيها.

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

ما يفضح من لم يفعل العمل

المُقابلون في هذا المجال يلاحظون نمطاً محدداً: طلاقة في أسماء الأدوات ولا آراء عن حدودها. من شغّل dbt في الإنتاج فعلاً يستطيع إخبارك أين يقصر إطار الاختبار وما يضعه فوقه. من شغّل Airflow فعلاً يستطيع إخبارك ما ينكسر عندما يكون لدى DAG مهام ديناميكية كثيرة جداً، أو لماذا نقل تحويلاً ثقيلاً خارج PythonOperator إلى المستودع نفسه. إذا كل إجابة تسمي أداة وتتوقف هناك، هذه الإجابة السطحية، ومن يوظفون مهندسي بيانات سمعوا مئات منها.

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

ما تفعله تالياً

قبل مقابلتك التالية، اختر خطي بيانات بنيتهما فعلاً وكن مستعداً لوصف، بمصطلحات محددة: كيف ستعيد تشغيلهما بأمان بعد فشل جزئي، ماذا سيحدث إذا تغيّر schema المصدر تحتك، وحادث واحد حيث انكسر وما غيّرته بعدها. تدرّب على قول المقايضة، ليس فقط الأداة — دفعات مقابل تدفق، منزوع الطبيعية مقابل مطبّع، منسّق A مقابل منسّق B — لأن هذا شكل الجملة الذي يستمع له المُقابل.

إذا كانت المشكلة الأصعب الآن هي الوصول لتلك المقابلة أصلاً — إعلانات تطلب خبرة مستودع أو تنسيق محددة لديك بشكل مختلف، وطلبات تصمت — jobmarket.pro يقرأ الإعلان كاملاً، يطابقه مع خبرتك الفعلية، ويعد الطلب من ذلك بدلاً من قالب عام.