การสัมภาษณ์โค้ดดิ้งแบบสดวัดแค่ความเครียด ไม่ได้วัดทักษะการเขียนโค้ด

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

---

ประสบการณ์ส่วนตัวเกี่ยวกับการสัมภาษณ์โค้ดดิ้งแบบสด

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

สมองที่ตอบสนองต่อความเครียด

• ในสถานการณ์ที่ มีความเสี่ยงสูงและกดดันด้านเวลา อะมิกดะลาในสมองจะถูกกระตุ้น และ ระดับคอร์ติซอล จะเพิ่มสูงขึ้น
• ส่งผลให้ การทำงานของสมองส่วน prefrontal cortex ซึ่งรับผิดชอบการใช้เหตุผลที่ซับซ้อนและความจำ เสียหายไป
• ความจำเพื่อการทำงานเป็นตัวชี้วัดสำคัญที่สุดในการตัดสินความสามารถในการแก้ปัญหาใหม่ ๆ และสิ่งนี้ลดลงอย่างมากในสถานการณ์โค้ดดิ้งแบบเรียลไทม์
• แม้จะมี ความกังวลเรื่องผลงาน เพียงเล็กน้อย ก็อาจทำให้แทบไม่สามารถคิดอย่างชัดเจนได้
• จะเริ่มมีสมาธิได้ยาก จำหลายขั้นตอนพร้อมกันไม่ได้ และรู้สึกว่าตัวเอง “แย่กว่าปกติมาก”

ผลการวิจัยที่ชี้ขาด

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

ความจริงของผลงานภายใต้ความเครียด

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

วิธีบรรเทาความเครียด

• เนื่องจากการโค้ดดิ้งแบบสดเป็นเรื่องปกติในอุตสาหกรรม จึงจำเป็นต้องมี การฝึกให้ปรับตัวต่อความเครียด
• การฝึกซ้ำในสภาพแวดล้อมที่ใกล้เคียงของจริง (เช่น Pramp, Interviewing.io, LeetCode mock test) สามารถช่วยให้สมองคุ้นชินกับความเครียดได้
• การตั้งเวลา อัดวิดีโอตัวเอง หรือให้เพื่อนนั่งดู เป็นวิธีฝึกที่ค่อย ๆ เพิ่มแรงกดดันและได้ผลดี
• นอกจากนี้ อาจลองใช้สารอาหารเสริมอย่าง L-tyrosine (ช่วยเสริมสารสื่อประสาทภายใต้ความเครียด) และ L-theanine (ช่วยผ่อนคลายและเพิ่มสมาธิ)
• ก่อนถึงวันสัมภาษณ์จริง ควรทดสอบล่วงหน้าในการฝึกจำลองเสมอว่าวิธีใดเหมาะกับตัวเองที่สุด

บทสรุป

• การทำได้ไม่ดีในการโค้ดดิ้งแบบสด ไม่ได้หมายความว่าขาดคุณสมบัติของการเป็นวิศวกร แต่เป็นลักษณะทั่วไปของมนุษย์

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันไม่ได้ตั้งใจจะเหมารวมจากกรณีของตัวเอง แต่อยากแชร์ประสบการณ์ส่วนตัว ตอนนี้ฉันเป็น indie developer ที่ทำงานอิสระและประสบความสำเร็จ เหตุผลสำคัญอย่างหนึ่งที่ฉันไม่เลิกทำ indie dev แม้ในช่วงยากลำบาก ก็คือฉันแทบจะอยู่ในสภาพที่หางานประจำไม่ได้แล้ว ฉันเป็นคนวัยกลางคนในวงการเทคที่เจอ ageism หนัก ไม่มีปริญญา computer science และเวลาเจอสัมภาษณ์ live coding สมองจะขาวโพลน ฉันอยากชี้ให้เห็นว่า stress ไม่ได้เหมือนกันทั้งหมด นักผจญเพลิงวิ่งเข้าอาคารที่กำลังไหม้ได้ แต่กลับกลัวการพูดต่อหน้าคนแปลกหน้า ส่วนฉันรับมือกับ stress จากงานประจำวันได้ดี แต่การมีคนมายืนจ้องข้ามไหล่และตัดสินอนาคตทางการเงินของฉันนั้นหนักหนาจนแทบทนไม่ไหว พอสัมภาษณ์เสร็จฉันกลับแก้โจทย์โค้ดได้อยู่บ่อย ๆ คนสัมภาษณ์อาจคิดว่าฉันเป็นพวกตบตา แต่ประสบการณ์เกือบ 20 ปีของฉันก็เป็นหลักฐานโต้แย้ง ดูเหมือนหลายคนจะมองว่า "false negative" เป็นเรื่องสุ่ม ๆ แต่สำหรับบางคนอย่างฉัน มันคือการถูกคัดออกทุกครั้ง ฉันตกสัมภาษณ์แบบออดิชันตลอด ฉันไม่ใช่คนที่แสดงบนเวทีเก่ง

  • อินมากกับการถูกประเมินขณะมีคนจ้องดูอยู่ ฉันอายุเพิ่งเข้าช่วงต้น 60 ตอนอายุ 20-30 ฉันสัมภาษณ์ได้พอใช้ แต่ยิ่งเวลาผ่านไปก็ยิ่งรู้สึกว่าตัวสัมภาษณ์เองมีความเป็นปฏิปักษ์มากขึ้น สมัยก่อนบรรยากาศเหมือน "พยายามจะจ้างให้ได้" แต่ตอนนี้เหมือน "พยายามหาข้ออ้างไม่จ้าง" มันอาจเป็น ageism ก็ได้ แต่ฉันคิดว่าบรรยากาศของอุตสาหกรรมก็เปลี่ยนไปด้วย ตลอด 15 ปีที่ผ่านมา ประสบการณ์สัมภาษณ์ยิ่งแย่ลงเรื่อย ๆ และฉันเคย panic ระหว่างสัมภาษณ์ด้วย ถึงอย่างนั้นสุดท้ายก็ยังพอได้งานบ้าง และด้วยประวัติการทำงานอ้างอิงที่ดี ฉันก็เคยรับงานสัญญาที่ไม่ต้องสัมภาษณ์ งาน startup สุดท้ายที่ฉันทำเงินหมดปลายปี 2022 และฉันก็ตัดสินใจเลิกทำต่อ ฉันชอบงานนี้มากและยังได้ใช้เทคโนโลยีใหม่ ๆ แต่เหตุผลใหญ่ที่สุดคือฉันไม่สามารถรับมือกับการสัมภาษณ์ได้อีกแล้ว

  • ฉันคิดว่าโครงสร้างนี้เองที่เป็นปัญหา การสัมภาษณ์เขียนโค้ดสมัยนี้เหมือนถูกสร้างมาเพื่อตรวจว่าเด็กหนุ่มสาวเคยทำการบ้านเรื่อง CS data structure มาหรือไม่ สำหรับที่ที่รับคนจำนวนมากแบบ FAANG ในยุค 2010s มันอาจพอมีเหตุผล แต่สำหรับบริษัทเล็กและกลาง การโฟกัสที่สถานการณ์งานจริง เช่น การอ่านโค้ดหรือคุยเรื่อง edge case กลับดีกว่ามาก ฉันทำงาน startup มาเกิน 20 ปีแล้ว แต่ยังผ่านการทดสอบแบบนี้ไม่ได้ และก็ไม่ยอมฝืนท่องจำด้วย ถ้าที่ไหนต้องการแบบนั้น งั้นไม่ผ่านก็คงถูกแล้ว ฉันเคยเป็น CTO เปิดบริษัทมาหลายครั้ง และบริหารทีมได้ดี แต่รอบนี้ก็ยังถูกปฏิบัติราวกับเป็นเด็กจบใหม่ ก่อนหน้านี้ฉันเคยตกเพราะเขียน LRU cache ได้ไม่เร็วและไม่เนี้ยบพอ ทั้งที่ฉันสงสัยมากว่าทุกวันนี้ startup ต้องใช้สิ่งนี้แค่ไหน ฉันเองก็ไม่ได้ใช้มานานแล้ว การแก้โจทย์แบบนี้ไม่ได้ทันทีอาจทำให้ดูเหมือนคนไร้ความสามารถ แต่ฉันไม่เข้าใจว่าจะไปซีเรียสกับสิ่งที่ไม่ได้ใช้ในงานจริงทำไม มันเหมือนการคัดเลือกสถาปนิกจากทักษะใช้ slide rule วิธีจ้างงานแบบนี้สุดท้ายก็สร้าง codebase ที่ซับซ้อน ทั้งที่สิ่งที่ต้องการจริง ๆ ควรเป็นการบรรลุเป้าหมายทางธุรกิจมากกว่าการเพิ่มความซับซ้อน ฉันอยากทำงานกับเพื่อนร่วมทีมที่แบ่งปัญหาเป็นส่วนย่อย ๆ และคงตรรกะกับโครงสร้างให้เรียบง่าย การใช้ leetcode คัดคนฉลาดก็มีข้อดี แต่คนที่แก้ปัญหาในโลกจริงได้อย่างสม่ำเสมอและมีประสิทธิภาพดีกว่า

  • ฉันเคยเจอสถานการณ์แบบนี้ในมุมของคนจ้าง ฉันสัมภาษณ์ทางโทรศัพท์นักศึกษาคนหนึ่งที่อยู่กับโปรเจ็กต์มานาน แต่ดูเหมือนเขาจะปล่อยของไม่ได้เพราะ stress หลายอย่างรวมถึง language barrier ฉันยินดีจะเปลี่ยนรูปแบบ แต่ผู้สมัครบอกเองว่าไม่อยากลองต่อแล้ว อย่างไรก็ตาม ถ้าเปลี่ยนไปใช้ coding interview แบบ asynchronous ก็อาจกลายเป็นแค่การทดสอบว่าใช้ LLM หรือไม่ สุดท้ายถ้าต้องเลือกระหว่างคัดคนที่ freeze ในสัมภาษณ์ออก กับคัดพวก impostor ที่ไม่มีความสามารถจริง ๆ ออก ฉันคิดว่าการกรองแบบแรกยังดีกว่า

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

  • อยากรู้ว่าอะไรคือจุดเริ่มต้นที่ทำให้คุณเริ่มประสบความสำเร็จในการเป็น indie developer ฉันเองก็เกือบ 40 แล้ว เขียนโปรแกรมเป็นงานอดิเรกมานาน แต่เพิ่งตัดสินใจจริงจังว่าจะทำเป็นอาชีพตั้งแต่ปีที่แล้ว มีโปรเจ็กต์ public บน GitHub เยอะ มีประสบการณ์ความสำเร็จในสายอื่นด้วย และทักษะการสื่อสารก็ไม่แย่ แต่กำลังลำบากกับ live coding อยากรู้ว่าคุณคิดยังไงกับเส้นทาง independent contribution ที่ทำให้แสดงความสามารถจริงได้ ถ้ามีฝีมือจริง ฉันก็อยากหารายได้จากมัน

• สัปดาห์นี้ฉันสัมภาษณ์ผู้สมัครตำแหน่ง Data Engineering ให้โจทย์ SQL พื้นฐาน 4 ข้อ เขาอ่านโจทย์ออกเสียงแล้วตอบทันทีด้วย syntax ที่ถูกต้องเป๊ะ ข้อสุดท้ายยากขึ้นนิดหน่อยแล้วเขาตัน พอบอกว่า "ลองดูผลลัพธ์สิ" เขากลับไม่เข้าใจและตั้งการ์ด พอบอกว่า "ลอง dump ตารางดู" ก็ยังไม่เข้าใจเลย เอาแต่แก้ตัว สุดท้าย SQL ที่เขา paste มา มี [redacted].ai อยู่ใน output น่าจะหมายความว่าข้อก่อนหน้าใช้ AI ช่วย แต่ข้อสุดท้ายทำให้หลุด ถ้าไม่มีคำถามเชิงเทคนิคแบบนี้ เราคงจับการโกงไม่ได้

  • เครื่องมือโกงสัมภาษณ์ด้วย AI กำลังแพร่หลายมากในกลุ่มคนอายุน้อย บางกรณีก็จับได้ทันที แต่ผู้สมัครที่มีประสบการณ์มากจะใช้ AI แล้วอาศัยช่วงคั่นอย่าง "ไม่ได้ยินเสียงครับ/ค่ะ" เพื่อกลบช่องโหว่ ในกลุ่มผู้จัดการที่ฉันอยู่ นี่เป็นหัวข้อเรื่องการจ้างงานที่ถูกพูดถึงมากที่สุดช่วงนี้ บริษัทที่พอมีกำลังจะนัดสัมภาษณ์รอบสุดท้ายแบบเจอตัว เพราะบนหน้าจอระยะไกลดูโอเค แต่พอเจอจริงกลับตอบคำถามพื้นฐานไม่ได้ ก็เลยต้องคัดออก แม้มันจะเสียเวลาและเงิน แต่ก็ยังดีกว่าค่าเสียหายจากการจ้างผิด การใช้ AI ไม่ได้ลามแค่ technical interview แต่ยังไปถึงเรซูเม่ คำถามเชิงพฤติกรรม และแม้แต่คำตอบรูปแบบ S.T.A.R. ที่ ChatGPT ช่วยเขียน การตรวจสอบ reference ที่เชื่อถือได้จึงสำคัญกว่าที่เคย ฉันเคยเจอหลายครั้งที่สิ่งที่หัวหน้าเก่าพูดถึงงานของผู้สมัคร ไม่ตรงกับสิ่งที่เขียนไว้ในเรซูเม่เลย ถ้าเขายอมรับตรง ๆ ตั้งแต่แรกว่าไม่มีประสบการณ์ตรงในโดเมนของเรา เราอาจยังจ้างได้ แต่เมื่อการโกหกหนักขนาดนี้ ความน่าเชื่อถือก็หายหมด

  • ช่วงนี้เวลาสัมภาษณ์ผู้สมัคร ประมาณ 50% ใช้ live GenAI แบบเรียลไทม์ จนถึงตอนนี้ยังจับได้ง่ายมากว่าใครใช้ AI มันโผล่ออกมาในการสนทนาอย่างเป็นธรรมชาติ ที่น่าขันคือผู้สมัครคนล่าสุดก็ทำแบบเดิม คือทวนโจทย์ซ้ำทุกครั้งแล้วหยุดรอ 10-15 วินาที เรื่องนี้ชี้ว่าการทดสอบลักษณะนี้ไม่ได้แก้ปัญหาต้นตอ กลับสร้างปัญหาใหม่และทำให้ผู้สมัครเก่ง ๆ ตกไป

  • ถ้ามองว่า "การใช้ AI ไม่ใช่การโกง แต่คือการลองทำสิ่งที่จะได้ทำจริงในงาน" งั้นสัมภาษณ์นี้ก็เป็นตัวอย่างเล็ก ๆ ของ <i>การตีความ requirement</i> ที่มีประสิทธิภาพมาก สุดท้ายฉันคิดว่าควรไปในทิศทางที่เปิดให้ใช้เครื่องมือที่ใช้ในงานจริงได้อย่างอิสระ ขณะเดียวกันก็ยังทดสอบความเข้าใจในตัวงานและในภาษาเอง สิ่งที่ต้องทำไม่ใช่แค่หนีออกจาก Leetcode แต่ต้องหาวิธีที่ดีกว่า

• ทุกอย่างสุดท้ายก็ขึ้นอยู่กับ "แล้วแต่กรณี" live coding interview ก็เหมือนกัน มันไม่ใช่ประสบการณ์ที่ดีที่สุดสำหรับผู้สมัคร แต่ในองค์กรขนาดใหญ่แบบ Meta หรือ Google มันลด false positive (การจ้างคนที่จริง ๆ ไม่มีฝีมือ) ได้ดีกว่าวิธีอื่น เพียงแต่ผู้สัมภาษณ์มักฝึกมาไม่พอ และโจทย์หลายข้อก็เป็นปริศนาเกินไป ทำให้ถ้าไม่ได้ฝึก LeetCode มาเยอะ หรือไม่ได้อยู่ในสายวิชาการ/เพิ่งเรียนจบ ก็แทบจะลำบาก ฉันทำงานด้าน assessment มา 6 ปี และเห็นกระบวนการจ้างงานมาหมดตั้งแต่ Fortune 10 ถึง startup ฉันแนะนำให้ใช้การประเมินที่คล้ายงานจริงสำหรับผู้สมัคร และทุกวันนี้ก็ไม่ชอบการเรียกสิ่งที่เกือบเป็น unpaid labor ว่า "งานจริง" แล้ว การประเมินควรเป็นเครื่องมือที่ช่วยให้บริษัทมั่นใจพอจะยื่นเงินเดือนสูงได้ การมาของ AI ทำให้แม้แต่โจทย์ take-home สั้น ๆ ก็รักษาความยุติธรรมได้ยากขึ้น บริษัทบางแห่งเลยย้อนกลับไปพึ่งวิธีสุดโต่งอย่าง onsite interview และการคุมสอบแบบเรียลไทม์ สิ่งที่ฉันมองว่าเป็นโซลูชันสมบูรณ์แบบคือทำให้ผู้สมัครทุกคนได้แสดงศักยภาพสูงสุดในเวลา สภาพแวดล้อม และเครื่องมือที่เท่าเทียมกัน ฉันคิดเรื่องนี้อยู่ตลอด แต่ยังหาคำตอบไม่ได้

  • ที่บอกว่า "ระดับ Meta, Google แล้วมันเวิร์ก" จริง ๆ ไม่มีข้อมูลรองรับ ฉันเคยทำงานกับนักพัฒนาเกรด F ที่มาจาก Facebook และ Google ในความเป็นจริง บริษัทยักษ์ใหญ่เหล่านี้ก็ยังปลดคน 3-5% อยู่ดี ซึ่งเป็นหลักฐานว่าการสัมภาษณ์อย่างเดียวก็ยังจับ false positive ไม่ได้ดีพอ เมื่อเทียบกับเวลาที่ผู้สัมภาษณ์ทุ่มลงไป อัตราผิดพลาด 3% ถือว่าสูงเกินไป มันแทบไม่ต่างจากระดับ 'Fizzbuzz' ในยุคก่อนเลย

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

  • วิศวกรที่เก่งที่สุดเท่าที่ฉันเคยเห็น มักถูกจัดเป็น false negative อยู่เสมอ พวกเขาเครียดกับ live coding จนแสดงออกมาได้ไม่เต็มที่ ฉันไม่คิดว่าเราจะฟันธงได้ว่าสัมภาษณ์แบบนี้ "ใช้ได้ผล"

  • การพูดว่า "แล้วแต่กรณี" แล้วต่อด้วย "live coding interview ใช้ได้ผล" มันขัดกันเอง ฉันเองก็สามารถพูดกลับได้เหมือนกันว่า "แล้วแต่กรณี แต่ live coding interview ใช้ไม่ได้ผล" ซึ่งก็ไม่มีความต่างทางตรรกะเลย

  • การผ่าน leet-code พอใช้กรองคนที่ไม่มีความสามารถในการแก้ปัญหาจริง ๆ ได้ ทางออกที่ดีที่สุดคือสร้างสภาพแวดล้อมที่ผู้สมัครใช้เครื่องมือและสภาพแวดล้อมของตัวเองได้เต็มที่ แต่ในทางปฏิบัติ ฉันกลับคิดว่าการให้ทำ leetcode แบบออฟไลน์บน whiteboard พร้อม pair programming กับผู้สัมภาษณ์อาจยุติธรรมที่สุดแล้ว นั่นแหละคือสภาพแวดล้อมที่สบายจริง ๆ

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

  • มีนักพัฒนาหลายคนที่ทำ live coding ได้ดี แต่ไม่มีประสบการณ์ออกแบบระบบขนาดใหญ่ คนแบบนี้มักนำ technical debt, anti-pattern และความไม่สอดคล้องต่าง ๆ เข้ามา ทำให้ codebase แย่ลงไปอีก ซึ่งจริง ๆ แล้วเป็นประเภทที่ควรหลีกเลี่ยง บริษัทมักหวังว่า senior ที่มีอยู่จะคุมเด็กจบใหม่ได้ แต่ทุกบริษัทก็พูดเหมือนกันว่า "codebase เรากาก" ดังนั้นวิธีนี้ก็ดูไม่ค่อยช่วยอะไร

  • ถ้าให้เขานั่งเขียนโค้ดคนเดียวในห้อง ก็จะไม่พลาดคนเก่งที่แค่ทำผลงานไม่ได้ในสภาพแวดล้อมที่ผิดธรรมชาติ

  • live coding ช่วงหลังไม่ได้เป็นแค่ coding test ธรรมดาอีกแล้ว แต่เป็นระดับที่ต้องท่อง algorithm เยอะ ๆ และเอา algorithm สองสามอย่างมาผสมแก้ปัญหาให้ได้ใน 30 นาที สุดท้ายหมดเวลาไปกับการแก้โจทย์ จนไม่มีเวลาแสดงทักษะการเขียนโค้ดจริงเลย

  • ตลอด 20 ปีที่ทำงานในสายนี้ ฉันไม่เคยร่วมงานกับ "senior ที่ไม่มีฝีมือ" แบบนั้นเลย แค่ดูเรซูเม่กับคุย 15 นาทีก็กรองออกได้แล้ว ตรงกันข้าม ฉันเห็นคนที่ผ่าน whiteboard interview แต่ทำให้ productivity ของทีมแย่ลงมีมากกว่ามาก

  • ฉันไม่เข้าใจว่าทำไมสภาพแวดล้อมที่ต้องคิดไปอธิบายไปต่อหน้า whiteboard ภายใต้เวลาจำกัดถึงถูกมองว่าเป็นสิ่งจำเป็น ถ้าจุดประสงค์คือกรองคนที่ทำงานจริงไม่ได้ ก็ไม่จำเป็นต้องไปไกลขนาดนั้น

• สำหรับฉัน วิธีเดียวที่จะตรวจสอบความสามารถในการทำงานของตำแหน่งใดตำแหน่งหนึ่งได้จริง คือให้ทำงานนั้นจริง ๆ ถ้ามีวิธีประเมินอื่นก็เถอะ แต่ถ้าสามารถให้ทำงานจริงได้ ก็ไม่มีเหตุผลจะใช้วิธีอื่น ถ้างานของบริษัทซับซ้อนเกินกว่าจะตัดบางส่วนมาใช้ในสัมภาษณ์ได้ ก็อาจหมายความว่าบริษัทกำลังทำเรื่องที่ซับซ้อนเกินจำเป็นเองด้วย เช่น ถ้าต้องการดูว่าคนยกของหนัก 10 กิโลกรัมได้ไหม ก็ให้ยกของหนัก 10 กิโลกรัมจริง ๆ ไม่ใช่บอกว่า "จะประเมินกำลัง" แล้วให้ "ถอดกางเกงมายกถัง 1 กิโลด้วยก้น" แบบทดสอบประหลาด สิ่งที่ควรทำคือดูเฉพาะทักษะที่จำเป็นกับงานจริง เช่น ถ้าเป็นเชฟก็ให้ทำอาหารในครัวจริง ถ้าเป็นเจ้าหน้าที่ให้คำปรึกษาก็ดูการสื่อสารในสถานการณ์จำลอง ส่วนงานคัดกรองทางโทรศัพท์ก็ให้ดูหน้าจอแบบเรียลไทม์ได้

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

  • มีคนเสนอให้จ้างตรงเป็นรายวัน รายสัปดาห์ หรือรายเดือนก่อน ถ้าเหมาะค่อยรับเข้าประจำ แต่แนวทางนี้ไม่เข้ากับระบบ employer healthcare แบบอเมริกัน

  • จากมุมบริษัท มันใช้เวลามากเกินไป เลยเลือกใช้ proxy ที่เอนเอียงไปทาง false negative (คัดคนที่ควรผ่านออกผิด) มากกว่า false positive

  • ถ้าให้ทำงานจริงในสัมภาษณ์ คุณคิดเห็นอย่างไรกับความกังวลเรื่องการเรียก "แรงงานฟรี"

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

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

  • คุณไม่ได้รู้สึกแบบนี้คนเดียว ยิ่งอายุมากขึ้น ความเร็วในการเรียนรู้ก็ลดลง เวลาว่างก็ลดลง ทำให้ประสิทธิภาพในการฝึก leetcode แย่ลง มันน่าหงุดหงิดที่ในโลกจริง คนที่มีเวลาเหลือมากกว่ากลับได้รางวัลมากกว่า

  • ขอลองแนะนำวิธีลด stress เช่น การทำสมาธิ การหายใจ L-Theanine และ beta blocker ลองใช้สมาร์ตวอตช์วัดอัตราการเต้นของหัวใจกับความดันดู วิธีแบบนี้ช่วยลดวงจร stress ที่ถาโถมได้จริง

• มันเป็นสภาพแวดล้อมความเครียดสูงมากที่มีคุณภาพต่างจาก stress ในงานจริง ขอแชร์ประสบการณ์สัมภาษณ์กับ Google: ฉันเป็นคนที่สร้าง search engine ท้องถิ่นตัวแรกของเนเธอร์แลนด์ แต่ที่ Google ผู้สัมภาษณ์ใส่หมวกคาวบอยแล้วให้ฉันเขียน binary search ด้วยมาร์กเกอร์บน whiteboard ฉันแทบไม่เขียนหนังสือด้วยมือในชีวิตประจำวัน ใช้แต่คีย์บอร์ด และเขาก็ไม่ได้สนใจประสบการณ์ที่ฉันมีในการออกแบบ search index เลย ฉันเลยสงสัยว่า Google อาจกำลังมองหา mindset แบบ "คาวบอย" มากกว่าหรือเปล่า

  • ฉันเองก็เคยโดน recruiter ของ Google กล่อมจนยอมไปสัมภาษณ์ แต่ผู้สัมภาษณ์แย่มาก จนฉันข้าม technical interview ไปทั้งที่ยังดำเนินต่อได้ หลังจากนั้นฉันก็ปฏิเสธทุกข้อเสนอจาก Google คำถามส่วนใหญ่เป็นแนว "ตกปลา" หรือถามเรื่องโครงสร้าง UNIX โบราณที่ไม่เกี่ยวกับโลกจริงเลย เช่น inode structure ทั้งที่ไม่เกี่ยวกับบทบาทงานนั้นเลย บริษัทต่าง ๆ จำเป็นต้องมีขั้นตอนติดตามคำถามสัมภาษณ์ รับ feedback และอบรมผู้สัมภาษณ์อย่างจริงจัง แต่ทุกวันนี้ก็ยังมีหลายบริษัทมากที่ปล่อยให้คำถามขึ้นกับรสนิยมส่วนตัวของผู้สัมภาษณ์

  • โครงสร้างแบบนี้จริง ๆ แล้วทำงานตรงตามที่ตั้งใจไว้ บริษัทแบบนี้ต้องการคนที่ยอมทนการหยามทุกรูปแบบจากบริษัทได้ สุดท้ายมันก็แปลว่าทั้งสองฝ่ายไม่ fit กัน และนั่นก็ถือว่าทั้งคู่ประสบความสำเร็จแล้ว

  • ถ้าคุณรู้สึกว่าการถูกให้ทำ binary search เป็นเรื่องน่าดูหมิ่น ก็คงเพราะอีโก้สูงเกินไปหรือเปล่า

  • ถ้ามีเงินเดือนปีละ 250,000 ดอลลาร์ พร้อม Google stock options เพิ่มเติม ฉันก็ยอมทน "ความดูหมิ่น" สักวันได้สบาย

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

  • ใช่เลย แก่นของ live coding interview ไม่ใช่ "แก้ปัญหาได้ไหม" แต่คือ "อธิบายได้ไหมว่าจะแก้อย่างไร" พื้นฐานเทคนิคเล็กน้อยกับทักษะการสื่อสารคือหัวใจสำคัญ งานจริงส่วนใหญ่ก็คือการอธิบายให้ผู้จัดการที่ไม่ใช่สายเทคนิคเข้าใจ ดังนั้นจะมองว่าเป็นการทดสอบสิ่งนี้ก็ได้

  • ฉันชอบวิธีนี้นะ ฉันแก้ FizzBuzz ได้อย่างน้อย 3 ภาษา 4 วิธี และมั่นใจว่าอธิบายได้ครบทั้ง 12 แบบ

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

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

  • ฉันคิดว่าการให้เขียน pseudocode บน whiteboard น่าจะดีกว่า เพราะลดความเครียดจาก syntax และทำให้เห็นตรรกะการแก้ปัญหาได้ชัดขึ้น ขณะเดียวกันก็เข้ากับวิธีทำงานร่วมกันของฉันที่ชอบแลกไอเดียกันบน whiteboard

• ปรากฏการณ์ที่ว่า “stress แยกจากความสามารถ” เกิดซ้ำแล้วซ้ำเล่า งานวิจัยของ Microsoft ก็เลวร้ายมาก คำแนะนำส่วนใหญ่มีแต่บอกให้ "ไปฝึก LeetCode ให้หนัก" แต่กลับมองข้าม stress (cortisol) ฉันเลยฝึกทำให้ตัวเองชินกับสภาพแวดล้อมที่กดดัน เพื่อน ๆ คงซ้อมให้เข้มขนาดนั้นไม่ได้ และโค้ชก็คิดค่าชั่วโมงแพงเกินไป ตอนนี้ฉันเลยกำลังทำ side project ชื่อ Tough Tongue AI เป็น live code editor ที่ตอบด้วยเสียง มีคำถามสด การรบกวน และ feedback ทันที การฝึกแบบนี้ช่วยให้ความตึงเครียดจากการถูกจับตามองค่อย ๆ กลายเป็นเรื่องคุ้นเคย ถ้า live coding interview ยังอยู่ต่อ เราก็ต้องมีวิธีฝึกปฏิกิริยาทางสรีรวิทยา (stress) เอง ไม่ใช่แค่ฝึก algorithm

  • เป็นหนึ่งในเครื่องมือเรียนรู้ที่ดีที่สุด