คนที่เบื่อการสัมภาษณ์สไตล์ LeetCode
(nelson.cloud)- หลังลาออกจาก Robinhood เมื่อปลายเดือนพฤศจิกายน 2023 ด้วยปัญหาสุขภาพ และผ่านกระบวนการสรรหาหลายแห่ง ผู้เขียนรู้สึกว่า การประเมินแบบ LeetCode ไม่สอดคล้องกับงานวิศวกรรมซอฟต์แวร์จริง
- มองว่าหลายบริษัททำตามแนวทางของ บริษัทเทคโนโลยีขนาดใหญ่ อย่าง Google, Facebook/Meta และ Amazon จึงทำให้การสัมภาษณ์คล้ายกันซ้ำไปมา
- วิจารณ์ว่า แม้วิศวกรจะบอกว่าไม่จำเป็นต้องท่องจำความรู้ที่ค้นหาได้ แต่ในการสัมภาษณ์กลับถาม ความรู้ที่ค้นหาได้ ซึ่งนึกออกทันทีได้ยาก ราวกับเป็นแบบทดสอบความจำ
- ผู้เขียนเคยทั้งผ่านและไม่ผ่านการสัมภาษณ์ลักษณะนี้ และเหตุผลของความไม่พอใจมาจาก ประสบการณ์ทำงานจริง ที่ผ่านมา มากกว่าประสบการณ์ความล้มเหลว
- เสริมว่าหากมีบริษัทที่กำลังมองหาวิศวกรที่มีประสบการณ์ AWS, Kubernetes และ Ruby on Rails โดยไม่ใช้ คำถามจุกจิกไร้สาระ ก็สามารถติดต่อมาได้
จุดที่การสัมภาษณ์แบบ LeetCode ไม่สอดคล้องกับงานจริง
- หลังลาออกจาก Robinhood เมื่อปลายเดือนพฤศจิกายน 2023 ด้วยเหตุผลด้านสุขภาพ ผู้เขียนได้สัมภาษณ์กับหลายบริษัท
- แม้กระบวนการสรรหาจะไม่ไปต่อด้วยหลายเหตุผล แต่ผู้เขียนรู้สึกเหนื่อยล้ากับ การสัมภาษณ์สไตล์ LeetCode ที่เกิดซ้ำ ๆ
- มองว่าการสัมภาษณ์แบบนี้ไม่สะท้อน ความรับผิดชอบของวิศวกรรมซอฟต์แวร์ ในโลกจริงได้เพียงพอ
- หลายบริษัทดูเหมือนจะนำวิธีประเมินแบบเดียวกันมาใช้ เพียงเพราะเป็นแนวทางที่บริษัทใหญ่ ๆ อย่าง Google, Facebook/Meta และ Amazon ใช้กัน
ความขัดแย้งระหว่างการประเมินแบบตอบคำถามกับประสบการณ์ทำงานจริง
- มีวิศวกรที่มักพูดว่าไม่จำเป็นต้องท่องจำความรู้ที่สามารถค้นหาใน Google ได้ง่าย ๆ
- แต่ในการสัมภาษณ์ กลับมีกรณีที่ถามเรื่องซึ่งถึงจะค้นหาก็รู้ได้ แต่ยากจะนึกออกทันที จึงรู้สึกว่าเป็นเรื่อง ย้อนแย้ง
- แม้ยังไม่มีวิธีแก้ที่ชัดเจนสำหรับปัญหานี้ แต่ผู้เขียนเห็นว่าตัวปัญหานั้นชัดเจน
- ผู้เขียนเคยประสบทั้งความสำเร็จและความล้มเหลวในการสัมภาษณ์ประเภทนี้ และมุมมองนี้ได้รับอิทธิพลจาก ประสบการณ์ทางวิชาชีพ ที่ผ่านมามากกว่าอัตราความล้มเหลว
- หากบริษัทใดต้องการวิศวกรซอฟต์แวร์ที่มีประสบการณ์ AWS, Kubernetes และ Ruby on Rails และไม่ใช้ การสัมภาษณ์แบบตอบคำถามทดสอบความจำ ก็สามารถติดต่อได้
- แนะนำให้อ่านบทความที่เกี่ยวข้อง Re-imagining Technical Interviews: Valuing Experience Over Exam Skills
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เข้าใจความอึดอัดนะ แต่สุดท้ายก็คิดว่าการสัมภาษณ์แบบนี้ก็มีจุดประสงค์ของมัน ถึงจะทำได้ไม่ดีนักแต่ก็ยังพอใช้ได้ และโดยทั่วไปแล้วมักสร้าง ผลลบลวง มากกว่า ผลบวกลวง จึงสมเหตุสมผลในมุมของบริษัท
ต้นทุนจากการปล่อยให้คนฉลาดหลุดไปนั้นต่ำกว่า แต่ถ้ารับคนที่ไม่เหมาะเข้ามา ก็ต้องใช้เวลาหลายเดือนกว่าจะพิสูจน์ได้ ต้องไล่ออก แล้วก็ต้องจ้างใหม่ ซึ่งมีค่าใช้จ่ายสูงมาก อย่างไรก็ดี สำหรับผู้สมัครมันเป็นกระบวนการที่เจ็บปวดอย่างยิ่ง และแม้แต่วิศวกรซอฟต์แวร์ที่ยอดเยี่ยมก็อาจจะตื่นเต้น พลาด หรือแค่เจอวันซวยจนตกได้หลายครั้ง การสัมภาษณ์ไม่ใช่คำตัดสินสุดท้ายของคุณค่าชีวิต มันเป็นแค่เครื่องมือทื่อ ๆ ก็ปล่อยมันผ่านไปได้
คำถามแบบ “ดักจับ” นั้นงี่เง่า แต่เราควรดูว่าผู้สมัครรู้พื้นฐานไหม และในขณะเดียวกันก็ควรแสดงให้เห็นด้วยว่าบริษัทเราเป็นที่แบบไหน เช่น ถ้าถามว่า “แก้ไข argument ได้ไหม?” หรือพูดว่า “จำไม่ได้ว่า strlen รวมไบต์ 0 หรือเปล่า งั้นผมจะบวก 1 ไว้ก่อน ปกติผมคงไปเปิดดู” นั่นเป็นสัญญาณที่ดี โจทย์ก็อยู่ระดับอย่าง atoi หรือ “สับไพ่หนึ่งสำรับ” คือเป็นพื้นฐานแต่ไม่ได้จิ๊บจ๊อยระดับ fizzbuzz หนึ่งในคนที่เราจ้างได้ดีที่สุดเคยทำพลาดแบบพื้นฐาน แต่พอถามว่ามันจะทำงานตามที่ตั้งใจไหม เขาก็ตอบว่า “ผมนี่โง่ชะมัด” แล้วแก้ได้ทันที น้ำเสียงแบบนั้นอาจไม่เหมาะในสัมภาษณ์ แต่สำหรับเราเป็นสัญญาณบวกที่แรงมาก ตรงกันข้ามก็เคยมีผู้สมัครที่ยืนกรานจนจบว่าคำถามให้ parse สตริงแล้วคืนค่าเป็นจำนวนเต็มนั้นไม่ยุติธรรม เพราะมีฟังก์ชันในไลบรารีอยู่แล้ว ทั้งที่จริงบางส่วนของระบบเราทำงานในสภาพแวดล้อม embedded ที่ไม่มีไลบรารี
อยากให้เลิกเลียนแบบวิธีทดสอบที่แย่ของโรงเรียนและมหาวิทยาลัย ที่เริ่มจากวัดความจำก่อน ฉันลำบากมากกับการต้องนึกสด ๆ ตอนนั้น และคงไม่ได้เป็นคนเดียว เวลาไปสัมภาษณ์นักพัฒนา Android ฉันจะถามคำถามแล้วดูวิธีคิดของเขา ไม่ได้คาดหวังว่าทุกคำตอบต้องเป๊ะทั้งหมด พอดูว่าเขาเข้าใจพื้นฐานของ Android ไหมแล้ว ก็ให้ลองทำแอปเล็ก ๆ ที่บ้าน
ท้ายที่สุดในการจ้างที่ต้องเติมตำแหน่งให้เต็ม ยิ่งมีผลลบลวงมากขึ้น โอกาสที่จะได้ ผลบวกลวง ก็เพิ่มขึ้นด้วย ถ้ามองแบบสุดโต่งว่าบนโลกนี้มีคนที่เหมาะกับงานนี้อยู่แค่คนเดียว แล้วคุณดันคัดเขาทิ้งด้วยผลลบลวง ทางเลือกที่เหลือก็มีแค่จ้างคนที่ไม่ใช่เท่านั้น
ปัญหาไม่ใช่เรื่องขาดสติปัญญา แต่คือแม้จะแก้โจทย์อัลกอริทึมเก่ง ก็อาจไม่ใช่วิศวกรซอฟต์แวร์ หรือไม่มีความสามารถตามที่ตำแหน่งนั้นต้องการ ฉันทำงานในทีมที่รับคนด้วยการสัมภาษณ์แนวปริศนาเยอะ ทุกคนฉลาด แต่ไม่ใช่วิศวกรซอฟต์แวร์ และความต่างนั้นเห็นได้ชัดมาก
ถ้าใครทำได้ มีโอกาสสูงกว่ามากว่าไม่ได้คิดคำตอบที่เหมาะที่สุดขึ้นมาใหม่จริง ๆ แต่เคยเจอโจทย์เดียวกันหรือคล้ายกันมาก่อนระหว่างทำแบบฝึกหัด
ครั้งหนึ่งฉันเคยเจอการสัมภาษณ์ที่ชอบมากทีเดียว เป็นของธนาคาร เขาให้โค้ดที่เขียนแบบรีบ ๆ เละ ๆ แต่ไม่ได้จงใจทำให้อ่านยาก แล้วให้รีแฟกเตอร์ให้ดีที่สุดเท่าที่ทำได้
ผู้สัมภาษณ์นั่งข้าง ๆ แล้วคุยกันตลอดทั้งกระบวนการ แทบจะเป็น pair programming ที่ผู้สมัครเป็นคนนำ หลังจากผ่านการสัมภาษณ์แบบ LeetCode มาหลายรอบ มันสดใหม่มาก แน่นอนว่าธนาคารนั้นรู้แน่ชัดอยู่แล้วว่าตัวเองใช้เทคโนโลยีอะไร จึงไม่ค่อยจำเป็นต้องวัดความสามารถในการเรียนรู้เทคโนโลยีใหม่ สำหรับพวกเขา การเขียนโค้ดที่ดูแลรักษาได้ การตั้งชื่อให้ดี และการสื่อสารกับเพื่อนร่วมงานสำคัญกว่า
สิ่งที่น่าสนใจคือมีคนที่เกือบล้มเหลวในคำถามพื้นฐาน แต่พอถึงช่วงรีวิวโค้ดกลับทำได้ดีจนเห็นความเชี่ยวชาญเชิงลึก การสัมภาษณ์เป็นเครื่องมือที่ค่อนข้างแย่ในการแสดงความสามารถในการทำงานของคน แต่ถ้าคนหนึ่งมองปัญหาได้ทั้งกว้างและลึก และยังเขียนโค้ดได้ดีพอ ก็มักนับว่าสำเร็จ
การสัมภาษณ์แบบ LeetCode น่าจะทำหน้าที่อยู่สองอย่าง อย่างแรกคือเป็นเครื่องมือกด ค่าจ้างและความคล่องตัวในการย้ายงาน ของวิศวกรซอฟต์แวร์ ถ้าจะย้ายงานก็ต้องอ่านหนังสือเตรียมตัวเป็นเดือนสองเดือน แล้วใครจะย้ายได้ง่าย ๆ
ถ้าโชคร้ายเจอผู้สัมภาษณ์ที่ตั้งใจเตรียมมาเต็มที่แล้วโยนโจทย์ระดับ LeetCode hard มาให้ ก็อาจยากที่จะสมัครบริษัทนั้นใหม่ได้อีกตลอด 1 ปี อย่างที่สองคือเป็นเครื่องมือซ่อนอคติของกระบวนการไว้ใต้คำอ้างว่าทุกคนมีเป้าหมายที่คล้ายกันและชัดเจน ถ้าเป็นคนที่มาจากมหาวิทยาลัยเดียวกัน เพศเดียวกัน หรือเชื้อชาติเดียวกัน แม้จะให้โจทย์เดียวกันก็อาจให้ hint ยอมมองข้าม syntax error และถึงจะหาวิธีที่เหมาะที่สุดไม่ได้ก็ยังให้ผลประเมินการจ้างงานที่ดีเพราะ “สื่อสารดี” ได้ ถ้าเป็นคนที่ไม่ถูกใจก็แค่โยนโจทย์ยาก ๆ แล้วนั่งเงียบทั้งสัมภาษณ์ สำหรับบริษัทนี่อาจเป็น noise ที่ยอมรับได้ แต่สำหรับแต่ละคนมันคือการเสียโอกาสค่าตอบแทนระดับหลายแสนดอลลาร์ เคยทั้งไปสัมภาษณ์ FAANG และเป็นผู้สัมภาษณ์เอง จึงเห็นทั้งคนที่ถูกจ้างด้วยมาตรฐานต่ำ และในเวลาเดียวกันก็เห็นวิศวกรเก่ง ๆ พลาดโอกาสเพราะโดนคำถามเหลวไหลอย่าง quadtree หรือ number theory
ถ้าตั้งต้นว่าผู้สัมภาษณ์ยุติธรรม วิธีนี้ก็เปิดโอกาสให้ผู้สมัครที่ไม่มีชื่อสถาบันดังในเรซูเม่ได้แสดงความสามารถ โอกาสบางส่วนที่ผมได้มาในฐานะคนที่ไม่มีปริญญาวิทยาการคอมพิวเตอร์ คงไม่มีทางเกิดขึ้นเลยถ้าไม่มีการสัมภาษณ์หน้ากระดาน เป็นเรื่องยากจะนึกวิธีป้องกันกรณีที่ผู้สัมภาษณ์อยากรับเพื่อนตัวเองจนจงใจบิดขั้นตอน
หลายบริษัทมีคลังโจทย์ที่ออกแบบมาให้ยุติธรรมและเกี่ยวข้องกับปัญหาในโลกจริงพอสมควร บริษัทที่ผมเคยสัมภาษณ์ส่วนใหญ่ก็เป็นแบบนั้น และถึงจะไม่ใช่โจทย์ LeetCode ตรง ๆ สุดท้ายมันก็ยังเป็นโจทย์โค้ดดิ้งแบบแยกเดี่ยว จึงถือว่าเป็นสไตล์ LeetCode การสัมภาษณ์ของบริษัทที่บริหารวิธีนี้ได้ดีถือว่าค่อนข้างโอเค บริษัทและผู้สัมภาษณ์ที่ดีไม่ได้ดูแค่โค้ดสุดท้าย แต่ดูอย่างอื่นมากกว่านั้นด้วย และยังให้คะแนนการจ้างงานเป็นสเกลเพื่อลดความเป็นตัดสินแบบสองค่า
ในโลกจริง แค่ fizzbuzz ก็กรองคนออกได้ 75% แล้ว หลายคนพออยู่ภายใต้ความกดดันก็เขียนโค้ดไม่ได้ และบางคนก็พยายามเอาตัวรอดด้วยการคัดลอก·วาง คนแบบนี้ไม่ได้แปลว่าทำงานอะไรไม่ได้เลย แต่จะช้าและสร้าง abstraction แปลก ๆ แล้วกินเวลาไปมากกว่าจะได้ผลลัพธ์ที่ใช้ได้ และคนเหล่านั้นก็เถียงกลับแบบเดียวกัน เพราะมีเงินระดับหลายแสนดอลลาร์เป็นเดิมพัน
จากมุมมองบริษัทก็สมเหตุสมผล เพราะอยากได้พนักงานที่ไม่วอกแวกและทำงานล่วงเวลาได้
ทุกวันนี้มีคำวิจารณ์ที่สมเหตุสมผลมากมายต่อแนวปฏิบัติการจ้างงานสายเทค แต่การบ่นว่า “ถ้าไม่ขายวิญญาณก็รวยมหาศาลไม่ได้” ฟังดูไม่ค่อยน่าเชื่อเท่าไร
สิ่งสำคัญในการคัดเลือกวิศวกรซอฟต์แวร์ไม่ใช่ความรู้ แต่คือ ความสามารถในการแก้ปัญหา และความสามารถในการสร้าง mental model ของปัญหา
ถ้าผู้สมัครไม่เคยเห็นปัญหานั้นมาก่อน และผู้สัมภาษณ์เข้าใจว่าควรดูอะไร การสัมภาษณ์หน้ากระดานก็เป็นวิธีที่ดีในการประเมินความสามารถนี้ แต่เหมือนกฎของ Goodhart เมื่อสิ่งที่วัดกลายเป็นเป้าหมาย มันก็จะไม่ใช่ตัวชี้วัดที่ดีอีกต่อไป คนที่ความสามารถด้านการแก้ปัญหาหรือการทำโมเดลไม่แข็งแรงนักก็ยังอยากได้งานซอฟต์แวร์เงินเดือนสูง จึงโหมทำ LeetCode และเมื่อเวลาผ่านไปคนเหล่านั้นก็กลายเป็นผู้สัมภาษณ์ แล้วทำการสัมภาษณ์เหมือนเป็นการทดสอบความจำอย่างที่ตัวเองเคยเจอ ถึงอย่างนั้น ภายใต้ข้อจำกัดที่บริษัทมี รวมถึงเงื่อนไขว่าต้องลดการเสียเวลาของผู้สมัคร และต้องรักษาแบบประเมินที่สม่ำเสมอซึ่ง HR ชอบ ผมก็ยังไม่เห็นวิธีสัมภาษณ์ที่ดีกว่านี้ถูกเสนอขึ้นมา และคงยังถูกใช้อยู่ไปอีกพักใหญ่
มันใกล้กับการสร้างซอฟต์แวร์มากกว่า LeetCode อยู่ไกลจากงานจริงเกินไป และผลลัพธ์ก็มีความสัมพันธ์กับความเหมาะสมต่อการทำงานจริงน้อยเกินไป
มันเหมือนถังรั่ว แต่บริษัทก็พอใจกับสภาพที่เป็นอยู่ และนักพัฒนาก็ยังคงโหมทำ LeetCode ต่อไป ดูไม่น่าจะเปลี่ยนเร็ว ๆ นี้ แต่ก็ดีที่เวลาเปลี่ยนงานใหม่ ผมอยู่ในสถานะที่สามารถปฏิเสธการสัมภาษณ์แบบนี้ได้
มีเพื่อนคนหนึ่งเคยหยุดพูดกลางการสัมภาษณ์เทคนิค แล้วลุกขึ้นเดินออกไปเลย คนของบริษัทวิ่งตามไปพร้อมพูดว่า “เป็นอะไรไป คุณทำได้ดีอยู่นะ!” แต่เขาบอกว่าหดหู่เกินไปจนไม่สนใจต่อแล้ว
น่าเศร้า ทั้งที่สำหรับคนส่วนใหญ่แล้วมันควรเป็นอาชีพที่สนุก
แต่พอสัมภาษณ์ไปได้สักพัก ก็มีการเอากระดานมา แล้วเพื่อนร่วมงานหลายคนเข้ามาให้ผมใช้ปากกาทำ implementation ของเรื่องพื้นฐานต่าง ๆ ยิ่งดำเนินไปก็ยิ่งเป็นปฏิปักษ์และเสียมารยาท จนรู้สึกเหมือน การกลั่นแกล้งที่ถูกทำให้เป็นพิธีกรรม เหมือนกำลังทดสอบว่าผมจะทนต่อการถูกดูหมิ่นและความเป็นศัตรูได้ไหม ทั้งที่ผลลัพธ์ทางเทคนิคนั้นเล็กน้อยมาก สุดท้ายผมหยุดการสัมภาษณ์แล้วพูดว่า “ผมเห็นแล้วว่าพวกคุณทำงานกันอย่างไร และตัดสินใจแล้วว่าไม่อยากทำงานที่นี่ ขอบคุณสำหรับโอกาส และขอโทษที่ทำให้เสียเวลาซึ่งกันและกัน” แล้วก็เดินออกมา CEO ยังวิ่งตามมาถึงลานจอดรถเพื่อถามว่าเกิดอะไรขึ้น และดูช็อกจริง ๆ ที่ผู้สมัครจะตัดสินใจระหว่างการสัมภาษณ์ได้ คนมักลืมว่าการสัมภาษณ์งานเป็นเรื่องสองทาง ตั้งแต่วันนั้นผมก็ตระหนักว่าผมมีสิทธิ์ดูทุกแง่มุมของบริษัทที่ผมอาจเข้าไปทำงานด้วย และถ้าเห็นอะไรในทางลบระหว่างกระบวนการ ก็ไม่จำเป็นต้องยอมประนีประนอม วันถัดมาผมได้เจอคนที่จนถึงทุกวันนี้ก็ยังเป็นทั้งเพื่อนและเพื่อนร่วมงานที่ดีในบริษัทคู่แข่ง ดังนั้นมันจึงเป็นการตัดสินใจที่ถูกต้อง อาชีพนี้สนุกก็จริง แต่ถ้าความสนุกนั้นถูกเก็บเกี่ยวและเอาเปรียบเหมือนทำฟาร์ม มันก็ไม่ต่างจากการกดขี่รูปแบบอื่น
พอผมบอกว่า “วันนี้เหมือนจะไม่ใช่วันของผม และผมอยากหยุดการสัมภาษณ์” พวกเขากลับพยายามอย่างมากที่จะให้ผมอยู่ต่อจนหมดเวลา ผมคิดว่าถ้าผู้สมัครอยากออก ก็ควรปล่อยให้เขาออก
แม้เวลาจะผ่านไป 5 ปีแล้ว ตอนนี้ก็ยังปฏิเสธการสัมภาษณ์แบบนี้อยู่ และไม่อยากเจอกระบวนการนั้นอีกแล้ว เคยถูกคนที่ปฏิบัติต่อคนเหมือนเกมเตะคนยาวหนึ่งชั่วโมงกลั่นแกล้งและเยาะเย้ย และไม่อยากข้องเกี่ยวอีกต่อไป
เพราะมีการสัมภาษณ์ LeetCode แบบไม่แจ้งล่วงหน้าบ่อยมาก จึงเขียนไว้ชัดเจนในโปรไฟล์ LinkedIn [1] และ GitHub [2] ว่าอะไรยอมรับได้และอะไรยอมรับไม่ได้: “ผมมีนโยบายส่วนตัวที่คัดค้าน live coding ทุกรูปแบบและการทดสอบเขียนโค้ดออนไลน์ระหว่างการสัมภาษณ์ และไม่ได้สนุกหรือเข้าร่วม competitive programming แทนที่จะเป็นแบบนั้น ผมยินดีทำโจทย์เขียนโค้ดแบบ take-home ที่มีเป้าหมายและกำหนดเวลาสมเหตุสมผล รวมถึงการพูดคุยเชิงเทคนิคเชิงลึกเกี่ยวกับ software architecture, การออกแบบ และเทคโนโลยีที่เกี่ยวข้อง”
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
แต่ก็มีคนพูดกันว่าในการสัมภาษณ์แบบมอบหมายงานมีการโกงกันแพร่หลาย เลยกังวลว่านายจ้างที่อยากใช้วิธีนี้จะลดลงอย่างรวดเร็ว
ถ้าจะลองมองอีกมุม LeetCode ถูกใช้ในการคัดกรองอย่างใดอย่างหนึ่งหรือทั้งสองอย่างในการจ้าง individual contributor ทั่วไป: ขยันไหม คือเป็นคนที่อ่านโจทย์เยอะ ท่องวิธีแก้ และทำซ้ำหรือเปล่า หรือฉลาดไหม คือถึงจะไม่ได้ทำ LeetCode ก็ยังรู้พื้นฐานและสังเคราะห์ความรู้เดิมมาตอบคำถามใหม่ได้หรือเปล่า
ถ้าไม่มีข้อมูลอื่นเลย ก็มองว่าคนที่ผ่านโจทย์ LeetCode ไม่ได้มีโอกาสสูงกว่าที่จะไม่เข้าข่ายทั้งสองแบบ สำหรับตำแหน่งที่ต้องเขียนโค้ด ก็ควรแก้โจทย์ LeetCode ระดับง่ายถึงกลางได้อย่างน้อยสักข้อ แม้จะมีผู้สัมภาษณ์ช่วยชี้ทางเล็กน้อยก็ตาม ในความเป็นจริงบริษัทต่าง ๆ จะให้น้ำหนักกับความสามารถด้าน LeetCode น้อยลงเมื่อเป็นตำแหน่งที่อาวุโสขึ้นหรือเฉพาะทางมากขึ้น ยังมีการแก้บั๊ก, system design, สัมภาษณ์เชิงพฤติกรรม, งานมอบหมาย, คำถามความรู้รอบตัว และคำถามเฉพาะสายงานอีกมากมาย และในการจ้างตั้งแต่ระดับไม่ใช่มือใหม่ขึ้นไป LeetCode ก็ไม่ใช่ทุกอย่าง มันไม่ใช่เครื่องมือวิเศษที่คัดวิศวกรที่ดีที่สุดได้ แต่เป็นเพียงอีกหนึ่งสัญญาณที่คณะกรรมการจ้างงานใช้
มันมองไม่เห็น ความสามารถเชิงวิศวกรรม ในการผลักงานให้เสร็จภายใต้งบประมาณ อย่างดีก็เป็นเรื่องข้างเคียง อย่างแย่ก็คือเป็นตัวชี้วัดแทนอคติเรื่องอายุที่เอื้อคนที่ใกล้ 19 ปีมากกว่า บางทีนี่อาจเป็นเหตุผลว่าทำไมวงการนี้ถึงลำบากนักกับการส่งมอบซอฟต์แวร์คุณภาพดี วิธีที่ดีกว่าคือให้สถานการณ์ล้มเหลว เช่น build ที่พังหรือโค้ดที่รันแล้ว crash แล้วให้แก้ ถ้าสามารถสำรวจระบบ, วินิจฉัยข้อบกพร่อง, หาต้นเหตุ, เสนอแพตช์, และปรับให้เข้ากับสไตล์การเขียนโค้ดและคอมเมนต์ได้ นั่นแหละคือคนที่ต้องการจริง ๆ อาจมีทั้ง branch และ issue tracker, อาจมีการคุยเรื่องบั๊กนั้นอยู่แล้ว, และอาจมีไฟล์แพตช์ในคอมเมนต์ที่ต้องนำไปใช้แบบ manual ก็ได้ แพตช์นั้นอาจมีบั๊กใหม่อยู่ หรือเป็นเหยื่อล่อที่แตะปัญหาคล้ายกันแต่ไม่เกี่ยวกันก็ได้ มันอาจเป็น regression ของบั๊กที่ปิดไปแล้วแต่ไม่มี unit test หรือถึงมี ผู้สมัครก็ต้องหาเอง หรือแม้แต่ตัวทดสอบเองก็อาจเก่าและมีบั๊กเต็มไปหมด นี่แหละคืองานจริง หลังจบงาน การพูดว่า “unit test พังอยู่” กับ “ผมไม่เข้าใจว่าจะรันให้ถูกต้องอย่างไรเลยข้ามไป” สะท้อนทัศนคติที่ต่างกันมาก และ team player คือแบบหลัง
ดังนั้นในทางกลับกัน คุณอาจได้ผู้สมัครที่ไม่ได้สร้างผลงานโดดเด่นในงานปัจจุบัน แต่เอาพลังที่เหลือทั้งหมดไปทุ่มกับ LeetCode
แค่ทำโปรเจกต์ไม่กี่สัปดาห์ คนฉลาดก็จะได้ insight ที่จำเป็นต่อการทำงานจริงแล้ว ปริศนาที่ LeetCode โยนมาแบบไม่มีปี่มีขลุ่ยจึงใกล้กับปริศนาอักษรไขว้ในนิตยสารสมัยก่อนมากกว่า
เหตุผลเดียวที่ทำได้ก็เพราะเคยเรียนมันมาก่อน
ถ้าเป็นปี 2022 ก็คงเห็นด้วยว่า LeetCode ไม่ใช่เครื่องมือคัดวิศวกรที่ดีที่สุด แต่ในปี 2024 ต่อให้ตอบถูกก็ยังถูกคัดออกมากขึ้นถ้าไม่เร็วพอหรือทำไม่ได้โดยไม่มี hint ผมไม่ใช่อัจฉริยะ LeetCode และก็มีอย่างอื่นให้ต้องเรียนอีกมาก แม้สัดส่วน LeetCode ในการสัมภาษณ์จะอยู่ราว 20% แต่ก็ไม่รู้สึกว่ามันแย่ลงจากเมื่อ 2 ปีก่อนมากนัก สิ่งที่พุ่งขึ้นไปบนฟ้าคือความคาดหวังของบริษัท และบรรยากาศแบบอยากซื้อคนประสบการณ์ 15 ปีขึ้นไปด้วยเงินเดือนระดับคนทำงาน 5 ปี
ประเด็นที่น่าสนใจและไม่ค่อยถูกพูดถึงในการสัมภาษณ์แบบ LeetCode คือมันเป็น พิธีรับน้องทางปัญญา อย่างหนึ่ง
มีการพิสูจน์มาหลายครั้งแล้วว่ายิ่งพิธีรับเข้ากลุ่มโหด คนที่ได้เข้าไปในกลุ่มนั้นก็ยิ่งมีความทุ่มเทสูงมาก
เวลาบริษัททุนนิยมจะจ้างโปรแกรมเมอร์ ระหว่าง “คนที่คล้ายกัน ฉลาด และเชื่อว่ามีคำตอบที่ถูกต้อง” กับ “คนมีฝีมือที่คละกันมาแบบสุ่ม” แบบไหนจะดีกว่ากัน ถ้าคุณตอบว่าอย่างหลัง นั่นก็ค่อนข้างอุดมคติ และความเห็นแบบนั้นไม่ได้สำคัญในโลกจริง ธรรมชาติจะเข้ามาแทนที่มันด้วยคนที่ฉลาดกว่าและมองโลกตามความเป็นจริงมากกว่า
ในช่วงไม่กี่ครั้งหลังของการสัมภาษณ์ ฉันให้ผู้สมัครดูโค้ดตัวอย่างแล้วรีวิว โดยในตัวอย่างจะมีบั๊กหรือปัญหาอย่างน้อยหนึ่งอย่างในทุกบรรทัด
หลังจากนั้นเป็นโจทย์การทำโมเดลลิง ปกติทำบนไวท์บอร์ด มีแบบฝึกง่าย ๆ สไตล์ fizzbuzz เพื่อดูว่าจูเนียร์ทำหน้าที่ในระดับจูเนียร์ได้จริงไหม และใช้เป็นจุดเริ่มต้นคุยต่อเรื่องอย่างความซับซ้อนของเวลาการรันหรือการจัดวางหน่วยความจำ กระบวนการจะเป็นแบบโต้ตอบสูงมากตามผลงานของผู้สมัคร โดยมีเป้าหมายเพื่อคัดคนที่ปลอมจนหลุดผ่านรอบสกรีนนิงมาได้ออกไป และพอจะสัมผัสได้ด้วยว่าเข้ากับวัฒนธรรมหรือไม่
ฉันจะทำปัญหายุ่ง ๆ อย่างเขตเวลาหรือการตรวจสอบหมายเลขโทรศัพท์ แล้วใช้หน้า Wikipedia เป็นสเปก พอเสร็จแล้วก็ถามวิธีแก้และทำ code review กัน ซีเนียร์ที่เก่งที่สุดจะใช้ไลบรารีไปเลย ผู้สมัครที่ดีจะทำเองได้แต่ก็อธิบายข้อแลกเปลี่ยนได้ ส่วนจูเนียร์จะหยุดแค่ทำให้เทสต์ผ่าน
https://github.com/emilybache/GildedRose-Refactoring-Kata
ฉันให้ผู้สมัครทำด้วยภาษาที่ตัวเองชอบ และมันเป็นตัวกรองที่มีประสิทธิภาพมาก
ฉันเคยสัมภาษณ์ผู้สมัครนักพัฒนาที่ดูเหมือนรู้ทฤษฎีเยอะมาก แต่พอให้เขียนโค้ดจริงกลับล้มเหลวอย่างน่าอนาถ เขียน fizzbuzz ยังไม่ได้ และ Senior Java นักพัฒนา ก็ import HashMap ไม่ได้ถ้าไม่ได้ค้นหา
มันคล้ายกับคณิตศาสตร์ 562 * 1041 ใช้เครื่องคิดเลขก็ถูกต้อง แต่ถ้าจะหา 3 * 7 แล้วยังต้องหยิบเครื่องคิดเลขออกมา ก็คงเริ่มสงสัยว่าเป็นผู้เชี่ยวชาญจริงไหม หลายบริษัททำการสัมภาษณ์แบบ LeetCode เกินพอดี แต่การสัมภาษณ์แบบ live coding ที่ให้แสดงการจัดการอาร์เรย์ การควบคุมลำดับการทำงาน และการใช้โครงสร้างข้อมูลพื้นฐาน จะบอกได้ว่ามี muscle memory ที่มาจากประสบการณ์จริงหรือไม่ ถ้าต้องไปท่องอัลกอริทึม traversal ของกราฟเพื่อให้ผ่าน ก็น่าจะ LeetCode เกินไปแล้ว
แต่ในโปรแกรมมีองค์ประกอบจุกจิกแบบนั้นหลายอย่าง และในโลกทัศน์นั้นต้องจำทั้งหมดให้ได้ สำหรับ 562 * 1041 คนคาดหวังว่าคุณควรรู้หลักการคำนวณ คือรู้ว่าทำอย่างไร การคำนวณอาจผิดได้ แต่แนวคิดของการคูณแบบยาวจะผิดไม่ได้ ในบริบทนั้น ลืมแม่สูตรคูณข้อหนึ่งอย่าง 3 * 7 ไปก็ยังพอรับได้ โปรแกรมเมอร์คือคนที่จัดระบบการคำนวณ ไม่ใช่คนที่คำนวณเอง และคอมพิวเตอร์ต่างหากที่ทำส่วนนั้น ฉันเห็นด้วยว่าอัลกอริทึม traversal ของกราฟ แค่รู้ว่าจะไปหาคำตอบจากที่ไหนก็พอ ไม่จำเป็นต้องพกทุกคำตอบไว้ในมือ
คนพวกนี้ต้อง import เองในสถานการณ์แบบไหนกัน ไม่มี IDE เหรอ
ไม่แน่ใจว่านี่เป็นการเสียดสีภาพจำตายตัวของผู้สัมภาษณ์หรือเปล่า