การสัมภาษณ์งานสายเทคนิคในยุค AI

• ในสถานการณ์ที่เครื่องมือ AI กำลังรุกเข้าสู่การเขียนโค้ดและการรีวิวอย่างรวดเร็ว ควร กีดกันการใช้ AI ในการสัมภาษณ์เป็นค่าเริ่มต้น และประเมินโดยยึดทักษะพื้นฐานเป็นหลัก
• การสัมภาษณ์ที่ดีประเมินได้จากสองแกนคือ คุณภาพของสัญญาณ (signal quality) และ ต้นทุนต่อบริษัท (cost to company) โดยทั้งสองปัจจัยไม่ได้เป็นอิสระจากกันโดยสมบูรณ์
• ประเภทของการสัมภาษณ์แบ่งเป็น 4 แบบ ได้แก่ Take-home, Live exercise, Presentation, Actual work ซึ่งแต่ละแบบมีคุณภาพของสัญญาณและต้นทุนต่างกัน
• ด้วย AI coding ทำให้ take-home ง่ายเกินไปและเพิ่มภาระในการรีวิว อีกทั้งเมื่อโจทย์รั่วไหล AI ก็ทำหน้าที่เป็นโค้ชที่ทรงพลังได้
• ความชำนาญในการใช้ AI เป็นเพียง instrumental skill (ทักษะเชิงเครื่องมือ) เท่านั้น ดังนั้นบริษัทควรโฟกัสที่การประเมิน foundational skill (ทักษะพื้นฐาน)

---

ประเด็นหลัก

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

สองมิติของการสัมภาษณ์ที่ดี

• คุณภาพของสัญญาณ (Signal quality)

  • ความสามารถในการระบุผู้สมัครที่แข็งแกร่งจากชุดทักษะที่กำหนด และมองข้าม noise (ปัจจัยที่ไม่ใช่แกนหลักของงานหรือสอนได้ง่าย)
  • ความทนทานต่อการเตรียมตัวเฉพาะเพื่อสอบ (Invulnerability to preparation): หากผลลัพธ์ขึ้นอยู่กับปริมาณการเตรียมตัวหรือความพยายาม เราก็จะได้สัญญาณเฉพาะคุณลักษณะนั้นเท่านั้น
  • ความสมจริง (Realism): การสัมภาษณ์ควรคล้ายงานประจำวัน แต่ไม่จำเป็นต้องเหมือนทั้งหมด "algorithm & data structure" แม้ไม่ได้ใช้ตรง ๆ ในงานจริงก็ยังอยู่รอดมานาน
  • ความเท่าเทียม (Equality): ผู้สมัครบางคนได้เปรียบกว่าจากความเชี่ยวชาญโดเมนล่วงหน้า เมนเทอร์แบบเสียเงิน เวลาว่าง ปัญหาที่รั่วไหลบนออนไลน์ หรือคนรู้จักที่เพิ่งเคยสอบมา ตามอุดมคติควรสร้างสภาพแวดล้อมที่ยุติธรรมกับทุกคน
  • ความยาก (Difficulty): การสัมภาษณ์ที่ดีควรยากพอที่คนส่วนใหญ่จะทำไม่สำเร็จ และสิ่งที่ดีที่สุดคือ ปัญหากว้างและคลุมเครือที่ต้องใช้หลายมุมมองเชิงลึก

• ต้นทุนต่อบริษัท (Cost to company)

  • คำถามสัมภาษณ์ต้องอาศัยการลงทุนเวลาอย่างมาก ทั้งการออกแบบร่างแรกและอนุมัติผ่านการทดลอง การทำ scorecard ตามตำแหน่งและระดับ การทดสอบกับผู้สมัครภายในและภายนอก รวมถึงการทำเอกสารและฝึกผู้สัมภาษณ์
  • คำถามและ scorecard ต้องมีการปรับเทียบอย่างต่อเนื่อง จึงต้องรักษาการลงทุนนี้ไว้ตลอด
  • ความยาก (Difficulty): การสร้างคำถามก็ยากอยู่แล้ว แต่การสร้างคำถามที่ยากได้พอดีนั้นยิ่งท้าทายกว่า ง่ายเกินไปหรือยากเกินไปล้วนเสียเวลาทุกฝ่าย
  • ความน่าสนใจสำหรับผู้สมัคร (Appeal to candidate): กระบวนการที่ใช้เวลามากเกินไปหรือคำถามที่น่าเบื่อจะผลักวิศวกรเก่ง ๆ ออกไปและทำให้อัตราการเปลี่ยนผ่านลดลง คำถามยังสะท้อนวัฒนธรรมวิศวกรรมของบริษัทด้วย
• ทั้งสองมิติไม่ได้เป็นอิสระจากกันโดยสมบูรณ์ เช่น ความยากส่งผลต่อทั้งสองด้าน การสัมภาษณ์ที่ยากช่วยให้ผู้สมัครที่แข็งแกร่งโดดเด่นขึ้น แต่ก็อาจทำให้เกิด false negative (การคัดออกผิดพลาด)
• การสัมภาษณ์ไม่จำเป็นต้องสมบูรณ์แบบ เพราะ false negative และ false positive มีอยู่เสมอ ระบุ false negative ได้ยาก แต่สามารถจัดการ false positive ได้เร็วผ่าน onboarding ที่ดีและ milestone ที่ชัดเจนในช่วงแรก

การจัดหมวดหมู่ประเภทการสัมภาษณ์

• Take-home

  • ผู้สมัครต้องส่ง (1) วิธีแก้ปัญหาที่คลุมเครือ เช่น product spec โดย (2) ปฏิบัติตามข้อจำกัดทางเทคนิคบางอย่าง เช่น รายการภาษาโปรแกรม
  • มักต่อด้วย การสัมภาษณ์แบบ review ที่ให้ผู้สมัครนำเสนองานและแก้ไขสดในหน้างาน
  • คุณภาพของสัญญาณ: (ก่อน AI) สูง — ให้สัญญาณกว้างทั้งการออกแบบ การเขียนโค้ด รายละเอียด และการทดสอบ การใช้เวลา 6 ชั่วโมงขึ้นไปยังพิสูจน์แรงจูงใจได้ด้วย
  • ต้นทุนต่อบริษัท: ปานกลาง — ทำระบบประเมินอัตโนมัติได้ และรีวิวผลลัพธ์ (โค้ด) แบบอะซิงก์ได้ แต่ก็อาจทำให้ผู้สมัครถอย
  • เปราะบางมากต่อ AI และผู้ที่มีแรงจูงใจจะเตรียมตัว

• Live exercise

  • เช่น algorithm & datastructure, live coding, system design, postmortem review ฯลฯ โดยทั่วไปใช้เวลา 1 ชั่วโมงขึ้นไป แก้โจทย์อย่าง "ออกแบบสถาปัตยกรรม Netflix" หรือ "เขียน rate-limiter" แบบสดต่อหน้าผู้สัมภาษณ์
  • คุณภาพของสัญญาณ: ปานกลาง — หากออกแบบและดำเนินการดีจะค่อนข้างเป็นกลาง แต่สัญญาณมักกระจุกอยู่ในหัวข้อเดียว
  • ต้นทุนต่อบริษัท: ปานกลาง — หากอยากลดผลกระทบจากการเตรียมตัวเฉพาะทาง ต้องมีคลังคำถามจำนวนมากและหลากหลาย
  • บางบริษัทใช้บริการอัตโนมัติเพื่อลดต้นทุน

• Presentation

  • ให้ผู้สมัครเลือกทั้งปัญหาและคำตอบเอง เช่น "อธิบายโปรเจกต์ที่คุณเป็นผู้นำ" "แผนภาพสถาปัตยกรรม" หรือ "ประสบการณ์ที่เคยทำเรื่อง ~"
  • คุณภาพของสัญญาณ: ต่ำ — มีรูปแบบความล้มเหลวหลายแบบ
    • ไม่เคยทำปัญหาที่น่าสนใจมาก่อน (เช่น ระดับจูเนียร์), เลือกปัญหาน่าเบื่อ, พูดเกินจริงเรื่องผลกระทบหรือบทบาท, เตรียมการนำเสนอไม่ดี, สื่อสารเก่งแต่ไม่ได้ลงมือทำจริง, หรือผู้สัมภาษณ์ไม่มีความรู้โดเมนพอจะประเมินได้แม่นยำ
  • ต้นทุนต่อบริษัท: ต่ำ — ในแง่การปรับเทียบมีสิ่งที่ต้องเตรียมไม่มาก
  • สามารถลดปัญหาคุณภาพสัญญาณต่ำได้ด้วยคำถามเชิงทบทวนอย่าง "ถ้าทำอีกครั้งจะทำต่างจากเดิมอย่างไร?" หรือคำถามสมมติอย่าง "ถ้าเปลี่ยน requirement X จะเกิดอะไรขึ้น?" ซึ่งทำให้มันใกล้เคียง live exercise ที่ยังไม่ปรับเทียบมากขึ้น แต่ก็ต้องใช้ความพยายามและความเชี่ยวชาญจากผู้สัมภาษณ์มากขึ้น

• Actual work (ไม่ใช่ประเภทการสัมภาษณ์)

  • รูปแบบทำงานร่วมกันจริง 1 สัปดาห์แบบมีค่าตอบแทน บริษัทอย่าง Linear ใช้วิธีนี้
  • คุณภาพของสัญญาณ: สูง / ต้นทุนต่อบริษัท: สูง
• บริษัทส่วนใหญ่มักผสมหลายประเภทเข้าด้วยกัน และ Live exercise เป็นรูปแบบที่เด่นที่สุด

โจทย์รั่วเป็นเรื่องของเวลาเท่านั้น (ไม่เกี่ยวกับ AI)

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

• กลยุทธ์รับมือ

  • ควบคุมการเตรียมตัว (Control the preparation): ใส่ presentation เข้าไปในชุดการประเมิน หรือให้คำแนะนำที่ละเอียด เช่น "system design จะเน้นฐานข้อมูล" หรือ "โจทย์อัลกอริทึมจะเป็นกราฟ" เพื่อสร้างความยุติธรรม
  • เพิ่มความหลากหลายของคำถามตามประเภท: เก็บคำถามเก่าเข้าคลังอย่างสม่ำเสมอ (archive) ถ้าผู้สมัครเดาโจทย์ไม่ตรง ก็ต้องขยายขอบเขตการเตรียมตัว ซึ่งนั่นคือเป้าหมาย แต่ไม่ได้ฟรี
  • ทำให้รั่วยากขึ้น (Make it harder to leak): จัดแบบ onsite ใช้ไวต์บอร์ด และวางคำถามที่เปราะบางที่สุดไว้ช่วงท้ายของกระบวนการ (เพราะมีผู้สมัครเหลือน้อยลง โอกาสรั่วจึงลดลง)

AI coding กำลังคุกคามโมเดลการสัมภาษณ์ในปัจจุบัน

• (1) Take-home กำลังง่ายเกินไปสำหรับผู้สมัคร และแพงเกินไปสำหรับบริษัท

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

• (2) เมื่อเวลาในการเขียนโค้ดลดลง ก็เป็นธรรมชาติที่จะลดสัดส่วนของ live-coding

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

• (3) ถ้าโจทย์รั่ว AI จะกลายเป็นโค้ชที่ทรงพลัง

  • ในอดีตการหาโจทย์และเตรียมตัวต้องใช้เวลาและทรัพยากรมาก แต่ตอนนี้ AI คือผู้ช่วยที่ทรงพลังที่สุดและราคาถูกที่สุด

วิธีที่ระบบประเมินแบบคลาสสิกของโรงเรียนต่อต้านเทคโนโลยี

• การสอบระดับมัธยมและมหาวิทยาลัยของฝรั่งเศสมีรูปแบบคล้ายเดิมเป็นส่วนใหญ่
  • ห้ามนำเอกสาร (เช่น เลกเชอร์หรือหนังสือ) เข้าไป เครื่องมือแทบไม่อนุญาตให้ใช้โดยเฉพาะเครื่องคิดเลข ไม่เปิดเผยเนื้อหาล่วงหน้า คาดเดาไม่ได้ (แต่ละข้อสอบต่างกันและใช้เพียงครั้งเดียว) และเป็นปัญหาที่กว้างและคลุมเครือ
  • แก่นของข้อสอบวรรณคดีฝรั่งเศสคือ dissertation ที่ให้เขียนเรียงความยาว 5–10 หน้า จากหัวข้อเพียงประโยคเดียว และมีมาตั้งแต่ปี 1830 ส่วนข้อสอบวิทยาศาสตร์ก็มีรูปแบบคล้ายกัน คือแก้ปัญหาคลุมเครือ 3–4 ข้อ
• มีการเสริมด้วยการประเมินรูปแบบอื่น เช่น take-home, คำถามความรู้แบบปรนัย, งานกลุ่ม, การนำเสนอ ฯลฯ แต่สิ่งเหล่านี้เป็นข้อยกเว้น ไม่ใช่หลักการหลัก
• เมื่อนำการจัดหมวดหมู่กลับมาใช้
  • คุณภาพของสัญญาณ: สูง — พื้นที่ของการเตรียมตัวกว้างมากและต้องใช้ความพยายามต่อเนื่อง
  • ต้นทุน: สูงมาก — ต้องออกแบบหัวข้อใหม่และแนวทางให้คะแนนทุกครั้ง และให้ผู้สมัครทุกคนสอบพร้อมกันแบบข้อสอบเดียวกัน (ซึ่งไม่สมจริงอย่างยิ่งสำหรับการสัมภาษณ์บริษัท)
• สิ่งที่น่าสนใจคือ แม้เครื่องมือทางปัญญาอย่างการคัดลอก-วาง อินเทอร์เน็ต เครื่องคิดเลข หรือ solver จะก้าวหน้ากระโดด ระบบนี้ก็แทบไม่เปลี่ยน
  • การศึกษาควรโฟกัสที่ ทักษะพื้นฐาน ไม่ใช่เครื่องมือของแต่ละยุค และแนวคิดนี้สอดคล้องกับโมเดลแบบอริสโตเติลที่เน้นการตัดสินใจเชิงปัญญา (phronesis) มากกว่าความจำ (mneme)

ทำไมบริษัทควรจำกัดการใช้ AI ระหว่างการสัมภาษณ์

• การแยกระหว่างทักษะพื้นฐานกับทักษะเชิงเครื่องมือ

  • Foundational traits & skills คือความสามารถ ทัศนคติ และนิสัยที่สร้างได้ยากหรือมีต้นทุนสูง
    • ความสามารถทางสติปัญญาขั้นต้น ความเชี่ยวชาญเชิงลึกที่ได้จากการเรียนรู้หลายปี (เช่น distributed system ที่รองรับคำขอหลายล้านครั้งต่อวินาที หรือการเปลี่ยนไมโครเซอร์วิสหลายร้อยตัวกลับเป็น monolith), การให้เหตุผลระดับรองลงมา และคุณธรรมอย่างจริยธรรมในการทำงาน integrity และความยืดหยุ่น
    • เป็นความรู้ที่ซึมซับอยู่ภายใน (fundamentals) ซึ่งทำให้สามารถระบุ ทำให้นามธรรม และแก้ปัญหาได้ และเป็นฐานให้เรียนรู้ทักษะอื่นเพิ่มต่อไป จนทำให้คนพูดได้ว่า "ฉลาด เดี๋ยวก็หาทางได้เอง"
  • Instrumental skills พัฒนาได้เร็วหรือมีต้นทุนต่ำกว่า
    • ความชำนาญระดับกลางในภาษาโปรแกรม การใช้ text editor ได้เหมาะสม การค้นเอกสาร และการปรับแต่งพรอมป์ต AI
  • ในการสัมภาษณ์ มักใช้สัญญาณจากทักษะเชิงเครื่องมือหลายอย่างเพื่ออนุมานถึงคุณลักษณะพื้นฐานของผู้สมัคร เช่น ความตั้งใจลงทุนเพื่อเพิ่มผลิตภาพ หรือการเรียนรู้อย่างมีโครงสร้าง

• เหตุผลที่ 1: ความชำนาญด้าน AI ไม่ใช่ทักษะพื้นฐาน

  • เครื่องมือทางวิศวกรรมพัฒนาขึ้นเรื่อย ๆ แต่รูปแบบสัมภาษณ์ส่วนใหญ่แทบไม่เปลี่ยน (ไม่มีประเภทสัมภาษณ์แบบ low-code และ system design ส่วนใหญ่ก็ยังใช้เทคโนโลยีพื้นฐานที่ไม่ได้ managed)
    • บริษัทชั้นนำไม่ได้มองหาความเชี่ยวชาญในเครื่องมือชิ้นเดียว และเมื่อ LLM ผงาดขึ้น ความสำคัญของ Expert Generalist ก็ยิ่งเพิ่มขึ้น
  • เหตุผลเดียวกันนี้อธิบายว่าทำไมความเชี่ยวชาญภาษาโปรแกรมเฉพาะภาษาไม่ค่อยสำคัญมากในการสัมภาษณ์ เพราะภาษาก็เป็นเพียงเครื่องมือสำหรับเป้าหมายที่สูงกว่าคือการแก้ปัญหา
  • การใช้ AI ก็เช่นกัน แม้จะต้องใช้ทักษะละเอียดอ่อนอย่าง prompt/context engineering, การนิยาม MCP/skills, multi-agent workflow หรือ harness engineering แต่สิ่งเหล่านี้เป็นทักษะเชิงเครื่องมือ และยังต้องอาศัย ทักษะพื้นฐานแบบเดียวกัน ที่จำเป็นต่อการเขียนโค้ด รีวิวโค้ด และออกแบบสถาปัตยกรรมที่ขยายได้
  • บริษัทจ้างสมอง ไม่ได้จ้างมือที่คอยพิมพ์คำสั่งให้ AI agent แบบไม่คิด
  • การรีวิวและการผลิตเป็นสองด้านของเหรียญเดียวกัน การรีวิวโค้ด สถาปัตยกรรม และการวิเคราะห์ ต้องใช้ทักษะใกล้เคียงกับการเขียน การออกแบบ และการวิเคราะห์ และเพราะยังต้องใช้มนุษย์ในการสร้างและตรวจสอบความต้องการทางธุรกิจ การรีวิวโค้ดจึงจะไม่หายไปในเร็ววัน (สเปกที่ละเอียดพอแทบเท่ากับโค้ดแล้ว)

• เหตุผลที่ 2: AI บดบังคุณลักษณะและทักษะพื้นฐาน

  • อ้างถึง Peter Drucker: คุณไม่อาจจ้างแค่สองมือได้ เพราะทั้งตัวคนมาพร้อมกันเสมอ
  • ใช้การแยกประเภทของ Lewis Mumford ระหว่าง tool (มนุษย์เป็นผู้ควบคุมแรงงาน) กับ machine (ทำงานตามตรรกะของตัวเองและมี agency) หากใช้ AI มากเกินไป ก็แทบเป็นไปไม่ได้ที่จะบอกได้ว่าส่วนใดคือผลงานเฉพาะของวิศวกร และส่วนใดคือผลงานของโมเดล AI
  • ควรระวังวิศวกรที่ใช้ AI แบบเป็น "machine" มากกว่า "tool" เพราะ AI ไม่ได้เป็นแค่ autocomplete ที่เก่งขึ้น แต่คือการกระโดดด้านผลิตภาพที่สามารถ externalize การคิดส่วนใหญ่ได้ แม้แต่พื้นที่เฉพาะมนุษย์อย่าง "taste" ก็ถูกคุกคาม จน Fitts' list ดูล้าสมัย
  • เช่นเดียวกับ pharmakon ของ Plato ที่ Derrida วิเคราะห์ AI เป็นได้ทั้งยา (เช่น ทำ refactor ซ้ำ ๆ อัตโนมัติ หรือช่วยประหยัดเวลาเรียนรู้รายละเอียดเฉพาะของไลบรารี) และพิษ (เสี่ยงทำให้ทักษะพื้นฐานฝ่อลง)
  • การสัมภาษณ์ที่เน้น AI มากเกินไปเสี่ยงต่อการประเมิน ตัวโมเดล ("machine") แทนที่จะเป็นมนุษย์ จึงต้องออกแบบโจทย์ที่ย้ำว่าการให้เหตุผลของมนุษย์คือหัวข้อหลักของการสัมภาษณ์

• เหตุผลที่ 3: AI พัฒนาเร็วเกินไป

  • ตามคำกล่าวของ Arthur Mensch (CEO ของ Mistral) โมเดล AI ได้รับประสบการณ์ด้านซอฟต์แวร์เอนจิเนียริงเพิ่มขึ้นราว 1 ปีในทุก ๆ 12 เดือน มุกที่เปรียบ AI agent เป็นเด็กฝึกงานจึงแทบไม่ค่อยได้ยินแล้ว
  • บริษัทส่วนใหญ่ไม่มีทรัพยากรพอจะสร้างและดูแลคำถามที่ต้าน AI ได้และยังบังคับให้ใช้ทักษะพื้นฐานต่อไป ในเมื่อโมเดลพัฒนาทุกเดือน และเราเองก็อาจเข้าถึงได้ไม่ครบทุกโมเดล การสร้างโจทย์ให้ต้านโมเดลที่ดีที่สุดได้ตลอดจึงเป็น สงครามที่แพ้แน่
    • "Designing AI resistant technical evaluations" ของ Anthropic เป็นกรณีศึกษาการ "ต่อสู้" กับ AI แทนที่จะต่อสู้กับผู้สมัคร
  • การทำ take-home ให้ยากขึ้นก็คล้ายกับการอนุญาตให้ใช้เครื่องคิดเลข แต่ดันออกโจทย์คิดเลขในใจให้ยากขึ้น
  • best practice ของ AI ก็เปลี่ยนทุกเดือน และเมื่อโมเดลเข้าใจคำสั่งได้ดีขึ้น ความสำคัญของ prompt engineering ก็ลดลง การดูว่าผู้สมัครตามเทคนิคใหม่ล่าสุดทันหรือไม่จึงไม่ใช่สัญญาณที่มีประโยชน์
  • ในทางตรงกันข้าม fundamentals ไม่เปลี่ยนตามนิยามอยู่แล้ว

คำตอบต่อข้อโต้แย้ง

• สำหรับคำวิจารณ์ว่า ไม่มีข้อมูลรองรับ: (1) การทดลองจริงที่มีนัยสำคัญทางสถิติ (randomized controlled trial) แทบเป็นไปไม่ได้ และไม่มีบริษัทไหนอยากยอมรับ false negative ที่จะเกิดจากมัน (2) การตัดสินใจออกแบบสัมภาษณ์ส่วนใหญ่อิงการให้เหตุผลเชิงนามธรรม ไม่ใช่การทดลองแบบ clinical trial
• การโกงด้วย AI (เช่น ระหว่างสัมภาษณ์): หากห้ามไว้ชัดเจน การใช้เครื่องมือ AI คือเหตุให้ไม่ผ่านทันที
  • อ้างคำพูดของ Warren Buffett: เวลาจ้างงาน เขาดู integrity, intelligence และ energy และถ้าขาด integrity อีกสองข้อที่เหลือจะยิ่งทำลายคน ๆ นั้น ถ้าต้องจ้างคนที่ไม่มี integrity ก็ยังอยากให้เขาโง่และขี้เกียจเสียกว่า
• ควรใช้ AI ประเมินผู้สมัครหรือไม่: ไม่ควร (1) ผิดจริยธรรม — เรากำลังจ้างมนุษย์ที่ทำงานเชิงความรู้ ไม่ใช่เครื่องจักรที่ประเมินได้ทุกอย่าง (2) การประเมินด้วย AI ไม่เป็นเชิงกำหนดแน่นอนและขึ้นชื่อเรื่อง hallucination สุดท้ายก็ต้องกลับมารีวิวผลประเมินของ AI อยู่ดี

คำแนะนำเชิงรูปธรรมสำหรับบริษัท

• อย่าอนุญาตให้ใช้ AI ในการสัมภาษณ์ส่วนใหญ่ อย่าเน้นเครื่องมือใดเครื่องมือหนึ่งมากเกินไป และให้โฟกัสที่ทักษะพื้นฐาน
• ลงทุนกับ Live exercise มันไม่จำเป็นต้องปลอม น่าเบื่อ หรือสัญญาณต่ำ และไม่จำเป็นต้องสั้น ทบทวนการสัมภาษณ์ data structure & algorithm ใหม่ เพราะยังคงเป็นสิ่งที่ท้าทายทางปัญญามากที่สุด ออกแบบโจทย์ที่ต้องใช้ความพยายามของมนุษย์ และมีคำถามจำนวนมากเพื่อป้องกันการเตรียมตัวหนักกับโจทย์ข้อเดียว
• ผสมประเภทการสัมภาษณ์ เพื่อให้ได้สัญญาณที่กว้างในต้นทุนที่คุ้มค่า
• ปรับ take-home โดยห้ามใช้ AI อย่างชัดเจน หรือจะอนุญาตก็ได้แต่ไม่ควรเสียเวลาไปกับการรีวิวผลลัพธ์จาก AI และ take-home ควรต้องต่อด้วย live exercise ที่อิงจากงานนั้นเสมอ เพื่อให้ผู้สมัครอธิบายงานของตัวเอง แนวทางชั่งน้ำหนัก trade-off การเปลี่ยน requirement และเรื่อง scalability
• ควรมีการสัมภาษณ์อย่างน้อยหนึ่งรอบที่ประเมินความสามารถในการรีวิว เพราะต้นทุนการสร้างต่ำ ให้สัญญาณที่น่าสนใจ และสร้างภาระให้ผู้สมัครน้อยกว่า เช่น รีวิวแผน AI, postmortem, codebase เดิม (Bug squash), เอกสารความต้องการของผลิตภัณฑ์, การวิเคราะห์ trade-off หรือการรีวิวสถาปัตยกรรมระบบ
• พิจารณาเรียกผู้สมัครมา onsite นี่คือวิธีที่ง่ายที่สุดในการป้องกันการโกง และยังช่วยให้โจทย์รั่วได้ยากขึ้นบ้าง แต่เหมาะเฉพาะบริษัทที่มีนโยบาย RTO (กลับเข้าออฟฟิศ)
• ให้คู่มือการเตรียมตัวสำหรับการสัมภาษณ์ที่ชัดเจน เพื่อสร้างสภาพแวดล้อมที่ยุติธรรม

[roxie]

สำหรับผม น่าจะเหมาะกับการได้ลองทำงานร่วมกันสัก 1 สัปดาห์

[linusjeh]

บทความนั้นก็คงเขียนด้วย AI เหมือนกันสินะ 555

[jjpark78]

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

ต่อให้เป็นโจทย์เดียวกัน แค่ดูว่าแต่ละคนส่งพรอมป์ตอย่างไร ก็รู้เรื่องเกี่ยวกับคนนั้นได้มากแล้วครับ