การรับสมัครนักพัฒนาซอฟต์แวร์ที่ดีเป็นเรื่องยาก เรซูเม่อาจดูน่าประทับใจ การทดสอบทางเทคนิคอาจดูเรียบร้อย แต่การสัมภาษณ์อาจไม่ได้แสดงให้เห็นว่าบุคคลนั้นสามารถทำงานร่วมกับทีมของคุณได้ดีหรือไม่
ที่ HDWEBSOFT เราถือว่าการสัมภาษณ์นักพัฒนาเป็นการสนทนา ไม่ใช่การสอบ เรายังคงตรวจสอบทักษะทางเทคนิคอย่างละเอียด แต่เรายังให้ความสนใจอย่างใกล้ชิดกับวิธีที่ผู้สมัครอธิบาย ถามคำถาม รับคำแนะนำ และเปลี่ยนปัญหาที่คลุมเครือให้เป็นโซลูชันที่ใช้งานได้จริง สิ่งนี้มีความสำคัญไม่ว่าเราจะกำลังสร้างทีม การพัฒนาซอฟต์แวร์เฉพาะ หรือสนับสนุนลูกค้าผ่านโมเดลวิศวกรรมแบบขยาย
ในบล็อกนี้ ผมจะแบ่งปันแนวทางการสัมภาษณ์ที่เราใช้เมื่อจ้างวิศวกรซอฟต์แวร์ บทความนี้เขียนขึ้นสำหรับผู้สัมภาษณ์ทางเทคนิคเป็นหลัก แต่ผู้เชี่ยวชาญด้าน HR หัวหน้าทีม และผู้ก่อตั้งก็สามารถใช้ได้เช่นกันเพื่อทำความเข้าใจว่าการสัมภาษณ์นักพัฒนาซอฟต์แวร์ที่ดีควรเปิดเผยอะไรบ้าง
ผมยังแนะนำให้อ่าน Software Engineer’s Guide to Interviewing Software Engineers ของ Chuck Groom และ Developer Job Interview Questions ทั้งสองแหล่งแบ่งปันมุมมองที่เป็นประโยชน์เกี่ยวกับการทำให้การสัมภาษณ์มีประสิทธิภาพและเคารพผู้สมัครมากขึ้น
กลุ่มผู้อ่าน
บทความนี้มีประโยชน์มากที่สุดสำหรับผู้สัมภาษณ์ทางเทคนิคที่สามารถดำเนินการสนทนาเชิงปฏิบัติกับผู้สมัคร ตัวอย่างบางส่วนอาจยากสำหรับผู้อ่านที่ไม่ใช่ด้านเทคนิค แต่แนวคิดหลักนั้นง่าย: การสัมภาษณ์ที่ดีควรเปิดเผยว่านักพัฒนาคิด สื่อสาร และเติบโตอย่างไร
กำหนดเกณฑ์ของคุณก่อน
ก่อนที่จะถามคำถาม ให้กำหนดสิ่งที่คุณต้องการประเมิน แต่ละบริษัทมีเกณฑ์การรับสมัครของตนเอง แต่จากประสบการณ์ของเรา สิ่งที่สำคัญที่สุดคือ:
- การสื่อสาร: ผู้สมัครสามารถอธิบายได้อย่างชัดเจน ถามคำถามที่เป็นประโยชน์ และทำงานร่วมกับผู้อื่นได้หรือไม่?
- ระดับที่แท้จริง: ผู้สมัครทำอะไรได้ในตอนนี้?
- ศักยภาพ: ผู้สมัครจะกลายเป็นอะไรในเดือนหน้า ปีหน้า และในอีกห้าหรือสิบปีข้างหน้า?
สำหรับ HDWEBSOFT การสื่อสารเป็นเกณฑ์แรก เราทำงานเป็น บริษัทพัฒนาซอฟต์แวร์นอกสถานที่ กับลูกค้าในประเทศต่างๆ ดังนั้นแม้แต่นักพัฒนาที่เก่งก็จะประสบปัญหาหากไม่สามารถสื่อสารได้อย่างชัดเจน
เริ่มต้นด้วยแนวทางที่เปิดกว้างและสงบ
ก่อนเริ่มส่วนทางเทคนิค เราทำให้บรรยากาศการสัมภาษณ์ชัดเจน เราบอกผู้สมัครประมาณนี้:
อย่าตื่นตระหนก ไม่มีใครรู้ทุกอย่าง วัตถุประสงค์ของการสัมภาษณ์นี้ไม่ใช่เพื่อพิสูจน์ว่าคุณรู้คำตอบทุกข้อ เราต้องการดูว่าเราสามารถทำงานร่วมกัน คิดวิเคราะห์ปัญหา และหาโซลูชันที่ดีได้หรือไม่
ข้อความง่ายๆ นี้ช่วยให้ผู้สมัครผ่อนคลาย ยังตั้งความคาดหวังที่ถูกต้อง: เราไม่ได้ทดสอบความจำเพียงอย่างเดียว เราสังเกตวิธีการทำงานของพวกเขา
ตรวจสอบการสื่อสารตลอดการสัมภาษณ์
วิธีที่ดีที่สุดในการสัมภาษณ์นักพัฒนาซอฟต์แวร์คือการประเมินการสื่อสารตลอดทั้งการสัมภาษณ์ ไม่ใช่เป็นส่วนแยกต่างหาก
การสื่อสารปรากฏเมื่อผู้สมัครอธิบายโครงการที่ผ่านมา ชี้แจงความต้องการ อธิบายการตัดสินใจทางเทคนิค หรือยอมรับสิ่งที่ตนไม่รู้ ช่วงเวลาเหล่านี้มักมีค่ามากกว่าคำตอบที่สมบูรณ์แบบตามตำรา
พวกเขาสามารถอธิบายสิ่งที่ทำมาก่อนได้หรือไม่?
คำถามที่เป็นประโยชน์คือการขอให้ผู้สมัครอธิบายโครงการที่พวกเขาเคยทำ ตัวอย่างเช่น:
- โครงการที่คุณชอบที่สุดคืออะไร?
- ใครใช้ผลิตภัณฑ์ และมันมีคุณค่าอะไรให้พวกเขา?
- ประเด็นทางเทคนิคที่สำคัญที่สุดในโครงการนั้นคืออะไร?
- การมีส่วนร่วมที่แท้จริงของคุณคืออะไร?
คำตอบที่คาดหวังไม่ใช่สุนทรพจน์ยาวๆ ที่เต็มไปด้วยรายละเอียดทางเทคนิค คำตอบที่ดีคือสั้น ชัดเจน และเน้นประเด็นสำคัญ
สิ่งนี้ช่วยให้เราประเมินสองสิ่ง:
- ผู้สมัครเข้าใจโครงการโดยรวมได้หรือไม่?
- ผู้สมัครสามารถเลือกประเด็นสำคัญได้โดยไม่หลงประเด็นรายละเอียดหรือไม่?
หากนักพัฒนาไม่มีความรู้สึกชัดเจนเกี่ยวกับสิ่งที่พวกเขาสร้าง ยากที่จะเชื่อว่าพวกเขาเข้าใจงานอย่างแท้จริง นักพัฒนาที่สามารถสรุปโครงการที่ผ่านมาได้ดีมักมีศักยภาพที่ดีกว่าในการเข้าใจโครงการในอนาคตด้วย
พวกเขาสามารถเปลี่ยนคำอธิบายเป็นข้อกำหนดทางเทคนิคได้หรือไม่?
อีกวิธีสัมภาษณ์ที่เป็นประโยชน์คือการให้ผู้สมัครได้รับความต้องการเล็กๆ และทำงานร่วมกันไปสู่โซลูชัน ความยากควรเหมาะกับระดับและประสบการณ์ของผู้สมัคร
เป้าหมายไม่ใช่เพื่อดูว่าพวกเขารู้คำตอบทันทีเสมอไป บางครั้งสัญญาณที่ดีกว่าคือพวกเขาสามารถถามคำถามที่ดี เข้าใจคำใบ้ และปรับความคิดได้
ด้านล่างนี้คือตัวอย่างบางส่วน
ตัวอย่างที่ 1: คำถามง่ายๆ สำหรับมือใหม่
คำถาม: ตอนนี้เวลา 1 นาฬิกาตามเวลานิวยอร์ก เวลาในเวียดนามคือกี่โมง?
หากผู้สมัครไม่สามารถตอบได้ทันที ผมอนุญาตให้พวกเขาถามคำถาม คำถามที่ดีอาจเป็น: “เขตเวลาของนิวยอร์กคืออะไร?”
หากพวกเขาไม่ทราบสูตร ผมสามารถอธิบายว่าเวียดนามคือ UTC+7 และนิวยอร์กมีเขตเวลาของตนเองขึ้นอยู่กับวันที่ จากนั้นผมสังเกตว่าพวกเขาสามารถใช้คำอธิบายนั้นเพื่อคำนวณคำตอบได้หรือไม่
ประเด็นไม่ใช่ภูมิศาสตร์ ประเด็นคือพวกเขาสามารถถามคำถามที่มีความหมายและใช้ข้อมูลใหม่ได้หรือไม่
ตัวอย่างที่ 2: การรวมคำถามกับอัลกอริทึมทั่วไป
คำถาม: ผมมีอาร์เรย์ที่เรียงลำดับแล้ว 1,000 รายการ ผมต้องการตรวจสอบว่ามีค่าหนึ่งอยู่ในอาร์เรย์นั้นหรือไม่ ในกรณีที่แย่ที่สุดของ binary search ต้องตรวจสอบกี่ครั้ง?
หากผู้สมัครลืม binary search ผมอธิบายวิธีการทำงาน หากพวกเขาสามารถตามคำอธิบายและคำนวณคำตอบได้ นั่นก็เป็นสัญญาณที่ดี
คำถามนี้ทดสอบมากกว่าความจำ ทดสอบว่าพวกเขาสามารถเข้าใจแนวคิดได้อย่างรวดเร็วและนำไปใช้ได้หรือไม่
ตัวอย่างที่ 3: สำหรับนักพัฒนา PHP, นักพัฒนา backend, หรือนักพัฒนา full-stack
คำถาม: ลืม PHP Session ไปก่อน หากคุณต้องเขียนไลบรารีของตัวเองเพื่อทำงานเดียวกัน คุณจะสร้างอะไร?
คำถามนี้อาจยากแม้สำหรับนักพัฒนา PHP ที่มีประสบการณ์ไม่กี่ปี หากพวกเขาไม่แน่ใจ ผมอธิบายว่า PHP Session ทำงานอย่างไรและดูว่าพวกเขาสามารถใช้เหตุผลต่อได้หรือไม่
นักพัฒนาหลายคนทำงานส่วนใหญ่กับเฟรมเวิร์กระดับสูงเช่น CakePHP, Laravel, Symfony หรือเครื่องมือที่คล้ายคลึง นั่นก็ใช้ได้ แต่บางครั้งทำให้พวกเขาประเมินพื้นฐานที่สำคัญต่ำไป คำถามนี้ช่วยเปิดเผยว่าพวกเขาเข้าใจสิ่งที่เกิดขึ้นใต้เฟรมเวิร์กหรือไม่ ซึ่งสำคัญเป็นพิเศษเมื่อคุณต้อง จ้างนักพัฒนา PHP สำหรับผลิตภัณฑ์ระยะยาว
ตัวอย่างที่ 4: สำหรับนักพัฒนา full-stack
คำถาม: คุณจะสร้าง ตะกร้าสินค้าและขั้นตอนการชำระเงิน e-commerce ปกติอย่างไร?
หากผู้สมัครจัดการขั้นตอนพื้นฐานได้ดี ผมขยายคำถาม: สมมติว่าผลิตภัณฑ์มีจำนวนสต็อกจำกัด คุณจะทำให้แน่ใจได้อย่างไรว่าปริมาณที่ซื้อจะไม่เกินขีดจำกัดนั้น?
นี่เป็นหัวข้อที่ดีเมื่อประเมินผู้สมัครสำหรับงานที่เน้น backend หนัก นักพัฒนาระดับจูเนียร์อาจพูดเกี่ยวกับพฤติกรรมตะกร้าพื้นฐาน นักพัฒนาที่เก่งกว่าอาจพูดถึงการตรวจสอบ ทรานแซกชัน การล็อก race conditions สถานะการชำระเงิน และการย้อนกลับคำสั่งซื้อ หากโครงการของคุณขึ้นอยู่กับการตัดสินใจเหล่านั้น อาจคุ้มค่าที่จะทำงานกับ นักพัฒนา backend ที่มีประสบการณ์
วิธีที่พวกเขาสำรวจปัญหาบอกอะไรเรามากมายเกี่ยวกับระดับที่แท้จริงของพวกเขา
ตัวอย่างที่ 5: ปัญหาทางเทคนิคที่ไม่ค่อยพบแต่น่าสนใจ
คำถาม: ผมมีหน้า admin ที่มีรายการผลิตภัณฑ์ เมื่อผู้ใช้คนหนึ่งเปิดหน้าแก้ไขผลิตภัณฑ์ จะทำให้แน่ใจได้อย่างไรว่าไม่มีใครอื่นแก้ไขผลิตภัณฑ์เดียวกันพร้อมกันได้?
นี่เกี่ยวกับ resource locking เป็นหลัก ผู้สมัครบางคนสามารถตอบได้โดยตรง หากไม่ได้ ผมชี้แนะพวกเขากลับไปยังกรณีที่คุ้นเคยมากขึ้น: การลงทะเบียนผู้ใช้ ที่ระบบต้องป้องกันไม่ให้ผู้ใช้สองคนถูกสร้างด้วยอีเมลเดียวกันพร้อมกัน
จากนั้นผมถาม: “สามารถใช้แนวปฏิบัติที่คล้ายกันกับที่นี่ได้หรือไม่?”
คำถามนี้มีประโยชน์เพราะแสดงให้เห็นว่าผู้สมัครสามารถถ่ายทอดความรู้จากปัญหาหนึ่งไปยังอีกปัญหาหนึ่งได้หรือไม่
คำถามเหล่านี้เปิดเผยอะไร
จากตัวอย่างข้างต้น การสัมภาษณ์มักนำไปสู่สองสถานการณ์:
- ผู้สมัครตอบอย่างคล่องแคล่วเพราะพวกเขาเข้าใจหัวข้อนั้นดีอยู่แล้ว
- ผู้สมัครไม่ทราบคำตอบทันที ดังนั้นเราแก้ปัญหาไปด้วยกัน
กรณีที่สองมักน่าสนใจกว่า ในระหว่างกระบวนการนั้น เราสามารถเห็นว่าผู้สมัครถามคำถามที่เป็นประโยชน์ เข้าใจการชี้แจง ใช้เหตุผลอย่างตรรกะ และก้าวไปสู่โซลูชันหรือไม่
สิ่งนี้ช่วยให้เราประเมินหลายสิ่งพร้อมกัน:
- การสื่อสาร: พวกเขาถามและอธิบายได้อย่างชัดเจนหรือไม่?
- ระดับที่แท้จริง: พวกเขาเคยจัดการปัญหาประเภทใดมาแล้ว?
- ศักยภาพ: พวกเขาจะกลายเป็นผู้แก้ปัญหาได้หรือไม่ หรือจัดการเฉพาะงานซ้ำๆ?
นั่นคือเหตุผลที่การสนทนาตามสถานการณ์เป็นหนึ่งในแนวทางที่ดีที่สุดในการสัมภาษณ์นักพัฒนาซอฟต์แวร์ มันอัดสัญญาณหลายอย่างไว้ในการสนทนาครั้งเดียว
ตรวจสอบระดับที่แท้จริงของผู้สมัคร
ผมจะไม่ใช้เวลามากในส่วนนี้เพราะมีรายการคำถามทางเทคนิคอยู่แล้วมากมาย Java มีคำถามทั่วไปของตนเอง .NET, Python, iOS, Android, React Native, Node.js, React, Vue, JavaScript, CSS และอีกหลายด้านก็เช่นกัน สำหรับทีมผลิตภัณฑ์ สิ่งนี้มักเชื่อมโยงโดยตรงกับประเภท บริการพัฒนาซอฟต์แวร์ ที่พวกเขาต้องการ
คำถามเหล่านั้นยังคงมีประโยชน์ คุณต้องรู้ว่าผู้สมัครทำงานได้วันนี้หรือไม่ แต่รายการคำถามเกี่ยวกับเฟรมเวิร์กไม่ควรเป็นทั้งการสัมภาษณ์
ใช้คำถามเหล่านั้นเพื่อตรวจสอบระดับทางเทคนิคปัจจุบันของผู้สมัคร จากนั้นใช้สถานการณ์ปฏิบัติเพื่อทำความเข้าใจวิธีคิดของพวกเขา สำหรับบทบาทที่เน้นคุณภาพ ให้รวมคำถามเกี่ยวกับกลยุทธ์การทดสอบและ บริการทดสอบอัตโนมัติ ไม่เพียงแต่ไวยากรณ์การเขียนโค้ด
ตรวจสอบศักยภาพของผู้สมัคร
ระดับที่แท้จริงมีความสำคัญ แต่ศักยภาพสำคัญยิ่งกว่า หากระดับที่แท้จริงมีน้ำหนักเป็น 1 ศักยภาพอาจมีน้ำหนักเป็น 10
ทำไม? เพราะการพัฒนาซอฟต์แวร์เปลี่ยนแปลงอย่างรวดเร็ว นักพัฒนาที่รู้เพียงเครื่องมือในปัจจุบันอาจหยุดเติบโต นักพัฒนาที่มีพื้นฐานที่แข็งแกร่ง ความอยากรู้อยากเห็น และความสามารถในการแก้ปัญหาสามารถพัฒนาต่อไปได้อีกหลายปี
การศึกษาที่ดีขึ้นช่วยได้ แต่ไม่ใช่ทั้งหมด
นักพัฒนาซอฟต์แวร์ที่ดีไม่ได้มาจากมหาวิทยาลัยที่มีชื่อเสมอไป วิศวกรที่ยอดเยี่ยมหลายคนเป็นผู้เรียนรู้ด้วยตนเองหรือมาจากโรงเรียนธรรมดา
อย่างไรก็ตาม การศึกษาที่แข็งแกร่งสามารถให้พื้นฐานที่ดีกว่า อาจไม่สร้างความได้เปรียบที่มองเห็นได้ในวันนี้ แต่ในระยะยาว พื้นฐานที่มั่นคงช่วยให้นักพัฒนาเรียนรู้ได้เร็วขึ้นและไปได้ไกลกว่า
ความรู้พื้นฐานที่แข็งแกร่งหมายถึงศักยภาพที่แข็งแกร่ง
การศึกษาเป็นเพียงสัญญาณหนึ่ง ความรู้พื้นฐานสำคัญกว่า เราให้คุณค่ากับผู้สมัครที่เข้าใจพื้นฐานอย่างลึกซึ้ง
โครงสร้างข้อมูลและอัลกอริทึม
สำหรับพื้นฐาน โครงสร้างข้อมูลและอัลกอริทึม ยังคงสำคัญ
นักพัฒนาแอปพลิเคชันหลายคนเน้นเฉพาะการพัฒนาแอปพลิเคชันระดับสูง: Java Spring, .NET Framework, Node.js, Python, PHP, React, Vue และอื่นๆ นั่นเข้าใจได้เพราะเป็นเครื่องมือที่ใช้ทุกวัน
อย่างไรก็ตาม นักพัฒนาที่เข้าใจโครงสร้างข้อมูลและอัลกอริทึมมักมีพื้นฐานที่แข็งแกร่งกว่าสำหรับการแก้ปัญหา การคิดเรื่องประสิทธิภาพ และการออกแบบระบบ
เทคนิคการเขียนโปรแกรม
เทคนิคการเขียนโปรแกรมพื้นฐานก็สำคัญเช่นกัน ที่ HDWEBSOFT เราคาดหวังให้นักพัฒนาเข้าใจแนวปฏิบัติ clean code และหลักการ SOLID ไม่ใช่เพียงท่อจำคำนิยาม
OOP, design patterns และ UML
นักพัฒนาส่วนใหญ่บอกว่าพวกเขาใช้ object-oriented programming แต่ยังคงยากที่จะหานักพัฒนาที่มีความคิดเชิง OOP ที่แข็งแกร่งอย่างแท้จริง
หลายคนสามารถอธิบาย abstraction, inheritance และ polymorphism ได้ แต่มีน้อยคนที่สามารถชี้ไปที่บรรทัดของโค้ดตัวเองและอธิบายได้ว่าหลักการใดถูกแสดงออก
ผมยังประทับใจเมื่อนักพัฒนาเชี่ยวชาญ design patterns หลายตัวและรู้ว่าเมื่อไรไม่ควรใช้ design patterns ไม่ใช่แค่สูตรสำเร็จ แต่เป็นภาษาที่ใช้ร่วมกันเพื่อทำความเข้าใจโครงสร้าง ความตั้งใจ และโค้ดของผู้อื่น
บทสรุป: วิธีที่ดีที่สุดในการสัมภาษณ์นักพัฒนาซอฟต์แวร์
ดังนั้น วิธีที่ดีที่สุดในการสัมภาษณ์นักพัฒนาซอฟต์แวร์คืออะไร?
ไม่มีคำถามวิเศษเพียงข้อเดียว การสัมภาษณ์ที่ดีผสมคำถามประเภทต่างๆ ใช้คำถามทางเทคนิคเพื่อตรวจสอบทักษะที่แท้จริง ใช้คำถามพื้นฐานเพื่อตรวจสอบความรู้พื้นฐาน ใช้สถานการณ์ปฏิบัติเพื่อตรวจสอบการสื่อสาร การแก้ปัญหา ความยืดหยุ่น และศักยภาพ
ที่ HDWEBSOFT แนวทางนี้ช่วยให้เราจ้างวิศวกรที่สามารถมีส่วนร่วมได้ตั้งแต่วันนี้และเติบโตไปกับความท้าทายในอนาคต ยังทำให้การสัมภาษณ์เป็นมนุษย์มากขึ้น: น้อยลงเหมือนการสอบ มากขึ้นเหมือนการสนทนาการทำงานจริง