ในโลกแห่งการแข่งขันของวิศวกรรมซอฟต์แวร์ มีรูปแบบที่น่าประหลาดใจปรากฏขึ้นมา นั่นคือ นักพัฒนาซอฟต์แวร์ที่มีความสามารถสูงบางส่วนแทบจะไม่ถูกตรวจจับได้โดยกระบวนการสรรหาบุคลากรแบบดั้งเดิม ขณะที่บริษัทต่างๆ ต่างพึ่งพาตัวชี้วัด เช่น กิจกรรมบน GitHub โปรไฟล์ LinkedIn และการสัมภาษณ์เชิงเทคนิค มากขึ้นเรื่อยๆ เพื่อหาผู้มีความสามารถ แต่วิศวกรชั้นเยี่ยมจำนวนมากกลับทำงานอย่างเงียบๆ อยู่เบื้องหลัง โดยที่ผลงานของพวกเขาเป็นที่รู้จักเฉพาะในหมู่ผู้ที่ทำงานด้วยโดยตรงเท่านั้น
การอภิปรายในชุมชนเผยให้เห็นถึงความตระหนักที่เพิ่มขึ้นว่าวิธีการประเมินในปัจจุบันของเราอาจกำลังพลาดผู้ที่มีส่วนร่วมอย่างมีคุณค่าที่สุดให้กับทีมซอฟต์แวร์ ตามที่ผู้แสดงความคิดเห็นหนึ่งระบุไว้เกี่ยวกับเพื่อนร่วมงานที่มีความสามารถว่า พวกเขาไม่สามารถถูกจัดอันดับได้ เพราะพวกเขาทำในสิ่งที่ไม่มีใครคิดจะวัด
ผู้มีส่วนร่วมที่ไม่มีใครเห็น
ทั่วทั้งบริษัทเทคโนโลยีทั่วโลก วิศวกรประเภทหนึ่งที่มีลักษณะเฉพาะสามารถส่งมอบงานชั้นเยี่ยมได้อย่างสม่ำเสมอ ในขณะเดียวกันก็ยังคงตรวจจับได้ยากผ่านช่องทางการจ้างงานแบบทั่วไป บุคคลเหล่านี้มักมีตัวตนทางออนไลน์น้อยมาก — มีโปรไฟล์ GitHub ที่ว่างเปล่า, หน้า LinkedIn ที่มีเนื้อหาน้อย และไม่มีร่องรอยบนโซเชียลมีเดีย รูปแบบการทำงานของพวกเขาไม่เข้ากับภาพเหมารวมของนักโปรแกรมมิ่งที่มีความหลงใหล โดยหลายคนรักษาขอบเขตระหว่างงานกับชีวิตส่วนตัวอย่างเคร่งครัด และแทบจะไม่เขียนโค้ดนอกเวลางาน
สิ่งที่ทำให้วิศวกรเหล่านี้มีคุณค่าไม่ใช่การเป็นที่สังเกตเห็น แต่คือผลกระทบจากงานของพวกเขา พวกเขาคือผู้ที่แก้ไขปัญหาที่สำคัญของโครงสร้างพื้นฐานก่อนที่ปัญหานั้นจะลุกลามเป็นวิกฤต เป็นผู้ให้คำปรึกษาและสอนนักพัฒนารุ่นใหม่โดยไม่ได้รับการยอมรับอย่างเป็นทางการ และเป็นสะพานเชื่อมช่องว่างระหว่างทีมที่กระบวนการอย่างเป็นทางการไม่สามารถจัดการได้ ผลงานของพวกเขามักจะเป็นในเชิงป้องกันมากกว่าเชิงรับ ทำให้คุณค่าของพวกเขาวัดได้ยากผ่านตัวชี้วัดประสิทธิภาพมาตรฐาน
ลักษณะทั่วไปของวิศวกร "ล่องหน":
- มีตัวตนบนโซเชียลมีเดียน้อยมาก
- โปรไฟล์ GitHub ที่มีข้อมูลน้อยหรือว่างเปล่า
- มุ่งเน้นงานเชิงป้องกันมากกว่าฟีเจอร์ที่มองเห็นได้
- มีทักษะการทำงานร่วมกันที่แข็งแกร่ง
- แนวทางการแก้ปัญหาเชิงปฏิบัติ
- มักจะรักษาสมดุลระหว่างชีวิตและการทำงาน
ปัญหาความขัดแย้งในการสรรหาบุคลากร
ความท้าทายพื้นฐานอยู่ในสิ่งที่นักวิทยาศาสตร์สังคมเรียกว่า ปัญหาความสามารถในการอ่านได้ (legibility problem) องค์กรขนาดใหญ่ต้องการวิธีการที่ได้มาตรฐานและขยายขนาดได้เพื่อประเมินผู้สมัคร ส่งผลให้พวกเขามุ่งความสนใจไปที่ตัวชี้วัดที่สังเกตเห็นได้ง่าย แทนที่จะเป็นคุณสมบัติที่วัดได้ยากกว่า เช่น การแก้ปัญหาเชิงปฏิบัติ การทำงานร่วมกันเป็นทีม และการคิดในระดับระบบ
การสัมภาษณ์เขียนโค้ดให้ความรู้สึกแบบนั้นกับผม เราไม่สามารถวัดสิ่งที่สำคัญได้ ดังนั้นเราจึงควรวัดสิ่งที่เราสามารถวัดได้อย่างเข้มงวดสุดๆ มากกว่า
สิ่งนี้สร้างสถานการณ์ที่กระบวนการสัมภาษณ์ favore ผู้สมัครที่เก่งในการแสดงออกในสถานการณ์เทคนิคที่ถูกสร้างขึ้น แทนที่ผู้ที่แสดงให้เห็นถึงประสิทธิภาพทางวิศวกรรมในโลกแห่งความเป็นจริง ผลลัพธ์ที่ได้คือระบบที่สามารถมองข้ามวิศวกรซึ่งจุดแข็งอยู่ที่การประยุกต์ใช้เชิงปฏิบัติ แทนที่จะเป็นการแสดงออกทางทฤษฎี อย่างเป็นระบบ
ตัวชี้วัดการจ้างงานแบบดั้งเดิม เทียบกับ ผลกระทบที่เกิดขึ้นจริง:
| ตัวชี้วัดแบบดั้งเดิม | ตัวชี้วัดผลกระทบที่เกิดขึ้นจริง |
|---|---|
| จำนวน commit บน GitHub | การปรับปรุงความเสถียรของระบบ |
| ผลการทำข้อสอบ Leetcode | การเพิ่มขึ้นของประสิทธิภาพทีม |
| กิจกรรมบน LinkedIn | การทำงานร่วมกันระหว่างทีม |
| โปรเจกต์ส่วนตัว | ประสิทธิผลในการให้คำปรึกษา |
| การสัมภาษณ์ด้านเทคนิค | การแก้ปัญหาในโลกแห่งความเป็นจริง |
ก้าวข้ามภาพเหมารวม
การอภิปรายในชุมชนชี้ให้เห็นว่าวิศวกรที่ยอดเยี่ยมมีอยู่ในรูปแบบที่หลากหลาย บางคนเข้ากับรูปแบบดั้งเดิมของผู้ที่หลงใหลในการเขียนโค้ดมาตลอดชีวิต ซึ่งเริ่มเขียนโปรแกรมตั้งแต่เด็กและมีโปรเจกต์ส่วนตัวที่ยังทำอย่างต่อเนื่อง บางคนค้นพบการเขียนโปรแกรมในวัยผู้ใหญ่และมองว่ามันเป็นงานฝีมือเชิงวิชาชีพมากกว่าความหลงใหลที่ต้องทุ่มเททุกอย่าง
เส้นทางร่วมกันของวิศวกรที่มีประสิทธิภาพสูงเหล่านี้ไม่ใช่ภูมิหลังหรือนิสัยการเขียนโค้ดนอกเวลางานของพวกเขา แต่คือความสามารถในการส่งมอบผลลัพธ์ที่มีคุณภาพสูงอย่างสม่ำเสมอในสภาพแวดล้อมการทำงานเป็นทีม พวกเขามีทั้งความสามารถทางเทคนิค ปัญญาเชิงปฏิบัติ และจิตวิญญาณแห่งการทำงานร่วมกัน ซึ่งอยู่เหนือประเภทบุคลิกภาพหรือเส้นทางอาชีพใดๆ โดยเฉพาะ
วิศวกรที่มีประสบการณ์หลายคนรายงานว่าการเขียนโค้ดนอกเวลางานของพวกเขาลดลงตามธรรมชาติเมื่อเวลาผ่านไป เนื่องจากความรับผิดชอบในครอบครัวเพิ่มขึ้นและความสนใจส่วนตัวมีความหลากหลายมากขึ้น ความก้าวหน้าของชีวิตตามปกตินี้ไม่ควรทำให้พวกเขาถูกตัดสิทธิ์จากการถูกมองว่าเป็นผู้มีความหลงใหลหรือเป็นมืออาชีพที่มีความสามารถ
ระดับอาชีพการงานและนิสัยการเขียนโค้ด:
- ช่วงต้นอาชีพการงาน: มีแนวโน้มที่จะเขียนโค้ดนอกเวลาทำงานมากกว่า
- ช่วงกลางอาชีพการงาน: สมดุลระหว่างความรับผิดชอบในงานและชีวิตส่วนตัว
- ระดับอาวุโส: มักจะมุ่งเน้นไปที่งานที่สร้างผลกระทบสูงในช่วงเวลาทำงาน
- ทุกระดับ: สามารถเป็นวิศวกรที่ยอดเยี่ยมได้โดยไม่คำนึงถึงการเขียนโค้ดนอกเวลางาน
อนาคตของการระบุผู้มีความสามารถ
ในขณะที่อุตสาหกรรมกำลังต่อสู้กับความท้าทายนี้ บริษัทบางแห่งกำลังสำรวจแนวทางอื่นๆ การทดลองงาน (Work trials) ซึ่งผู้สมัครใช้เวลาทำงานจริงกับทีม เป็นหนึ่งในแนวทางแก้ปัญหาที่เป็นไปได้ แม้ว่าจะไม่สะดวกในทางปฏิบัติสำหรับสถานการณ์ส่วนใหญ่ก็ตาม การปรับปรุงที่สมจริงกว่าอาจรวมถึงการให้ความสำคัญกับใบรับรองจากเพื่อนร่วมงานเดิมมากขึ้น การออกแบบการสัมภาษณ์ที่จำลองสถานการณ์การทำงานจริง และการฝึกอบรมผู้จัดการฝ่ายสรรหาบุคลากรให้รู้จักสัญญาณอันละเอียดอ่อนของความสามารถเชิงปฏิบัติ
ความก้าวหน้าที่น่าพอใจที่สุดมาจากองค์กรที่ให้อำนาจทีมวิศวกรรมของพวกเขาในการระบุและสรรหาผู้มีความสามารถโดยอิงจากประสบการณ์การทำงานโดยตรง แทนที่จะพึ่งพากระบวนการที่เป็นทางการเพียงอย่างเดียว แนวทางเชิงอินทรีย์นี้ แม้จะไม่สามารถขยายขนาดได้อย่างสมบูรณ์แบบ แต่มักจะทำให้ผู้สมัครที่ในสถานการณ์ปกติจะยังคงไม่เป็นที่สังเกตได้ปรากฏตัวขึ้น
การอภิปรายที่กำลังดำเนินอยู่ชี้ให้เห็นว่าการปรับปรุงวิธีการระบุความสามารถด้านซอฟต์แวร์ของเรานั้น จำเป็นต้องยอมรับถึงข้อจำกัดของวิธีการในปัจจุบันของเรา ด้วยการยอมรับว่าวิศวกรที่ยอดเยี่ยมไม่ได้มีรูปแบบเดียวกันทั้งหมด บริษัทต่างๆ จึงสามารถพัฒนาวิธีการที่ละเอียดอ่อนมากขึ้น ซึ่งสามารถดึงดูดผู้มีส่วนร่วมที่มีคุณค่าทุกประเภทได้อย่างครบถ้วน
ความท้าทายของอุตสาหกรรมไม่ใช่การหาวิศวกรที่มีความสามารถ — แต่เป็นการเรียนรู้ที่จะมองเห็นพวกเขาในสถานที่ที่พวกเขาอยู่จริง แทนที่จะมองหาเฉพาะในที่ที่แสงสว่างส่องไปถึงที่สุดเท่านั้น
อ้างอิง: The illegible nature of software development talent