أرهم كيف تفكر: التحضير لمقابلة تصميم الأنظمة
1. مقدمة
لن أعلمك تصميم الأنظمة. الإنترنت مليء بذلك. هذا المقال يتحدث عن الـ 90 دقيقة التي يجب أن تُظهر فيها كيف تفكر.
لقد خضت بضع مقابلات لتصميم الأنظمة مؤخرًا. مقابلات حقيقية، مع شركات حقيقية، والشيء الذي حدد مسار كل جلسة لم يكن عدد أنماط المعمارية التي أحفظها. بل كان ما إذا كنت قادراً على إظهار طريقة تفكيري المنطقي، وحلي للمشكلات، وقدرتي على التعاون، بطريقة منظمة.
هذه هي الفكرة بأكملها. المقابلة ليست اختباراً قصيراً. إنها استعراض عملي.
ملاحظة حول نطاق المقال قبل أن نبدأ. أنت لا تزال بحاجة إلى الأساس التقني. التخزين المؤقت (Caching)، التقسيم (Partitioning)، الطوابير (Queues)، نماذج التناسق (Consistency models)، كلها. أنا لا أدعي أنه يمكنك تجاوز غياب الأساسيات بأسلوبك فقط. يخبرك القسم 2 بالضبط من أين سأبني هذا الأساس. يغطي هذا المقال الطبقة التي تتخطاها معظم التحضيرات: كيف تُظهر أفضل ما لديك بمجرد وجود الأساس.
2. التحضير
كان وضعي عبارة عن تنشيط للمعلومات، وليس بداية من الصفر. لذلك، كان هناك مصدران يحملان التحضير بأكمله: أدلة ByteByteGo و Tech Interview Handbook. لقد راجعتها لإيقاظ المعرفة التي كانت موجودة بالفعل، نائمة تحت سنوات من العمل اليومي.
المحاولة الأولى هي الأصعب. أنت تنشط ذاكرتك، وتسترجع المفاهيم من التخزين، وقد استغرق مني ذلك حوالي أسبوعين. خطط لذلك. ليس مجرد عطلة نهاية أسبوع. أسبوعان من الجهد الصادق قبل المقابلة الأولى، وكل محاولة بعد ذلك تصبح أسهل.
لو كنت أبدأ من الصفر بدلاً من ذلك، لقمت بقراءة بعض الكتب، بهذا الترتيب من حيث الفائدة للمقابلات: Cracking the Coding Interview، ثم Grokking Algorithms، ثم System Design Interview لـ Alex Xu، وأخيراً Designing Data-Intensive Applications. الكتابان الأولان يعيدان بناء قاعدتك الخوارزمية. يعطيك Alex Xu الرؤية المصممة خصيصاً لمقابلات الأنظمة. أما DDIA فيمنحك العمق الذي يصمد أمام أسئلة المتابعة المعمقة.
اقرأها. ثم عُد إلى هنا، لأن الكتب لن تعلمك ما سيأتي بعد ذلك.
3. الركيزة الأولى: السلوك
أنا أحضّر للسلوك قبل أن أحضّر للمعمارية. هذا الترتيب متعمد.
الانطباع المستهدف هو الحزم، والوضوح، والإيجاز. ليس الغرور. وهنا الجزء الذي فاجأني: كونك ودوداً بشكل مفرط يُقرأ على أنه انعدام للثقة. هناك خط فاصل بين الدفء والرغبة في الإرضاء، والمُحاور يشعر بالضبط أين تقف على هذا الخط.
بقية ركيزة السلوك يسهل قولها ويصعب فعلها تحت الضغط. ابتسم. أظهر الحماس للمشكلة. اطرح أسئلة توضيحية قبل أن تلمس السبورة. تعاون طوال الوقت.
السلوك الوحيد الأكثر فائدة الذي تدربت عليه هو التحدث بصوت عالٍ عندما أعلق. ليس التظاهر بالثقة، بل مجرد السرد بصدق: "لست متأكداً هنا. أفكر في الذهاب إلى س، أو ص، أو ع. ما رأيك؟" هذه الجملة الواحدة تحول الصمت القاتل إلى تعاون. الصمت هو الشيء الذي يقتلك في تلك الغرفة، وهذا هو الترياق.
واختتمها جيداً. أنهِ الجلسة بملاحظة إيجابية حقيقية، شيء مثل "كان هذا نقاشاً جيداً". آخر ثلاثين ثانية تلون كيف يتم تذكر الـ 90 دقيقة بأكملها.
4. الركيزة الثانية: الخطوات
عندما تُطرح المشكلة على الطاولة، أمشي في نفس الخطوات الأربع، في كل مرة.
التخطيط يأتي أولاً. الميزات، المتطلبات غير الوظيفية، المقايضات (Tradeoffs)، وحالات الحافة (Edge cases). هنا تحدد نطاق المشكلة بصوت عالٍ وتتفق مع المحاور على ما تبنيه فعلياً. أشارك الخطة قبل تنفيذها، وأتحقق من الموافقة قبل المضي قدماً. المقابلة هي نشاط لشخصين. المضي قدماً دون توافق هو تصميم بمفردك، والتصميم بمفردك في تلك الغرفة هو شكل من أشكال الفشل، وليس استعراضاً للقوة.
ثم المعمارية عالية المستوى. المربعات الكبيرة والأسهم بينها. أبقِ الأمر واقعياً وامضِ قدماً.
ثم ركز (Zoom in). اختر الأجزاء التي تحمل المخاطر وتعمق فيها، مفكراً بصوت عالٍ طوال الوقت.
ثم اختتم وراجع. راجع التصميم مرة أخرى، واذكر ما ستقوم بتحسينه إن كان لديك المزيد من الوقت، واهبط بالطائرة بأمان.
نصيحة عملية لا يذكرها أحد: السبورة نفسها تهم. إذا أتيح لك اختيار الأداة، فاختر Excalidraw. إنها لا تعيقك، وتبدو نظيفة دون جهد، وتسمح لك بالرسم بسرعة المحادثة.
5. وقفة سريعة
إذا كنت قد جلست في إحدى هذه الغرف، على أي من جانبي الطاولة، فأنت تعرف بالفعل كم أن الكثير من هذا لا يُكتب أبداً. أنا أنشر ما أتعلمه من بناء الأنظمة وإجراء المقابلات، بما في ذلك التكاليف الحقيقية والإخفاقات الحقيقية. تابعني إذا كان ذلك مفيداً لك.
6. الركيزة الثالثة: المقايضات (Tradeoffs)
المقايضات هي حيث يفصل المحاورون بين التفكير المنطقي والحفظ. تتكرر الأسئلة في مختلف الشركات، لذا حضّر تفكيرك حول هذه الثلاثة مسبقاً.
القابلية للتوسع (Scalability). عندما يزداد الحمل، فإن أدواتي هي التكرار (Redundancy)، والتقسيم (Partitioning)، والانتقال إلى العمليات غير المتزامنة (Async). الهدف ليس تسمية الأدوات. الهدف هو شرح أي منها يحتاجه هذا النظام ولماذا.
التناسق (Consistency). قوي (Strong) أو نهائي (Eventual). اختر بناءً على حالة الاستخدام، بصوت عالٍ، مع وضع تكلفة كل خيار على الطاولة.
أسلوب التواصل. متزامن (Synchronous) مقابل غير متزامن (Asynchronous)، طلب-استجابة (Request-response) مقابل مبني على الأحداث (Event-based). كل واحد منها هو التزام له عواقب، والمحاور يريد أن يسمعك وأنت توازن بينها.
في كل هذه الثلاثة، هناك قاعدة واحدة: البساطة مفضلة على الهندسة المفرطة (Over-engineering). اتبع أفضل الممارسات، وقاوم الرغبة في تزيين التصميم بتكنولوجيا لا يحتاجها. يذكر المحاورون أن هذا النمط بالذات يُعتبر إشارة سلبية: المرشحون الذين يلجأون إلى Kafka بشكل تلقائي، أو يضعون Redis في المخطط دون ربطه بمشكلة في زمن الوصول (Latency). التصميم الممل الذي يمكنك الدفاع عنه يتفوق على التصميم المبهر الذي لا تستطيع الدفاع عنه.
7. ما الذي يفشل في الغرفة
لقد أخبرتك بما ينجح. إليك ما لا ينجح، ولاحظ أن كل عنصر هو عكس سلوك معين، وليس قطعة مفقودة من المعرفة.
الانجراف الفردي. تتجه نحو السبورة وتصمم بمفردك لمدة عشر دقائق. يصبح المحاور جمهوراً بدلاً من متعاون، وتفقد السيطرة على الغرفة.
المضي قدماً دون موافقة. تنهي الخطة وتنطلق مسرعاً دون التحقق من التوافق. الآن يقوم المحاور بتقييم تصميم لم يوافق أبداً على تحديد نطاقه.
مقايضات سيئة. اختيارات تُتخذ بشكل تلقائي (Autopilot)، دون أي صلة بالمتطلبات التي جمعتها أثناء التخطيط.
غياب التواصل. الصمت عندما تصبح الأمور صعبة. هذا هو الفشل الذي أجده الأكثر إنسانية والأكثر قابلية للتجنب، لأن حله جملة صادقة واحدة: أنا لست متأكداً، هذه هي خياراتي، ما رأيك؟
النمط وراء الأربعة هو نفسه. يفشل المهندسون الأقوياء في هذه المقابلات على الرغم من اقتراحهم لتصميمات معقولة تقنياً، لأن الجلسة كانت تقيس إشارات لم يكونوا يرسلونها.
8. أليس هذا مجرد تدريب على الأداء؟
هناك اعتراضان يستحقان قسماً خاصاً بهما، لأنني كنت سأثيرهما بنفسي.
الأول: إذا اتبع الجميع نفس الخطوات المنظمة، ألا تصبح الهيكلة هي النص الجديد المحفوظ؟ إجابتي هي العكس. إذا استخدم كل مرشح هذه الهيكلة، فسوف يمنحهم ذلك فرصة عادلة ومتساوية لإظهار تفكيرهم، بدلاً من أن يعيقهم التنسيق نفسه. الهيكلة ليست أداءً تمثيلياً. إنها الأرضية المستوية التي تسمح لتفكيرك الفعلي بأن يصبح مرئياً. النص المحفوظ يخبرك بما يجب أن تقوله. أما الهيكلة فتخبرك فقط بمتى يُسمح لك بقوله.
الثاني: الابتسامة، الحماس، الأجواء الإيجابية. قد يقول شخص متشكك أن هذا يكافئ الكاريزما ويعاقب المهندسين الهادئين. أنا أرى الأمر بشكل مختلف. أنت ستتعاون مع هذا الفريق. يجب أن تُظهر لهم الجلسة أنك لست الذئب الوحيد، وأنك قادر على التواصل، وأن الناس سيشعرون بالراحة في التعامل معك. هذه ليست كاريزما. هذا دليل على طبيعة العمل اليومي معاً، يتم جمعه بالطريقة الوحيدة التي يمكن للمقابلة جمعها بها.
كلا الاعتراضين يشتركان في افتراض أن الإشارة التقنية والإشارة البشرية تتنافسان. في جلسة مدتها 90 دقيقة، هما نفس الإشارة. التفكير المنطقي يصل من خلال التواصل أو لا يصل على الإطلاق.
9. لن تكون مستعداً تماماً أبداً
إليك النهاية الصادقة. لن تكون مستعداً تماماً أبداً، لأن التحدي يتغير ويصعب التنبؤ به.
تطلب منك المقابلة التفكير بصوت عالٍ بينما يراقبك الغرباء وأنت تحلل الأمور. هذا أمر غير مريح. وسيظل غير مريح. التعود على هذا الشعور بعدم الراحة ليس تأثيراً جانبياً للتحضير، بل هو التحضير نفسه.
ما زلت أعمل على هذا الجزء بنفسي. الركائز تصمد، والخطوات تصمد، ويظهر الشعور بعدم الراحة على أي حال، في كل مرة. ربما يكون هذا هو الاختبار الحقيقي، وربما يكون ذلك لا بأس به.
10. المراجع
- أدلة ByteByteGo، "Guides"، bytebytego.com/guides، تم الوصول في يونيو 2026. المصدر الأساسي لاسترجاع مفاهيم تصميم الأنظمة.
- Tech Interview Handbook، "Software Engineering Interview Guide"، techinterviewhandbook.org، تم الوصول في يونيو 2026. المصدر الأساسي لاسترجاع هيكلة المقابلات والتدريب عليها.
- Gayle Laakmann McDowell، كتاب "Cracking the Coding Interview". موصى به كأساس للبداية من الصفر، والخوارزميات وفن المقابلات.
- Aditya Bhargava، كتاب "Grokking Algorithms". موصى به كأساس للبداية من الصفر، والحدس الخوارزمي.
- Alex Xu، كتاب "System Design Interview". موصى به كأساس للبداية من الصفر، والتفكير في الأنظمة المهيأ للمقابلات.
- Martin Kleppmann، كتاب "Designing Data-Intensive Applications". موصى به كأساس للبداية من الصفر، والعمق الذي يصمد أمام أسئلة المتابعة.
- Engineering Enablement، مقال "How I can usually tell a System Design interview went well"، عبر Substack، مايو 2026. سرد من وجهة نظر المحاور: تسمية التقنيات دون ربطها بالقيود يُعتبر حفظاً وتلقيناً.
- Fahim ul Haq، مقال "The System Design Interview Trap: Why Engineers Fail and How to Succeed"، عبر Medium، يناير 2026. المهندسون الأقوياء يُرفضون بسبب تحسين الإشارات الخاطئة، وليس بسبب التصميمات الضعيفة.