โปรดหยุดการทดสอบเขียนโค้ดที่ไร้สาระ

• ปัญหาของการทดสอบเขียนโค้ดที่ไม่สอดคล้องกับความเป็นจริง

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

• เวลาที่สูญเปล่าแบบซ่อนอยู่

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

• มายาคติเรื่องความยืดหยุ่น

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

• เป็นการประเมิน หรือการโชว์มาตรฐานของบริษัท?

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

• ถึงเวลาตรวจสอบความเป็นจริง

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

[GN⁺]

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

• นักพัฒนาคนหนึ่งกล่าวว่าตนมักต้องดีบักและดูแลโค้ดเบส C++ เก่าที่แทบไม่มีเอกสารประกอบ

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

• เห็นด้วยกับความเห็นที่ว่าการทดสอบความสามารถในการแก้ปัญหาในการสัมภาษณ์เป็นสิ่งสำคัญ

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

• แชร์ประสบการณ์ของคู่รักของเพื่อนคนหนึ่งที่ฝึกทำโจทย์ LeetCode เพื่อเตรียมสัมภาษณ์กับบริษัทเทคขนาดใหญ่

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

• แชร์ประสบการณ์การจัดกระบวนการสัมภาษณ์สำหรับตำแหน่งวิศวกรอาวุโสในสตาร์ตอัปขนาดเล็ก

  • อธิบายว่าเปิดให้ผู้สมัครเลือกวิธีสัมภาษณ์ได้หลายแบบ และส่วนใหญ่เลือกแบบ takehome test

• แสดงความคิดเห็นว่าการดีบักโค้ดเบสเก่าที่ไม่มีเอกสารเป็นเรื่องปกติ

  • มองว่าการดีบักแอปพลิเคชัน PHP เป็นวิธีที่ดีในการทดสอบความยืดหยุ่นในการทำงาน

• ยืนยันว่าการสัมภาษณ์แบบเขียนโค้ดเป็นวิธีที่ดีที่สุดในการคัดเลือกผู้สมัครที่เหมาะกับงานพัฒนาซอฟต์แวร์

  • เตือนว่าหากไม่มีทักษะการเขียนโปรแกรมพื้นฐาน บริษัทก็คงมองหาผู้สมัครคนอื่น

• กล่าวว่าตนต้องเจอกับการดีบักโค้ดเบสที่เอกสารไม่เพียงพอทุกวัน

  • อธิบายว่าครึ่งหนึ่งของทีมถูกเลย์ออฟหรือออกจากบริษัทไปแล้ว

• แชร์ประสบการณ์แย่ ๆ จากบริษัทที่ไม่ได้จัดการทดสอบการเขียนโค้ด

  • อธิบายว่าต้องคอยช่วยเพื่อนร่วมงานที่ทำงานพื้นฐานไม่ได้ในทีมที่ต้องรับมือกับเทคสแตกหลากหลาย

• ยืนยันว่าหากเป็นงานที่ต้องใช้เทคโนโลยีเฉพาะ ก็ควรทดสอบเทคโนโลยีนั้นโดยตรง

  • เตือนว่าการวิจารณ์แนวทางการจ้างงานโดยไม่เข้าใจบริบทนั้นไม่ก่อให้เกิดประโยชน์

• อธิบายว่าโจทย์ takehome อาจใช้เวลามากกว่า และอาจก่อให้เกิดความเสี่ยงเชิงจริยธรรม

  • ชี้ว่าการบ้านที่ใช้เวลามากจะเอื้อประโยชน์ต่อคนที่มีเวลาว่างมากกว่า