السلام عليكم يا جماعة، معكم أبو عمر.
خليني أحكيلكم قصة صارت معي زمان، في بداياتي. كنت مقدم على وظيفة في شركة كبيرة، ووصلت للمقابلة التقنية. دخلت على الغرفة، ثقة عالية ومعلومات “آخر حبة”. المقابِل، رجل وقور وخبرته واضحة على وجهه، أعطاني مسألة على اللوح الأبيض تتعلق بالـ
Algorithms. قرأت المسألة… وصمت.
مش صمت الجاهل، لا والله. كان صمت اللي عقله شغال زي محرّك الطيارة، بيحلل وبيفكك وبيركب حلول. في رأسي، كنت قد بنيت الحل الأول، ووجدته غير فعال. ثم بنيت الحل الثاني، وحسّنته. ووصلت للحل الأمثل. كل هذا حدث في دقيقتين من الصمت المُطبق. نظرت إلى المقابِل، ابتسمت، وبدأت بكتابة الكود النهائي مباشرة على اللوح.
بعد أن انتهيت، التفت إليه بكل فخر. نظر إليّ، ثم إلى اللوح، وقال ببرود: “شكرًا لوقتك، سنتواصل معك”. طبعًا، عمرهم ما تواصلوا. خرجت من المقابلة وأنا بسأل حالي: “وين الغلط؟ الكود صح 100%!”.
بعد فترة، وبمساعدة صديق أكبر مني بالعمر والخبرة، فهمت الدرس. المقابِل لم يكن يريد رؤية الحل النهائي فقط. كان يريد أن يرى الرحلة التي قطعتها للوصول إلى هذا الحل. صمتي القاتل جعله يظن أنني إما حفظت الحل حفظًا، أو أنني “بطيخ” (لا أفقه شيئًا) وضربت معي بالصدفة. يا زلمة، حسيت حالي ممثل في فيلم صامت! من يومها، قررت أن أغير استراتيجيتي تمامًا، وهنا وُلدت تقنية “التفكير بصوت عالٍ” في قاموسي المهني.
لماذا الصمت قاتل في المقابلات التقنية؟
قبل أن ندخل في “كيف”، دعنا نفهم “لماذا”. المقابلة التقنية ليست اختبارًا في المدرسة، حيث الأهم هو الجواب النهائي الصحيح. المقابلة التقنية هي أشبه بورشة عمل مصغرة، والمقابِل يريد أن يعرف:
- كيف تفكر؟ هل تبدأ بالحل السهل ثم تحسنه، أم تقفز مباشرة للحل المعقد؟
- كيف تحلل المشاكل؟ هل تسأل أسئلة توضيحية أم تفترض الافتراضات من عندك؟
- كيف تتعامل مع الضغط؟ هل تتجمد عندما تواجه تحديًا، أم تظل هادئًا وتفكر بمنطق؟
- هل أنت شخص يمكن العمل معه؟ هل تتواصل بشكل جيد؟ هل تبدو كزميل عمل متعاون؟
عندما تكون صامتًا، أنت تحرم المقابِل من رؤية كل هذه المهارات الرائعة. أنت تعطيه شاشة فارغة، وهو سيملؤها بأسوأ الافتراضات. ببساطة، الصمت يجعلك تبدو أقل كفاءة مما أنت عليه حقًا.
ما هو “التفكير بصوت عالٍ” وكيف تطبقه؟
“التفكير بصوت عالٍ” (Thinking Aloud) هو ببساطة أن تروي قصة حلك للمشكلة أثناء قيامك بحلها. إنها عملية تحويل الأفكار الداخلية في رأسك إلى حديث مسموع ومنظم. دعنا نقسمها إلى خطوات عملية.
الخطوة الأولى: الاستيعاب والتوضيح (لا تكن عجولًا!)
بمجرد أن تُطرح عليك المشكلة، لا تقفز مباشرة إلى الحل. خذ نفسًا عميقًا وابدأ الحوار. هذا يظهر أنك شخص دقيق ولا يفترض الأمور.
“تمام، شكرًا على هذه المسألة. حتى أتأكد أني فهمت صح، المطلوب هو [أعد صياغة المشكلة بكلماتك الخاصة]… صحيح؟ وهل هناك حالات خاصة يجب أن آخذها في الاعتبار؟ مثلًا، ماذا لو كان المُدخل فارغًا (empty array) أو null؟ هل الأحرف الكبيرة والصغيرة تُعامل بنفس الطريقة؟”
هذه الأسئلة لا تظهرك بمظهر الغبي، بل تظهرك بمظهر المحترف الذي يهتم بالتفاصيل.
الخطوة الثانية: الحل الساذج أولًا (The Brute Force)
لا تخف من البدء بالحل البديهي أو “الساذج”. هذا يثبت أنك قادر على إيجاد حل، أي حل، قبل أن تبدأ في التفكير بالتحسينات.
“حسنًا، أول فكرة تخطر في بالي هي الحل المباشر. يمكنني أن أعمل كذا وكذا [اشرح الحل البسيط]. أعرف أن هذا الحل قد لا يكون الأفضل من ناحية الأداء، ربما تكون تعقيداته الزمنية (Time Complexity) O(n²)، ولكنه نقطة بداية جيدة لنتأكد من صحة المنطق.”
بهذه الطريقة، أنت تضع أساسًا وتظهر للمقابِل أنك تفهم مفاهيم مثل تعقيدات الوقت والمساحة.
الخطوة الثالثة: التحسين والمفاضلة (The Optimization)
بعد عرض الحل الأول، ابدأ في نقده بنفسك وابحث عن طرق لتحسينه. هنا تظهر قوتك الحقيقية.
“الآن، كيف يمكننا تحسين هذا الحل؟ الحل السابق يتطلب المرور على القائمة مرتين، وهذا غير فعال. ماذا لو استخدمنا بنية بيانات مثل الـ Hash Map أو الـ Set؟ صحيح أن هذا سيزيد من استهلاك الذاكرة (Space Complexity)، ولكنه سيحسن الأداء الزمني بشكل كبير ليصبح O(n). أعتقد أن هذه مفاضلة (trade-off) مقبولة في معظم الحالات.”
هذا الحوار يوضح أنك لا تفكر في الحل فقط، بل في المفاضلات بين الحلول المختلفة، وهذه مهارة مهندس برمجيات خبير.
الخطوة الرابعة: كتابة الكود مع الشرح
الآن حان وقت كتابة الكود. لا تكتب بصمت! اشرح وأنت تكتب. تخيل أنك تشرح الكود لزميلك في الفريق.
“تمام، سأبدأ بتعريف دالة اسمها `solveProblem`. أولًا، سأتحقق من الحالات الخاصة التي ناقشناها. الآن، سأقوم بإنشاء الـ Hash Map لتخزين القيم التي مررت عليها. سأمر على القائمة مرة واحدة (single pass)، وفي كل مرة سأقوم بالتحقق من [كذا وكذا]…”
مثال عملي: مشكلة “Two Sum” الشهيرة
المشكلة: أعطِ قائمة من الأرقام (array) ورقمًا مستهدفًا (target)، أوجد فهرس (index) رقمين مجموعهما يساوي الرقم المستهدف.
الطريقة الصامتة (السيئة): صمت… تفكير… صمت… كتابة الكود… “تفضل”.
طريقة أبو عمر (التفكير بصوت عالٍ):
- فهم وتوضيح: “تمام، يعني لو عندي القائمة `[2, 7, 11, 15]` والهدف `9`، المفروض أرجع `[0, 1]` لأن `nums[0] + nums[1] = 9`. هل ممكن يكون في أكتر من حل؟ وإذا فيه، أرجع أي واحد منهم؟ وهل ممكن أستخدم نفس العنصر مرتين؟”
- الحل الساذج: “أول حل بيخطر ببالي هو إني أستخدم حلقتين متداخلتين (nested loops). آخذ كل رقم وأجمعه مع كل الأرقام اللي بعده وأشوف إذا المجموع بيساوي الهدف. هذا الحل شغال 100%، بس تعقيداته الزمنية O(n²)، ويمكن يكون بطيء لو القائمة كبيرة جدًا.”
- التحسين: “لتحسين الأداء، ممكن أستخدم Hash Map. بفكرة بسيطة: وأنا بمر على الأرقام، لكل رقم `x`، بسأل حالي: هل الرقم `(target – x)` موجود في الـ Hash Map؟ إذا موجود، بكون لقيت الحل. وإذا مش موجود، بضيف الرقم الحالي `x` وفهرسه للـ Hash Map عشان الأرقام الجاية تشوفه. هيك بحتاج أمر على القائمة مرة واحدة بس، وبتصير التعقيدات الزمنية O(n).”
- كتابة الكود مع الشرح: “الآن سأكتب هذا الحل باستخدام لغة Python. سأعرف الـ map وأسميه `seen_numbers`. سأستخدم `enumerate` عشان آخذ الرقم والفهرس مع بعض في نفس الحلقة…”
# سأقوم بتعريف الدالة كما اتفقنا
def two_sum(nums, target):
# هذا هو الـ Hash Map الذي سيخزن الأرقام التي رأيناها وفهرسها
seen_numbers = {} # {number: index}
# سأمر على القائمة باستخدام enumerate للحصول على الفهرس والقيمة
for index, num in enumerate(nums):
# الرقم المكمل الذي نبحث عنه
complement = target - num
# الآن أتحقق إذا كان المكمل موجودًا في الـ map
if complement in seen_numbers:
# إذا كان موجودًا، فقد وجدنا الحل!
# نرجع فهرس المكمل والفهرس الحالي
return [seen_numbers[complement], index]
# إذا لم نجد المكمل، نضيف الرقم الحالي وفهرسه للـ map
# لاستخدامه في التكرارات القادمة
seen_numbers[num] = index
# في حال لم نجد حلًا بعد المرور على كل القائمة (حسب متطلبات السؤال)
return [] # أو نطلق خطأ، حسب المواصفات
نصائح أبو عمر الذهبية للتفكير بصوت عالٍ
- تدرب مع بطة مطاطية (Rubber Duck Debugging): نعم، كما سمعت. ضع أي مجسم (بطة، فنجان قهوة) على مكتبك واشرح له المشكلة والحل. ستشعر بالغرابة في البداية، لكنها طريقة فعالة جدًا لتعتاد على الشرح.
- لا تخف من قول “لحظة لأفكر”: من المقبول تمامًا أن تقول “هذه نقطة مثيرة للاهتمام، دعني أفكر بها للحظة”. هذا يمنحك وقفة قصيرة للتفكير ويظهر أنك تأخذ الأمور بجدية، وهو أفضل من الصمت الطويل المربك.
- اجعلها حوارًا: اسأل المقابِل عن رأيه. “هل هذا التوجه يبدو منطقيًا بالنسبة لك؟” أو “هل لديك تفضيل بين استخدام ذاكرة أكثر مقابل أداء أسرع في هذه الحالة؟”. هذا يحول المقابلة من امتحان إلى جلسة عمل تعاونية.
- استخدم اللوح الأبيض (الفعلي أو الرقمي): ارسم، خطط، اكتب ملاحظات. الرسم على اللوح يساعدك على تنظيم أفكارك ويجعل متابعتك أسهل بكثير بالنسبة للمقابِل.
الخلاصة: ورجيهم كيف مخك بيشتغل!
يا صديقي المبرمج، تذكر دائمًا: المقابلة التقنية ليست مجرد اختبار لمعلوماتك، بل هي نافذة تتيح للآخرين رؤية طريقة عمل عقلك. الصمت يغلق هذه النافذة ويتركهم في الظلام. أما “التفكير بصوت عالٍ”، فهو المفتاح الذي يفتحها على مصراعيها، ليظهر لهم مهندسًا واثقًا، منظمًا، وقادرًا على التواصل وحل المشكلات.
المرة القادمة التي تدخل فيها مقابلة، لا تكن ممثلًا في فيلم صامت. كن المخرج والراوي لقصة الحل. ورجيهم كيف مخك بيشتغل! بالتوفيق يا وحوش. 💪
