ما مدى صعوبة مقابلة Amazon؟

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

تعتمد Amazon على مسار مقابلات منظّم. يُكلَّف المحاورون بمبادئ Leadership Principles محددة لاستقصائها، ويدوّنون ملاحظات مفصلة أثناء المحادثة، وتُقارن هذه الملاحظات لاحقاً في جلسة مراجعة. ينتج عن ذلك أمران. القصة التي بدت جيدة في الغرفة تبدو ضعيفة على الورق إن لم تحتوِ على قرار ونتيجة، والقصة نفسها التي تُروى مرتين بتفاصيل مختلفة في جولتين تظهر فوراً عند مقارنة الملاحظات.

المصدر الآخر للصعوبة هو أن المعيار السلوكي يُطبَّق أيضاً في الجولات التقنية. المرشح الذي يحل سؤال البرمجة بدقة لكنه لا يستطيع وصف موقف اختلف فيه مع مدير يكون قد فشل في عنصر لم تكن مقابلة تقنية بحتة لتقيسه أبداً.

Bar Raiser محاور من خارج فريق التوظيف، مدرَّب لهذا الدور، ومهمته الحكم على ما إذا كنت ترفع متوسط مستوى الأشخاص الموجودين بالفعل في تلك الدرجة. لا يقيّم ما إذا كان الفريق بحاجة إلى شخص إضافي هذا الربع، ويمكنه منع توظيف يريده مدير التوظيف.

عملياً، هذا يعني أن الشخص الذي يقرر نتيجتك لا مصلحة له في شغل الوظيفة. الاستعجال لا يفيدك، ولا الانسجام مع المدير. ما يفيد هو دليل يصمد بعد أن يُكتَب ويقرأه شخص لم يلتقِ بك قط.

عادةً لا يمكنك معرفة من هو ذلك المحاور، وهذا لا يهم. أجب في كل جولة كأن غريباً سيقرأها لاحقاً، لأن هذا فعلاً ما يحدث.

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

يحتاج النصف السلوكي إلى ما بين ثماني وإثنتي عشرة قصة موزّعة على Leadership Principles، كل واحدة بموقف، وما قررته أنت شخصياً، ونتيجة قابلة للقياس. يمكن لمشروع واحد أن يقدّم قصتين أو ثلاث من زوايا مختلفة. اكتب النتيجة كرقم أينما وُجد، لأن السؤال التوضيحي عادةً ما يطلب ذلك بالضبط.

ثم تدرّب عليها بصوت مسموع. مهندسة back-end لديها تسع سنوات خبرة كتبت ملاحظات ممتازة ومع ذلك تعثرت في أول جلسة تدريب لها، لأن قراءة قصة وسردها تحت سؤال توضيحي مهارتان مختلفتان. غيّر أسبوعان من التدرب الشفهي على /mock-interview طريقة الأداء أكثر مما كان سيفعله شهر إضافي من القراءة. الصورة التفصيلية خطوة بخطوة للمسار نفسه موجودة على /answers/topic/company-interviews.

أربعة أنماط تفسّر معظم الحالات، ولا علاقة لأي منها بالذكاء.

• قصص بلا قرار. وصف ما فعله فريق بدلاً مما اخترته أنت. تنتهي الملاحظات دون دليل مرتبط باسمك.
• بلا نتيجة. قصة تنتهي عند إطلاق المشروع، دون أي ذكر لما إذا كان قد نجح.
• نفاد المادة. إعادة استخدام المشروع نفسه في أربع جولات، وهو ما تلاحظه جلسة المراجعة رغم أن أياً من المحاورين بمفرده لم يلحظه.
• حل المشكلة بصمت. العمل على سؤال برمجي دون سرد التفكير بصوت مسموع، تاركاً المحاور بلا شيء يدوّنه.

يستحق الأمر أيضاً أن يُقال بوضوح إن مهندسين أكفاء يُرفضون هنا لأسباب لا علاقة لها بالكفاءة، منها ملاءمة الفريق وتركيبة اللجنة في ذلك اليوم. التحضير يغيّر الاحتمالات؛ لكنه لا يحسمها، والرفض ليس حكماً على قدرتك.