كيف تستعد لمقابلة مهندس برمجيات في Google

أغلب المهندسين اللي يرسبون في Google loop يقولون نفس الكلام بعدها: "كنت عارف الإجابة، بس ما قدرت أشرح تفكيري بوضوح تحت الضغط." هذا مو مشكلة معرفة. هذا مشكلة استعداد، وتقدر تحلها.

مقابلة Google عندها شكل محدد. لو فهمت هذا الشكل قبل ما تبدأ تحل مسائل، هذا هو الفرق بين اللي يأخذ الـ offer واللي يقضي ثلاثة أشهر على LeetCode ويرسب في الـ behavioral round.

الجواب المختصر: مقابلة Google للـ software engineer تمر في 5-7 مراحل خلال 4-8 أسابيع: recruiter screen، ثم technical phone screen، ثم 4-5 جلسات onsite تغطي coding وsystem design وتقييم سلوكي اسمه "Googleyness." كل مقابل يرفع feedback مكتوب لـ hiring committee مركزية، هم اللي يتخذون قرار الـ offer، مو المقابلون مباشرة. أسئلة الـ coding مستوى medium إلى hard على LeetCode، مع تركيز على graphs والـ dynamic programming. الـ system design متوقع من أي مهندس عنده 3 سنوات أو أكثر. الـ committee تبحث عن consistency عبر كل المراحل. جولة ضعيفة وحدة نادراً تقتل الـ offer، لكن 2 أو 3 جولات غامضة تعني الرفض تقريباً. Google تستقبل أكثر من 3 مليون طلب توظيف سنوياً، ونسبة الـ offer الإجمالية أقل بكثير من 1%. نسبة التحويل من onsite إلى offer تقدر بحوالي 1 من كل 7 مرشحين، بناءً على تقارير مجمّعة من Glassdoor وLevels.fyi.

شو يبدو عليه الـ Google interview loop فعلياً؟

الـ Google interview loop هو عملية تقييم متعددة المراحل مصممة لقياس الكفاءة البرمجية، والتفكير في System Design، والتواصل، والـ cultural fit، وذلك قبل إحالة القرار لـ hiring committee بدلاً من المقابلين مباشرة.

إليك الترتيب المعتاد لمهندس متوسط أو senior:

• Recruiter screen (30 دقيقة): السيرة الذاتية، الدوافع، التوفر، ومدى ملاءمة الدور. أحياناً يكون فيه سؤال behavioral خفيف. هذه الجلسة تحدد كيف يقدمك الـ recruiter داخلياً.
• Technical phone screen (45-60 دقيقة): سؤال أو سؤالان على Google Docs أو محرر مشترك. المقابل يشوف شاشتك مباشرة. خلّيك عند مستوى LeetCode medium قبل ما تحدد موعد هذه الجلسة.
• Onsite loop (4-5 جلسات، 45 دقيقة كل واحدة):
  • 2-3 جلسات coding
  • جلسة system design واحدة (للمهندسين بخبرة 3 سنوات أو أكثر)
  • جلسة Googleyness and Leadership سلوكية

هتقابل خليط من SWEs وstaff engineers وأحياناً engineering manager. كل واحد يرفع feedback مستقل بعد انتهاء الـ loop.

جولة سيئة وحدة نادراً تقتل الـ offer؛ نمط تواصل مبهم عبر ثلاث جولات يفعل ذلك دائماً تقريباً.

قرار الـ hiring committee هو اللي يحدد مصيرك فعلاً. يبحثون عن signals متسقة، مو قمم وقيعان. مرشح يؤدي بشكل ثابت عبر 5 جلسات يتغلب على مرشح بارع في اثنتين وغامض في ثلاث. خطط استعدادك على أساس الـ consistency، مو فقط التألق التقني.

ما أنواع الأسئلة اللي Google تختبر فيها فعلاً؟

أسئلة الـ coding في Google مستوى medium إلى hard على LeetCode، مع تحيّز واضح للمسائل اللي تكافئ التعرف على الـ patterns أكثر من الحفظ.

أكثر المواضيع اللي تظهر:

• Arrays وstrings وhash maps: هذا الأساس. لو ما تقدر تحل مسألة sliding window أو two-sum بكفاءة في 15 دقيقة، كل استعداد ثاني سابق لأوانه.
• Trees والـ binary search: Traversals، lowest common ancestor، عمليات BST. توقّع سؤال tree واحد على الأقل في كل loop.
• Graphs: BFS، DFS، topological sort، connected components. منتجات Google، من Maps لـ Search لـ YouTube، تتعامل مع graph data باستمرار. يظهر هذا في الأسئلة.
• Dynamic programming: Google تسأل DP أكثر من معظم شركات FAANG. يستخدمونها كإشارة على التفكير المنظم في التحسين.
• Two pointers وsliding window: شائعة في الـ phone screens. سريعة التطبيق بعد ما تستوعب الـ patterns.

أسئلة الـ system design للـ senior engineers تبدو هكذا: "صمم نموذج مشاركة الملفات في Google Drive" أو "صمم distributed rate limiter لـ public API." الإجابة الصح مو البنية النهائية، البنية الصح هي العملية. حدد الغموض، اسأل أسئلة توضيحية، سمّ الـ trade-offs صراحةً.

الأسئلة السلوكية تُستهان بها أكثر بكثير من الأسئلة التقنية. Prompts شائعة في Googleyness: "حدثني عن خلاف مع زميل"، "صف project فشل وماذا كنت ستفعل بشكل مختلف"، "أعطني مثالاً حين تولّيت مسؤولية خارج نطاق دورك الرسمي." Google تريد قصصاً محددة ومنظمة، مو فلسفات عامة عن التعاون.

بناءً على بيانات Glassdoor لتجارب مقابلات Google SWE (تعكس آلاف التقارير من المرشحين)، أسئلة الـ graphs والـ dynamic programming هي الفئات التقنية الأصعب الأكثر ذكراً، وتظهر في أكثر من 60% من تجارب الـ onsite المُبلَّغ عنها.

ما الـ signals اللي Google تقيّسها فعلاً في كل جلسة؟

المقابلون في Google ما يتحققون فقط من صحة الحل. يقيّمون 4 signals مستقلة في نفس الوقت:

1. الكفاءة الإدراكية العامة: هل تقدر تقسّم مشكلة جديدة لأجزاء يمكن التعامل معها؟ هل تجد الـ patterns بدون hints؟
2. الكفاءة البرمجية: هل الكود مقروء من النظرة الأولى؟ هل تعالج الـ edge cases بدون تذكير؟ هل تكتب tests عند الطلب؟
3. التواصل: هل تشرح منطقك في الوقت الفعلي؟ هل تُعلم المقابل حين تكون غير متأكد؟
4. Googleyness: الفضول الفكري، الارتياح مع الغموض، التعاون الموثق، والملكية على النتائج.

Googleyness مو نوع شخصية، بل مجموعة سلوكيات موثقة تتوقع Google إثباتها من خلال أمثلة ماضية محددة.

المقابلون ذوو الخبرة يلاحظون ما إذا كنت تتعامل مع المقابلة كأداء منفرد أو حوار. المرشحون اللي يطرحون أسئلة توضيحية، ويسمّون الـ trade-offs، ويقولون "غريزتي X لكن أريد التحقق من Y أولاً" يحصلون على تقييمات أعلى بشكل ملحوظ. نموذج الـ feedback المكتوب عنده خانة محددة لجودة التواصل. امنح المقابل ما يحتاجه ليملأها.

خطأ شائع عند الـ senior candidates: الخلط بين ما فعله الفريق وما فعلته أنت. في الإجابات السلوكية، استخدم "أنا" مو "نحن." الـ hiring committee لا تستطيع تقييم الإسهامات الفردية من قصص الفريق.

ما الأشياء اللي يستهين بها المرشحون باستمرار؟

هذه الفخاخ الثلاثة تصطاد مهندسين مؤهلين تقنياً لكنهم يخرجون من الـ loop بدون offer.

الفخ الأول: البرمجة بصمت. ممكن تحل مسألة DP صعبة في 12 دقيقة وتحصل على تقييم منخفض لأن المقابل ليس لديه فكرة كيف فكّرت. المقابلون في Google يوثّقون ما قلته بصوت عالٍ. لو تفكر في شيء، قله. روّي غموضك بنفس سهولة روايتك ليقينك.

الفخ الثاني: System design سطحي. المرشحون بخبرة 5 سنوات أو أكثر كثيراً ما يرسمون بنية three-tier عالية المستوى ويعتبرون المهمة انتهت. مقابلو Google Senior يتوقعون منك تناول نقاط الفشل المحتملة، ومقايضات CAP theorem بلغة مفهومة، واستراتيجية الـ sharding، وكيف ستراقب النظام في الـ production. الاتساع هو الحد الأدنى. العمق هو ما يفصل تقييم L4 عن L5.

الفخ الثالث: اعتبار الاستعداد السلوكي اختيارياً. جلسة Googleyness تُحتسب بالتساوي مع جلساتك التقنية في قرار الـ hiring committee. المهندسون اللي يقضون 90% من وقت استعدادهم على الـ algorithms وصفر على السلوكي يخسرون الـ offers أمام مرشحين استعدوا للاثنين. وفقاً لتحليل Candor.co لنتائج مقابلات التقنية، الأداء السلوكي كان عاملاً حاسماً في قرابة 30% من الحالات الحدية في شركات التقنية الكبرى.

كيف ترتب استعدادك، سواء كان لديك أسبوعان أو 4 أو 8 أسابيع؟

خطة الأسبوعين (إذا كنت قوياً تقنياً أصلاً):

• الأيام 1-7: مسألتان على LeetCode يومياً. تركيز على graphs وDP. حد زمني صارم 45 دقيقة للمسألة.
• الأيام 8-12: mock واحد لـ system design يومياً. غطّ بنية YouTube، وdistributed key-value store، وURL shortener، وrate limiter.
• الأيام 13-14: 6 قصص سلوكية بصيغة STAR. دربها بصوت عالٍ، مو فقط بالكتابة.

خطة 4 أسابيع (قاعدة جيدة، مع ثغرات):

• الأسبوع 1: Arrays وstrings وhash maps والـ recursion. 10 مسائل هادفة.
• الأسبوع 2: Trees وgraphs وBFS/DFS وtopological sort. 10 مسائل متصاعدة الصعوبة.
• الأسبوع 3: أساسيات DP وSystem Design. اقرأ الفصول 1-5 من Designing Data-Intensive Applications.
• الأسبوع 4: مقابلات تجريبية يومية، تقني وسلوكي في كل جلسة.

خطة 8 أسابيع (عائد من انقطاع مهني أو تغيير لغة البرمجة الأساسية):

• الأسبوعان 1-2: مراجعة كاملة لهياكل البيانات مع تحليل التعقيد من الصفر.
• الأسبوعان 3-4: حل مسائل مبني على الـ patterns باستخدام قائمة NeetCode 150.
• الأسبوعان 5-6: System Design. Grokking the System Design Interview يغطي الـ patterns الأساسية بكفاءة.
• الأسبوعان 7-8: مقابلات تجريبية يومية، صقل السلوكي، وتدريب مقيّد بالوقت في ظروف واقعية.

مهما كان timeline، لا تتخطى الـ mock interviews الحية. الممارسة بمفردك تبني ثقة زائفة. تحتاج تتكلم بصوت عالٍ، مع مؤقت، ومع شخص يشاهد ويطرح أسئلة متابعة. IntervYou يتيح لك mocks منظمة مصممة تحديداً لطريقة Google، تشمل جلسات الـ coding والـ system design وجلسة الـ Googleyness السلوكية.

ما الأدوات والـ frameworks اللي تظهر فعلاً؟

مقابلات الـ coding في Google غير مرتبطة بلغة محددة. Python شائعة وممتازة تماماً. Java وC++ كذلك مستخدمتان على نطاق واسع. استخدم اللغة اللي تتقنها، مو تغيّر لغتك لأجل المقابلة.

للـ system design في المستويات الـ senior، معرفة تقنيات بعينها مهمة:

• MapReduce: أساسي لطريقة تفكير Google في الحوسبة الموزعة. ما تحتاج تبرمجه، تحتاج تشرح نموذج البرمجة وقيوده.
• Bigtable وSpanner: Google اخترعتهما. معرفة تصميم Bigtable كـ map متعدد الأبعاد، متفرق، موزع، ومرتب، يعطيك مفردات حقيقية لمناقشات trade-offs التخزين.
• Paxos وRaft: بروتوكولات الإجماع الموزع تظهر في نقاشات الـ system design للـ senior حين يتعلق الأمر بالـ consistency. ما تحتاج تبرمجها. تحتاج تشرح متى تختارها وما الذي تتنازل عنه.
• Protocol Buffers: Google تستخدم protobuf في كل stack. في أسئلة تصميم الـ API، معرفة الفرق بين protobuf وJSON في تطبيق الـ schema والتوافق مع الإصدارات وكفاءة التشفير الثنائي تُظهر خبرة production حقيقية.

المرشحون اللي يُبهرون المقابلين الـ senior في Google مو الحافظون للـ architectures، بل الذين يعرفون القيود المحددة اللي تجعل تصميماً أفضل من غيره لمشكلة بعينها.

الـ offers ما تذهب بالضرورة للأعلى تقييماً على LeetCode. تذهب للذين يفكرون بصوت عالٍ تحت ضغط الوقت، ويتواصلون عن الـ trade-offs بدون أن يُطلب منهم، ويعطون إجابات محددة ومنظمة في كل جلسة بما فيها السلوكية. ابدأ بأساسيات الـ coding، لكن لا تدفع الاستعداد السلوكي لآخر أسبوع. لو تريد تدخل الـ loop الحقيقي وأنت تعرف كيف يبدو "الجهوز الحقيقي"، IntervYou يمرّرك على مقابلة Google محاكاة كاملة، coding وsystem design وGoogleyness، قبل ما يُحسب عليك شيء.

ابدأ mock مجاني ←

---

مقالات ذات صلة

• كيف تحضّر لمقابلة Product Manager في 2026 (مع سكريبت تجريبي مجاني)
• مقابلة بنك الراجحي: الأسئلة والمراحل وكيف تستعد
• مقابلة التوظيف التقني في بنك الراجحي: ما الذي يحدث فعلاً