บทเรียนจากการสัมภาษณ์ราว 1,000 ครั้งที่ Amazon

• บทความวิเคราะห์จากประสบการณ์ทำงานที่ Amazon นาน 17 ปี และสัมภาษณ์งานราว 1,000 ครั้ง (ในจำนวนนี้ประมาณ 600 ครั้งเป็นการสัมภาษณ์แบบ Bar Raiser) ว่าอะไรคือสิ่งที่มีผลต่อการตัดสินใจจ้างมากกว่าการสัมภาษณ์ด้านเทคนิค
• เหตุผลหลักที่ผู้สมัครซึ่งเก่งด้านเทคนิคต้องตกไป ไม่ใช่เพราะขาดทักษะ แต่เป็นปัญหาเรื่อง วิธีนำเสนอตัวเอง
• จุดบอดใหญ่ที่สุดคือ ผู้สมัครมักใช้เวลาเตรียมตัว 95% ไปกับด้านเทคนิค แต่แทบไม่ใช้เวลากับการเตรียม การสัมภาษณ์เชิงพฤติกรรม
• การสัมภาษณ์ไม่ใช่การสอบ แต่ใกล้เคียงกับการ ออดิชัน เพื่อดูว่า "เราอยากร่วมงานกับคนนี้ไหม"
• สิ่งหลักที่บริษัทประเมินในการสัมภาษณ์เชิงพฤติกรรมคือ ความเหมาะกับบทบาท ความเหมาะกับองค์กร และการประเมินระดับ ซึ่งถ้าเข้าใจเรื่องนี้ก็จะเลือกเรื่องเล่าที่ดีกว่าได้

---

แพตเทิร์นสำคัญที่พบจากการสัมภาษณ์แบบ Bar Raiser

• Bar Raiser คือผู้สัมภาษณ์ที่ผ่านการฝึกเป็นพิเศษและมาจากนอกทีมที่กำลังจ้างงาน มีหน้าที่ตรวจสอบว่าคนที่รับเข้ามาใหม่จะช่วยยกระดับมาตรฐานบุคลากรของ Amazon ได้หรือไม่
• มี สิทธิ์วีโต้ ผู้สมัครทุกคน และเข้าร่วม interview loop ได้ทุกระดับ ตั้งแต่นักศึกษาฝึกงานไปจนถึง Principal Engineer
• หลังทำ Bar Raiser interview ราว 50 ครั้ง ก็เห็นแพตเทิร์นชัดเจนว่า ผู้สมัครส่วนใหญ่ที่ไม่ได้ข้อเสนอ ไม่ได้แพ้เพราะความสามารถทางเทคนิคไม่พอ แต่แพ้เพราะ สื่อสารตัวเองไม่สำเร็จ
• เมื่อมาถึงรอบสุดท้ายแล้ว แปลว่าผ่าน technical screen หรือ assignment มาแล้ว ดังนั้นคำถามสำคัญจริง ๆ ของรอบสุดท้ายคือ "ทีมนี้อยากร่วมงานกับคนนี้ไหม"

• บทเรียนที่ 1: เตรียมมากเกินไปกับสัมภาษณ์ด้านหนึ่ง แต่น้อยเกินไปกับอีกด้าน

  • ผู้สมัครทั่วไปใช้เวลา 95% ไปกับการเตรียมด้านเทคนิค และอีก 5% กับอย่างอื่น บางคนไม่เตรียมส่วนที่ไม่ใช่เทคนิคเลย
  • การเตรียมด้านเทคนิคดึงดูดใจเพราะเป็นรูปธรรมและวัดความคืบหน้าได้ แต่โจทย์โค้ดดิ้งแม้จะไม่เคยเห็นมาก่อน ก็ยังพอใช้ hint ช่วยคิดต่อได้
  • แต่ในการสัมภาษณ์เชิงพฤติกรรม หากถูกถามว่า "ตอนที่โปรเจกต์มีปัญหา คุณรับมืออย่างไร" แล้ว ไม่มีเรื่องที่เตรียมไว้ ก็แทบตอบสดไม่ได้
    • ไม่มี hint ให้ ไม่มีการอนุมานแบบเรียลไทม์ และถ้าไม่เตรียมไว้ก็มักตอบแบบกระจัดกระจาย
  • มีให้เห็นนับร้อยครั้งว่าผู้สมัครที่ผ่านรอบโค้ดดิ้งได้ดี กลับพังตอนถูกถามเรื่องประสบการณ์
    • ฟีดแบ็กใน debrief มักเป็นว่า: "ดึงคำตอบที่เป็นรูปธรรมออกมาไม่ได้เลย ทุกเรื่องคลุมเครือและไม่น่าเชื่อถือ"
  • การเตรียมส่วนที่ไม่ใช่เทคนิคใช้เวลาน้อยกว่ามาก: จากเวลาเตรียมสัมภาษณ์ 80–100 ชั่วโมง ถ้าแบ่งแค่สุดสัปดาห์เดียว (ประมาณ 10 ชั่วโมง) มาเตรียมเรื่องเล่า ผลลัพธ์ของ behavioral interview อาจเปลี่ยนไปอย่างสิ้นเชิง
  • ผลตอบแทนจากการเตรียมด้านเทคนิคจะ ลดลงอย่างรวดเร็ว แต่ผลตอบแทนจากการเตรียมเรื่องเล่ากลับ พุ่งแบบทวีคูณ เพราะแทบไม่มีใครทำ

• บทเรียนที่ 2: วิธีเล่าเรื่องสำคัญพอ ๆ กับตัวเรื่องเอง

  • ต่อให้เป็นผลงานที่น่าประทับใจแค่ไหน ก็สูญเปล่าได้ถ้าถ่ายทอดไม่ดี และรูปแบบล้มเหลวที่พบบ่อยที่สุดคือ "ramble and stumble" (พูดวกวน ติดขัด)
    • เช่น ผู้สมัครเล่าไปพร้อมกับเหมือนกำลังประกอบเรื่องอยู่ตรงนั้น หรืออธิบายบริบท 5 นาทีแล้วค่อยกลับมาเติมรายละเอียดที่ลืมไป
  • เวลาทำ presentation สำคัญในงาน คนเรามักเตรียมโครงสร้าง ลำดับ และประเด็นหลักพร้อมซ้อมมา แต่ เวลาเข้าสัมภาษณ์กลับด้นสดกันเยอะ
  • หลายคนรู้สึกว่าการเตรียมเรื่องเล่าสำหรับสัมภาษณ์ดู "ไม่เป็นธรรมชาติ" หรือ "เหมือนหลอก" แต่เหมือนนักดนตรีที่ซ้อมก่อนขึ้นคอนเสิร์ต การ ฝึกซ้อมไม่เกี่ยวกับความจริงใจ
  • วิธีปฏิบัติ: เริ่มจากสองคำถามคือ "แนะนำตัวเอง" และ "ทำไมถึงอยากทำงานที่บริษัทนี้"
    • เขียนคำตอบ อัดวิดีโอ แล้วกลับมาดูว่าเริ่มยืดยาวตรงไหน มีคำติดปากที่ไม่จำเป็นหรือไม่
    • ทำซ้ำจนฟังแล้วรู้สึกว่า "อยากร่วมงานกับคนนี้"
  • การฝึกแบบนี้ 30 นาที อาจช่วยเพิ่มผลงานในการสัมภาษณ์ได้มากกว่าฝึกโค้ดดิ้ง 20 ชั่วโมง

• บทเรียนที่ 3: การสัมภาษณ์คือออดิชันว่าถ้าร่วมงานกันจะเป็นอย่างไร

  • ผู้สมัครส่วนใหญ่มองการสัมภาษณ์เป็น การสอบ แต่จริง ๆ ไม่ใช่กระบวนการที่มีเฉลยตายตัว มันคือกระบวนการที่ผู้สัมภาษณ์กำลังก่อตัวความประทับใจ
  • หน้าที่เฉพาะของ Bar Raiser คือประเมินว่าผู้สมัคร ดีกว่าพนักงานครึ่งบน 50% ที่มีอยู่ในบทบาทนั้นหรือไม่
  • โจทย์โค้ดดิ้งในการสัมภาษณ์อาจไม่เหมือนงานจริง แต่ คำถามเชิงพฤติกรรมคือสถานการณ์ที่เจอทุกวัน เช่น การแก้ความเห็นไม่ตรงกัน การรับมือวิกฤตโปรเจกต์ หรือการตัดสินใจด้วยข้อมูลไม่ครบ
    • เมื่อถามถึง "ประสบการณ์ที่ต้องเสนอความเห็นต่างกับผู้มีส่วนได้ส่วนเสีย" ผู้สัมภาษณ์กำลังจินตนาการถึงคน ๆ นี้ใน planning meeting ครั้งถัดไป
    • เมื่ออธิบายวิธีรับมือความขัดแย้งในทีม ผู้สัมภาษณ์กำลังถามตัวเองว่า "อยากอยู่ห้องเดียวกับคนนี้ไหม"
  • ผู้สมัครที่เข้าหาแบบการสอบ มักพยายามเดาคำตอบที่ผู้สัมภาษณ์อยากได้ แล้วให้คำตอบที่ลื่นไหลและไร้เหลี่ยมมุม
    • ผลลัพธ์คือความไม่แน่ใจว่า "ถ้าทำงานกับคนนี้จริงจะเป็นอย่างไร" → ส่วนใหญ่ลงเอยที่ "No"
  • วิธีปฏิบัติ: อย่าเตรียมเรื่องโดยยึดจากสิ่งที่คิดว่าผู้สัมภาษณ์อยากฟัง แต่ให้ยึดจากสิ่งที่ คุณเองอยากได้ยินจากคนที่จะเข้ามาร่วมทีม
    • เล่า เวอร์ชันจริง อย่างตรงไปตรงมา รวมถึงส่วนที่ยากและจังหวะตัดสินใจที่เฉียด ๆ

ข้อสรุปสำคัญจากการสัมภาษณ์ราว 1,000 ครั้ง

• คนที่ได้งานคือคนที่เดินเข้าห้องมาแล้วเล่าเรื่องงานและความสามารถของตัวเองได้อย่างชัดเจน จนผู้สัมภาษณ์รู้สึกว่า "อยากร่วมงานกับคนนี้"
• ความสามารถในการเล่าเรื่องเป็น ทักษะที่พัฒนาได้ด้วยการฝึก แต่คนส่วนใหญ่มักไม่คิดว่านี่คือสิ่งที่เตรียมได้ จึงไม่ฝึก
• แค่เตรียมเพิ่มอีกนิด ก็อาจให้ผลมากกว่าสิ่งอื่นแทบทุกอย่างที่คุณทำได้ในเส้นทางอาชีพ

สิ่งที่บริษัทมองหาในการสัมภาษณ์เชิงพฤติกรรม

• ข้อเสนอจ้างไม่ได้ตัดสินจากความสามารถทางเทคนิคเพียงอย่างเดียว บริษัทใช้ behavioral interview เพื่อตอบคำถามหลักสองข้อคือ "เหมาะกับบทบาทและบริษัทไหม?" และ "จะมีประสิทธิภาพที่สุดในระดับไหน?"
• ถ้า fit ไม่ตรง ต่อให้เก่งเทคนิคก็อาจไม่ผ่าน และถ้าประเมินระดับผิดก็อาจถูก downlevel หรือถูกปฏิเสธว่าไม่ถึงเกณฑ์

• ทำความเข้าใจเรื่อง fit: ความเหมาะกับบทบาทและความเหมาะกับองค์กร

  • Role Fit: รับมือกับความท้าทายเฉพาะและเงื่อนไขการทำงานของตำแหน่งนั้นได้หรือไม่
    • งาน backend ในสตาร์ตอัปที่โตเร็วกับงาน backend ในองค์กรใหญ่ อาจใช้ทักษะคล้ายกัน แต่สิ่งที่คาดหวังต่างกัน
  • Company Fit: จะประสบความสำเร็จได้ไหมในสภาพแวดล้อมขององค์กรนั้น
    • เป็นการประเมินว่าสไตล์การทำงาน วิธีตัดสินใจ และค่านิยม สอดคล้องกับวิธีทำงานของบริษัทหรือไม่

• บริษัทจับสัญญาณเรื่อง fit อย่างไร

  • บริษัทถามตรง ๆ ว่า "เหมาะกับบริษัทเราไหม" ไม่ได้ จึงต้องมองหา สัญญาณของความสอดคล้องหรือไม่สอดคล้อง จากเรื่องเล่าของผู้สมัคร
  • สัญญาณด้าน Role Fit: ความสบายใจกับ requirement ที่คลุมเครือ ความสามารถในการประสานงานข้ามทีม ความเร็วในการ iterate และรับฟีดแบ็ก
  • สัญญาณด้าน Company Fit: ปรากฏจากตัวเลือกที่ผู้สมัครตัดสินใจ และวิธีที่อธิบายตัวเลือกนั้น
    • บริษัทที่ให้ความสำคัญกับ bias for action จะชอบเรื่องที่แสดงว่าคุณขยับเร็วแม้ข้อมูลยังไม่ครบ
    • บริษัทที่ให้ความสำคัญกับ customer obsession จะอยากเห็นตัวอย่างที่คุณขุดลึกถึงความต้องการของผู้ใช้
    • บริษัทที่เน้น radical transparency จะมองหาเรื่องที่คุณเลือกแชร์ข้อมูลอย่างเปิดเผย แม้จะเป็นเรื่องไม่สบายใจ
  • เรื่องเดียวกันอาจส่งสัญญาณต่างกันในแต่ละบริษัท: การใช้เวลา 3 สัปดาห์ขัดเกลา solution ให้สมบูรณ์ อาจถูกมองว่า ใส่ใจคุณภาพ ในบริษัทหนึ่ง แต่ถูกมองว่า analysis paralysis ในอีกบริษัทหนึ่ง

• รูปแบบ mis-fit ที่พบบ่อย

  • อิสระ vs. การทำงานร่วมกัน: สไตล์แก้ปัญหาคนเดียวแล้วค่อยกลับมา เทียบกับสไตล์ดึงทีมเข้ามาทุกขั้นตอน
    • ถ้าทุกเรื่องเล่าเป็นงานเดี่ยวทั้งหมด ก็อาจน่ากังวลสำหรับบริษัทที่เน้นฉันทามติ ในทางกลับกัน ถ้าทุกเรื่องต้องรอการยืนยันจากกลุ่ม ก็อาจน่ากังวลสำหรับบริษัทที่เน้น ownership รายบุคคล
  • ความเร็ว vs. ความรอบคอบ: การทดลองเร็วและทำ MVP แบบสตาร์ตอัป เทียบกับการตรวจสอบอย่างระมัดระวังในสายการแพทย์หรือการเงิน
    • รวมถึงมุมมองเรื่องคุณภาพโค้ด: จะเพิ่มเวลาเพื่อสถาปัตยกรรมที่สะอาด หรือจะให้น้ำหนักกับ solution ที่ใช้งานได้ทันเวลา
  • ความเป็นเลิศ vs. ความปฏิบัติได้จริง: ให้ความสำคัญสูงสุดกับความสมบูรณ์ทางเทคนิคและสถาปัตยกรรมที่สะอาด เทียบกับทางออกเชิงปฏิบัติที่ส่งออกได้ตามกำหนดแม้ไม่สมบูรณ์
  • นวัตกรรม vs. เสถียรภาพ: สร้างทางออกใหม่และท้าทายวิธีเดิม เทียบกับการดูแลและเพิ่มประสิทธิภาพระบบที่พิสูจน์แล้ว
  • ตรงไปตรงมา vs. มีชั้นเชิงทางการทูต: วัฒนธรรมแบบ radical candor ที่พูดตรงตามคิด เทียบกับวัฒนธรรมที่เน้นความกลมกลืนและการรักษาหน้า
  • ข้อมูล vs. สัญชาตญาณ: วัฒนธรรมที่ต้องการข้อมูลรองรับทุกการตัดสินใจ เทียบกับวัฒนธรรมที่เชื่อการตัดสินใจจากประสบการณ์
  • ผู้เชี่ยวชาญเฉพาะทาง vs. Generalist: ความเชี่ยวชาญลึกในโดเมนเดียวแบบองค์กรใหญ่ เทียบกับความสามารถทำ หลายบทบาท ในบริษัทขนาดเล็ก

4 มิติที่ใช้ตัดสินระดับ

• ประเมินระดับของผู้สมัครจาก 4 มิติที่ปรากฏในทุกเรื่องเล่า และมิติเหล่านี้ร่วมกันบอกว่าคุณจะทำงานได้มีประสิทธิภาพที่สุดในตำแหน่งไหน

• Scope (ขอบเขต)

  • วัด จำนวนคนและขอบเขต ที่งานนั้นส่งผลกระทบ
  • Entry Level: เพิ่มประสิทธิภาพการทำงานของตัวเอง ช่วยเพื่อนร่วมทีมไม่กี่คน
  • Mid Level: ส่งผลต่อบางส่วนของวิธีทำงานของทีม
  • Senior Level: ส่งผลโดยตรงต่อทั้งทีม และเริ่มขยายอิทธิพลไปอย่างน้อยอีกหนึ่งทีม ทำงานใกล้ชิดกับ partner ฝั่ง product และ design
  • Staff Level: ส่งผลโดยตรงอย่างน้อยสองทีม และขยายไปยังองค์กรในวงกว้างขึ้น มีอิทธิพลข้ามไปนอก engineering ถึง product, design และ program management
  • Principal Level: เปลี่ยนวิธีทำงานของหลายทีมหรือส่วนงานใหญ่ขององค์กร และขยายอิทธิพลไปถึงกลยุทธ์ธุรกิจ

• Contribution (การมีส่วนร่วม)

  • วัด สิ่งที่ตัวคุณทำจริง โดยแยกเส้นแบ่งระหว่าง "ฉัน" กับ "พวกเรา" ให้ชัด
  • Entry Level: ทำงานที่ได้รับมอบหมาย รับผิดชอบเต็มตัวต่อฟีเจอร์ที่นิยามชัดเจน
  • Mid Level: เป็นเจ้าของ solution แบบครบวงจรตั้งแต่ระบุปัญหาจนถึงลงมือทำ พร้อมกับช่วยชี้แนะคนอื่น
  • Senior Level: นำ initiative ที่ต้องอาศัยการประสานงาน และพางานเดินหน้าได้แม้ requirement ยังไม่ชัดหรือทิศทางยังไม่แน่นอน
  • Staff Level: นำ initiative ข้ามทีม วางทิศทางทางเทคนิค และรับมือสถานการณ์ที่ลำดับความสำคัญของ stakeholder ขัดกัน
  • Principal Level: สร้างขีดความสามารถระดับองค์กร กำหนดวิธีทำงานใหม่ และทำงานในสภาพแวดล้อมที่คลุมเครือสูงซึ่งต้อง นิยามตัวปัญหาเอง

• Impact (ผลกระทบ)

  • แสดงว่า มีอะไรดีขึ้นบ้าง จากผลงานของคุณ และสำคัญมากที่จะใส่ตัวเลขเชื่อมผลลัพธ์ทางเทคนิคเข้ากับผลลัพธ์ทางธุรกิจหรือผู้ใช้
  • Entry Level: เพิ่ม productivity ส่วนบุคคล ลดเวลางานซ้ำซาก ป้องกันบั๊ก ฯลฯ
  • Mid Level: ปรับปรุงเชิงปริมาณที่วัดได้ในบางพื้นที่ของทีม เช่น ลดเวลา deploy หรือสร้างเครื่องมือใหม่
  • Senior Level: เปลี่ยนวิธีทำงานของทั้งทีม ขยายผลไปยังทีมข้างเคียง และส่งผลไปถึงผลลัพธ์ของผลิตภัณฑ์ ประสบการณ์ผู้ใช้ หรือค่าใช้จ่ายในการดำเนินงาน
  • Staff Level: ปรับปรุงการทำงานของหลายทีม และเชื่อมโยงผลกระทบกับ ตัวชี้วัดทางธุรกิจ เช่น รายได้ การรักษาลูกค้า หรือความเร็วในการออกสู่ตลาด
  • Principal Level: สร้างขีดความสามารถระดับองค์กร ขับเคลื่อนการเปลี่ยนแปลงเชิงกลยุทธ์ และวัดผลด้วยผลลัพธ์ทางธุรกิจรวมถึงความสามารถเชิงกลยุทธ์

• Difficulty (ความยาก)

  • สะท้อน ความซับซ้อน ข้อจำกัด และ trade-off ของปัญหาที่คุณแก้ และบางครั้งปัญหายากที่แก้ได้ดีน่าประทับใจกว่าปัญหาง่ายที่มีผลกระทบใหญ่
  • Entry Level: ปัญหาที่ตรงไปตรงมาภายใต้ pattern ที่มีอยู่แล้ว เช่น เรียนรู้เทคโนโลยีใหม่หรือ debug โค้ดที่ไม่คุ้นเคย
  • Mid Level: ปัญหาที่มีชิ้นส่วนเคลื่อนไหวมากขึ้นและทางแก้ไม่ชัดเจน ต้องรับมือ requirement ที่ขัดกันหรือความซับซ้อนทางเทคนิคที่ไม่เคยเจอมาก่อน
  • Senior Level: บริหารข้อจำกัดที่เกิดจากหลายระบบปฏิสัมพันธ์กัน ตัดสินใจด้านสถาปัตยกรรมระดับทีม และต้องคำนึงทั้งปัจจัยทางเทคนิคและธุรกิจ
  • Staff Level: บริหาร trade-off ที่ขัดกันข้ามหลายทีม และถ่วงดุลแนวทางเทคนิคหลายแบบเมื่อความต้องการของทีมขัดกันจริง
  • Principal Level: รับมือ trade-off เชิงพื้นฐานระหว่างความต้องการระดับองค์กร แก้ ปัญหาใหม่ ที่ไม่มี pattern หรือบรรทัดฐานมาก่อน และตัดสินใจระดับกลยุทธ์บริษัทที่ต้องได้รับการอนุมัติจากผู้บริหาร

รีเสิร์ชสิ่งที่บริษัทให้ความสำคัญจริง ๆ

• ไม่มีทางได้ข้อมูลที่สมบูรณ์แบบ แต่แค่รีเสิร์ชแบบมีจุดโฟกัสเพียงเล็กน้อย ก็อาจได้ insight ที่ผู้สมัครส่วนใหญ่พลาด

• ใช้ประโยชน์จาก recruiter

  • ผู้สมัครจำนวนมากมอง recruiter เป็นแค่ ด่านผ่านเข้าออก แต่จริง ๆ แล้วคือแหล่งข้อมูลภายในที่ดีที่สุด
  • ผลงานของ recruiter วัดจากจำนวน offer ที่ผู้สมัครตอบรับ ดังนั้น recruiter อยากให้คุณสำเร็จ
  • คำถามที่ควรถามตรง ๆ: "ความท้าทายหลักของบริษัทตอนนี้คืออะไร" , "ความสามารถอะไรสำคัญที่สุดสำหรับบทบาทนี้" , "มีเอกสารเตรียมสัมภาษณ์ที่แชร์ให้ได้ไหม"
  • ตัวอย่างคำถามในเอกสารเตรียมตัวมัก มีโอกาสสูงมากที่จะถูกถามจริงในการสัมภาษณ์

• ใช้ข้อมูลสาธารณะ

  • คำที่ปรากฏซ้ำในประกาศรับสมัครงานบอกได้ว่าบริษัทให้ค่าน้ำหนักกับอะไร: "fast-paced" กับ "compliance" ส่งสัญญาณคนละแบบมาก
  • จุดที่ควรดู: engineering blog (บริษัทฉลองความสำเร็จแบบไหน), tech talk หรือ conference (หัวข้อที่ไปพูด), การมีส่วนร่วมใน open source (บริษัทเปิดอะไรออกมา), เอกสารเทคนิค (คุณภาพของเอกสาร public API), status page และ postmortem (มีวัฒนธรรมเรียนรู้จากความล้มเหลวหรือไม่)
  • ต่อให้ไม่มี engineering blog ก็ยังพอมองลำดับความสำคัญได้จากรูปแบบการออกผลิตภัณฑ์ (ความเร็วในการพัฒนา) และตัวเลือกทางเทคนิค (นวัตกรรม vs. เสถียรภาพ)

• วิเคราะห์แพตเทิร์นจากการพูดคุย

  • ใน Glassdoor, Blind, Reddit ให้มองข้ามคำบ่นรายโพสต์ แล้วหาว่า แพตเทิร์น อะไรโผล่ซ้ำหลายครั้ง
  • คำบ่นว่า "ประชุมเยอะเกินไป" อาจสะท้อนวัฒนธรรมที่เน้น collaboration/consensus หรืออาจสะท้อนว่าประชุมมากจน productivity ลดลง
  • คำชมเรื่อง "อิสระในการทำงาน" บ่งชี้สภาพแวดล้อมที่ได้รับความไว้วางใจให้ตัดสินใจได้โดยไม่ต้องคอยขออนุมัติ

• คุยกับพนักงานปัจจุบัน

  • อย่าถามเรื่องวัฒนธรรมแบบผิวเผิน แต่ให้ถามแบบเฉพาะเจาะจง
    • "คนที่ได้เลื่อนตำแหน่งที่นี่ เขาทำอะไรถึงได้เลื่อน?"
    • "พฤติกรรมแบบไหนที่มักได้รับฟีดแบ็กเชิงลบ?"
    • "เวลามีความเห็นไม่ตรงกัน ทีมตัดสินใจกันอย่างไร?"
    • "อะไรคือเรื่องที่คุณประหลาดใจที่สุดหลังมาทำงานที่นี่?"
  • พนักงานปัจจุบันจะบอกความจริงที่ไม่มีวันรู้จากเว็บไซต์บริษัท เช่น "customer obsession" ในทางปฏิบัติอาจหมายถึงต้องเช็ก usage data ก่อนเขียนโค้ด หรือ "ownership" อาจหมายถึงต้องพร้อมตื่นมาตามแก้ production issue ตอนตีสอง

• เป้าหมายสูงสุดของการรีเสิร์ช

  • การรีเสิร์ชทั้งหมดมีเป้าหมายเดียวคือ หาว่าเรื่องเล่าแบบไหนจะสร้างความเชื่อมโยงในห้องสัมภาษณ์ได้
  • ถ้าบริษัทให้คุณค่ากับความเร็ว ก็เน้นเรื่องที่คุณปล่อยงานเร็วและ iterate ต่อ ถ้าให้ค่ากับความลึกทางเทคนิค ก็เน้นกรณีที่คุณขุดถึงรากของปัญหา ถ้าให้ค่ากับ collaboration ก็โฟกัสงานข้ามทีม
  • การรีเสิร์ชยังช่วยตัดสินด้วยว่าบริษัทนั้นเหมาะกับคุณไหม: ถ้าบริษัทให้คุณค่ากับพฤติกรรมที่คุณไม่อยากพัฒนา หรือไม่สามารถแสดงออกได้อย่างเป็นธรรมชาติ การไล่ตามบทบาทนั้นอาจไม่จำเป็น

สรุป

• บริษัทไม่ได้ประเมินแค่ว่าคุณทำงานได้หรือไม่ แต่ประเมินทั้ง โอกาสที่จะประสบความสำเร็จ ในสภาพแวดล้อมนั้น และ ระดับ ที่คุณจะทำผลงานได้ดีที่สุด
• การเข้าใจเรื่อง fit ช่วยให้เลือกประสบการณ์ที่เชื่อมกับคุณค่าของบริษัทได้ดีที่สุด
• การเข้าใจเรื่อง level ช่วยให้วางตำแหน่งเรื่องเล่าได้เหมาะสม: โปรเจกต์เดียวกันอาจถูกมองเป็นการลงมือทำระดับ entry-level การเป็นเจ้าของระดับ mid-level หรือภาวะผู้นำระดับ senior-level ได้ ขึ้นอยู่กับ contribution จริงและการ framing
• เป้าหมายไม่ใช่ได้ offer อะไรก็ได้ แต่คือการได้ offer ที่ใช่ ในบริษัทที่ใช่ ในระดับที่ใช่ ซึ่งทำให้คุณมีโอกาสประสบความสำเร็จ