Amazon Mülakatı Ne Kadar Zor?

Algoritma sorularıyla uğraşıp hâlâ hazır hissetmiyorsanız, bu içgüdü doğru. Bu bölüm, ekstra zorluğun neyden oluştuğunu açıklıyor; çünkü sorun sorularda değil ve daha fazlasını çözmek bunu çözmüyor.

Amazon yapılandırılmış bir süreç yürütür. Mülakatçılara sorgulayacakları belirli Leadership Principles atanır, görüşme sırasında ayrıntılı notlar alırlar ve bu notlar sonradan bir değerlendirme toplantısında karşılaştırılır. Bunun iki sonucu vardır. Odada gayet iyi görünen bir hikaye, içinde bir karar ve bir sonuç yoksa kağıt üzerinde zayıf görünür; aynı hikayenin iki turda farklı ayrıntılarla anlatılması, notlar karşılaştırıldığında hemen ortaya çıkar.

Zorluğun diğer kaynağı, davranışsal barın teknik turlarda da geçerli olmasıdır. Kodlama sorusunu düzgünce çözen ama bir yöneticiyle anlaşmazlığa düştüğü bir anı anlatamayan bir aday, tamamen teknik bir mülakatın asla ölçmeyeceği bir bileşende başarısız olmuş demektir.

Bar Raiser (standardı yükselten kişi), işe alım ekibinin dışından, bu rol için eğitilmiş bir mülakatçıdır ve görevi, sizin o seviyedeki mevcut kişilerin ortalamasını yükseltip yükseltmediğinizi değerlendirmektir. Ekibin bu çeyrekte bir kişiye ihtiyacı olup olmadığını değerlendirmezler ve işe alım yöneticisinin istediği bir işe alımı engelleyebilirler.

Pratikte bu, sonucunuza karar veren kişinin pozisyonu doldurmakta hiçbir çıkarı olmadığı anlamına gelir. Aciliyet size yardımcı olmaz, yöneticiyle kurduğunuz yakınlık da olmaz. Yardımcı olan şey, yazıya geçirildiğinde ve sizi hiç tanımayan biri tarafından okunduğunda ayakta kalan kanıttır.

Genellikle hangi mülakatçı olduğunu anlayamazsınız ve bu önemli değildir. Her turu, daha sonra bir yabancı tarafından okunacakmış gibi yanıtlayın; çünkü öyle.

İşi ikiye bölün. Teknik yarı tanıdık olandır: veri yapıları, algoritmalar ve orta seviye ile üzeri için sistem tasarımı. Başarısız olan adayların çoğu burada başarısız olmadı.

Davranışsal yarı, Leadership Principles'a yayılmış sekiz ila on iki hikaye gerektirir; her birinde durum, kişisel olarak ne karar verdiğiniz ve ölçülebilir sonuç bulunur. Tek bir proje farklı açılardan iki veya üç hikaye sağlayabilir. Sonucu mümkün olduğunda bir sayı olarak yazın, çünkü takip sorusu genellikle tam olarak bunu ister.

Sonra bunları sesli olarak prova edin. Dokuz yıllık deneyime sahip bir back-end mühendisi mükemmel notlar yazdı ama ilk prova turunda yine de takıldı; çünkü bir hikayeyi okumak ile onu bir takip sorusu altında anlatmak farklı becerilerdir. /mock-interview'da iki haftalık sözlü pratik, bir ay daha okumaktan daha fazla değişiklik yarattı. Sürecin aşama aşama görünümü /answers/topic/company-interviews adresinde.

Bunun büyük kısmını dört kalıp açıklıyor ve hiçbiri zekayla ilgili değil.

• Kararsız hikayeler. Sizin ne seçtiğinizi değil, bir ekibin ne yaptığını anlatmak. Notlarda adınıza bağlı hiçbir kanıt kalmaz.
• Sonuç yok. Proje teslim edildiğinde biten, işe yarayıp yaramadığı hakkında hiçbir şey söylemeyen bir hikaye.
• Malzemenin tükenmesi. Aynı projeyi dört turda yeniden kullanmak; hiçbir tek mülakatçı fark etmese bile değerlendirme toplantısı bunu görür.
• Sessiz problem çözme. Bir kodlama sorusunu düşünme sürecini anlatmadan çözmek, mülakatçıya not alacak hiçbir şey bırakmaz.

Yetenekli mühendislerin burada yetenekle hiç ilgisi olmayan nedenlerle, ekip uyumu ve o günkü panelin bileşimi dahil, reddedildiğini de açıkça söylemekte fayda var. Hazırlık, olasılıkları değiştirir; onları kesinleştirmez ve bir ret, yeteneğinize dair bir hüküm değildir.