คำถามสัมภาษณ์งาน Full Stack Developer

คุณอาจกังวลว่าการสัมภาษณ์ full stack หมายถึงการเตรียมตัวสำหรับการสัมภาษณ์ที่สมบูรณ์สองครั้ง ทั้ง frontend และ backend ในเวลาที่ผู้สมัครส่วนใหญ่ใช้เตรียมตัวสำหรับการสัมภาษณ์เพียงครั้งเดียว ความกังวลนั้นสมเหตุสมผล และหัวข้อนี้จะแสดงให้เห็นว่างานนี้เล็กกว่าที่คิดไว้มาก ผู้สัมภาษณ์มักไม่ทำการสัมภาษณ์เฉพาะทาง frontend หรือ backend ซ้ำอีกครั้ง แต่จะสำรวจจุดที่เลเยอร์ต่าง ๆ มาบรรจบกัน เพราะนั่นคือจุดที่ full stack engineer พิสูจน์คุณค่าของตำแหน่งนี้จริง ๆ

กระบวนการสัมภาษณ์ส่วนใหญ่ผสมผสานรอบสัมภาษณ์สี่ประเภท:

• เขียนโค้ด: โจทย์ data structure หรืองานเชิงปฏิบัติ เช่น การ parse การจัดกลุ่ม หรือการทำ pagination ข้อมูล มักใช้ JavaScript, TypeScript, Python หรือ Java
• สร้างฟีเจอร์: งานขนาดเล็กแบบ end to end เช่นฟอร์มที่บันทึกข้อมูลผ่าน API และแสดง validation error ใน shared editor หรือ take-home repository
• ดีไซน์ข้ามทั้งสแตก: ร่างฟีเจอร์อย่างคอมเมนต์หรือการแจ้งเตือน ครอบคลุมทั้ง schema, API, สถานะฝั่ง client และสิ่งที่เกิดขึ้นเมื่อเครือข่ายล่ม
• Behavioral: การรับผิดชอบฟีเจอร์หนึ่งตั้งแต่ ticket จนถึง production และบั๊กที่คุณเคยตามรอยข้ามเลเยอร์

คำถามเชิงลึกเฉพาะเลเยอร์ก็ยังคงปรากฏอยู่ และชุดคำถามเฉพาะทาง รวมถึงหน้าแยกสำหรับ frontend และ backend developer อยู่ในศูนย์รวมคำถามสัมภาษณ์ หน้านี้ครอบคลุมส่วนที่อยู่ระหว่างสองฝั่งนั้น

API คือสัญญาระหว่างสองฝั่งของงานคุณ ผู้สัมภาษณ์จึงมักถามจากทั้งสองมุมมอง:

• คุณจะออกแบบ endpoint สำหรับฟีเจอร์หนึ่งอย่างไร และแต่ละ endpoint จะคืนค่าอะไรเมื่อสำเร็จและเมื่อล้มเหลว?
• คุณจะเปลี่ยนแปลง API อย่างไรโดยไม่ทำให้ client ที่ใช้งานจริงอยู่แล้วพัง? (versioning, การเปลี่ยนแปลงแบบเพิ่มเติม, deprecation window)
• pagination แบบ offset หรือแบบ cursor: คุณจะเลือกใช้แบบไหนสำหรับ activity feed และเพราะอะไร?
• คุณจะทำให้ POST ปลอดภัยสำหรับการ retry ได้อย่างไรหาก client เกิด timeout? (idempotency key)
• REST, GraphQL หรือ RPC สำหรับ client หนึ่ง ๆ: สิ่งที่เปลี่ยนไปในเรื่อง caching, over-fetching และการจัดการ error คืออะไร?
• validation ควรอยู่ที่ไหน ฝั่ง client, ฝั่ง server หรือทั้งสองฝั่ง และฝั่งไหนคือฝั่งที่ถูกต้องที่สุด?
• คุณจะหลีกเลี่ยง N+1 query ได้อย่างไรเมื่อ list endpoint คืนค่าข้อมูลแบบซ้อนกัน?

คำตอบที่ดีจะระบุ trade-off ไม่ใช่แค่ตัวเลือก คำตอบอย่าง "ใช้ cursor pagination เพราะแถวที่ถูกเพิ่มระหว่างที่ผู้ใช้เลื่อนหน้าจะทำให้ offset เลื่อนและเกิดรายการซ้ำ" ดีกว่าการแค่ไล่บอกทั้งสองตัวเลือกแล้วหยุดไว้แค่นั้น

คำถามสองประเภทที่แยกผู้สมัคร full stack ออกจากผู้เชี่ยวชาญเฉพาะทาง ประเภทแรกคือการยืนยันตัวตนแบบ end to end: อธิบายว่าเกิดอะไรขึ้นตั้งแต่ผู้ใช้ส่งฟอร์มล็อกอิน จนถึงตอนที่การเรียก API ที่ผ่านการยืนยันตัวตนสำเร็จ ผู้สัมภาษณ์จะฟังว่า credential ถูกเก็บไว้ที่ไหน (cookie หรือ client storage) server ตรวจสอบมันอย่างไร ทำไม cookie แบบ HttpOnly จึงต้านทานการเข้าถึงผ่านสคริปต์ได้ session ที่ใช้ cookie ต้องการการป้องกัน CSRF แบบไหน CORS ส่งผลอย่างไรต่อ frontend ที่มาจากคนละ origin และการล็อกเอาต์กับการหมดอายุของ token ถูกจัดการอย่างไร

ประเภทที่สองคือคำถามตามรอย: "ผู้ใช้กด Save แล้วไม่มีอะไรเกิดขึ้น ช่วยอธิบายว่าคุณจะดีบั๊กเรื่องนี้อย่างไร" คำตอบที่ดีจะไล่ทีละเลเยอร์ จาก browser console และ network tab ไปยัง request และ response ไปยัง server log จนถึงการเขียนข้อมูลลงฐานข้อมูล แทนที่จะเดาสุ่ม

ตัวอย่างทั่วไปคือ full stack developer คนหนึ่งที่กำลังสัมภาษณ์กับบริษัท SaaS ขนาดกลาง เมื่อถูกถามว่าฟีเจอร์คอมเมนต์จะทำงานอย่างไร เธอเริ่มจากตาราง (คอมเมนต์ที่มี post ID, author ID และ timestamp โดยจัดทำดัชนีตาม post) จากนั้นกำหนด list endpoint ด้วย cursor pagination อธิบาย optimistic rendering ฝั่ง client พร้อม rollback หาก POST ล้มเหลว และปิดท้ายด้วยวิธีที่เธอจะป้องกันไม่ให้ double-click โพสต์ซ้ำสองครั้ง เธอเล่าแต่ละเลเยอร์อย่างกระชับ และคำถามต่อเนื่องของผู้สัมภาษณ์ก็ตรงไปที่รอยต่อที่เธอระบุไว้พอดี

ฝึกตามรอยด้วยการพูดออกเสียงดัง ๆ เลือกฟีเจอร์หนึ่งจากแอปที่คุณใช้ทุกวันแล้วอธิบายตั้งแต่ schema ไปจนถึงหน้าจอ จากนั้นลองอีกครั้งโดยใส่ปัญหาเข้าไป: API ทำงานช้า การเขียนข้อมูลสำเร็จเพียงบางส่วน ผู้ใช้ถูกล็อกเอาต์ระหว่างที่ request กำลังทำงาน อัดเสียงตัวเองไว้ หรือลองตอบคำถามในการสัมภาษณ์จำลองด้วย AI ซึ่งจะถามคำถามต่อเนื่องตามคำตอบที่คุณพูดออกมา

ในรอบสัมภาษณ์จริง แอปเดสก์ท็อปของ SubcueAI สำหรับ macOS และ Windows สามารถถอดเสียงคำพูดของผู้สัมภาษณ์และแนะนำโครงสร้างคำตอบสำหรับคำถามดีไซน์และ behavioral ได้ในกรณีที่กฎของการสัมภาษณ์อนุญาตให้มีความช่วยเหลือ ส่วนขยาย Chrome/Edge ครอบคลุมสายที่โทรผ่านแท็บเบราว์เซอร์ และแอป iPhone จะฟังสายที่กำลังเล่นอยู่บนอุปกรณ์อีกเครื่อง ขีดจำกัดที่ตรงไปตรงมานี้สำคัญที่สุดในรอบสัมภาษณ์ full stack: การสร้างฟีเจอร์และรอบเขียนโค้ดมักเกิดขึ้นบนหน้าจอที่แชร์กัน และทุกอย่างบนหน้าจอที่แชร์กันมองเห็นได้หมด ความช่วยเหลือจึงอยู่นอกขอบเขตตรงนั้น การทดสอบออนไลน์ที่มีผู้คุมสอบและอุปกรณ์ที่บริษัทควบคุมก็อยู่นอกขอบเขตเช่นกัน วิธีตั้งค่าอยู่ในคู่มือการใช้งาน