ผมมีงานอันน่าท้าทายมาให้ทุกคนลองทำครับ

ผมจะให้คุณคุยกับคนแปลกหน้าเป็นเวลา 1 ชั่วโมง

หลังจากนั้นคุณจะต้องตัดสินใจว่า คุณอยากจะใช้เวลาร่วมกับคนคนนี้ 8 ชั่วโมงต่อวัน เป็นระยะเวลาอย่างต่ำ 1 ปี หรือไม่

ฟังดูยากไหมครับ?

งานนี้เรียกว่า “การสัมภาษณ์งาน”

ทำไมถึงเขียนเรื่องนี้

ช่วงสามปีที่ผ่านมา ผมทำหน้าที่เป็นคนสัมภาษณ์งาน นับรวมๆกันน่าจะเกือบร้อยครั้งแล้ว

เป็นอะไรที่ค่อนข้างแปลกใหม่ที่ต้องมาอยู่อีกฟากของโต้ะสัมภาษณ์ แต่ก็ทำให้เรียนรู้อะไรหลายๆอย่าง อย่างแรกก็คือ…

การสัมภาษณ์งานให้มีประสิทธิภาพนี่มันยากเหี้ยๆเลยครับ

คุณมีเวลาไม่ถึง 1 ชั่วโมง คุยกับคนแปลกหน้าที่ไม่เคยรู้จักมาก่อน แล้วต้องตัดสินว่าเค้าทำงานได้ดีขนาดไหน และต้องฟันธงด้วยว่าจะจ้างหรือปฏิเสธ ไม่มีกลางๆว่าจ้างแค่ครึ่งคน

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

ในบทความนี้ ผมจะยกตัวอย่างปัญหาที่พบเห็นได้บ่อยในกระบวนการสัมภาษณ์งาน พร้อมวิธีแก้ไข

จุดประสงค์ของบทความนี้ คือให้คุณได้มองย้อนไปในการสัมภาษณ์งานของทีม ว่ายังมีจุดที่พัฒนาได้อีกหรือเปล่า

เริ่มกันเลยครับ

ทีมไม่เห็นความสำคัญของการสัมภาษณ์งาน

เรื่องแรก ผมอยากจะเน้นย้ำถึงความสำคัญของการสัมภาษณ์งานก่อน

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

ดังนั้น ถ้าผมจะบอกว่า หนึ่งในกระบวนการที่สำคัญที่สุดในการพัฒนาซอฟท์แวร์ คือการคัดเลือกคนเข้ามาร่วมทีม คงเห็นด้วยกับผมนะครับ?

ถ้าเราเริ่มต้นที่การคัดคนผิด จ้างคนที่ไม่เหมาะสมกับงานหรือกับทีมมา เราจะคาดหวังอะไรกับสิ่งที่ตามมาได้?

ในฐานะผู้ร่วมทีม เราควรจะทำทุกอย่างให้กระบวนการนี้ออกมาดีที่สุด โดยไม่โบ้ยว่าเป็นหน้าที่ของ HR หรือผู้จัดการ เพราะเรานั่นแหละ ที่จะได้รับผลกระทบจากการสัมภาษณืงานมากที่สุด

ไม่กำหนดเกณฑ์การวัดผลให้ชัดเจน

การสัมภาษณ์งานที่ล้มเหลว คือเมื่อสัมภาษณ์จบแล้ว ผู้สัมภาษณ์ตอบไม่ได้ ว่าจะจ้างหรือปฏิเสธ

เหมือนเป็นเรื่องง่ายนะครับ แต่ถ้าใครเคยสัมภาษณ์งาน จะเจอกรณีนี้บ่อยมาก สาเหตุหนึ่งคือทีม (หรือบริษัท) ไม่มีเกณฑ์ในการวัดให้ชัดเจน ว่าต้องการวัดอะไรจากผู้สมัคร

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

การใช้ความรู้สึกตัดสินเป็นอะไรที่อันตรายมาก เพราะเราอาจได้คนนิสัยดีน่าคบหา แต่เขียนโค้ดไม่เป็น มานั่งอยู่ข้างๆและใส่บั๊กเข้าระบบรัวๆ

การกำหนดเกณฑ์ควรจะละเอียดและชัดเจน ไม่ใช่ก็อบแปะมาจาก Job Description เช่น

• เขียนโปรแกรมได้ดี (อะไรคือดี ต้องดีแค่ไหน)
• เขียนโปรแกรมที่ดูแลได้ง่าย (อะไรคือง่าย)
• มีพื้นฐานด้าน Computer Science (เรื่องไหนบ้าง เอาครบสี่ปีเลยไหม?)
• รักการเรียนรู้ (คือต้องมีงานอดิเรกเป็นการเขียนโปรแกรมในช่วงวันหยุดหรืออย่างไร?)
• สามารถทำงานร่วมกับผู้อื่นได้ (คือไม่เถียง ไม่ทะเลาะกับเพื่อร่วมทีมเหรอ?)
• …

เกณฑ์ประเภทนี้ จะทำให้ผู้สมัครต้องนั่งเทียนเอง ทำให้เกณฑ์ของแต่ละคนไม่ตรงกัน

นำมาเขียนใหม่ให้ละเอียด

• ด้าน Technical
  • สามารถแก้ปัญหาที่ใช้ if/else กับ for/while loop หลายชั้นได้
  • รู้จักแยกโค้ดเป็น Function เพื่อให้อ่านง่าย
  • สามารถอธิบายได้ว่า Big O notation ของโปรแกรมคืออะไร ถ้าไม่ได้จบด้าน Computer Science มา ก็ต้องอธิบายได้ว่าโค้ดบรรทัดไหนถูกเรียกใช้มากที่สุด และถูกเรียกใช้กี่ครั้ง
  • อธิบาย HashTable, LinkedList, Array, Tree ได้ ว่าต่างกันยังไง เมื่อไรควรใช้อันไหน
  • เขียน Recursive ง่ายๆ (เช่น Factorial) ได้ แปลงเป็น Iterative ได้
  • …
• ด้าน Soft skill
  • มีตัวอย่างงานเขียนโปรแกรม นอกเหนือจาก Assignment ในวิชาเรียน
  • สามารถยอมรับความผิดพลาดของตัวเองได้ และนำไปปรับปรุงแก้ไข
  • กล้าที่จะเถียงถ้าตัวเองไม่ผิด
  • …

ซึ่งถ้าทีมมีเกณฑ์ตรงนี้ชัดเจน ผู้สัมภาษณ์จะสามารถออกแบบคำถามได้ง่าย

และไม่ว่าใครจะสัมภาษณ์ เราก็มั่นใจได้ว่าคนที่รับเข้ามา จะมีมาตรฐานตรงตามที่เรากำหนดไว้

ผู้สัมภาษณ์แต่ละคนมีมาตรวัดของเกณฑ์ไม่ตรงกัน

“เห้ย โหดไปรึเปล่า น้องเค้าก็เขียนโปรแกรมได้ ผิดนิดผิดหน่อยไม่เห็นต้องให้ตกเลย”

หลังจากเรามีเกณฑ์ที่ชัดเจนแล้ว ผู้สัมภาษณ์แต่ละคนก็จะสามารถออกแบบคำถามได้ชัดเจนขึ้น เช่น

ในตัวอย่างข้อแรก ถ้าผู้สมัคร:

1. เขียนโปรแกรมได้ครบหมดโดยไม่มีบั้กเลย
2. เขียนโปรแกรมได้ครบ แต่จำรายละเอียดของ Library ในการอ่านไฟล์ไม่ได้ ต้องให้ผู้สัมภาษณ์ช่วย
3. เขียนโปรแกรมได้ครบ แต่ไม่สามารถเขียนการอ่านไฟล์ได้ แม้ผู้สัมภาษณ์ช่วยแล้วก็ตาม
4. เขียนโปรแกรมได้ครบ แต่มีบั้ก 2-3 ตัว
5. เขียนโปรแกรมได้ไม่ทัน ได้แค่ส่วนของการอ่านไฟล์และโฟลเดอร์ แต่ไม่มีบั้กเลยเพราะเขียน Test case ตั้งแต่ก่อนเขียนโค้ดครบถ้วน
6. ตอบเป็น CLI ได้ แต่เขียนเป็นโค้ดในภาษาอื่นๆไม่ได้ เช่น

1

for file in `find . -type f`; do cat $file; done | sed '/^\s*$/d' | wc -l

อย่างนี้ผู้สัมภาษณ์คนไหนผ่านบ้างครับ?

หรือ ถ้าผู้สัมภาษณ์ตอบคำถามด้าน Technical ได้ดีหมด แต่พอเจอคำถามว่าจะทำอย่างไรในกรณีที่บั้กหลุดไปถึงผู้ใช้ กลับตอบมาว่า “เดินไปหา QA บอกว่าคราวหน้าเทสต์ให้ดีขึ้นกว่านี้หน่อย” อย่างนี้จะผ่านไหมครับ?

พอจะเห็นปัญหาไหมครับ?

สิ่งที่ตามมาคือ ถ้าให้คนสัมภาษณ์สองคน ผลลัพธ์ที่ได้จากการสัมภาษณ์อาจไม่เหมือนกัน แม้ถามคำถามเดียวกันหมด เพราะสัก 20% ผู้สมัครจะคาบเส้นแบบนี้

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

ถึงจะให้ผู้สัมภาษณ์ให้คะแนน เช่น 8/10 ปัญหาที่ตามมาคือ 8 ของแต่ละคนก็ไม่เท่ากันอยู่ดี

ปัญหานี้สามารถลดได้ด้วยสองวิธีนี้ครับ

1. ให้ผู้สัมภาษณ์คนใหม่ๆมานั่งคู่กับคนที่สัมภาษณ์มานานแล้ว อย่างน้อยสัก 2-3 ครั้ง ก่อนสัมภาษณ์เอง เพื่อจะได้ปรับเกณฑ์ให้ตรงกันทั้งทีม (เหมือน Pair Programming)
2. ให้มีผู้สัมภาษณ์มากกว่าหนึ่งคน และส่งผลการสัมภาษณ์พร้อมเหตุผลแยกกัน แล้วค่อยมานั่งดูด้วยกันทีหลังว่าขัดแย้งกันหรือเปล่า

ผู้สัมภาษณ์ไม่มีทักษะในการสัมภาษณ์

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

เคยเจอประสบการณ์สัมภาษณ์งานแย่ๆไหมครับ?

ตัวอย่างเช่น

1. ไม่เตรียมคำถาม, ไม่อ่าน Resume มาก่อน, มาสดเอาตอนสัมภาษณ์
2. คุยไปสิบนาที แล้วค้นพบว่าตำแหน่งต้องการคนเขียน Ruby เป็น แต่ใน Resume คนสมัครก็เขียนชัดแล้วว่าไม่เคยเขียน Ruby มาก่อน
3. ผู้สัมภาษณ์ทำกิริยาไม่เหมาะสม อวดเก่ง ดูถูกผู้สมัคร
4. มัวแต่คุยเรื่อง Resume ให้ผู้สัมภาษณ์พูดอย่างเดียว ไม่ได้ถามอะไรเพิ่ม ทำให้ไม่มีข้อมูลในการตัดสินใจ

อย่างที่ผมบอกข้างต้นครับ งานสัมภาษณ์เป็นงานที่สำคัญ คนที่มาสัมภาษณ์ต้องเตรียมตัว ทำการบ้าน และฝึกฝนตัวเองมาให้ดี

กรณีแย่ที่สุดคือสัมภาษณ์เสร็จปุ๊บ อยากรับคนนี้เข้าทำงาน แต่ผู้สมัครไม่อยากทำงานด้วยแล้ว เพราะคนสัมภาษณ์ทำตัวห่วยมาก

ไม่จบแค่นั้น ผู้สมัครมีเพื่อน มีเฟสบุ้ค เวลาคนบ่น เค้าบ่นเหมาะรวมทั้งบริษัทนะครับ ฉาวโฉ่กันเลยทีเดียว หาคนยากกว่าเดิมอีก

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

ไม่จดบันทึก

ถ้ามีผู้สัมภาษณ์มากกว่าหนึ่งคน แล้วมีความเห็นไม่ตรงกัน สุดท้ายจะต้องมานั่งคุยกันเพื่อหาข้อตกลง

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

อย่างน้อย ที่ต้องจดไว้ก็คือโค้ดที่เขียนและคำตอบครับ

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

หรือถ้าผู้สมัครไม่เห็นด้วยกับผลการตัดสินและร้องเรียนมา เราก็จะมีข้อมูลชี้แจงด้วย

ให้อำนาจผู้จัดการในการตัดสินใจ

ถึงแม้จะมีเกณฑ์ชัดเจน แต่หากผู้มีอำนาจสามารถล็อบบี้ให้จ้างเลย แม้ไม่ผ่านเกณฑ์ ไอ้ที่ทำไปทั้งหมดข้างต้นทั้งหมดจะสูญเปล่าครับ

ฟังดูเหมือนตลกร้าย แต่ผู้จัดการหรือหัวหน้าทีมหลายคนทำแบบนั้นจริงๆครับ

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

ตัวอย่างพอเป็นน้ำจิ้มครับ

“ผมว่าคนนี้โอเคแล้วนะ ก็พอเขียนโปรแกรมได้นิ แหม จะให้เขียนได้ถูกหมดนี่เป็นไปไม่ได้หรอก”

“เฮ้ย คุณคาดหวังมากไปเปล่า เด็กจบใหม่เองนะ หยวนๆหน่อยเถอะ”

“ถึงเค้าจะเขียนโปรแกรมไม่ได้เลย แต่เค้าตอบคำถามอื่นๆดีมากเลยนะ พูดจาฉะฉาน เอาเข้ามาแล้วให้เวลาเค้าเรียนรู้หน่อยเถอะ”

“คุณปฏิเสธอไปกี่คนแล้ว? ถ้าไม่รับคนนี้ เราก็มีคนไม่พอปิดโปรเจ็คนะ คุณรับผิดชอบไหวเหรอ”

พอเอาคนที่ทำงานไม่ได้มา ต้องเสียเวลาเทรนใหม่ ใส่บั้กเข้าระบบ เขียนโค้ดแล้วอ่านไม่รู้เรื่อง

สุดท้าย งานก็เสร็จช้าอยู่ดี

แล้วไอ้โปรเจ็คถัดๆไปก็จะเสร็จไม่ทันด้วย เพราะจ้างแล้วอยู่กันนาน หลายโปรเจ็ค

เวลาเจอคำถามแบบนี้ ให้ตอบกลับไปว่า

ถ้าคุณจะตัดสินใจเอง จะให้ผมไปสัมภาษณ์ทำซากอะไรครับ?

อุ้ย มือลั่น ตอบแบบนี้ครับ

นี่เป็นเกณฑ์ที่ทุกคนในทีมตกลงกันครับ เราเช็คกันแล้วว่าไม่ได้สูงไป ถ้าหัวหน้าคิดว่าเกณฑ์สูงไป อยากให้หัวหน้าฟังความเห็นคนในทีมให้ครบก่อนนะครับ

ส่วนเรื่องโปรเจ็คเลท ถ้าเราเอาคนที่ไม่เหมาะกับงานเข้ามา ยังไงก็เลทอยู่ดี พอไปถึงจุดนั้น เราจะเปลี่ยนคนก็ไม่ได้แล้ว จะยิ่งมีปัญหาหนักกว่าเดิมนะครับ

อันนี้ผมเข้าใจนะว่าที่ไทยอาจจะยากหน่อย เพราะบางบริษัทหัวหน้ายิ่งใหญ่เหลือเกิน เถียงไม่ได้ แต่เรื่องบางเรื่องที่มีผลกระทบหนักๆ เราไม่ควรจะนิ่งเฉยไม่ดูดำดูดี

สำหรับคนที่อึดอัด ถ้าคุณขึ้นถึงระดับผู้ที่มีอำนาจแล้ว อย่าทำแบบนี้เลยครับ ไม่งาม คนไม่ด่าต่อหน้าก็ด่าลับหลัง

สรุป

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

ผมเข้าใจว่าตอนนี้หาโปรแกรมเมอร์ดีๆยาก แต่เราต้องมองถึงผลกระทบในระยะยาว เพราะการได้คนที่ไม่เหมาะสมเข้าทีม จะส่งผลกระทบต่อเนื่องไปเป็นปี การอดทนรอไปอีกเดือนสองเดือนจะมีผลดีในระยะยาวมากกว่า

ดังนั้น เป็นหน้าที่ของทุกคนในทีมที่ต้องช่วยกันให้กระบวนการสัมภาษณ์ดีที่สุด

เรื่องแรกที่ทีมสัมภาษณ์ควรตกลงร่วมกัน คือกเกณฑ์การวัดผล และมาตรวัดของแต่ละคน ทุกคนควรมีสองอย่างนี้ตรงกัน

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

และท้ายที่สุด อย่ายอมให้หัวหน้ามาบีบให้เปลี่ยนเกณฑ์ เพราะเราคือคนที่ได้รับผลกระทบจากการจ้างงานที่ผิดพลาดมากที่สุด