สมมติว่าบริษัทค้าส่งได้รับใบสั่งซื้อจากลูกค้าทุกวัน ก่อนบันทึกเป็นคำสั่งขายใน ERP บางใบจับคู่รหัสสินค้าไม่ได้ บางใบราคาต่างจากข้อตกลง พนักงานต้องเปิดหลายหน้าจอเพื่อหาสาเหตุ ถ้ามีคนขอให้ “ทำ AI ช่วยตรวจใบสั่งซื้อ” เราจะเริ่มตรงไหน และจะรู้ได้อย่างไรว่าของที่ทำช่วยงานจริง?
นี่เป็นกรณีสมมติเพื่ออธิบายวิธีเตรียมตัว ไม่ใช่งานของลูกค้าหรือผลจากระบบที่ผมสร้างมาแล้ว คำตอบอาจเริ่มจากการคุยกับคนรับใบสั่งซื้อ ดูว่าข้อมูลต้นทางเชื่อถือได้แค่ไหน แล้วทำหน้าจอรวมรายการผิดปกติแบบอ่านข้อมูลอย่างเดียว ก่อนตัดสินใจว่าจะใช้ AI ตรงไหน
โจทย์ลักษณะนี้ช่วยอธิบายบทบาท Forward Deployed Engineer (FDE) วิศวกรที่เข้าไปทำงานใกล้ทีมลูกค้า ทำความเข้าใจกระบวนการและข้อจำกัด สร้างหรือปรับซอฟต์แวร์ และตามงานจนระบบใช้ได้ในสภาพแวดล้อมจริง
ขอบเขตไม่เหมือนกันทุกบริษัท Palantir อธิบายงานที่ครอบคลุมข้อมูล สถาปัตยกรรม และแอปพลิเคชัน ขณะที่ตำแหน่งของ OpenAI และ Anthropic เน้นการนำระบบ AI ไปใช้กับลูกค้า จึงไม่ควรอ่านชื่อ FDE แล้วสรุปว่าเป็นงานเขียนพรอมป์ตอย่างเดียว หรือคิดว่าทุกแห่งต้องการทักษะชุดเดียวกัน ข้อมูลประกาศงานที่อ้างถึงตรวจเมื่อ 27 ตุลาคม 2569 และอาจเปลี่ยนได้
ก่อนเขียนโค้ด ต้องรู้ว่าปัญหาอยู่ที่ไหน
ถ้าคนทำงานบอกว่า “ใบสั่งซื้อผิดบ่อย” ผมอยากแยกคำนี้ให้เล็กลงก่อน ผิดตั้งแต่รับไฟล์ จับคู่รหัสสินค้า คำนวณราคา หรือรอคนอนุมัติ? ใครเห็นความผิดปกติเป็นคนแรก ใครมีสิทธิแก้ และถ้าไม่แก้จะเสียเวลาในขั้นใด? คำถามเหล่านี้ทำให้เลือกจุดเริ่มต้นได้โดยไม่ต้องเดาระบบทั้งก้อน
สำหรับกรณีสมมติ ผมจะเขียนบันทึกโจทย์หนึ่งหน้า: เส้นทางของใบสั่งซื้อหนึ่งใบ ข้อมูลชุดใดเป็นหลัก ข้อยกเว้นที่พบได้ ผู้มีสิทธิตัดสินใจ และผลที่ควรวัดจากวิธีเดิม แล้วให้คนที่ทำงานนั้นจริงช่วยตรวจว่าบันทึกตรงหรือไม่ ถ้ายังตอบไม่ได้ว่า “ผิด” หมายถึงอะไร การเริ่มด้วยโมเดล AI ก็อาจทำให้ตรวจงานยากขึ้น
เรื่องนี้ตรงกับวิธีที่ OpenAI อธิบายงาน FDE ของตน ว่าต้องเรียนรู้งานของลูกค้าและทดสอบกับงานจริงจนเลยตัวอย่างสาธิตไปถึงการใช้งาน ผมมองว่าเป็นบทเรียนที่ใช้กับงานระบบธุรกิจทั่วไปได้ด้วย แม้เทคโนโลยีที่เลือกจะไม่ใช่ AI
ทำชิ้นงานเล็กที่เห็นทั้งกรณีปกติและข้อผิดพลาด
ถ้าจะใช้กรณีใบสั่งซื้อเป็นผลงานเตรียมตัว ผมจะทำด้วยข้อมูลสังเคราะห์ ไม่ดึงข้อมูลลูกค้าเก่ามาใส่พอร์ต เริ่มจากหน้าจอแสดงรายการที่มีปัญหา ต่อกับ API จำลองของ ERP และกติกาตรวจรหัสสินค้า ราคา และสิทธิผู้ใช้ รายการที่ตรวจไม่ผ่านต้องบอกเหตุผลและระบุผู้รับช่วงตรวจต่อ
ชิ้นงานนี้ควรเปิดให้ดูได้ตั้งแต่ต้นจนจบ: รับข้อมูลอย่างไร แปลงฟิลด์ไหน ถ้า ERP ตอบช้าหรือตอบผิดรูปแบบจะเกิดอะไรขึ้น ระบบบันทึกข้อผิดพลาดอย่างไร และใครจะรับงานต่อหลังส่งมอบ ผมจะให้ส่วนนี้ อ่านข้อมูลอย่างเดียวก่อน หากจะเพิ่มการสร้างคำสั่งขายใน ERP ต้องตรวจสิทธิฝั่งเซิร์ฟเวอร์ บันทึกว่าใครอนุมัติ และกันการสร้างซ้ำเมื่อส่งคำขอใหม่หรือระบบลองอีกครั้ง การให้คนกดอนุมัติอย่างเดียวไม่พอ
ทักษะที่ควรฝึกกับชิ้นงานนี้คือ SQL สำหรับตรวจข้อมูล การออกแบบ API และการยืนยันตัวตน บันทึกเหตุการณ์ที่ช่วยตามข้อผิดพลาดได้ และการทดสอบทั้งกรณีปกติกับกรณีที่ระบบปลายทางล้มเหลว จะใช้ Python หรือ TypeScript ให้ดูภาษาที่ตำแหน่งสนใจใช้และเลือกภาษาที่ทำชิ้นงานให้จบได้ก่อน ไม่มีชุดเทคโนโลยีเดียวที่เป็นข้อบังคับของ FDE ทุกแห่ง
ถ้าสมัครงาน FDE ที่เน้น AI ค่อยเพิ่มส่วนช่วยจัดประเภทข้อผิดพลาดหรือเสนอข้อมูลที่คนควรตรวจ โดยเก็บชุดกรณีทดสอบที่มีทั้งเหตุการณ์ปกติ ข้อมูลกำกวม และคำตอบที่ระบบควรปฏิเสธ บันทึกด้วยว่าระบบแนะนำผิดเมื่อใดและคนแก้อย่างไร ข้อความในใบสั่งซื้อเป็นข้อมูลจากภายนอก แม้จะเขียนว่า “อนุมัติแล้ว” ก็ต้องไม่เปลี่ยนสิทธิหรือสั่งสร้างคำสั่งขายได้เอง OpenAI ระบุการตรวจด้วยงานตัวแทนก่อนใช้งานจริง ส่วน Anthropic ระบุประสบการณ์ด้านการประเมินระบบ AI เป็นคุณสมบัติที่มองหาในตำแหน่งนี้ ชิ้นงานฝึกนี้เป็นข้อเสนอของผม ไม่ใช่รายการบังคับของสองบริษัท
| สิ่งที่อยากสื่อ | หลักฐานในชิ้นงานฝึก |
|---|---|
| เข้าใจงาน | บันทึกขั้นตอนใบสั่งซื้อ ผู้ใช้ ข้อยกเว้น และเกณฑ์รับงานที่ตั้งไว้ |
| สร้างระบบ | หน้าจอเล็กหนึ่งหน้า API จำลอง ผังจับคู่ข้อมูล โค้ดและวิธีรันซ้ำ |
| จัดการข้อผิดพลาด | กรณีทดสอบ สิทธิอ่านข้อมูล บันทึกข้อผิดพลาด และทางส่งให้คนตรวจ |
| วัดก่อนอ้างผล | วิธีเก็บเวลาและความผิดพลาดของงานเดิม กับแผนเทียบหลังทดลอง โดยยังไม่ใส่ตัวเลขผลลัพธ์ที่ไม่ได้วัด |
| ส่งต่องาน | คำอธิบายทางเลือกที่ตัดสินใจ เจ้าของระบบ วิธีเฝ้าดู และสิ่งที่ต้องแก้ก่อนเปิดใช้จริง |
ตารางนี้เป็นแนวทางทำพอร์ตที่ผมเสนอ ไม่ใช่แบบประเมินรับสมัครของบริษัทใด จุดสำคัญคือผู้อ่านพอร์ตสามารถตามเหตุผลและทดลองชิ้นงานได้ หากให้คนที่ไม่เคยเห็นชิ้นงานลองจัดการกรณีสังเคราะห์หนึ่งใบ ก็ควรจดว่าทำสำเร็จหรือสะดุดตรงไหน ถ้ามีเพียงวิดีโอหน้าจอที่ทำงานได้ครั้งเดียว ก็ยังตอบเรื่องความผิดพลาดและการดูแลต่อไม่ได้
เอาประสบการณ์เดิมมาแปลงเป็นหลักฐาน
คนทำ ERP หรือระบบให้ลูกค้าอาจคุ้นกับการถามความต้องการ เชื่อม API ย้ายข้อมูล และแก้ปัญหาหน้างานอยู่แล้ว ประสบการณ์เหล่านี้มีค่า แต่เวลาเล่าให้คนรับสมัคร FDE ฟัง ควรแสดงว่าตัวเองตัดสินใจอย่างไรภายใต้ข้อจำกัด มากกว่าบอกเพียงว่าเคยรับผิดชอบโครงการขนาดใหญ่
ผมทำงานกับซอฟต์แวร์ธุรกิจและงานที่เชื่อมความต้องการฝ่ายบริหารกับระบบมานาน หากจะจัดพอร์ตสำหรับบทบาทนี้ ผมจะเลือกงานที่เปิดเผยได้จริง ลบชื่อและข้อมูลอ่อนไหว ระบุว่าผมทำส่วนไหน และอธิบายทางเลือกที่เคยต้องชั่ง เช่น ทำฟังก์ชันใหม่หรือปรับขั้นตอนเดิม ปล่อยให้ระบบแก้เองหรือส่งให้คนอนุมัติ สิ่งที่ยังไม่เคยทำก็ระบุว่าเป็นชิ้นงานฝึก ไม่แต่งผลลัพธ์ให้เหมือนงานลูกค้า
ผู้เริ่มทำงานก็ใช้หลักเดียวกันได้ ไม่ต้องมีประวัติโครงการองค์กรเพื่อทำตัวอย่างที่ตรวจได้ เลือกกระบวนการเล็ก ใช้ข้อมูลสังเคราะห์ ขอให้คนอื่นลองทำงานตามโจทย์ แล้วจดจุดที่เขาติดขัด สิ่งที่ผู้สมัครสองกลุ่มต้องพิสูจน์ต่างกัน แต่ทั้งคู่ควรอธิบายการตัดสินใจและข้อจำกัดของชิ้นงานตัวเองได้
เตรียมสมัครโดยอ่าน “งานจริง” ในประกาศ
ชื่อ FDE อาจทับกับงานของ solutions engineer, architect หรือ consultant ในบางบริษัท ผมจึงจะอ่านแต่ละประกาศจากคำถามสี่ข้อ: ต้องลงมือสร้างอะไร ต้องอยู่กับงานถึงช่วงไหน วัดว่าใช้ได้อย่างไร และส่งสิ่งที่เรียนรู้กลับทีมผลิตภัณฑ์แบบใด นี่เป็นวิธีอ่านประกาศ ไม่ใช่เส้นแบ่งตำแหน่งที่ใช้ได้ทุกองค์กร
ประกาศของ Palantir เน้นการสร้างบนข้อมูลและแอปพลิเคชันกับลูกค้า OpenAI กล่าวถึงการทำความเข้าใจโจทย์ ออกแบบ เขียนโค้ด นำไปใช้ และติดตามว่าคนใช้จริงหรือไม่ ส่วน Anthropic ระบุงานระบบ Claude ในสภาพแวดล้อมลูกค้าและนำรูปแบบที่ใช้ได้กลับไปเป็นแนวทางร่วมกัน ความต่างนี้ทำให้พอร์ตและเรื่องที่จะเล่าในการสัมภาษณ์ควรเลือกตามประกาศจริง เงื่อนไขปีประสบการณ์ ภาษา สถานที่ทำงาน และการเดินทางก็ต้องอ่านเป็นรายตำแหน่ง เพราะเปลี่ยนได้
ถ้าต้องวางเวลาเตรียม ผมจะใช้ 6 ถึง 8 สัปดาห์เป็นกรอบฝึกที่ปรับได้ตามพื้นฐานและขนาดชิ้นงาน
- สัปดาห์ที่ 1 ถึง 2 อ่านประกาศที่สนใจ คุยกับคนที่ทำกระบวนการใกล้เคียงกัน และเขียนโจทย์กับวิธีวัดงานเดิม
- สัปดาห์ที่ 3 ถึง 4 ทำทางอ่านข้อมูลและหน้าจอข้อยกเว้นให้รันซ้ำได้
- สัปดาห์ที่ 5 ถึง 6 ทดสอบข้อผิดพลาด กรณี AI ถ้ามี และให้คนอื่นลองใช้กับข้อมูลสังเคราะห์
- สัปดาห์ที่ 7 ถึง 8 เก็บสิ่งที่ผู้ลองใช้ติดขัด เขียนเอกสารส่งต่อและจัดพอร์ต
หากทำไม่ทัน ควรลดขอบเขตให้จบหนึ่งเส้นทาง กรอบเวลานี้ไม่ได้รับประกันความพร้อมหรือผลการสมัคร
ก่อนส่งพอร์ต ลองให้คนอื่นเปิดชิ้นงานจากคำแนะนำที่เขียนไว้ แล้วให้เขาหาว่าใบสั่งซื้อสมมติหนึ่งใบติดตรงไหนเมื่อ ERP ตอบช้า ถ้าเขารันซ้ำ เห็นเหตุผลที่ระบบหยุด และรู้ว่าต้องส่งให้ใครตรวจต่อได้ พอร์ตนั้นจะพาไปคุยเรื่องการตัดสินใจทางวิศวกรรมได้ละเอียดกว่าภาพหน้าจอที่ทำงานเฉพาะกรณีปกติ
