ขอให้ยุติแบบทดสอบเขียนโค้ดที่ไม่สมจริง
(blackentropy.bearblog.dev)- โจทย์เขียนโค้ดที่ไม่สมจริง ในการสัมภาษณ์งานด้านเทคนิคบางแห่ง สร้างแรงกดดันที่ต่างจากงานจริง และวัดความสามารถในการทำงานจริงของนักพัฒนาได้ไม่ดีนัก
- โจทย์เดี่ยวภายใต้ความกดดันสูงไม่สะท้อนสภาพแวดล้อมการทำงานที่มีทั้งการทำงานร่วมกันและการสนับสนุน และมักกลายเป็นการให้ดีบัก โค้ดเบสเก่า โดยไม่มีเอกสารหรือความช่วยเหลือจากทีม
- แม้บริษัทจะบอกว่าเป็น “โจทย์ 4 ชั่วโมง” แต่เมื่อรวมเวลาศึกษาบริษัท ตรวจสอบความต้องการของตำแหน่ง และเกลาผลงานแล้ว อาจยืดเป็น 8–10 ชั่วโมงขึ้นไป
- โจทย์ที่ใช้เทคโนโลยีสแตกไม่ตรงกับบทบาทมักถูกอ้างว่าใช้วัดความสามารถในการปรับตัว แต่การให้ Ruby developer ไปดีบัก PHP อาจไม่สอดคล้องกับการประเมินความเหมาะสมจริง
- การจ้างงานควรเน้นทักษะที่เกี่ยวข้อง การแก้ปัญหา การทำงานร่วมกัน และศักยภาพในการเติบโต มากกว่าการให้โจทย์กดดันแบบสุ่ม และโจทย์ที่หนักเกินไปอาจทำให้ผู้สมัครที่ดีเหนื่อยล้าและถอยออกไป
โจทย์สัมภาษณ์ที่ไม่ตรงกับงานจริง
- การสัมภาษณ์ด้านเทคนิคบางแห่งให้ผู้พัฒนาทำโจทย์อย่าง การดีบัก legacy PHP หรือสร้างมินิแอปภายในไม่กี่ชั่วโมง
- โจทย์เดี่ยวลักษณะนี้ต่างจากวิธีทำงานจริง
- ในการทำงานจริง มักมีการร่วมงานกับทีมและสามารถขอการสนับสนุนที่จำเป็นได้
- การต้องดีบักโค้ดเบสเก่าอย่างรวดเร็วเพียงลำพังโดยไม่มีเอกสารหรือความช่วยเหลือจากทีม ไม่สอดคล้องกับสภาพแวดล้อมการพัฒนาทั่วไป
- บริษัทอาจมองว่านี่คือการประเมิน “ความสามารถในการแก้ปัญหา” แต่หากโจทย์ไม่เชื่อมโยงกับความต้องการจริงของบทบาท ก็ยากจะเห็นความเหมาะสมในการทำงานจริงของผู้สมัคร
ต้นทุนเวลาที่ซ่อนอยู่และภาระของผู้สมัคร
- เวลาที่แนะนำ สำหรับโจทย์เขียนโค้ดอาจไม่สะท้อนเวลาที่ผู้สมัครต้องใช้จริงอย่างเพียงพอ
- ก่อนเริ่มโจทย์ ผู้สมัครต้องศึกษาบริษัทและตรวจสอบความต้องการของตำแหน่ง
- ยังต้องใช้เวลาเกลาโปรเจกต์เพื่อให้ผลงานที่ส่งมีคุณภาพดี
- โจทย์ “4 ชั่วโมง” อาจกลายเป็น 8 ชั่วโมง 10 ชั่วโมง หรือมากกว่านั้น
- สำหรับนักพัฒนาที่ต้องควบคู่ทั้งงานประจำและชีวิตส่วนตัว สิ่งนี้อาจให้ความรู้สึกเหมือนกำลัง ทำงานฟรี เพื่อชิงตำแหน่งที่ยังไม่ได้รับ
จุดที่การประเมินความสามารถในการปรับตัวพลาดเป้า
- โจทย์ที่ใช้เทคโนโลยีสแตกไม่เกี่ยวข้องกัน บางครั้งถูกทำให้ชอบธรรมด้วยเหตุผลว่าใช้วัด “ความสามารถในการปรับตัว”
- การให้ Ruby developer ไปดีบัก PHP แม้จะสะท้อนความสำคัญของการปรับตัว แต่ก็อาจไม่เหมาะจะใช้เป็นเกณฑ์ตัดสินคุณค่าของผู้สมัคร
- ความสามารถในการจัดการโจทย์ที่คลุมเครือและไม่เกี่ยวข้องได้อย่างรวดเร็ว เพียงอย่างเดียว ไม่พอจะบอกได้ว่าผู้สมัครเหมาะกับบทบาทจริงหรือไม่
- โจทย์บางอย่างอาจทำให้รู้สึกว่าบริษัทกำลังอวดมาตรฐานความเป็น “elite” มากกว่าประเมินความเหมาะสมของผู้สมัคร
- หากทุกการจ้างงานสร้างกำแพงแบบ “top 1%” ผู้สมัครที่มีประสบการณ์และน่าจะทำงานจริงได้ดี ก็อาจหลุดออกไปเพราะสถานการณ์ที่ประดิษฐ์ขึ้นและกดดันเกินจำเป็น
สิ่งที่โจทย์คัดเลือกควรประเมิน
- กระบวนการจ้างงานควรถูกออกแบบโดยยึด ทักษะเฉพาะ ที่จำเป็นต่อบทบาทเป็นศูนย์กลาง
- ควรหลีกเลี่ยงโจทย์สไตล์ coding bootcamp ที่ไม่เกี่ยวข้องกับความต้องการจริงของงาน
- ควรโฟกัสที่การแก้ปัญหา การทำงานร่วมกัน และศักยภาพในการเติบโตในขอบเขตที่เกี่ยวข้อง
- ความสามารถในการปรับตัวควรถูกประเมินจากศักยภาพในการเรียนรู้ระยะยาว ไม่ใช่จากความเร็วในการจัดการโจทย์สุ่มตามอำเภอใจ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ถามว่าครั้งสุดท้ายที่ต้องดีบักโค้ดเบสเก่า ๆ ที่ไม่มีทั้งเอกสารและไม่มีทีมช่วยคือเมื่อไหร่? ก็เป็นแบบนั้นมาตลอด เป็นโค้ด C++ 300,000~400,000 บรรทัด และคำว่าเลกาซีหมายถึงไม่มีเทสต์เลย เอกสารก็แทบไม่มี ในฐานะนักพัฒนาเพียงคนเดียวของบริษัทเล็ก ๆ ต้องคอยให้บริการผู้ใช้หลายหมื่นคนต่อไป พร้อมแก้บั๊กและเพิ่มฟีเจอร์
ตัวอย่างล่าสุดคือมีแพตช์ฟีเจอร์หลักที่ค้างมานานกว่าหนึ่งปี ผู้เขียนเดิมก็ไม่อยู่แล้ว จึงต้องเลือกว่าจะเขียนโค้ดใหม่ตั้งแต่ต้น หรือกู้แพตช์ขึ้นมาให้เข้ากับ master
ความสามารถในการกระโดดเข้าไปในโปรเจกต์แล้วพาผู้คนไปสู่เป้าหมายเป็นทักษะที่ นักพัฒนาอาวุโส จำเป็นต้องมีอย่างแน่นอน และเห็นด้วยกับข้อสรุปว่าควรทดสอบความสามารถในการแก้ปัญหา เพียงแต่เนื้อหาของการสัมภาษณ์เชิงเทคนิคควรแตกต่างกันตามบทบาท ไม่จำเป็นต้องถามนักพัฒนาเว็บจูเนียร์เรื่องอัลกอริทึมกราฟบนไวท์บอร์ด แต่ถ้าเป็นนักพัฒนาอาวุโสหรือสถาปนิกของผลิตภัณฑ์โซเชียลเน็ตเวิร์กก็ควรเข้าใจอย่างลึกซึ้ง
สัปดาห์ก่อนก็ดีบัก โค้ด Go จากปี 2020 ที่ไม่มีทั้งคอมเมนต์และเอกสารเหมือนกัน นั่นก็เป็นส่วนแกนหลักของระบบ และเหมือนเขียนโดยคนเสียสติ เจ็บปวดมาก
ผมมองว่าความเต็มใจที่จะขุดลงไปข้างล่างเพื่อแก้ปัญหาในเลเยอร์ที่ถูกต้อง เป็นหนึ่งใน soft skill สำคัญที่แยกวิศวกรอาวุโสออกจากคนอื่น แทนที่จะอ้อมด้วยการชดเชยภายหลังในโค้ดของตัวเองเพราะมีบั๊กหรือฟีเจอร์ขาดหายในเลเยอร์ล่าง หากแก้ในเลเยอร์ที่ถูกต้อง ระบบโดยรวมจะทนทานต่อการเปลี่ยนแปลงทั้งขึ้นและลงในสแตก รวมถึงกรณีการใช้งานในอนาคตที่คาดไม่ถึงได้มากกว่า
ในทางกลับกัน หากไม่ใช้แนวทางนี้ พอวิศวกรอาวุโสลาออกหรือถูกแทนที่ด้วยจูเนียร์ โค้ดเบสก็จะเริ่มเน่า ตัวอย่างเช่น ถ้าสำหรับกรณีขอบของการ parse อินพุตแต่ละแบบ เราเอา regex ตรวจสอบแบบไร้เดียงสาไปแปะเพิ่มไว้หน้า parser ที่น่ากลัวและทึบไปเรื่อย ๆ แต่ไม่แก้ไวยากรณ์ของ parser เอง โค้ดเบสก็กำลังวิวัฒน์ไปเป็นกองโคลน
แน่นอนว่าการแก้ในเลเยอร์ที่ถูกต้องมักทำให้บริษัทต้องดูแล hotfix branch ระยะยาวแบบส่วนตัวเล็ก ๆ ของซอฟต์แวร์ในอีโคซิสเต็มที่ใช้ในสแตก เพราะ upstream มักไม่มองว่านั่นเป็นปัญหา จึงไม่รับแพตช์ และเราก็ต้องเก็บไว้เอง
พูดแบบขำ ๆ ถ้ายืนยันผ่านโปรไฟล์ GitHub แล้วนับจำนวนครั้งที่เคยสร้างหรือดูแล hotfix branch ส่วนตัวระยะยาวแบบนี้ ก็น่าจะวัดความอาวุโสของวิศวกรได้ง่ายกว่าการทดสอบเขียนโค้ดมาก
ทำเป็นว่ามันไม่มีประโยชน์ในโลกจริงไปก็ไม่ช่วยอะไร โลกจริงนั้นยุ่งเหยิง เอกสารมักไม่มีหรือเชื่อถือไม่ได้ และคนหรือทีมที่เขียนโค้ดต้นฉบับอาจไม่อยู่แล้ว
มีเกร็ดเล็ก ๆ อยู่เรื่องหนึ่ง คู่สมรสของเพื่อนลาออกเมื่อต้นปีนี้ แล้วเตรียมตัวสัมภาษณ์กับบริษัท Big Tech แต่ละแห่งแห่งละ 4~6 สัปดาห์ เตรียมแบบ Meta 4~6 สัปดาห์, Stripe 4~6 สัปดาห์ ระหว่างนั้นก็ซ้อมด้วยการสัมภาษณ์แบบสุ่มเป็นระยะ ๆ เพื่อสร้างความเคยชินและ muscle memory ไปด้วย ศึกษาปัญหาที่น่าจะเจอในแต่ละบริษัท แล้วทำ LeetCode วันละหลายชั่วโมง
ผลคือไปได้สวย และรับข้อเสนอระดับ L6/staff จาก MAANG แต่พอคุยกันสัปดาห์นี้ เขาบอกว่ายังไม่ทันเริ่มบทบาทใหม่ด้วยซ้ำ รายละเอียดส่วนใหญ่ที่เคยซ้อมมาก็ลืมไปแล้ว เขาบอกว่าส่วนที่ยากที่สุดคือการเตรียม system design เพราะไม่เคยมีประสบการณ์ออกแบบระบบ แต่ตอนนี้ก็ได้เป็น staff eng ของ MAANG แล้ว จากภาพจริงที่เคยทำโปรเจกต์เล็ก ๆ ด้วยกัน เขาเป็นวิศวกรที่ยอดเยี่ยม แต่ไม่ได้โดดเด่นเป็นพิเศษ
มันแปลกจริง ๆ และดูเหมือนจะอธิบายวัฏจักรขาขึ้นขาลงของการจ้างงานได้มากทีเดียว พอดูวิดีโอเตรียมสัมภาษณ์ system design แล้วแทบจะเหมือนบทพูดเลย แค่เข้าไปในห้องสัมภาษณ์แล้วทำตามบทก็พอ ส่วนเคยออกแบบระบบที่คล้ายกันหรือซับซ้อนกว่านั้นจริงไหม ดูเหมือนจะไม่สำคัญ เป้าหมายของการสัมภาษณ์ system design สุดท้ายแล้วเหมือนเป็นการถามว่า “รู้บทไหม”
ถ้าดูสองวิดีโอนี้ต่อกันที่ความเร็ว 2x จะน่าทึ่งมากว่ามันถูกแสดงออกมาเหมือนตามบทแค่ไหน: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc
พ่อแม่ผมทั้งคู่เคยอยู่ในวงการเทคโนโลยีที่ Santa Cruz ช่วงทศวรรษ 1980~90 ตอนนั้นกลุ่มคนเก่งไม่ได้ใหญ่มาก มันจึงเป็นเครื่องมือแบบเปิดกว้างสำหรับหาคนที่จะพัฒนาให้เติบโตเป็นนักพัฒนาได้ วงการตอนนี้รับแนวปฏิบัตินั้นมา แต่กลับทำให้มันกลายเป็นสิ่งที่กีดกันในทางตรงข้าม
หนึ่งในคนที่ผมเคยจ้างเป็นนักฟิสิกส์ เขาไม่รู้ศัพท์เฉพาะทางเลย และตอนเห็นโจทย์ไวท์บอร์ดครั้งแรกก็ตกใจกลัว พอค่อย ๆ พาเขาไปจนถึงจุดที่รู้สึกสบาย เขาก็เริ่มเล่าเรื่องเครื่องมือที่เขาสร้างขึ้นเพื่อช่วยงานฟิสิกส์ของตัวเอง และแปลกใจเมื่อผมบอกว่าเครื่องมือที่เขาสร้างโดยไม่มีความรู้ด้านการพัฒนานั้นก็คือซอฟต์แวร์ นั่นไม่ใช่แค่ซอฟต์แวร์จริง ๆ เท่านั้น แต่ยังน่าประทับใจมากด้วย และโจทย์ไวท์บอร์ดก็เป็นเครื่องมือที่เผยให้เห็น ศักยภาพ
ผมเข้าใจว่าบริษัทใหญ่ ๆ ต้องการชิ้นส่วนสำเร็จรูปที่เสียบเข้าไปใช้งานได้ทันทีแทนที่จะเป็นคน แต่ก็น่าขำที่พวกเขากำลังใช้สิ่งที่เดิมถูกสร้างขึ้นเพื่อจุดประสงค์ตรงกันข้าม บางทีก็คิดว่าโชคดีแล้วที่แก่เกินกว่าจะมีความหวังได้เข้าบริษัทเท่ ๆ ที่ใช้โค้ดชาเลนจ์แบบนี้
ตรรกะคือ ไม่ว่าจะจบมหาวิทยาลัยไหน เคยเรียนวิชาอะไรมา หรือมีข้อได้เปรียบเสียเปรียบแบบใด หากมีคุณสมบัติที่บทบาทต้องการ เนื้อหาเหล่านี้ก็เป็นสิ่งที่เรียนได้ภายในไม่กี่เดือน เทคโนโลยีถูกทำให้เป็นมาตรฐานมาก จึงทำให้กระบวนการค่อนข้างเปลี่ยนเป็นสิ่งที่วัดได้อย่างเป็นกลาง
พวกเขาไม่ได้คาดหวังว่าจะใช้ทักษะเฉพาะนั้นในงานจริง แต่ต้องการให้แสดงให้เห็นว่าสามารถเรียนทักษะประเภทนั้น และทำผลงานในระดับสูงภายใต้สถานการณ์สัมภาษณ์ที่กดดันมากได้ ตรรกะคือสิ่งนี้เป็นสัญญาณที่ดีว่าภายหลังจะสามารถเรียนเทคโนโลยีที่จำเป็นสำหรับโปรเจกต์ที่ได้รับมอบหมาย และทำงานได้ภายใต้แรงกดดันของเดดไลน์ใหญ่ ๆ
ผมไม่ได้กำลังปกป้องระบบนี้ แต่เบื้องหลังมันมีตรรกะที่ชัดเจนอยู่
เจ้าตัวบอกว่าลืมไปแล้ว แต่ถ้าได้ตำแหน่งนั้นมา ก็น่าจะเคยแก้โจทย์ LeetCode ระดับกลางได้ คงยากที่จะบอกว่าลืมไปหมด และมีโอกาสสูงว่ายังแก้โจทย์ง่าย ๆ ที่คนส่วนใหญ่ทำสด ๆ ไม่ได้อยู่ เขาน่าจะยังรู้ complexity ของงานแบ็กเอนด์พื้นฐานอย่างการค้นหา การเรียงลำดับ อาร์เรย์กับการค้นหาในแฮช การเดินต้นไม้และกราฟด้วย
และพรสวรรค์ด้านการแสดงอาจพบได้ทั่วไปในประชากรมากกว่าพรสวรรค์ด้านการเขียนโปรแกรมก็ได้
เมื่อไม่นานมานี้ ผมได้จัดกระบวนการสัมภาษณ์สำหรับตำแหน่งวิศวกรค่อนข้างอาวุโสในสตาร์ทอัพขนาดเล็กแห่งหนึ่ง ผมเชื่อว่าแต่ละคนเหมาะกับรูปแบบการสัมภาษณ์ไม่เหมือนกัน จึงให้ทุกคนมีตัวเลือก
ผมเห็นความไม่พอใจต่อแบบทดสอบเป็นงานมอบหมายมามาก เลยคิดว่าทั้งสามตัวเลือกน่าจะกระจายกันค่อนข้างสม่ำเสมอ แต่ที่น่าประหลาดใจคือผู้สมัครประมาณ 90–95% เลือกแบบทดสอบเป็นงานมอบหมาย สำหรับผมเองถ้าเป็นผู้สมัครก็คงชอบวิธีนี้ จึงเป็นข้อมูลที่น่าสนใจ และน่าทึ่งมากที่คนส่วนใหญ่ก็ชอบแบบนั้น
การสัมภาษณ์แบบพบหน้าบริษัทก็ต้องเสียต้นทุนไม่น้อย จึงพอถือได้ว่าโอกาสที่เวลาของผมจะสูญเปล่าต่ำกว่า ความไม่สมมาตร ในกระบวนการหางานนั้นมากขึ้นอยู่แล้ว และงานมอบหมายก็เป็นแนวโน้มที่เร่งเรื่องนี้ให้หนักขึ้น
เพื่อนที่ไม่ใช่สายเทคนิคคนหนึ่งยังไม่ค่อยพอใจผมจนถึงทุกวันนี้ เพราะครั้งหนึ่งผมทำงานมอบหมายไม่เสร็จ ทั้งที่ข้อกำหนดหลักเห็นชัดว่าเป็นเรื่องเล็กน้อย แต่คำสั่งคลุมเครือพอที่จะทำให้ผมเสียเวลาไปหลายชั่วโมงเพื่อประเมินว่าดีพอจะส่งหรือยัง แถมยังคาดหวังชุดเทคโนโลยีที่แคบมาก ซึ่งแม้จะไม่ยาก แต่ผมก็ไม่อยากเรียนเพื่อโอกาส “ช่วย” บริษัทที่บอกว่าหาคนเก่งด้านเทคนิคไม่ได้
ผมน่าจะชอบข้อ 1 และ 2 มากกว่าข้อ 3 เพราะผู้สัมภาษณ์ต้องเข้าใจโจทย์ที่ผมกำลังแก้ จึงจะประเมินแนวทางของผมได้ดีขึ้น
ถ้าทำจากบ้านแล้วส่งภายหลัง ผู้สัมภาษณ์จะเปรียบเทียบวิธีแก้ของผมกับวิธีของตัวเองหรือวิธีอื่น ๆ บนโจทย์เดียวกัน และเข้าใจ สไตล์การเขียนโค้ด ของผมได้ดีขึ้น
ถ้าทำงานร่วมกันแบบ pair programming ก็จะเห็นกระบวนการคิดของผม และผมอธิบายได้ดีขึ้นว่าทำไมถึงเลือกใช้ idiom บางอย่าง
โค้ดในอดีตแทบไม่มีบริบท มันก็แค่โค้ดที่เขียนขึ้นเพื่อโปรเจกต์อื่น ใช้ได้ดีในช่วงต้น ๆ เพื่อส่งพร้อมเรซูเม่และยืนยันว่าผมเขียนโค้ดได้จริง แต่ในขั้นถัดไปมันจะน่าประทับใจก็ต่อเมื่อมีแอปที่ใช้งานได้ และผมสามารถพาไล่ดูโค้ดของฟีเจอร์เฉพาะได้เท่านั้น แล้วจะมีสักกี่คนที่มีซอฟต์แวร์ที่ทำงานได้อยู่ในมือจริง ๆ? ปกติก็มักมีแค่โค้ดที่พอรันได้ด้วยทริกบางอย่างเท่านั้น
ผมชอบข้อ 1 มากกว่าข้อ 2 เพราะลดโอกาสผิดพลาดได้ แทนที่จะเสี่ยงพังใน 2 ชั่วโมงหน้างานจากแรงกดดันและกฎของเมอร์ฟี แน่นอนว่าผมย่อมเลือกใช้เวลาเพิ่มอีก 2 ชั่วโมงที่บ้าน และมีเวลาค้นคว้าเรื่องที่ไม่รู้ได้อย่างอิสระ
ผมเคยอยู่ฝั่งประเมินแบบทดสอบเป็นงานมอบหมายด้วย และรู้ว่าการทำให้ใครสักคนประทับใจด้วยสิ่งนั้นยากแค่ไหน
ครั้งล่าสุดที่ผมสัมภาษณ์เขียนโค้ดจริง ๆ ผมเลือกภาษาโปรแกรมอะไรก็ได้ และเลือกโจทย์ที่จะทำได้จาก 3 ข้อ ผมค่อนข้างชอบ และก็ได้ offer ด้วย การได้เลือก Python แทน C++ ในการสัมภาษณ์ที่มีเวลาจำกัดนั้นรู้สึกแทบจะเหมือนใช้สูตรโกง
ยิ่งเห็นคนบ่นเรื่องการสัมภาษณ์เขียนโค้ดทางออนไลน์มากขึ้นเท่าไร ผมก็ยิ่งมั่นใจว่า การสัมภาษณ์เขียนโค้ด เป็นวิธีที่ดีที่สุดอย่างแท้จริงในการคัดกรองผู้สมัครตำแหน่งพัฒนาซอฟต์แวร์ ในอุตสาหกรรมนี้มีคนพูดเก่ง คนแอบอ้าง และคนที่คอยนัดประชุมมากเกินไป แต่มีคนที่พับแขนเสื้อแล้วลงไปเขียนโค้ดจนทำงานให้เสร็จจริง ๆ ไม่พอ
ปัญหานี้ยิ่งหนักขึ้นเมื่อขึ้นไปสู่ระดับสูง ๆ จะบ่นเท่าไรก็ได้ แต่งาน FAANG สบาย ๆ เงิน ปีละ 500,000 ดอลลาร์ ไม่ใช่สิ่งที่ได้มาโดยอัตโนมัติ ถ้าไม่ยอมกลับไปดูพื้นฐานการเขียนโปรแกรมและเขียน for loop สักสองสามอัน บริษัทก็จะข้ามไปหาคนที่ยอมทำแบบนั้นแทน
ถ้าการสัมภาษณ์ทดสอบความสามารถในการพับแขนเสื้อแล้วลงมือเขียนโค้ดจริง ๆ ทำไมผมในฐานะคนที่เพิ่งเข้าใหม่ถึงต้องอธิบายแนวปฏิบัติด้าน software engineering และ debugging ให้คนที่อยู่มานานฟังมากขนาดนั้นก็ไม่รู้
ถ้าเคยทำงานในบริษัทใหญ่จริง ๆ จะรู้ว่างานจริง 90% ทำโดยคนไม่ถึง 5% ถ้าการสัมภาษณ์ทำงานได้ถูกต้อง สัดส่วนนี้ควรจะดีกว่านี้มาก
มีทั้ง Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/ภาษาอื่น ๆ, LeetCode กับเว็บสมัครสมาชิกพรีเมียมแบบเสียเงิน ไปจนถึง bootcamp ซ้อมสัมภาษณ์ ตอนนี้มันใกล้เคียงกับการเล่นเกมระบบมากกว่าการวัดความสามารถแล้ว
น่าประหลาดใจที่ไม่มี ความไม่สอดคล้องทางความคิด เลยระหว่างสมมติฐานที่ว่าการสัมภาษณ์เขียนโค้ดเป็นวิธีจ้างงานมาตรฐาน กับความจริงที่ว่าผลลัพธ์มันแย่ขนาดนี้
ถ้าโจทย์เป็นเรื่องอย่างการทำ tokenization ของ LLM จะห้ามใช้ LLM ในโจทย์ “ML-LeetCode” ได้อย่างไร?
ถ้าผู้สมัครเป็นผู้เชี่ยวชาญที่ใช้ Cursor กับ Claude เขียนโค้ดได้คล่อง จนแก้ได้ใน 10 นาทีด้วย prompt 3 อันและการแก้บั๊กที่หาเจอง่าย ๆ 2 จุด แถมยังมี论文ระดับ NeurIPS และโค้ด open source ด้วย ผมคัดกรองนักต้มตุ๋นตัวปลอมออกไป หรือกำลังคัดผู้สมัครระดับท็อปออกกันแน่?
ผมไม่เห็นว่าโจทย์แบบ LeetCode จะสมเหตุสมผลสำหรับคนที่ทำงานเกี่ยวกับ LLM ไม่ว่าจะชอบหรือไม่ งาน FAANG+ สบาย ๆ เงินปีละ 500,000 ดอลลาร์ในอนาคตจะเกี่ยวข้องกับ LLM มากขึ้นเรื่อย ๆ
การให้ Ruby developer ดีบัก PHP เพื่อทดสอบความยืดหยุ่น ฟังดูเป็นการทดสอบที่โอเคนะ นักพัฒนาที่เก่ง โดยเฉพาะ senior developer ควรทำเรื่องแบบนั้นได้ การจำกัดตัวเองว่าเป็นแค่ “Ruby developer” อย่างเดียวคือกับดักทางอาชีพ
บางครั้งต้องดีบัก DSL เก่า ๆ ที่ผูกกับ vendor เฉพาะ หรือโค้ดที่เฟรมเวิร์กกับมาตรฐานเก่ามากจนแทบกลายเป็นอีกภาษาไปแล้ว
ยังมีงานเพิ่มการรองรับฟีเจอร์ที่ backport มา หรือแพตช์ช่องโหว่ความปลอดภัยให้ไคลเอนต์เก่ากับ legacy stack ด้วย ในบริษัทใหญ่ เราเคยต้องรับผิดชอบโค้ด escrow ของพาร์ทเนอร์ที่เล็กกว่ามากด้วย
การจัดสภาพแวดล้อมให้ดีบักได้จริงมักเป็นงานใหญ่กว่าการแก้ไขจริงเสียอีก ถึงอย่างนั้นก็ยังเป็นการทดสอบที่ดีสำหรับระดับ senior ขึ้นไป
เมื่อผู้สัมภาษณ์บอกว่า “ลองกลับลำดับ array นี้ดู” ผมตอบว่า “ถ้าเป็น Python ผมจะใช้ array.reverse() หรือ reversed(array) และใน JS ก็น่าจะมีอย่างใดอย่างหนึ่ง ดังนั้นน่าจะเป็นเมธอด .reverse” ผู้สัมภาษณ์บอกว่า “เดาได้ดีครับ”
ผมออกมาด้วยความรู้สึกว่าสนุกจริง ๆ และได้เรียนรู้อะไรหลายอย่าง อีกฝ่ายก็ได้เห็นว่าผมใช้เหตุผลกับปัญหาใหม่ ๆ อย่างไร
ผมเคยดีบัก codebase เก่า ๆ ที่ไม่มีเอกสารและไม่มีทีมช่วยมาหลายครั้งแล้ว ระบบที่คนสร้างไม่เหลืออยู่เลย และเอกสารไม่มีหรือหาไม่เจอมีอยู่จริง ดังนั้นตัวอย่างนี้จึงไม่ค่อยดีนัก ความสามารถในการดีบักโปรแกรม ไล่ตาม flow ของ request และดูว่าเกิดอะไรขึ้น เป็นทักษะที่ดี
แต่จุดที่ตัวอย่างนี้แย่จริง ๆ คือการ จับนักพัฒนาไปขังไว้ในกรงนกพิราบ ตามเทคโนโลยีเฉพาะ ถ้ามีแอปพลิเคชัน PHP legacy ก็จะคัดคนที่เป็น Java, Python, Ruby, Go ซึ่งมีความสามารถดีบักแบบนั้น แต่อาจช้าเพราะไม่รู้ PHP ออกไป ทั้งที่ถ้าได้จับ PHP เองสักไม่กี่เดือน อาจกลายเป็นนักพัฒนาที่แข็งแกร่งกว่าก็ได้
ผมเห็นด้วยว่า “งาน 4 ชั่วโมง” สามารถบานปลายเป็น 8 ชั่วโมง 10 ชั่วโมง หรือมากกว่านั้นได้ง่าย ๆ เพื่อให้ได้ผลงานที่ดี เวลาที่ระบุสามารถถูกเล่นเกมได้ง่าย ทำให้คนที่มีเวลามากกว่าดูเหมือนเป็นผู้สมัครที่ดีกว่า
ถามว่าเคยดีบัก codebase เก่า ๆ ที่ไม่มีเอกสารและไม่มีทีมช่วยเมื่อไหร่น่ะหรือ? ทุกวัน ในสัปดาห์นี้เลย
ถ้าเป็นเอกสาร โค้ดอัปเดตล่าสุดในเดือนมิถุนายน ส่วนเอกสารอัปเดตล่าสุดในเดือนมกราคม 2022
ถ้าเป็นทีม ครึ่งหนึ่งที่ไม่ได้ถูกเลิกจ้างเมื่อสองปีก่อนก็ย้ายไปที่ที่ดีกว่ากันหมดแล้ว แน่นอนว่ามีทีมที่เป็นเจ้าของโปรเจกต์นี้อยู่ แต่พวกเขาก็มีอีกสามโปรเจกต์ด้วย และตลอดปีที่ผ่านมา contribution ให้ตรงนี้มีแค่ราวสิบกว่าบรรทัด ซึ่ง 11 บรรทัดในนั้นเป็นการอัปเดต dependency
คำว่า “เหมือนให้ Ruby developer ไปดีบัก PHP” หรือ “ถ้าตำแหน่งต้องใช้เทคโนโลยีเฉพาะ ก็ทดสอบเทคโนโลยีนั้น” ฟังดูเหมือนคนที่ตก coding challenge
พูดจริง ๆ บริษัทแทบไม่ค่อยนำแนวทางการจ้างงานมาใช้แค่เพื่อความสนุก โดยปกติมันคือวิธีที่ดีที่สุดที่ภูมิปัญญารวมของกลุ่มนั้นคิดออก การบอกให้เลิกโดยไม่พยายามเข้าใจว่าพวกเขากำลังแก้ปัญหาอะไร และไม่เสนอทางเลือกอื่น ไม่ได้ช่วยให้เกิดผล
ผมคิดว่าในการพัฒนาซอฟต์แวร์ เรามักคิดค้นวงล้อใหม่บ่อยเกินไป แทนที่จะยืมแนวปฏิบัติจากอาชีพอื่น ลองดูว่า วิศวกรโยธา ต้องผ่านกระบวนการจ้างงานแบบไหนเพื่อรับเงินเดือนครึ่งหนึ่งของนักพัฒนาซอฟต์แวร์ แล้วนำสิ่งนั้นมาผสานกับแนวปฏิบัติของเรา แบบนั้นทุกคนก็จะเป็นทหารที่มีความสุขกันหมด
ผมคิดว่าโอกาสที่พวกเขาจะไตร่ตรองจริง ๆ ว่าต้องการบรรลุอะไรนั้นต่ำมาก แค่ทำตามเพราะคนอื่นทำกัน และเชื่อว่าขั้นตอนนั้นต้องมีใครสักคนที่ไหนสักแห่งสร้างขึ้นมาอย่างมีเจตนา
การจ้างงานสายเทคนิคหลงทางไปมาก จนอย่างดีที่สุดก็ดูเหมือนมาติดอยู่ที่ local maximum เท่านั้น
ผมมีประสบการณ์แย่มากกับบริษัทที่ไม่มีการทดสอบเขียนโค้ดเลย มีแค่สัมภาษณ์ 2–3 รอบเท่านั้น
ปัญหาเริ่มปรากฏเมื่อเริ่มทำงานร่วมกับทีม data engineering สแต็กส่วนใหญ่ตั้งอยู่บน Hadoop, Kubernetes, Ruby, Python และเทคโนโลยีหลายอย่าง อีกทั้งต้องมีความเข้าใจพื้นฐานเกี่ยวกับ cloud computing
แต่ประสบการณ์ทำงานและพื้นหลังของแต่ละคนต่างกันมาก จนแทนที่จะได้ทำงานที่ผมถูกจ้างมา ผมกลับต้องคอยอุดช่องว่างให้คนอื่นบ่อย ๆ เพื่อนร่วมงานบางคนทำงานพื้นฐานอย่างการแพ็กเกจ Python CLI ด้วย Docker หรือการตรวจงาน Hadoop ไม่ได้ ผมจึงต้องทำ glue work เพื่อชดเชยอยู่มาก
สุดท้ายผมก็ลาออก ไม่ใช่เพราะคิดว่าตัวเองพิเศษ แต่เพราะเบื่อที่จะใช้เวลา 80% ไปกับการ support คนที่ถูกจ้างเข้ามาในระดับเดียวกันหรือสูงกว่า ยอมรับว่ากระบวนการจ้างงานของบริษัทนั้นแย่มาก แต่การทดสอบทักษะพื้นฐานในรูปแบบใดรูปแบบหนึ่งก็จำเป็น
อีกคำถามสำคัญคือ ต้องอธิบายเรื่องเดิมซ้ำ ๆ ให้คนเดิมฟังหรือไม่ การไม่รู้นั้นพอรับได้ แต่การไม่ยอมเรียนนั้นยอมรับได้ยาก
ส่วนที่น่าสนใจของการทดสอบแบบให้ทำโจทย์กลับไปคือ แม้จะบอกว่า “ใช้เวลาแค่ X ชั่วโมงพอ” แต่ก็มี moral hazard ที่ชักจูงให้ผู้สมัครใช้เวลามากกว่านั้นอยู่ดี และถ้าบริษัทถาม ก็ยังเกิดแรงจูงใจให้โกหกเรื่องเวลาที่ใช้จริงด้วย
ผมเคยส่งงานที่แก้ปัญหาได้อย่างเหมาะสมโดยเน้นให้ทำให้อยู่ภายในเวลาที่แนะนำอยู่หลายครั้ง แต่ในสัมภาษณ์รอบถัดไปกลับถูกตำหนิว่า “ทำไมไม่ implement X ล่ะ?”
ในเรื่องนี้ การทดสอบแบบให้ทำโจทย์ที่เปิดกว้างเกินไปถือเป็นโจทย์ที่ไม่ดี เพราะมันเอื้อให้คนที่มีเวลาว่างมากกว่าและทำได้ละเอียดกว่าได้เปรียบ ขอทักทายไปถึงการทดสอบแบบให้ทำโจทย์ด้าน data science ที่กำหนดให้ผลลัพธ์สุดท้ายเป็นสไลด์นำเสนอ PowerPoint