Notes & software courses · Free to learn
Aph's Blog
On this page

สัมภาษณ์เชิงปฏิบัติ (Take-home & Practical)

👋 อ่านฟรีทั้งหมดบน Aph's Blog — เนื้อหาภาษาไทย ทำตามทีละหน้าใน sidebar ได้เลย หากมีข้อเสนอแนะหรืออยากให้เพิ่มหัวข้อไหน บอกได้เสมอ

รูปแบบสัมภาษณ์ที่บริษัทไทยและ startup ส่วนใหญ่ใช้จริง — แทนการเขียน algorithm บนกระดาน

ไม่ใช่ทุกบริษัทจะให้แก้โจทย์ algorithm สด ๆ บริษัทไทยและ startup จำนวนมากใช้วิธีที่ใกล้เคียงงานจริงมากกว่า เช่นให้โจทย์กลับไปทำที่บ้าน (take-home), เขียนโค้ดด้วยกันสด (pair programming) หรือให้แก้บั๊กในโค้ดที่เตรียมไว้ การเตรียมตัวจึงต่างจากการฝึก LeetCode

Take-home Assignment

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

  • โค้ดสะอาด อ่านง่าย ตั้งชื่อตัวแปร/ฟังก์ชันสื่อความหมาย
  • มี README อธิบายวิธีรัน, การตัดสินใจเชิงออกแบบ และข้อจำกัดที่รู้ตัว
  • มี test ครอบส่วนสำคัญ (จุดที่ทำให้เด่นกว่าคนอื่นมาก)
  • git history เป็นขั้นเป็นตอน ไม่ใช่ commit เดียวจบ
  • โครงสร้างโปรเจกต์เป็นระเบียบ แยก concern ชัดเจน
อย่า over-engineer และอย่าเกินเวลา

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

Pair Programming / Live Practical

บางที่ให้เขียนโค้ดสด ๆ ร่วมกับผู้สัมภาษณ์ โดยสร้าง feature เล็ก ๆ ที่เหมือนงานจริง ต่างจากโจทย์ algorithm บนกระดานตรงที่เปิด docs, ค้น Google หรือใช้ editor จริงได้ จุดที่ถูกประเมินคือวิธีคิดและการสื่อสาร

  • พูดอธิบายสิ่งที่กำลังทำและเหตุผลไปด้วยตลอด
  • ถามให้ชัดเรื่อง requirement ก่อนลงมือ อย่าเดาเอง
  • ค้น documentation ได้ตามปกติ — ไม่ใช่เรื่องน่าอาย แสดงว่าหาข้อมูลเป็น
  • รับ feedback ระหว่างทางและปรับตามได้ แสดงว่าทำงานร่วมกับทีมได้

Debugging Exercise

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

  1. ทำให้บั๊กเกิดซ้ำได้ก่อน (reproduce) เข้าใจว่าอาการคืออะไร
  2. ไล่ตาม flow ของโค้ดจากจุดที่ error ไปหาต้นตอ อ่าน error message ให้ละเอียด
  3. ตั้งสมมติฐานว่าอะไรพัง แล้วพิสูจน์ด้วยการ log/debug ทีละจุด
  4. แก้ที่ต้นเหตุ ไม่ใช่กลบอาการ แล้วทดสอบว่าหายจริงและไม่พังที่อื่น

สิ่งที่ผู้สัมภาษณ์มองหาจริง ๆ

ด้านสิ่งที่ดูจาก
Code qualityอ่านง่าย ตั้งชื่อดี โครงสร้างเป็นระเบียบ
Communicationอธิบายความคิด ถามเมื่อไม่ชัด รับ feedback ได้
Testingมี test ที่ครอบ edge case ไม่ใช่แค่ happy path
Gitcommit เป็นขั้นตอน message สื่อความหมาย
Problem-solvingแตกปัญหา จัดลำดับความสำคัญ รู้ว่าอะไรทำก่อน
บริบทไทย

หลายบริษัทในไทยใช้ take-home ผสมกับการสัมภาษณ์ที่ให้เล่าโปรเจกต์จริงของผู้สมัครเชิงลึก ดังนั้นการมีโปรเจกต์ที่ทำเองและอธิบายการตัดสินใจเชิงเทคนิคได้ จะช่วยได้มากทั้งสองด่าน