Amazon کا انٹرویو کتنا مشکل ہے؟

اگر آپ نے الگورتھم کے سوالوں کی خوب مشق کی ہے اور پھر بھی خود کو غیر تیار محسوس کرتے ہیں، تو یہ احساس درست ہے۔ یہ حصہ بتاتا ہے کہ اضافی مشکل کس چیز سے بنتی ہے، کیونکہ یہ سوالوں میں نہیں ہے، اور مزید سوالوں کی مشق اسے حل نہیں کرتی۔

Amazon ایک منظم عمل چلاتا ہے۔ انٹرویو لینے والوں کو جانچنے کے لیے مخصوص Leadership Principles تفویض کیے جاتے ہیں، وہ گفتگو کے دوران تفصیلی نوٹس لیتے ہیں، اور یہ نوٹس بعد میں ایک ڈی بریف میں موازنہ کیے جاتے ہیں۔ اس کے دو نتائج نکلتے ہیں۔ جو کہانی کمرے میں اچھی لگی تھی وہ کاغذ پر کمزور نظر آتی ہے اگر اس میں کوئی فیصلہ اور نتیجہ نہ ہو، اور وہی کہانی جو دو راؤنڈز میں مختلف تفصیلات کے ساتھ دو بار سنائی جائے، نوٹس کے موازنے پر فوراً پکڑی جاتی ہے۔

مشکل کا دوسرا سبب یہ ہے کہ رویے کا معیار تکنیکی راؤنڈز میں بھی لاگو ہوتا ہے۔ وہ امیدوار جو کوڈنگ کا سوال صاف طریقے سے حل کر لیتا ہے مگر کسی مینیجر سے اختلاف کا کوئی لمحہ بیان نہیں کر پاتا، اس نے ایک ایسے حصے میں ناکامی حاصل کی جسے خالصتاً تکنیکی انٹرویو کبھی جانچ ہی نہ پاتا۔

Bar Raiser بھرتی کرنے والی ٹیم سے باہر کا ایک انٹرویو لینے والا ہوتا ہے، جسے اس کردار کے لیے تربیت دی جاتی ہے، اور اس کا کام یہ جانچنا ہے کہ آیا آپ اس سطح پر پہلے سے موجود لوگوں کا اوسط بلند کرتے ہیں۔ وہ یہ نہیں جانچتا کہ اس سہ ماہی میں ٹیم کو ایک اور شخص کی ضرورت ہے یا نہیں، اور وہ hiring manager کی چاہی گئی بھرتی روک سکتا ہے۔

عملی طور پر اس کا مطلب یہ ہے کہ جو شخص آپ کا نتیجہ طے کرتا ہے اسے وہ عہدہ بھرنے میں کوئی دلچسپی نہیں ہوتی۔ عجلت آپ کی مدد نہیں کرتی، اور نہ ہی مینیجر کے ساتھ اچھا تعلق۔ جو چیز مدد کرتی ہے وہ ایسا ثبوت ہے جو لکھے جانے اور کسی ایسے شخص کے پڑھنے کے بعد بھی قائم رہے جو آپ سے کبھی نہیں ملا۔

عام طور پر آپ کو نہیں پتا چلتا کہ وہ کون سا انٹرویو لینے والا ہے، اور اس سے فرق نہیں پڑتا۔ ہر راؤنڈ کا جواب ایسے دیں جیسے اسے بعد میں کوئی اجنبی پڑھے گا، کیونکہ ایسا ہی ہوتا ہے۔

کام کو دو حصوں میں بانٹ دیں۔ تکنیکی حصہ وہی جانا پہچانا ہے: ڈیٹا سٹرکچرز، الگورتھمز، اور مڈ لیول اور اس سے اوپر کے لیے سسٹم ڈیزائن۔ زیادہ تر ناکام ہونے والے امیدوار یہاں ناکام نہیں ہوتے۔

رویے والے حصے کے لیے Leadership Principles میں پھیلی آٹھ سے بارہ کہانیاں چاہییں، ہر ایک میں صورتحال، جو آپ نے ذاتی طور پر فیصلہ کیا، اور قابلِ پیمائش نتیجہ شامل ہو۔ ایک ہی پراجیکٹ مختلف زاویوں سے دو یا تین کہانیاں دے سکتا ہے۔ نتیجہ جہاں بھی موجود ہو اسے عدد کی صورت میں لکھیں، کیونکہ فالو اپ سوال عموماً بالکل یہی مانگتا ہے۔

پھر انہیں اونچی آواز میں دہرائیں۔ نو سال کے تجربے والی ایک بیک اینڈ انجینیئر نے بہترین نوٹس لکھے تھے مگر پھر بھی اپنی پہلی مشق میں اٹک گئی، کیونکہ کہانی پڑھنا اور فالو اپ سوال کے تحت اسے سنانا الگ الگ مہارتیں ہیں۔ /mock-interview پر دو ہفتے کی زبانی مشق نے پیشکش کو ایک اور مہینے کی پڑھائی سے کہیں زیادہ بدل دیا۔ خود اس عمل کی مرحلہ وار تصویر /answers/topic/company-interviews پر موجود ہے۔

چار طرزیں زیادہ تر معاملات کی وضاحت کرتی ہیں، اور ان میں سے کوئی بھی ذہانت کے بارے میں نہیں ہے۔

• فیصلے کے بغیر کہانیاں۔ یہ بتانا کہ ٹیم نے کیا کیا، نہ کہ آپ نے کیا چنا۔ نوٹس آخر میں آپ کے نام سے جڑے کسی ثبوت کے بغیر رہ جاتے ہیں۔
• کوئی نتیجہ نہیں۔ ایسی کہانی جو پراجیکٹ کی ڈیلیوری پر ختم ہو جائے، اس بارے میں کچھ بتائے بغیر کہ وہ کامیاب رہا یا نہیں۔
• مواد ختم ہو جانا۔ ایک ہی پراجیکٹ کو چار راؤنڈز میں دہرانا، جو ڈی بریف میں نظر آ جاتا ہے چاہے کسی اکیلے انٹرویو لینے والے نے اسے نوٹ نہ کیا ہو۔
• خاموشی سے مسئلہ حل کرنا۔ کوڈنگ کا سوال بغیر سوچ کو زبانی بیان کیے حل کرنا، جس سے انٹرویو لینے والے کے پاس نوٹ کرنے کو کچھ نہیں بچتا۔

یہ صاف طور پر کہنا بھی ضروری ہے کہ قابل انجینیئرز یہاں ایسی وجوہات سے رد کیے جاتے ہیں جن کا صلاحیت سے کوئی تعلق نہیں، جیسے ٹیم فٹ اور اس دن کے پینل کی ترکیب۔ تیاری امکانات بدلتی ہے؛ وہ انہیں طے نہیں کرتی، اور رد ہونا آپ کی صلاحیت پر کوئی فیصلہ نہیں ہے۔