يا جماعة الخير، السلام عليكم ورحمة الله. اسمي أبو عمر، مبرمج فلسطيني قضيت سنين طويلة من عمري بين الأكواد والخوارزميات، من أيام ما كنا نكتب الكود على شاشات سوداء بخط أخضر، لحد اليوم وعالم الذكاء الاصطناعي اللي صار زي بحر ما إله قرار.
بدي أحكيلكم قصة صارت معي زمان، في بداية مسيرتي المهنية. كنت مقدم على وظيفة في شركة كبيرة، وظيفة كنت أحلم فيها ليل نهار. بعد عدة مراحل، وصلت للمقابلة النهائية: مقابلة الترميز المباشر (Live Coding). دخلت على الاجتماع الافتراضي، قلبي بطق زي “طبلة المسحّر” في رمضان. المُقابِل كان مهندس خبير، هادي ورايق، أعطاني “شير” لشاشة عليها محرر أكواد ومسألة برمجية.
المسألة ما كانت معقدة كثير، إشي بشبه اللي بنحله على مواقع زي LeetCode. قرأتها مرة ومرتين وثلاثة… وفجأة، حسيت كل إشي بعرفه عن البرمجة تبخّر. عقلي صار صفحة بيضا. صمت… صمت رهيب، ما بقطعه غير صوت نقرات أصابعي على الكيبورد وأنا بحاول أكتب أي إشي بس ما في فايدة. كل سطر بكتبه بحسّه غلط، فبمسحه. الدقايق بتمر، وأنا بتصبب عرق، وحاسس بالفرصة بتضيع مني زي الرمل بين الأصابع.
بعد حوالي خمس دقايق من الصمت القاتل، حكى المُقابِل بهدوء: “أبو عمر، كل إشي تمام؟ ممكن تحكيلي عن شو بتفكر؟”. هاي الجملة كانت زي كاسة مي باردة لواحد عطشان في عز الصيف. أخذت نفس عميق، وبديت أحكي بصوت متردد: “والله يا بشمهندس، أنا فاهم إنه المطلوب هو إيجاد… بس علّقت في نقطة… بفكر أبدأ بحل بسيط حتى لو كان بطيء، يمكن باستخدام حلقتين متداخلتين…”.
وبمجرد ما بديت أحكي، حسيت العُقد بدت تنفك. الكلام رتّب أفكاري، والمُقابِل صار يتفاعل معي، يسألني أسئلة توجيهية بسيطة. شوي شوي، قدرت أبني الحل، وبعدين أحسّنه. في نهاية المقابلة، ما كنت كاتب الكود المثالي من أول مرة، لكني كنت شاركت رحلة تفكيري كاملة مع المُقابِل. المفاجأة كانت إني حصلت على عرض العمل. بعدها، حكالي المدير المسؤول عن التوظيف: “أبو عمر، إحنا ما وظفناك عشان حليت المسألة، وظفناك عشان شفنا كيف بتفكر لما تواجه مشكلة”.
هاي القصة علمتني درس من أهم دروس حياتي المهنية، وهو الدرس اللي بدي أشاركه معكم اليوم: قوة “التفكير بصوت عالٍ”.
ليش “التفكير بصوت عالٍ” هو سلاحك السري في المقابلات؟
كتير من المبرمجين الشاطرين، وخصوصاً الانطوائيين منا، بيفكروا إنه المقابلة هي اختبار لكتابة الكود الصحيح وبس. بيقعد صامت، بيكتب الكود في عقله، ولما يجهز، بيكتبه بسرعة. هاي الطريقة كارثية في مقابلة الترميز المباشر، وهاي هي الأسباب:
المُقابِل لا يقرأ الأفكار
بكل بساطة، الشخص اللي بقابلك ما بعرف شو بدور في راسك. الصمت الطويل ممكن يُترجم لعدة أشياء سلبية في نظره:
- “هو مش فاهم السؤال أصلًا.”
- “شكله ما عنده أي فكرة عن كيفية الحل.”
- “هذا الشخص صعب التواصل معه.”
بينما في الحقيقة، ممكن تكون أنت في عقلك بتبني حل عبقري، بتقارن بين الخوارزميات، وبتفكر في الحالات الهامشية (Edge Cases). بس هو ما بشوف كل هاد. هو بشوف شاشة فاضية وشخص صامت.
يُظهر طريقة تفكيرك، وهذا هو الأهم
“الشركات الكبيرة لا توظفك لحل مشكلة واحدة، بل توظفك لقدرتك على حل آلاف المشاكل المستقبلية.”
الهدف الحقيقي للمقابلة هو تقييم “عملية حل المشكلات” عندك. كيف بتحلل المشكلة؟ كيف بتقسمها لأجزاء أصغر؟ كيف بتفكر في الحلول الممكنة؟ كيف بتقارن بينها من ناحية الأداء (Time Complexity) والمساحة (Space Complexity)؟ كل هذا يظهر فقط عندما “تفكر بصوت عالٍ”.
يفتح باب التعاون والمساعدة
لما تشرح طريقة تفكيرك، أنت بتحوّل المقابلة من “امتحان” إلى “جلسة عمل تشاركية”. إذا كنت ماشي في طريق مسدود، المُقابِل ممكن يعطيك تلميح بسيط يرجعك للمسار الصحيح. مثلًا، ممكن يحكي: “فكرتك باستخدام مصفوفة جيدة، بس هل فكرت في بنية بيانات أخرى ممكن تكون أسرع في البحث؟”. هذا التلميح لا يعني أنك فشلت، بل يعني أن المُقابِل مهتم يشوف كيف بتتفاعل مع الملاحظات وكيف بتطور أفكارك.
كيف تتقن فن “التفكير بصوت عالٍ”؟ دليل أبو عمر العملي
طيب يا أبو عمر، كلامك حلو ومقنع، بس كيف أطبق هاد الحكي عمليًا؟ الموضوع بده تدريب، وهاي هي الخطوات اللي بنصح فيها دائمًا.
المرحلة الأولى: استوعب، كرر، واسأل
أول ما تشوف المسألة، لا تقفز مباشرة للحل. ابدأ بالآتي:
- كرر السؤال بكلماتك الخاصة: “تمام، إذا فهمي صحيح، المطلوب مني أكتب دالة (function) تستقبل مصفوفة من الأرقام، وترجع…”. هذا يؤكد للمُقابِل أنك فهمت المطلوب.
- اسأل أسئلة توضيحية: هذا يظهر أنك شخص دقيق ويفكر في التفاصيل.
- “ما هي القيود على حجم المدخلات؟”
- “هل ممكن تكون الأرقام سالبة أو أعداد عشرية؟”
- “ماذا يجب أن أرجع في حال لم يتم العثور على حل؟ هل أرجع
nullأم مصفوفة فارغة؟”
المرحلة الثانية: ابدأ بالحل الساذج (Brute Force)
لا تخف من البدء بالحل الأبطأ أو الأقل كفاءة. هذا طبيعي جدًا ويظهر أنك تبني تفكيرك بشكل تدريجي.
قل شيئًا مثل: “أول فكرة تخطر ببالي هي الحل المباشر (Brute Force). يمكنني استخدام حلقتين متداخلتين (nested loops) للمرور على كل الاحتمالات الممكنة. هذا الحل سيكون تعقيده الزمني O(n²)، وهو ليس مثاليًا، ولكنه نقطة انطلاق جيدة للتأكد من أننا نفهم المشكلة.”
المرحلة الثالثة: حسّن الحل وفاضل بين البدائل
هنا تكمن فرصتك للتألق. بعد طرح الحل الساذج، ابدأ في تحسينه.
“الآن، كيف يمكننا تحسين أداء O(n²)? أعتقد أن المشكلة تكمن في البحث داخل الحلقة الثانية. يمكننا تسريع عملية البحث هذه إذا استخدمنا بنية بيانات أسرع، مثل HashMap أو HashSet. بهذه الطريقة، يمكننا تقليل التعقيد الزمني إلى O(n)، على حساب استخدام ذاكرة إضافية بحجم O(n)، وهذا تبادل (trade-off) مقبول في معظم الحالات.”
المرحلة الرابعة: اكتب الكود مع الشرح المستمر
لا تكتب الكود بصمت. أنت الآن لست مبرمجًا فقط، بل أنت “معلّق رياضي” على الكود الذي تكتبه.
“حسنًا، سأبدأ الآن بكتابة الحل المحسّن باستخدام لغة بايثون. أولاً، سأقوم بتعريف قاموس (dictionary) لتخزين الأرقام التي مررت عليها…”
# سأشرح الكود أثناء كتابته
def find_sum_pair(nums, target):
# "هنا سأعرف القاموس الذي سيخزن الرقم وفهرسه"
prev_map = {} # val -> index
# "الآن سأمر على المصفوفة مرة واحدة فقط"
for i, n in enumerate(nums):
# "لكل رقم، سأحسب القيمة المكملة له"
diff = target - n
# "سأتحقق إذا كانت القيمة المكملة موجودة في القاموس"
if diff in prev_map:
# "إذا كانت موجودة، فهذا يعني أننا وجدنا الحل"
return [prev_map[diff], i]
# "إذا لم تكن موجودة، سأضيف الرقم الحالي وفهرسه للقاموس"
prev_map[n] = i
# "في حال انتهت الحلقة ولم نجد حلاً، سأرجع قيمة مناسبة"
return None
هذه الطريقة تجعل المُقابِل يتابع معك خطوة بخطوة ويفهم منطق كل سطر تكتبه.
المرحلة الخامسة: اختبر الكود بنفسك
بعد الانتهاء من الكتابة، لا تقل “أنا انتهيت” وتسكت. قم باختبار الكود بنفسك على مثال بسيط وعلى الحالات الهامشية.
“ممتاز، أعتقد أن هذا الحل يعمل. لنتتبعه سريعًا مع مثال: لو كانت المدخلات nums = [2, 7, 11, 15] والهدف target = 9. في أول دورة، n=2، diff=7. 7 ليست في القاموس، لذا نضيف {2: 0}. في الدورة الثانية، n=7، diff=2. 2 موجودة في القاموس! إذن نرجع [prev_map[2], 1] أي [0, 1]. الحل يبدو صحيحًا. كما أنه يتعامل مع حالة عدم وجود حل عن طريق إرجاع None.”
شوية بهارات من مطبخ أبو عمر 🌶️
مع السنين والخبرة، جمعت شوية نصايح عملية إضافية، “تحابيش” بتخلي الطبخة أزكى:
- تدرب مع صديق: أفضل طريقة للتحضير هي الممارسة. امسك صاحبك المبرمج، واعملوا مقابلات وهمية لبعضكم البعض. واحد يسأل والثاني يحل وهو “يفكر بصوت عالٍ”.
- سجّل صوتك: إذا ما عندك حدا تتدرب معه، افتح مسجل الصوت على جوالك وحل مسألة من أي موقع تحديات برمجية. اسمع التسجيل بعدين، وشوف وين سكتت، وين كان شرحك ضعيف، وين كان ممكن توضح أكثر. “بتعرف علّتك وبتداويها”.
- لا تخف من قول “لا أعرف، لكن…”: من الطبيعي ألا تعرف كل شيء. الشجاعة تكمن في الاعتراف بذلك ثم محاولة التفكير في حل. “لست متأكدًا من هذه النقطة، لكنني أفترض أن…” أو “لم أستخدم هذه المكتبة من قبل، لكن بناءً على اسمها، أتوقع أنها تفعل كذا وكذا…”.
- استخدم السبورة (البيضاء أو الافتراضية): إذا كانت المقابلة تسمح، ارسم. ارسم هياكل البيانات، وخطوات الخوارزمية. الصورة بألف كلمة، وتساعدك أنت والمُقابِل على تصور الحل.
الخلاصة: المقابلة ليست مجرد كود
يا أصدقائي ويا زملائي المبرمجين، تذكروا دائمًا أن التجمد في المقابلة هو شعور طبيعي يمر به حتى أفضل الخبراء. الفرق يكمن في كيفية تعاملك معه. تقنية “التفكير بصوت عالٍ” ليست مجرد خدعة لاجتياز المقابلة، بل هي مهارة أساسية للمهندس الناجح الذي يعمل ضمن فريق.
المقابلة القادمة، لا تركز فقط على كتابة الكود الصحيح. ركز على إظهار أنك مهندس منظم، تواصلي، ومتعاون يستمتع بحل المشكلات. فرجيهم كيف العقل الهندسي بفكر، مش بس كيف الأصابع بتكتب.
يلا يا جماعة، شدّوا حيلكم، والمقابلة الجاي فرجوهم كيف المهندس بفكر! بالتوفيق. 💪
