مقابلة البرمجة الخاصة بك تقيس الشيء الخطأ

تواصلت معي ثلاث شركات بشأن دور مهندس برمجيات أول (Senior IC).

الأولى أرسلت لي تحدي برمجة لبناء تطبيق كامل. الثانية أرسلت رابطًا لاختبار خوارزميات (Leetcode). الثالثة حددت موعدًا لجلسة مباشرة لتصميم الأنظمة. لم يكن هناك كتابة أكواد. لا ألغاز. فقط محادثة حول البنية التحتية، والمفاضلات التقنية (Trade-offs)، والملكية.

شركة واحدة فقط كانت تختبر للوظيفة التي توجد في الواقع. أما الشركتان الأخريان فكانتا تختبران مهارات يمكن لنموذج مثل "كلود" (Claude) اجتيازها في ثوانٍ.

1. المقابلة التي اختبرت الوظيفة الفعلية

طلبوا مني أن أشرح أنظمة قمت ببنائها. لم يسألوا عن الكود بل عن القرارات. لماذا استخدمت بنية الخدمات المصغرة (Microservices) هنا وليس بنية متجانسة (Monolith)؟ ماذا تعطل عندما توسع النظام؟ ماذا تعلمت من آخر حادث (Incident) كنت مسؤولاً عنه؟

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

هذه لم تعد تجربة نادرة. تتوقع "جارتنر" (Gartner) أن 40% من تطبيقات المؤسسات ستتضمن وكلاء ذكاء اصطناعي بحلول نهاية عام 2026، ارتفاعًا من أقل من 5% في عام 2025. يوثق تقرير اتجاهات البرمجة الوكيلة لعام 2026 من "أنثروبيك" (Anthropic) زيادة بمقدار خمسة أضعاف في الفرق التي تدير خمسة أو أكثر من وكلاء البرمجة المتخصصين في وقت واحد. هذا التحول واسع وسريع ويعيد بالفعل تعريف طبيعة عمل مهندس البرمجيات الأول.

2. مراجعة الكود أصبحت أصعب من كتابته

كتابة الكود هي ذاكرة عضلية. يتشكل المنطق في رأسك وتنفذ أصابعك أنماطًا استوعبتها على مدار سنوات.

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

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

اكتشاف هذه الأشياء يتطلب فهمًا أعمق من كتابة الكود بنفسك. مراجعة مخرجات الوكلاء هي أصعب مراجعة كود قمت بها على الإطلاق. يلتقط معيار مقابلات مهندسي البرمجيات لعام 2026 من "Prepfully" هذا التحول: فهم يقيمون الآن "الحكم، حل المشكلات تحت القيود، والتواصل" إلى جانب قدرات البرمجة. التفكير وراء الكود هو الشيء النادر. الكود نفسه رخيص.

3. المهارات التي ستبقى

عندما يكتب الكود نفسه، فإن المهارات التي تنجو هي تلك التي كانت دائمًا الأصعب في التعلم.

حدس تصميم الأنظمة. ليس معرفة الصيغة البرمجية لقفل موزع (Distributed lock)، بل معرفة متى تحتاجه ومتى لا تحتاجه. معرفة أن عنق الزجاجة لن يظهر في مقاييس الأداء (Benchmarks) لأنه يعتمد على نمط وصول في العالم الحقيقي لم يره الوكيل أبدًا.

الملكية. ليس "من كتب هذا الخطأ"، بل من يكتشف حالة الحافة أثناء المراجعة لأنه يعرف المنتج والمستخدم ونمط الفشل من آخر حادث؟

الطلاقة في المفاضلات (Trade-offs). يقوم الوكلاء بسرد الخيارات، لكنهم لا يستطيعون وزنها مقابل فريقك، والجدول الزمني، وتحمل المخاطر، وبنيتك التحتية الحالية. هذا الحكم يعود لك.

الطلاقة في المجال. ليس حفظ قاعدة البيانات (Codebase)، بل معرفة المجال بعمق كافٍ لترجمة احتياجات العمل إلى بنية تحتية. كتابة موجه (Prompt) يلتقط القيد الحقيقي، وليس فقط المطلب المذكور. فحص مخرجات الوكيل واكتشاف أين أساء فهم نموذج المجال. يمكن للوكلاء قراءة كودك، لكنهم لا يستطيعون قراءة أعمالك.

4. للشركات التي لا تزال تجري مقابلات برمجة تقليدية

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

لكن التنسيق معطل. سلسلة تحديات (Leetcode). لغز الخوارزمية تحت ضغط الوقت. التحدي المنزلي الذي يستهلك عطلة نهاية الأسبوع. يمكن لأي مرشح أن يأخذ لقطة شاشة، ويسقطها في "كلود"، ويجتازها في خمس ثوانٍ. أنت تقيس الاستعداد للقفز عبر الحلقات، وليس القدرة على التفكير في الأنظمة.

جرب جلسة مراجعة كود بدلاً من ذلك. أعطهم طلب سحب (PR) حقيقي من قاعدة بياناتك، واحد تم إطلاقه مع خطأ خفي. راقب كيف يقرؤونه. ماذا يسألون؟ ماذا يكتشفون؟ عشرون دقيقة من ذلك تخبرك بأكثر من أي تحدي (Leetcode) متوسط الصعوبة.

أو مناقشة إعادة هيكلة (Refactoring). إليك وحدة (Module) إنتاجية حقيقية. إنها تعمل ولكنها فوضوية. ماذا ستغير؟ من أين ستبدأ؟ أنت تختبر ما إذا كانوا يستطيعون التفكير في نظام، وليس ما إذا كانوا قد حفظوا خوارزميات الفرز.

أو شرح تصميم نظام. ليس "تصميم تويتر". صمم شيئًا ذا صلة بمنتجك. قيود حقيقية، خيارات قواعد بيانات حقيقية، مفاضلات حقيقية. راقب كيف يفكرون.

تغيرت الوظيفة. لكن المقابلة لم تلحق بالركب بعد.

5. ما زلت أكتشفه

التوسع. هل تنجح إدارة الوكلاء مع خمسين مهندسًا؟ خمسمائة؟ لم أجرب ذلك بعد.

المقابلات العادلة. نجحت جلسة تصميم الأنظمة معي. هل هي قابلة للتكرار عبر كل مرشح، وكل مستوى، وكل مجال؟ غير واضح.

الدور نفسه. هل "المهندس الأول الذي يراجع ويطلق المنتجات من خلال الوكلاء" هو الشكل الدائم، أم شكل انتقالي؟ هناك شيء يستقر، ولكنه لم يستقر تمامًا بعد.

واحدة من تلك الشركات الثلاث اختبرت للوظيفة الموجودة بالفعل. الشركتان الأخريان اختبرتا لوظيفة تختفي. هذا التمييز كلفهم مرشحين.

المراجع

1. GitHub، "تقديم Agent HQ"، 4 فبراير 2026. منصة برمجة موحدة متعددة الوكلاء مع حوكمة للمؤسسات.
2. Gartner، "توقعات تبني وكلاء الذكاء الاصطناعي"، 2026. تتوقع أن 40% من تطبيقات المؤسسات ستتضمن وكلاء ذكاء اصطناعي بحلول نهاية عام 2026، ارتفاعًا من أقل من 5% في عام 2025.
3. Anthropic، "تقرير اتجاهات البرمجة الوكيلة لعام 2026"، 2026. يوثق زيادة بمقدار 5 أضعاف في الفرق التي تدير خمسة أو أكثر من وكلاء البرمجة المتخصصين في وقت واحد.
4. Prepfully، "معيار مقابلات مهندسي البرمجيات لعام 2026"، 2026. يشير إلى تحول التقييم نحو الحكم، حل المشكلات تحت القيود، والتواصل.