คำถามสัมภาษณ์ Backend Developer: จริง ๆ แล้วเขาถามอะไรกัน

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

• การออกแบบ API REST เทียบกับ RPC, การจัดการเวอร์ชัน, pagination, การตอบกลับข้อผิดพลาด, การยืนยันตัวตน และ idempotency key
• ฐานข้อมูลและการโมเดลข้อมูล การเลือกใช้ relational หรือ document storage, index, join, transaction, isolation level, N+1 query และวิธีรัน schema migration อย่างปลอดภัย
• แคชและประสิทธิภาพ การทำ cache invalidation, การหมดอายุ, cache stampede และวิธี profile endpoint ที่ทำงานช้า
• การทำงานพร้อมกันและความน่าเชื่อถือ race condition, lock, queue, timeout และการ retry แบบมี backoff
• การออกแบบระบบ โจทย์อย่างเช่น URL shortener, rate limiter หรือระบบแจ้งเตือน
• การเขียนโค้ด โครงสร้างข้อมูลและโจทย์เชิงปฏิบัติ มักให้เลือกใช้ภาษาที่คุณถนัด

รอบที่เจาะจงภาษาหรือเฟรมเวิร์กจะเจาะลึกรายละเอียดมากขึ้น ศูนย์รวมคลังคำถามสัมภาษณ์ รวบรวมชุดคำถามสำหรับ Go, Java, Spring Boot, ไมโครเซอร์วิส และอื่น ๆ อีกมาก

คำถามเหล่านี้จะปรากฏในรูปแบบใดรูปแบบหนึ่งในการสัมภาษณ์สาย Backend ส่วนใหญ่ ลองฝึกตอบแต่ละข้อออกเสียงดัง ๆ ให้ได้ภายในเวลาไม่ถึงสองนาที:

• เกิดอะไรขึ้นเมื่อคุณเพิ่ม index ให้กับคอลัมน์หนึ่ง และ index จะกลายเป็นผลเสียเมื่อใด?
• read committed กับ serializable isolation ต่างกันอย่างไร และเมื่อใดที่คุณยอมจ่ายต้นทุนเพื่อระดับที่เข้มงวดกว่า?
• คุณจะหาและแก้ไข N+1 query ใน ORM ได้อย่างไร?
• จะทำอย่างไรให้ endpoint สำหรับการชำระเงินปลอดภัยเมื่อฝั่ง client ทำการ retry?
• จะแบ่งหน้า (paginate) ผลลัพธ์ชุดใหญ่ที่เปลี่ยนแปลงระหว่างที่ผู้ใช้เลื่อนหน้าจอได้อย่างไร?
• เมื่อใดที่คุณจะเลือกใช้ document store แทนฐานข้อมูลเชิงสัมพันธ์?
• คุณจะ roll out การเปลี่ยนชื่อคอลัมน์โดยไม่มี downtime ได้อย่างไร?

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

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

คำถามเรื่องการดีบักคือจุดที่แสดงประสบการณ์จริงออกมา วิศวกร Backend คนหนึ่งที่สัมภาษณ์ตำแหน่งระดับกลางที่บริษัทด้านการชำระเงินถูกถามว่าทำไม latency ของ endpoint หนึ่งจึงเพิ่มขึ้นเป็นสองเท่าหลังจากปล่อยเวอร์ชันใหม่ แทนที่จะเดาสาเหตุ เขาอธิบายขั้นตอนของตัวเอง: ตรวจสอบว่าอะไรเปลี่ยนไปใน deploy เทียบ trace ของเส้นทางที่ช้า อ่าน query plan และยืนยันการแก้ไขด้วย latency metric ตัวเดิม จากนั้นเขาเชื่อมโยงเรื่องนี้กับเหตุการณ์ query ช้าจากงานก่อนหน้า และบทสนทนาที่เหลือก็วนเวียนอยู่ที่เหตุการณ์นั้นมากกว่าเรื่องเครื่องมือ

เตรียมเรื่องราวจาก production ไว้สองเรื่องก่อนสัมภาษณ์ Backend ทุกครั้ง: บั๊กที่คุณตามหาจนเจอต้นตอ และการตัดสินใจด้านดีไซน์ที่ตอนนี้คุณจะทำต่างไปจากเดิม

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

สำหรับการสัมภาษณ์วิดีโอสดจริง ๆ SubcueAI จะถอดเสียงคำพูดของผู้สัมภาษณ์และร่างประเด็นคำตอบแบบมีโครงสร้างในโอเวอร์เลย์บนเครื่องของคุณ ไม่ว่าจะเป็นแอปเดสก์ท็อปบน macOS หรือ Windows (Zoom, Google Meet, Microsoft Teams) หรือใน Side Panel ของส่วนขยายเบราว์เซอร์สำหรับการโทรในแท็บ Chrome หรือ Edge ไม่มีบอทเข้าร่วมสายเลย มันมีประโยชน์ที่สุดในรอบที่เป็นการสนทนา เช่น การพูดคุยเรื่องดีไซน์และคำถามเกี่ยวกับประสบการณ์ ส่วนรอบเขียนโค้ดแบบแชร์หน้าจอ การประเมินที่มีผู้คุมสอบ การสัมภาษณ์แบบบันทึกวิดีโอทางเดียว และอุปกรณ์ที่บริษัทควบคุม อยู่นอกเหนือขอบเขตที่มันจะครอบคลุมได้อย่างปลอดภัย และทุกอย่างที่คุณแชร์บนหน้าจอจะมองเห็นได้ทั้งหมด ดูวิธีตั้งค่าได้ที่หน้า บทแนะนำการใช้งาน