ปิดรอบสองด้วยประสบการณ์จริง

รอบนี้ไม่ได้วัดว่าเรารู้มากแค่ไหน แต่วัดว่า "ไว้ใจให้ไปทำงานจริงกับลูกค้าได้ไหม" Team Lead มองสามอย่าง: หนึ่งคือความลึกจากประสบการณ์จริง ว่าเคยลงมือทำไม่ใช่แค่อ่านมา; สองคือวิจารณญาณ ว่าตัดสินใจภายใต้ข้อจำกัดจริงเป็นไหม; สามคือความเป็นทีมและการสื่อสาร ว่าทำงานกับคนอื่นและอธิบายให้ลูกค้าเข้าใจได้ไหม ดังนั้นการเตรียมที่ดีที่สุดคือแปลงประสบการณ์จริงให้เล่าได้คมและเป็นระบบ

ถ้าพื้นฐานเดิมเป็น AWS นี่คือจุดแข็ง ไม่ใช่จุดอ่อน เตรียม mapping ในหัวเพื่อเล่าข้ามคลาวด์ได้ลื่น:

• EC2 เทียบ Compute Engine, S3 เทียบ Cloud Storage, RDS เทียบ Cloud SQL, Redshift เทียบ BigQuery, Lambda เทียบ Cloud Functions, EKS เทียบ GKE, ECS/Fargate เทียบ Cloud Run
• CloudFormation เทียบ Terraform/Deployment, IAM ทั้งคู่ชื่อ IAM แต่โมเดลต่างกันเล็กน้อย
• AWS DMS เทียบ Database Migration Service, AWS Application Migration Service เทียบ Migrate to Virtual Machines

วิธีเล่า: "งานนี้ผมทำบน AWS ด้วย X ซึ่งบน GCP เทียบเท่ากับ Y หลักการเดียวกัน แต่ผมจะปรับตรงนี้เพราะ GCP ต่างตรง..." การเล่าแบบนี้แสดงว่าเราเข้าใจแก่น ไม่ใช่ท่อง service ของค่ายเดียว และปรับตัวเรียนรู้ของใหม่เร็ว

เรื่องเล่าจากประสบการณ์คือคันโยกที่ใหญ่ที่สุดของรอบนี้ ใช้กรอบ STAR:

• Situation: สถานการณ์และบริบท
• Task: โจทย์หรือความรับผิดชอบของเรา
• Action: สิ่งที่เราลงมือทำ (เน้นตรงนี้มากที่สุด บอกวิธีคิดและการตัดสินใจ)
• Result: ผลลัพธ์ วัดเป็นตัวเลขได้ยิ่งดี

เตรียมเรื่องอย่างน้อย 5 เรื่องให้เล่าได้คล่อง แต่ละเรื่องปรับได้หลายมุม:

• เรื่อง migration จริง: ย้ายระบบขึ้นคลาวด์ เจอปัญหาอะไร แก้ยังไง (เช่นปัญหา network, VPN, database connectivity)
• เรื่อง build/automation: สร้าง infra หรือ CI/CD ตั้งแต่ศูนย์ ทำ IaC หรือ pipeline
• เรื่อง incident/ops: จัดการเหตุการณ์ฉุกเฉิน กู้ระบบ เช่นกู้ข้อมูลจาก snapshot หรือแก้ระบบล่ม
• เรื่องการตัดสินใจ architecture ที่มี trade-off ยาก: เลือกทางหนึ่งเหนืออีกทางเพราะอะไร
• เรื่องการทำงานกับทีมหรือลูกค้า: คุยเชิงเทคนิคกับลูกค้า เขียน proposal/SOW ประสานทีมขาย

เคล็ดลับ: เลือกเรื่องที่แสดงทั้งความลึกเทคนิคและวิจารณญาณ และซ้อมให้เล่าได้กระชับใน 2–3 นาที เน้น Action และ Result

เชิงประสบการณ์:

• "เล่าโปรเจกต์ migration ที่คุณภูมิใจที่สุด"
• "เคยเจอ migration หรือ deployment ที่พังไหม ทำยังไง"
• "เคยตัดสินใจ architecture ที่ยากที่สุดคืออะไร"
• "เคยทำงานกับทีมขายหรือลูกค้าที่กดดันให้ commit เกินจริงไหม จัดการยังไง"

เชิง building/migrating/managing:

• "ลูกค้ามีหลาย VMs และ database อยากขึ้น GCP จะเริ่มยังไง"
• "จะย้าย database ที่ห้าม downtime ยังไง"
• "หลังย้ายแล้วจะดูแลและคุมต้นทุนยังไง"
• "จะวางรากฐาน landing zone ให้ลูกค้ายังไง"

เชิงวิจารณญาณและการสื่อสาร:

• "ถ้าลูกค้ายืนยันจะใช้เทคโนโลยีที่คุณคิดว่าไม่เหมาะ จะทำยังไง"
• "จะอธิบายเรื่องเทคนิคยาก ๆ ให้ผู้บริหารที่ไม่ใช่สายเทคนิคเข้าใจยังไง"
• "ถ้าเจอปัญหาที่ไม่เคยแก้มาก่อน จะทำยังไง"

บางคำถามอาจถามสิ่งที่เราไม่เคยทำตรง ๆ ห้ามแกล้งรู้และห้ามยอมแพ้ทันที ให้ทำสามอย่าง: หนึ่ง ซื่อสัตย์ว่ายังไม่เคยทำเคสนี้ตรง ๆ; สอง โยงประสบการณ์ใกล้เคียงที่เคยทำและหลักการที่ใช้ได้; สาม แสดงวิธีคิดว่าถ้าต้องทำจะเข้าหาอย่างไร การตอบแบบนี้แสดงความซื่อสัตย์และความสามารถเรียนรู้ ซึ่ง Team Lead ให้คุณค่ามากกว่าการเดามั่ว

• คิดออกเสียง: ให้ Team Lead เห็นวิธีคิด ไม่ใช่แค่คำตอบสุดท้าย
• ถามกลับเพื่อเก็บ requirement ก่อนตอบโจทย์ scenario แสดงว่าเราคิดแบบ advisor
• วาด diagram หรือโครงเมื่ออธิบายสถาปัตยกรรม
• เล่า trade-off ทุกครั้งที่ตัดสินใจ
• ปิดคำตอบด้วยคุณค่าทางธุรกิจเสมอ
• เมื่อถูกท้วง ให้รับฟัง ปรับ และอธิบายเหตุผลใหม่อย่างมืออาชีพ ไม่ดื้อและไม่พังทันที
• จัดการเวลา อย่าจมรายละเอียดจุดเดียว
• แสดงว่าเข้าใจว่างาน DCE สำเร็จเมื่อลูกค้าสำเร็จ ไม่ใช่แค่ระบบสวย

Team Lead มักเปิดให้ถามกลับ เตรียมคำถามที่แสดงความสนใจงานจริง เช่น ทีม POD ทำงานร่วมกันยังไง, ลูกค้าส่วนใหญ่อยู่ช่วง migration เฟสไหน, ความท้าทายทางเทคนิคที่ทีมเจอบ่อย, หรือโอกาสเรียนรู้และเติบโต การถามที่ดีทำให้ดูเป็นคนที่คิดเรื่องการทำงานจริง ไม่ใช่แค่อยากได้งาน

เล่าประสบการณ์ลอย ๆ ไม่มีโครง STAR และไม่มีผลลัพธ์; แกล้งรู้ในสิ่งที่ไม่เคยทำ; ตอบเชิงทฤษฎีทั้งที่เขาอยากได้ประสบการณ์จริง; ไม่เล่า trade-off และวิธีคิด; ดื้อเมื่อถูกท้วง; ไม่เตรียม mapping AWS เป็น GCP ทั้งที่เป็นจุดแข็ง; ไม่มีคำถามถามกลับ; ลืมโยงคุณค่าธุรกิจ

รอบ Team Lead วัดว่าไว้ใจให้ทำงานจริงได้ไหม เตรียมเรื่องเล่า STAR อย่างน้อย 5 เรื่องที่แสดงทั้งความลึกและวิจารณญาณ แปลงประสบการณ์ AWS เป็นภาษา GCP ให้เป็นจุดแข็ง เมื่อไม่เคยทำสิ่งที่ถูกถามให้ซื่อสัตย์ โยงประสบการณ์ใกล้เคียง และแสดงวิธีคิด ระหว่างตอบให้คิดออกเสียง ถามก่อนตอบ เล่า trade-off และปิดด้วยคุณค่าธุรกิจ เตรียมคำถามถามกลับ ทั้งหมดนี้ทำให้ Team Lead เชื่อว่าเราพร้อมนั่งหน้าลูกค้าจริงและปิด technical win ได้