مقدمة

أول مقابلة عمل برمجية إلها طعم مختلف… مو لأنها أصعب مقابلة، بل لأنها أول مرة بتكون فيها “مكشوف” قدام شخص بيسألك: ليش لازم نوظّفك أنت تحديدًا؟

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

اللي صار بعدها كان درس قاسي: المشكلة مو بس بالمعلومات… المشكلة إني كنت أتعامل مع المقابلة كأنها امتحان حفظ، بينما هي عمليًا اختبار شغل على الواقع: كيف بتفكر؟ كيف بتشرح؟ كيف بتسأل؟ وكيف بتتصرف لما تتوه.

إذا أنت داخل على أول مقابلة برمجية، خليني أوفّر عليك الجزء المؤلم. مش رح أعطيك “نصائح تحفيزية” ولا كلام فضفاض. رح نحكي بخطة عملية، وبأخطاء صار معي ومع غيري، وبالضبط شو تعمل قبل المقابلة وأثناءها وبعدها.

ليش أول مقابلة بتخوف لهالدرجة؟

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

المشكلة إن كثير مطورين بيحضّروا لمحور واحد وبيتركوا الباقي.

بتلاقي واحد ممتاز بالكود، بس صامت وما بيفهم المقابل شو عم يعمل.
وواحد تاني بيحكي كتير، بس كوده فوضى وما بيخلص.
وواحد ثالث حافظ حلول، بس أول ما يتغيّر الشرط شوي بيضيع.

كمان لازم تتوقع إن عملية التوظيف نفسها غالبًا بتكون مراحل: تواصل أولي مع HR/Recruiter، بعدها مقابلة/مكالمة تقنية، وأحيانًا اختبار منزلي أو مقابلة مباشرة فيها حل مسائل على الهواء.

موقف حقيقي: كيف خربتها بأبسط طريقة

في أول مقابلة تقنية جدّية إلي، انطرح علي سؤال خوارزمي بسيط نسبيًا.

الغريب إني كنت “بعرف” الحل.

بس صار شي واحد كفيل ينسف كل شيء: سكت.

كنت عم فكّر جوّاتي، وبحاول أطلع الحل كامل قبل ما أحكي كلمة. بعد دقيقتين صار في صمت غريب، والمقابل سألني: “شو عم تفكر؟”. وأنا بدل ما أستغل السؤال وأشرح، بلشت أكتب بسرعة… ومن هون بدأت الأخطاء.

ما سألت عن القيود (Constraints).
ما جربت مثال صغير قدامه.
ما حكيت عن التعقيد الزمني.
وما اختبرت الكود إلا بالنهاية.

لاحقًا فهمت إن المقابلة مش بس “الجواب الصح”، بل الطريقة اللي بتوصل فيها للجواب. كثير أدلة مقابلات بتأكد إن التواصل وشرح خطوات الحل جزء من التقييم، مو إضافة اختيارية.

كيف تفكر بالمقابلة كأنها “يوم عمل”

خلّيك واقعي: الشركة عم تحاول تتنبأ كيف رح تشتغل معهم.

هل بتسأل أسئلة توضيحية قبل ما تكتب؟
هل بتناقش Trade-offs لما يكون في أكثر من حل؟
هل بتكتب كود قابل للقراءة؟
هل بتعرف تختبر وتدبّغ (debug) بدل ما تتمنى إنه يشتغل؟

حتى منصات التقييم الحديثة (زي منصات المقابلات المباشرة) تركّز على أسئلة أقرب لبيئة العمل: تصليح Bug، تعديل Feature، مراجعة كود… مو بس مسائل ورق.

هذا تغيير مهم بعقليتك: التحضير لازم يشبه الشغل الحقيقي.

تجهيزات قبل ما تفتح LeetCode أصلاً

افهم شكل المقابلة

قبل ما تحل ولا مسألة، اسأل HR أو الشخص اللي نسق معك:

هل المقابلة فيها Coding على الهواء؟
هل في System Design؟
هل في Live Coding على Whiteboard أو IDE؟
هل في Take-home Task؟

هذا السؤال لحاله بيختصر عليك أسبوعين تحضير غلط.

اختر لغة واحدة للمقابلة

لا تروح على المقابلة وأنت بتتردد: JavaScript ولا Python ولا Java؟

اختار لغة “مريحة” لإلك، وكون قادر تكتب فيها بسرعة وبأقل أخطاء، وتعرف مكتباتها الأساسية (collections، sorting، string ops…). كثير تحضيرات مقابلات LeetCode-style تنصح تستخدم اللغة اللي أنت أقوى فيها وتدرّب حالك على التفكير بصوت عالي خلالها.

حضّر قصصك البرمجية (مش بس مشاريعك)

حط قدامك 3 مشاريع/تجارب جاهزة تحكيها:

مشروع فخور فيه.
مشروع فشل أو تعلّمت منه.
مشروع فيه تحدي تقني حقيقي (أداء، بنية، أمان، مشاكل إنتاج).

أكاديمية حسوب بتقترح أثناء الحديث عن المشاريع تكون إجابتك مبنية على “ماذا/من/كيف/لماذا” حتى تكون قصة متماسكة وواضحة.

إذا عندك مقالات أو شروحات سابقة على مدونتك أو مشاريع على GitHub، جهّز رابطين أو ثلاثة. وحتى لو ما عندك، هاد تذكير مهم: لازم تبني أثر… مو بس CV.

رابط داخلي مقترح لقراءة سريعة قبل المقابلات (لتذكيرك بأهمية إدارة الكود):
لماذا يجب على كل مبرمج تعلم Git؟

الجزء التقني: كيف تتعامل مع سؤال خوارزمي تحت الضغط

خلّيني أعطيك “بروتوكول” ثابت. إذا مشيت عليه، حتى لو ما جبت الحل الأمثل، رح تبين كمطور فاهم ومرتب.

1) أعد صياغة السؤال بصوت عالي

أول 30 ثانية… لا تكتب كود.

قل للمقابل: “تمام، المطلوب كذا وكذا… صح؟”

هذه الحركة بتخليك تتأكد إنك ما فهمت السؤال غلط، وبتعطيك وقت تهدأ.

2) اسأل عن القيود وعرّف الافتراضات

في كثير مقابلات، المقابل بده يشوفك تسأل أسئلة توضيحية وتذكر افتراضاتك بدل ما تقفز للكود.

أمثلة أسئلة ذكية:

حجم الإدخال قدّيش؟ 10؟ 10 آلاف؟ مليون؟
هل البيانات ممكن تكون سالبة؟ هل في تكرار؟
هل بدنا أفضل أداء ولا حل بسيط مقبول؟

كل Constraint بتغير الحل.

3) جرّب مثال صغير على الورق

قبل الكود، خذ Input بسيط وامشِ فيه خطوة خطوة.

هذا بيكشف لك زوايا ما كنت شايفها، وبيخليك تشرح بشكل طبيعي.

4) ابدأ بحل بسيط (Brute Force) ثم حسّنه

في كثير مقابلات، الحل البسيط إذا كان واضح ومبرر، بيفتح لك الباب للتحسين.

قول: “أول حل ببالي كذا… تعقيده O(n^2)، بس ممكن نعمله O(n) باستخدام HashMap…”.

مجرد إنك بتذكر Big-O وبتقارن حلول، أنت عم تثبت إنك فاهم أسس المقابلات التقنية.

5) اكتب كود قابل للقراءة

أسماء متغيرات واضحة.
تقسيم لدوال صغيرة إذا لزم.
تعليق بسيط إذا في جزء tricky.

الكود اللي بينقرأ بسرعة بيعمل فرق كبير.

6) اختبر قبل ما تقول “خلصت”

جرب:

Edge cases.
Empty input.
أكبر/أصغر قيم.

Indeed بتذكر إن من المهارات المهمة أثناء المقابلة إنك “تحكي خلال الحل” وتوضح تفكيرك، وضمنها إنك تختبر وتشرح ليش اخترت خطواتك.

تمرين عملي

أكبر ترقية تقدر تعملها خلال أسبوع واحد هي إنك تتعلم تحكي وأنت بتحل.

في أدلة مقابلات كثيرة بتعتبر “الـ overcommunication” ميزة حقيقية لأن المقابل ما بيعرف شو جوات دماغك.

طريقة تدريب سريعة:

حل 5 مسائل سهلة… بس الشرط إنك تسجّل صوتك.
ارجع اسمع التسجيل: هل شرحت ليش اخترت هيك؟ هل ضيعت وقت بصمت؟ هل قفزت للكود؟

رح تنصدم قديش في أشياء كنت تعملها غلط بدون ما تنتبه.

التحضير للمقابلات مش LeetCode فقط… بس LeetCode جزء من الصورة

إذا الشركة من النوع اللي بيسأل LeetCode-style، التدريب المنهجي مهم.

منصات مثل LeetCode عندها مسارات “Interview” وقوائم أسئلة مقابلات شائعة تساعدك تبني العضلة خطوة خطوة.

وبرضه HackerRank عنده “Interview Preparation Kit” مفيد خصوصًا إذا شركتك بتستخدم تقييمات أونلاين بزمن محدد.

بس انتبه: حلّ مسائل بدون تحليل وبدون مراجعة أخطائك… تضييع وقت.

كيف تختار “كم” و“ماذا” تحل؟

خلّيني أعطيك قاعدة واقعية:

إذا أنت Frontend/Backend Mid-level: ركز على Arrays, Hashing, Two pointers, Stack/Queue, Trees basics, Graph basics.
إذا Junior قوي: ركز على الأساسيات + 20–30 مسألة منوعة مع مراجعة.
إذا Senior: غالبًا رح يجيك System Design أكتر من خوارزميات ثقيلة، حسب الشركة.

Tech Interview Handbook يلخّص التحضير بشكل واسع: فهم فورمات المقابلة، اختيار اللغة، تقوية أساسيات CS، التحضير للـ coding interview، والتحضير للـ system design والـ behavioral حسب المستوى.

System Design لأول مرة (حتى لو ما طلبوه)

كثير مطورين بينصدموا لما ينحكى: “صمّم نظام مشابه لتويتر” أو “كيف تعمل Upload Service”.

حتى لو أنت مو داخل على شركة Big Tech، التفكير التصميمي صار شائع.

نصائح واقعية:

خليك أنت السائق

في مقالات خبراء مقابلات Big Tech في نصيحة تتكرر: لا تقعد ساكت وتستنى المقابل يقودك؛ أنت اللي لازم تدير الحوار، تحط افتراضات، وتوضح Trade-offs.

ابدأ بالمتطلبات قبل الرسم

Functional requirements: شو النظام لازم يعمل؟
Non-functional: أداء؟ تأخير؟ توافر؟ تكلفة؟

بعدها ارسم High-level: API، قاعدة بيانات، كاش، Queue… ثم انزل للتفاصيل.

احكي عن القيود حتى لو ما طلبوها

ماذا لو صار Spike بالترافيك؟
كيف تتعامل مع فشل خدمة؟
هل تحتاج Observability؟ Logs/Metrics/Tracing؟

حتى لو الإجابة مش كاملة، طريقة التفكير بتنعكس.

الأسئلة السلوكية (Behavioral): الجزء اللي كثير مطورين بيستهينوا فيه

الغلط الشائع: “أنا مبرمج، خلص خلّيهم يشوفوا الكود”.

الحقيقة؟ كثير مقابلات فيها محور سلوكي واضح: تعاون، ضغط، خلاف مع فريق، قرار تقني غلط…

مهم تحضّر إجابات مبنية على قصص واقعية.

أكاديمية حسوب بتشير لفكرة إنك تحكي عن المشاريع بشكل منظم (ماذا/من/كيف/لماذا)؛ هذا بيساعدك تبني قصة مفهومة بدل ما تحكي بعشوائية.

كمان في أدلة تحضير تذكر إن تجهيز “مشروعين فخور فيهم” والقدرة على شرح تفاصيلهم خطوة أساسية قبل المقابلة السلوكية.

أسئلة لازم تكون جاهز إلها

احكيلي عن مرة صلحت Bug مزعج… كيف وصلت لسببه؟
احكيلي عن مرة اختلفت مع زميل على قرار تقني… كيف حليت الموضوع؟
احكيلي عن Feature اشتغلت عليها من الصفر… شو كانت تحدياتها؟

إذا بتحس إنك بتضيع بقراءة كود قديم أو مشروع كبير، راجع المقال هذا لأنه مرتبط مباشرة بأسئلة من نوع “كيف بتتعامل مع Codebase ما بتعرفه؟”:

كيف تفهم وتتعامل مع الأكواد المعقدة؟

خطة تحضير عملية (14 يوم) — إذا وقتك ضيق

هاي الخطة للي عنده مقابلة قريبة، وبدّه يطلع بأكبر عائد بأقل وقت.

اليوم 1–2: أساسياتك تحت المجهر

راجع أساسيات اللغة اللي رح تستخدمها بالمقابلة (data structures built-in، strings، arrays، maps).
اكتب كود صغير بدون autocomplete (شوية “يدوي”) لأن بعض المقابلات فيها كتابة على whiteboard أو محرر بسيط.

اليوم 3–6: مسائل مركّزة + شرح صوتي

يوميًا 2 مسألة: واحدة Easy وواحدة Medium.
ممنوع تحل بصمت: احكي كل خطوة.
بعد كل مسألة: اكتب 5 سطور “شو غلطت؟ شو كان المفروض أسأل؟”.

اليوم 7: Mock Interview مع صديق

45 دقيقة Live Coding.
15 دقيقة Behavioral.

حتى لو صديقك مو خبير، مجرد وجود شخص قدامك بيكشف توترك.

اليوم 8–10: مشاريعك وCV

جهّز “شرح دقيقتين” لكل مشروع: المشكلة، دورك، التقنيات، التحديات، النتيجة.
رتّب GitHub: README واضح، صور بسيطة، خطوات تشغيل.

اليوم 11–12: أساسيات System Design (حسب المستوى)

تمرّن على سؤال واحد: صمّم URL Shortener أو File Upload.
ركّز على المتطلبات والتدرّج بالحل، لا تغرق بالتفاصيل.

اليوم 13: مراجعة الأخطاء

ارجع على دفتر الأخطاء اللي كتبته. هاد هو منهجك الحقيقي.

اليوم 14: بروفة كاملة

ساعة مسائل.
نصف ساعة Behavioral.
تجهيز بيئة المقابلة: إنترنت، ميكروفون، كاميرا، محرر، سطر أوامر.

يوم المقابلة: تفاصيل صغيرة بتفرق

إذا المقابلة أونلاين

افتح محرر بسيط (VS Code) وخلي Tabs قليلة.
اقفل Notifications.
جهّز ورقة وقلم للأمثلة.

أثناء الحل

اسأل سؤال/سؤالين توضيحيين.
جرّب مثال.
احكي عن التعقيد.
اختبر.

لو ضعت… لا تمثل إنك فاهم.

في نصائح مقابلات كثيرة بتقول: لا تهلع إذا ما عرفت الحل؛ ناقش طريقة تفكيرك واطلب توضيح، لأن التفكير بصوت عالي بيفرق بالتقييم.

أخطاء شائعة (بتنهي المقابلة بسرعة)

1) تقفز للكود بدون فهم

هذا أكثر خطأ قاتل. المقابل بيشوفك كأنك “بتجرب حظك”.

2) الصمت الطويل

أنت مو بمسابقة شطرنج. إذا سكتّ، أنت عم تخسر معلومات تقييم مجانية.

3) حفظ حلول بدل فهم نماذج

أول تعديل صغير بالسؤال… الحل المحفوظ بينكسر.

4) تجاهل الاختبارات وEdge cases

كتير كود بيكون “يشتغل” على المثال اللي حكاه المقابل، ويفشل على حالات بسيطة.

5) تحكي عن تجاربك بتعالي أو سلبية

حتى لو اشتغلت بمكان سيء، احكي بطريقة محترمة وتعلّم… لا “فضح”.

روابط داخلية مفيدة (لتقوية جانب الشغل الواقعي)

المدونة — تصفح مقالات عملية مرتبة حسب الاهتمام.
قسم العمل في البرمجة — محتوى مرتبط بالمسار المهني.
من نحن — لو بدك تعرف فلسفة المنصة وطريقة بناء المحتوى.

روابط خارجية موثوقة (للتمرين والتحضير)

كلمة أخيرة

أول مقابلة برمجية غالبًا ما رح تكون مثالية… وهذا طبيعي.

الفرق الحقيقي بيظهر بشي واحد: هل أنت عم تحضّر لتكون “شخص يحل مسائل”؟ ولا “مطور يعرف يشتغل، يشرح، ويسأل، ويتحسن”؟

إذا مشيت بخطة واضحة، ودرّبت حالك تحكي وأنت بتحل، وراجعْت أخطائك بدل ما تهرب منها… أول مقابلة رح تكون بداية، مو نهاية.

مرتبط

اكتشاف المزيد من كود التطور

اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.