18.5 เรซูเม่, Networking และการสมัคร

ทุกบทที่ผ่านมาในหนังสือเล่มนี้พูดถึงการสร้างของบางอย่าง — เกม ระบบ shader หรือ tool แต่บทนี้พูดถึงขั้นตอนที่ไม่มีใครสอนในโรงเรียน นั่นคือการเอางานที่เราสร้างมาแปลงให้กลายเป็นงานจริง CV (curriculum vitae เอกสารหนึ่งถึงสองหน้าที่รวมทักษะกับผลงานของเรา บางที่เรียกว่า "resume" ในสหรัฐฯ) ไม่ใช่เรื่องเล่าชีวิตของเรา มันคือตัวกรอง recruiter หรือ hiring manager ที่มีใบสมัคร 150 ใบกองอยู่ตรงหน้าและมีเวลาแค่บ่ายเดียวจะอ่าน CV ของเราแค่ไม่กี่วินาที ไม่ใช่หลายนาที บทนี้จะพูดถึงว่าอะไรบ้างที่ถูกอ่านจริง ๆ ในเวลาสั้น ๆ นั้น วิธีเขียน bullet ที่รอดจากการอ่านแบบเร็ว วิธีเขียน cover note สั้น ๆ วิธี visible ในวงการโดยไม่ดูแปลก ๆ งานอยู่ตรงไหนบ้าง วิธีสมัครงานตอนที่เรายังเป็นมือใหม่จริง ๆ และ routine รายสัปดาห์ที่เราทำต่อเนื่องได้เป็นเดือน ๆ โดยไม่หมดไฟ ทั้งหมดนี้ไม่ต้องการให้เราเป็นโปรแกรมเมอร์อัจฉริยะ แค่ต้องการให้เรานำเสนองานจริงในแบบที่คนแปลกหน้าที่กำลังยุ่งมองเห็นได้เร็ว

1. การทดสอบ 20 วินาที: สิ่งที่เกิดขึ้นจริงกับ CV ของเรา

เมื่อ CV ไปตกอยู่ในกองใบสมัคร แทบไม่มีใครอ่านตั้งแต่บนลงล่างในรอบแรก พวกเขาจะ skim (กวาดสายตาอ่านคร่าว ๆ) แทน งานวิจัยเรื่องพฤติกรรม recruiter หลายชิ้นให้ตัวเลขรอบแรกไว้ตั้งแต่ประมาณ 6 ถึง 30 วินาที ให้เราถือว่า 20 วินาทีเป็นตัวเลขทำงาน ไม่ใช่กฎวิทยาศาสตร์ตายตัว สิ่งที่สำคัญคือรูปแบบของการ skim นั้น เพราะมันเป็นรูปแบบเดียวกันแทบทุกครั้ง

สังเกตว่าอะไร ไม่ อยู่ในลิสต์นั้น: เกรดเฉลี่ยของเรา ย่อหน้าที่อธิบายว่าทำไมเรารักเกม หรือ objective statement บนหัวกระดาษที่บอกว่าเราเป็น "a passionate and driven individual" ไม่มีอันไหนช่วยให้คนอ่านตัดสินใจอะไรได้ใน 20 วินาทีเลย สิ่งที่ช่วยจริง ๆ คือ ตำแหน่งที่ตรงกับที่เขากำลังหาคน ชื่อโปรเจกต์กับเทคโนโลยีที่ตรงกับ stack ของเขา และลิงก์ที่คนอ่านกดได้เลยโดยไม่ต้องไล่หา

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

2. ลำดับที่ตรงกับวิธีที่คนอ่านจริง ๆ: ลิงก์มาก่อน โปรเจกต์อยู่เหนือการศึกษา

เพราะสายตาของคนอ่านจะไปถึงแค่ส่วนบนของหน้ากระดาษอย่างเชื่อถือได้ในการ skim ครั้งหนึ่ง ลำดับที่แต่ละ section ปรากฏจึงไม่ใช่เรื่องรสนิยม — มันตัดสินเลยว่าอะไรจะถูกเห็นบ้าง มีสองกฎที่ตามมาโดยตรงจาก Section 1

• ข้อมูลติดต่อกับลิงก์ต้องอยู่บนสุด ไม่ใช่ล่างสุดของหน้าแรกและไม่ใช่หน้าสอง ถ้าคนอ่านต้องไปไล่หาลิงก์ GitHub ของเรา ส่วนใหญ่จะไม่ไล่หา
• สำหรับผู้สมัครระดับจูเนียร์ที่แทบไม่มีประสบการณ์ทำงานที่ได้เงิน PROJECTS ต้องมาก่อน EDUCATION ปริญญาจากมหาวิทยาลัยคือ credential — มันบอกว่าเราเรียนจบโปรแกรมนั้นแล้ว แต่โปรเจกต์ที่ shipped แล้วคือหลักฐาน — มันแสดงว่าเราสร้างอะไรได้จริง คนอ่านที่กำลังหาคนมาทำงานสายโปรแกรมมิ่งอยากเห็นหลักฐานก่อน (กฎนี้จะกลับกันเมื่อเรามีประสบการณ์ทำงานที่ได้เงินหลายปีแล้ว ตอนนั้นประสบการณ์จะกลายเป็นหลักฐานที่แข็งแรงที่สุดและขึ้นไปอยู่บนสุด ส่วนโปรเจกต์กับการศึกษาจะเล็กลงหรือหายไป บทนี้พูดถึงงานแรก ดังนั้นโปรเจกต์จึงนำ)

ปกติแค่สามลิงก์ก็พอ: portfolio (เว็บส่วนตัวหรือหน้าเดียวที่รวมผลงานของเรา — ถ้าอีกสองลิงก์แข็งแรงพอก็ไม่จำเป็นต้องมี), playable build (สิ่งที่คนกดเล่นได้จริง — หน้า itch.io, ไฟล์ APK, ลิงก์ TestFlight, หรือ WebGL build ที่เล่นในเบราว์เซอร์ได้เลย) และ code ของเรา (GitHub หรือ repository อื่น ๆ ในสามอย่างนี้ playable build สำคัญที่สุดและมักถูกมือใหม่ข้ามไปบ่อยที่สุด recruiter กด bullet บน resume แล้วเช็คว่าจริงไม่จริงไม่ได้ แต่กดลิงก์แล้วเล่นเกมของเราได้ภายในสามสิบวินาที

3. เขียน Bullet ที่แสดง Impact ไม่ใช่แค่ลิสต์หน้าที่

CV ของมือใหม่ส่วนใหญ่บรรยาย duty (หน้าที่): สิ่งที่คน ๆ นั้นถูกมอบหมายให้ทำ ส่วน CV ที่แข็งแรงบรรยาย impact (ผลกระทบ): สิ่งที่เปลี่ยนแปลงไปเพราะคน ๆ นั้นทำงานนี้ ความต่างไม่ได้อยู่ที่การเขียนประโยคให้หรูขึ้น แต่อยู่ที่การจบประโยคด้วยผลลัพธ์ แทนที่จะหยุดแค่ที่ตัวงาน

สูตร

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

นี่คือตัวอย่างที่สูตรนี้ถูกสร้างขึ้นมาจากมันโดยตรง — bullet แบบ duty ถูกแปลงเป็น bullet แบบ impact

WEAK:   Worked on enemy AI.

STRONG: Built the enemy AI for a 3-month student project: behaviour
        trees, navmesh pathfinding and perception; profiled and cut
        AI frame cost roughly in half.

สังเกตทุกอย่างที่เวอร์ชัน strong เพิ่มเข้ามาโดยไม่กลายเป็นย่อหน้ายาว: โปรเจกต์นานแค่ไหน (3 เดือน — บอก scope), เทคนิคที่ใช้ชัดเจน (behaviour trees, navmesh pathfinding, perception — แสดงคำศัพท์เทคนิคจริง ไม่ใช่คำกว้าง ๆ) และผลลัพธ์ที่วัดได้ (cut frame cost roughly in half — แสดงว่างานนี้มีผลจริง และถูกวัดจริง ไม่ใช่แค่เดา)

อีกห้าตัวอย่างการเขียนใหม่

สูตรเดียวกันนี้ใช้ได้กว้างกว่าแค่เรื่อง AI มาก นี่คืออีกห้าตัวอย่าง ครอบคลุมทั้ง gameplay system, tool, การ optimize, multiplayer และ leadership

WEAK:   Worked on inventory system.

STRONG: Built a drag-and-drop inventory and equipment system in
        Unity (C#) for a 4-person team project, using
        ScriptableObjects for item data; shipped in a public demo
        played by 200+ people at a local game jam showcase.

WEAK:   Made a level editor tool.

STRONG: Built a custom Unity editor tool that let 3 designers place
        and tweak enemy spawn points without touching code, cutting
        level setup time from about 2 hours to 20 minutes per level.

WEAK:   Optimized the game.

STRONG: Reduced frame time on a mid-range Android device from 22ms
        to 15ms by batching draw calls and compressing textures to
        ASTC, taking the game from an unstable 35fps to a steady
        60fps.

WEAK:   Helped with multiplayer.

STRONG: Implemented client-side prediction and reconciliation for
        player movement over Unity Netcode for GameObjects, cutting
        visible rubber-banding at 150ms simulated latency from
        constant to rare.

WEAK:   Was team lead.

STRONG: Led a 4-person team through a 48-hour game jam, split work
        across gameplay, art and audio, and delivered a finished,
        submitted build with no missed deadline.

สังเกตว่าคำกริยาแบบ "weak" มีรูปแบบเหมือนกัน: worked on, helped with, was involved in, responsible for ทุกคำนี้บรรยายความสัมพันธ์กับงาน (เราอยู่ใกล้ ๆ งานนั้น) แทนที่จะบรรยายการกระทำกับผลลัพธ์ (เราทำสิ่งนี้เฉพาะเจาะจง แล้วสิ่งนี้เฉพาะเจาะจงก็เกิดขึ้น) ให้เปลี่ยนไปใช้คำกริยาอย่าง built, implemented, fixed, optimized, shipped, led, reduced, designed — คำกริยาที่จะสมเหตุสมผลก็ต่อเมื่อเราทำสิ่งนั้นจริง ๆ เท่านั้น

4. รวมทุกอย่างเข้าด้วยกัน: CV หน้าเดียวแบบเต็ม

นี่คือตัวอย่าง CV ที่สมบูรณ์และสมจริงสำหรับตำแหน่ง junior gameplay programmer ตามลำดับจาก Section 2 และสูตร bullet จาก Section 3 ตัวละครกับทุกโปรเจกต์ในนี้ถูกสร้างขึ้นมาสำหรับบทเรียนนี้โดยเฉพาะ แต่รูปร่าง ความยาว และการใช้คำ คือสิ่งที่ CV จูเนียร์จริง ๆ ในวงการนี้ควรมีหน้าตาแบบนี้

มีบางอย่างที่น่าสังเกตในตัวอย่างนี้: ทุก bullet ของโปรเจกต์ใช้สูตรคำกริยาหนักแน่นจาก Section 3 ไม่มี section "Objective" เป็นย่อหน้า และไม่มี "About Me" — โปรเจกต์กับลิงก์บอกอยู่แล้วว่านี่คือโปรแกรมเมอร์แบบไหน ส่วน skills เป็นลิสต์แน่น ๆ ไม่ใช่ประโยค เพราะคนอ่านที่กำลังหาคำตอบว่า "คนนี้รู้ C# กับ Unity ไหม" อยากได้คำตอบในครึ่งวินาที ไม่ใช่ต้องไปขุดในย่อหน้า และ education มีแค่สองบรรทัดพอดี อยู่ล่างสุด เพราะสำหรับผู้สมัครจูเนียร์ มันคือหลักฐานที่อ่อนที่สุดบนหน้ากระดาษ ไม่ใช่แข็งแรงที่สุด

5. ปรับ CV ให้เข้ากับแต่ละงาน: สะท้อนคำในประกาศงาน

Tailoring (การปรับให้เข้ากับงานเฉพาะ) หมายถึงการปรับ CV ให้ตรงกับประกาศงานแต่ละอัน แทนที่จะส่งเอกสารเดิมทุกที่ ไม่ได้หมายความว่าต้องเขียน CV ใหม่ทั้งหมดทุกครั้ง — แต่หมายถึงการอ่านประกาศงานอย่างละเอียด สังเกตคำนามเฉพาะที่มันใช้ (เครื่องมือของเขา ระบบของเขา สิ่งที่เขาให้ความสำคัญ) แล้วตรงไหนที่จริงกับงานเราจริง ๆ ให้เขียน bullet เดิมของเราโดยใช้คำเดียวกันนั้น แทนคำพ้องความหมาย

นี่ไม่ใช่เรื่องโกหก มันคือข้อเท็จจริงที่ว่าเรื่องจริงเรื่องเดียวสามารถพูดได้สองแบบ และแบบหนึ่งง่ายกว่าให้คนอ่านคนหนึ่งจำได้ว่าตรงกัน สมมติประกาศงานเขียนว่า "Looking for a programmer with experience in gameplay systems and combat design." ถ้า bullet หนึ่งของเราเขียนไว้แล้วว่า "Built the enemy AI... behaviour trees, navmesh pathfinding and perception" คำนั้นตรงอยู่แล้ว — เก็บไว้แบบเดิม แต่ถ้าอีก bullet เขียนว่า "Built a physics-based movement system" และระบบนั้นมี hit reaction กับ knockback สำหรับ boss fight จริง ๆ การ tailor คือการดึงรายละเอียดจริงนั้นออกมาให้มีคำว่า "combat" สำหรับใบสมัครนี้ เพราะมันจริงและเป็นสิ่งที่คนอ่านคนนี้กำลังมองหา สิ่งที่ tailoring ไม่เคยหมายถึงคือการเติมคำว่า "combat systems" ลงใน bullet ของโปรเจกต์ที่ไม่เคยแตะเรื่อง combat เลย

ทำไมเรื่องนี้ถึงสำคัญกว่าปริมาณ ลองเทียบการส่ง CV เดิมไปยัง 100 สตูดิโอ กับการ tailor CV สำหรับ 10 สตูดิโอ

วิธีแบบ generic กระจายความพยายามจำนวนคงที่ให้บางลงไปในความพยายามคุณภาพต่ำจำนวนมาก ส่วนวิธีแบบ tailored รวมความพยายามรวม ๆ ปริมาณใกล้เคียงกันไปไว้ในความพยายามที่น้อยครั้งกว่าแต่แข็งแรงกว่า — และผลข้างเคียงของการทำงาน tailor คือเราได้เรียนรู้อะไรบางอย่างที่จริงเกี่ยวกับแต่ละสตูดิโอจริง ๆ ซึ่งนั่นคือสิ่งที่ interviewer กำลังฟังอยู่พอดีตอนถามว่าทำไมเราถึงสมัครที่นี่

6. ส่วนที่ตรงไปตรงมา: ตัวกรอง Keyword และ Applicant Tracking System (ATS)

นี่คือสิ่งที่มือใหม่ไม่ค่อยมีใครบอกตรง ๆ: ที่หลายสตูดิโอ โดยเฉพาะสตูดิโอใหญ่ ใบสมัครของเราไม่ได้ไปถึงมือมนุษย์โดยตรง มันจะผ่าน Applicant Tracking System (ATS) ก่อน — ซอฟต์แวร์ที่สแกน จัดอันดับ หรือกรองใบสมัครด้วยการจับคู่ keyword กับ job description ก่อนที่จะมีใครเปิดอ่านมันเลย เมื่อปริมาณใบสมัครสูงมาก นี่คือวิธีที่ระบบขยายตัวได้จริง ๆ ไม่ใช่ทฤษฎีสมคบคิดต่อต้านมือใหม่ แต่มันหมายความว่า CV แพ้ได้ตั้งแต่ก่อนที่มนุษย์คนไหนจะเห็นมันเลย ด้วยเหตุผลที่ไม่เกี่ยวกับทักษะจริงของเราเลย

วิธีตอบสนองที่ใช้ได้จริงคือ layout เรียบง่ายแบบเดียวกับที่บทนี้พูดถึงมาตลอด

• เลือก layout แบบข้อความล้วน ๆ มากกว่า PDF ที่ออกแบบหนัก ๆ เป็นรูปภาพ หรือมีหลายคอลัมน์ parser บางตัวอ่านเนื้อหาที่เป็นรูปภาพไม่ได้เลย หรือสลับลำดับข้อความหลายคอลัมน์ผิดที่
• ใช้ชื่อ section มาตรฐาน — Projects, Skills, Education — เพราะทั้งคนที่ skim ด้วยตาและ parser ต่างมองหาคำพวกนี้พอดี
• ใส่ keyword เฉพาะเจาะจงจากประกาศงานลงไปในเนื้อหาอย่างซื่อสัตย์ ตามที่พูดไว้ใน Section 5 ตัวกรองจับคู่ทักษะที่เรามีแต่ไม่เคยเขียนไว้ไม่ได้

นี่คือเหตุผลจริง ๆ ที่ layout เรียบ ๆ เป็นกล่องจาก Section 2 กับ 4 สำคัญสองต่อ: มันคือสิ่งที่มนุษย์ที่กำลังรีบอ่านได้เร็วที่สุดใน 20 วินาทีของเขา และมันก็เป็นสิ่งที่ parser อัตโนมัติดึงข้อมูลออกมาได้ถูกต้องด้วย CV template ที่สวยงามเต็มไปด้วยไอคอน sidebar และกราฟิก อาจดูน่าประทับใจบนหน้าจอของเราเอง แต่พังไม่เป็นท่าทันทีที่ผ่าน parser

7. Cover Note: สามย่อหน้าที่ทำหน้าที่ของมัน

cover note (เรียกอีกอย่างว่า cover letter) คือข้อความสั้น ๆ ที่ส่งไปพร้อมกับ CV ของเรา — อีเมล หรือกล่องข้อความบนฟอร์มสมัครงาน มันไม่ใช่ CV ของเราฉบับที่สองในรูปประโยค หน้าที่ของมันคือทำสามอย่างที่เฉพาะเจาะจง แต่ละอย่างในย่อหน้าสั้น ๆ หนึ่งย่อหน้า

• ทำไมสตูดิโอนี้โดยเฉพาะ อะไรบางอย่างที่เป็นรูปธรรมและจริง — เกมที่ shipped แล้วที่เราเล่นจริง เทคโนโลยีเฉพาะที่เขาใช้ talk ที่คนในทีมเคยพูด อย่าใช้คำชมกว้าง ๆ อย่าง "I've always dreamed of working at your amazing company" เพราะมันเอาไปแปะในจดหมายถึงสตูดิโอไหนบนโลกก็ได้ ดังนั้นมันจึงไม่พิสูจน์อะไรเลย
• เรามีอะไรมาเสนอ สองถึงสามผลงานที่เกี่ยวข้องที่สุดของเรา จับคู่กับสิ่งที่ประกาศงานถามหาจริง ๆ ด้วยคำพูดของเราเอง — ไม่ใช่ก็อปมาจาก CV ตรง ๆ แต่อ้างอิงถึงมัน
• ลิงก์ และการปิดท้ายสั้น ๆ ลิงก์หนึ่งหรือสองอันที่เกี่ยวข้องที่สุดกับงานนี้โดยเฉพาะ ความพร้อมของเรา และการปิดท้ายสั้น ๆ สุภาพ ไม่กดดัน ไม่ต้องมีประโยคปิดท้ายดราม่า

Subject: Junior Gameplay Programmer application -- {Your Name}

Hi {Studio / Hiring Team},

{Paragraph 1 -- why this studio, something specific and true}

{Paragraph 2 -- what you bring, 2-3 concrete things tied to the ad}

{Paragraph 3 -- the most relevant link(s), your availability, thanks}

{Your Name}
{portfolio link} | {build link} | {code link}

เติมเนื้อหาจริงจากตัวละครกับโปรเจกต์ใน Section 4 สมัครไปยังสตูดิโอเล็ก ๆ ที่สมมติขึ้น

Subject: Junior Gameplay Programmer application -- Jordan Reyes

Hi Lantern Peak Games,

I played through Driftlight on my phone last month, and the way
combat stays smooth even on my three-year-old Android is exactly
the reason I'm writing -- getting that kind of frame time on
mid-range hardware is the kind of problem I like solving.

For a solo project called Reef Runner I built a physics-based
movement system from scratch and brought frame time down from
22ms to 15ms through draw call batching and texture compression,
and for a 3-person student project I built enemy AI with
behaviour trees and navmesh pathfinding, cutting its frame cost
roughly in half. Both are C# in Unity, which I saw is your stack
too.

A playable build of Reef Runner is at jordanreyes.itch.io and the
code is at github.com/jreyes. I'm finishing my degree in Bangkok
and free to start part-time now, full-time from May. Thanks for
reading this far -- happy to send anything else that's useful.

Jordan Reyes
jordanreyes.dev | jordanreyes.itch.io | github.com/jreyes

สังเกตว่าย่อหน้าแรกไม่ได้พูดว่า "I love Lantern Peak Games" มันพูดอะไรบางอย่างที่เฉพาะเจาะจงพอที่จะเขียนได้เฉพาะคนที่เล่นเกมนั้นจริง ๆ เท่านั้น — ความเฉพาะเจาะจงนั้นแหละที่ทำให้มันอ่านแล้วรู้สึกจริงใจ ไม่ใช่แค่ก็อปแปะ ถึงแม้ว่าโดยโครงสร้างแล้วมันคือ template ก็ตาม

8. การเป็นที่มองเห็น: Networking โดยไม่ดูแปลก ๆ

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

• โพสต์ความคืบหน้าให้คนอื่นเห็นอย่างสม่ำเสมอ devlog (บันทึกความคืบหน้าการพัฒนา) สั้น ๆ คลิปสิบวินาที หรือ screenshot — โพสต์บน itch.io, forum, หรือโซเชียลมีเดีย ด้วยจังหวะที่สม่ำเสมอ มีค่ามากกว่า trailer สวย ๆ ที่โพสต์ครั้งเดียวมากเมื่อมองในระยะเวลาหลายเดือน
• ไปงาน jam กับ meetup แบบตัวต่อตัวถ้าทำได้ ออนไลน์ถ้าทำไม่ได้ game jam (งานสั้น ๆ ที่จำกัดเวลา ให้คนมาสร้างเกมเล็ก ๆ ร่วมกัน ปกติ 48 ชั่วโมงถึงหนึ่งสัปดาห์) พาเราไปอยู่ในห้องเดียวกับคนทำเกมคนอื่น ๆ ทำงานเคียงข้างกันแทนที่จะพูดใส่กัน — ซึ่งเป็นวิธีที่เป็นธรรมชาติกว่าการทัก message เย็น ๆ มากในการกลายเป็นคนที่คนอื่นจำได้
• คอมเมนต์งานของคนอื่นอย่างจริงใจ ไม่ใช่แค่โพสต์งานตัวเอง คอมมูนิตี้ที่เราโผล่มาแค่โปรโมทตัวเองตลอดจะดูออกเลยว่าเป็นแบบนั้น

หลักการเบื้องหลังคือ ให้ก่อนขอ — เป็นคนที่คนอื่นจำได้ในทางที่ดีอยู่แล้ว — เพราะเขาเคยเห็นโพสต์ของเรา เคยเล่นงาน jam ของเรา หรือเคยได้คอมเมนต์ที่มีประโยชน์จากเรา — ก่อนที่เราจะต้องขออะไรจากเขาเลย message จากคนแปลกหน้าที่ไม่เคยมีส่วนร่วมอะไรในคอมมูนิตี้เลยจะอ่านแตกต่างจาก message เดียวกันที่ส่งโดยคนที่คนอื่นเคยเห็นผลงานมาแล้วมาก

9. ทัก Message หาคนในวงการอย่างสุภาพ

สุดท้ายแล้ว การ visible อย่างเดียวไม่พอ และเราจะอยากทัก message หาใครสักคนโดยตรง — อาจเป็นโปรแกรมเมอร์ที่เราดู talk ของเขา หรือคนที่สตูดิโอที่เราสนใจ มีกฎข้อเดียวที่แยก message ที่คนอยากตอบ ออกจาก message ที่โดนเลื่อนผ่าน

วิธีแก้คือ ขอสิ่งเล็ก ๆ เฉพาะเจาะจงที่ตอบได้ในเวลาไม่ถึงสองนาที — ไม่ใช่ "can you get me a job" คำถามเฉพาะเจาะจงหนึ่งข้อ การขอให้ดู screenshot สามสิบวินาที คำถาม yes/no ว่าอะไรบางอย่างจริงในประสบการณ์ของเขาไหม เขียน message ทั้งหมดให้อยู่แค่สี่ถึงหกประโยค ทำให้เป็นส่วนตัวด้วยรายละเอียดจริงเฉพาะเจาะจงหนึ่งอย่างเกี่ยวกับงานของเขา และบอกตรง ๆ ว่าไม่กดดันให้ตอบ

Hi {Name},

I saw your {specific thing -- talk / post / shipped game / clip}
about {specific detail}, and it changed how I think about {topic}.

I'm a student / self-taught programmer working on {one-line
project description}. I have one small question, no pressure to
answer: {one specific, answerable-in-two-minutes question}.

Thanks either way, and congrats on {specific thing} again.
{Your name}

เติมเนื้อหาเป็นตัวอย่างจริง

Hi Priya,

I saw your GDC talk clip about tuning navmesh agent avoidance for
crowds of 200+ NPCs, and it changed how I set up pathfinding for
my own student project.

I'm a student programmer finishing a 3-person game with a fairly
dense NPC crowd. One small question, no pressure to answer: did
you find agent radius or avoidance priority mattered more for
keeping frame cost down at that count?

Thanks either way, and congrats again on the GDC talk.
Jordan

สังเกตว่า message นี้ ไม่ ทำอะไร: มันไม่ได้ของาน ขอ referral หรือขอให้รีวิว resume เลยสักจุดเดียว ถ้าบทสนทนาไปได้ดีและต่อเนื่องไปตามธรรมชาติ การขอที่ใหญ่กว่านั้นบางครั้งก็โผล่มาทีหลัง จากฝั่งอีกคนเอง แต่ message เปิดบทสนทนามีสิทธิ์ได้รับคำตอบก็เพราะมันเล็ก เฉพาะเจาะจง และตอบง่ายจริง ๆ เท่านั้น

10. งานในวงการเกมถูกประกาศอยู่ที่ไหนบ้าง

งานสายโปรแกรมมิ่งเกมระดับจูเนียร์มักโผล่อยู่ในไม่กี่ที่ที่พอเดาได้

• เว็บหางานเฉพาะทางในวงการเกม — เว็บที่สร้างมาเพื่อวงการเกมโดยเฉพาะ ซึ่งมักมี noise น้อยกว่าเว็บหางานทั่วไป
• job board ของ itch.io และเว็บลิสต์งานแนวอินดี้อื่น ๆ ที่มักเอนไปทางสตูดิโอเล็ก ๆ ที่เต็มใจรับจูเนียร์ที่มี portfolio แข็งแรงแม้ไม่มีประวัติทำงานมืออาชีพเลยก็ตาม
• เว็บหางานทั่วไป (LinkedIn และอื่น ๆ) มีประโยชน์หลัก ๆ ในเรื่องปริมาณและการหาข้อมูลบริษัท แต่มีคู่แข่งต่อประกาศงานมากกว่ามาก
• หน้า career ของสตูดิโอเอง เข้าไปดูตรง ๆ คุ้มค่าที่จะเข้าไปดูแม้ไม่มีตำแหน่งเปิดระบุไว้ — บางสตูดิโอ โดยเฉพาะสตูดิโอเล็ก ๆ มีข้อความ "always open to strong junior applicants" ค้างไว้ตลอด หรือบางทีก็รับใบสมัครที่ไม่ได้ตอบประกาศไหนเลยเงียบ ๆ ถ้า portfolio ของเราไปเข้าตา recruiter ภายในโดยบังเอิญ
• คอมมูนิตี้ทำเกมในพื้นที่หรือภูมิภาค — Discord server, forum, ชมรมทำเกมในมหาวิทยาลัย — ที่สตูดิโอขนาดเล็กถึงกลางบางทีก็ประกาศงานตรงไปยังคอมมูนิตี้แทน (หรือก่อน) จะประกาศบนบอร์ดสาธารณะ
• งานประชุมและ expo ที่มักมี job board กับบูธของตัวเองควบคู่ไปกับงาน

cold application (การสมัครตรงไปยังสตูดิโอโดยไม่มีตำแหน่งเปิดระบุไว้และไม่มีคนติดต่อไว้ก่อนเลย) แทบไม่ได้ผลกับสตูดิโอใหญ่ที่มีโครงสร้างชัดเจน เพราะปกติเขาจะรับคนผ่าน pipeline ทางการที่ผูกกับตำแหน่งเปิดจริงเท่านั้น แต่มันได้ผลบ่อยกว่ามากกับสตูดิโอเล็กหรืออินดี้ ที่บางทีรับคนแบบฉวยโอกาสทันทีที่ portfolio ที่แข็งแรงและตรงกับที่ต้องการไปตกอยู่ตรงหน้าคนที่ถูกต้อง ไม่ว่าจะมีตำแหน่งเปิดหรือไม่ก็ตาม

11. สมัครงานตอนที่ยังเป็นมือใหม่: เส้นทาง Junior, Intern และ QA-to-Programmer

มีเส้นทางเข้าสู่งานโปรแกรมมิ่งงานแรกที่สมจริงอยู่สามเส้นทาง และควรรู้จักทั้งสามเส้นทาง ไม่ใช่จดจ่ออยู่แค่เส้นทางที่มองเห็นชัดที่สุดเส้นเดียว

ตำแหน่ง Junior / Graduate Programmer

เส้นทางที่ตรงที่สุด และก็เป็นเส้นทางที่มีตำแหน่งเปิดน้อยที่สุดและคู่แข่งต่อตำแหน่งมากที่สุดด้วย — โดยเฉพาะที่สตูดิโอใหญ่ ๆ ที่มีชื่อเสียงและมี graduate program เป็นระบบ ตำแหน่งพวกนี้มีอยู่จริงและคุ้มค่าที่จะสมัคร แต่ให้มองว่ามันเป็นแค่หนึ่งในสามเส้นทาง ไม่ใช่แผนเดียว

Internship

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

QA (Quality Assurance) Tester แล้วขยับเข้าไปเป็นโปรแกรมเมอร์ภายในองค์กร

เส้นทางจริงที่พบได้บ่อยมากแต่มือใหม่มักประเมินค่าต่ำไป QA (Quality Assurance) testing — การเล่นเกมอย่างเป็นระบบเพื่อหาและรายงานบั๊กก่อนปล่อยเกม — มีมาตรฐานเข้าง่ายกว่าตำแหน่งโปรแกรมมิ่งมาก และมีตำแหน่ง QA เปิดมากกว่าตำแหน่งโปรแกรมมิ่งจูเนียร์ที่สตูดิโอส่วนใหญ่ พอเข้าไปข้างในแล้ว เราจะได้เรียนรู้ codebase เครื่องมือ และคนจริง ๆ ของสตูดิโอนั้น และกลายเป็นคนที่คนอื่นรู้จักและเชื่อใจได้ก่อนที่เราจะสมัครตำแหน่ง engineering ภายในองค์กรด้วยซ้ำ โปรแกรมเมอร์เกมที่ทำงานอยู่จริงหลายคนมาจากเส้นทางนี้เป๊ะ ๆ มันช้ากว่า และมันได้ผลก็ต่อเมื่อเราเอางาน QA เองไปทำอย่างจริงจังและทำได้ดี การเข้าไปทำงานโดยหวังว่าจะรอเฉย ๆ จนกว่า "อะไรที่ดีกว่า" จะเปิดขึ้นมา คนรอบตัวจะมองออก และมันขัดกับจุดประสงค์ทั้งหมดของเส้นทางนี้เลย

สตูดิโอเล็ก ๆ คุ้มค่าที่จะสมัครก่อนด้วยเหตุผลที่เป็นรูปธรรม ไม่ใช่แค่เพราะเข้าง่ายกว่า: ผู้สมัครต่อตำแหน่งน้อยกว่า การตัดสินใจจ้างเร็วกว่า (บางทีเป็นสัปดาห์แทนที่จะเป็นเดือน) และความรับผิดชอบวันแรกที่กว้างกว่า — ที่ทีมเล็ก เราแตะระบบหลายอย่างมากกว่าและเรียนรู้เร็วกว่าเพราะไม่มีใครอื่นให้ส่งงานต่อ ผลงานที่ shipped จริงจากสตูดิโอเล็กเป็นบรรทัดที่แข็งแรงกว่าในการสมัครงานครั้งต่อไปของเรา มากกว่าโปรเจกต์ส่วนตัวที่ยังทำไม่เสร็จอีกอัน แม้สตูดิโอนั้นจะไม่ใช่ชื่อที่คนรู้จักทั่วไปก็ตาม

12. Application Funnel: ตัวเลขที่สมจริง การถูกปฏิเสธ และความเงียบ

application funnel คือลำดับขั้นตอนที่ใบสมัครผ่านไป โดยจำนวนใบสมัครจะลดลงในแต่ละขั้น การเห็นตัวเลขที่สมจริงล่วงหน้าเปลี่ยนความรู้สึกตอนที่เราอยู่ในกระบวนการนี้จริง ๆ ตัวเลขข้างล่างเป็นตัวอย่างประกอบ ไม่ใช่คำสัญญาหรือการรับประกัน — แต่ รูปร่าง ของ funnel ที่แคบลงอย่างมากในทุกขั้น ใกล้เคียงกับสิ่งที่ปกติสำหรับการหางานจูเนียร์ครั้งแรก

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

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

13. Routine การสมัครงานรายสัปดาห์ที่ทำต่อเนื่องได้จริง

การหางานสำหรับตำแหน่งโปรแกรมมิ่งงานแรกมักใช้เวลาเป็นเดือน ไม่ใช่สัปดาห์ routine ที่ทุ่มสุดตัวสองสัปดาห์แล้วพังเพราะหมดแรงให้ผลลัพธ์แย่กว่า pace สม่ำเสมอเล็ก ๆ ที่รักษาไว้ได้นานเท่าที่ต้องใช้ เป้าหมายของ routine ไม่ใช่ความพยายามสูงสุดรายวัน — แต่คือ pace ที่เรารักษาได้จริงโดยไม่หยุดไปเงียบ ๆ

Routine

นิสัยหนึ่งที่คุ้มค่าเพิ่มเข้าไปในตัว routine รายวัน: ติดตามทุกใบสมัครใน spreadsheet ง่าย ๆ — สตูดิโอ ตำแหน่ง วันที่สมัคร tailor แล้วหรือยัง ลิงก์ไหนส่งไป วันที่ follow up และผลลัพธ์ หลังจากผ่านไปหนึ่งหรือสองเดือน spreadsheet นั้นจะกลายเป็นเครื่องมือวินิจฉัยจริง ๆ: ถ้าอัตราการตอบกลับต่ำ ปัญหาน่าจะอยู่ที่ CV หรือการ tailor ถ้าได้รับการตอบกลับแต่แปลงเป็น interview น้อย ปัญหาน่าจะอยู่ที่การฝึกซ้อม technical interview ถ้า interview ไปได้ดีแต่ offer ไม่มา อาจคุ้มค่าที่จะฝึกพูดถึงงานของเราออกเสียงให้คล่องขึ้น การเดาว่าขั้นไหนอ่อนแอเสียเวลาไปกับการปรับปรุงจุดผิด แต่ข้อมูลที่ติดตามไว้ไม่กี่สัปดาห์บอกเราตรง ๆ เลย

14. Glossary

• CV (resume) — เอกสารหนึ่งถึงสองหน้าที่รวมทักษะกับผลงานของเรา ใช้สมัครงาน "resume" คือคำที่สหรัฐฯ นิยมใช้เรียกเอกสารเดียวกัน
• Portfolio — เว็บส่วนตัวหรือหน้าเดียวที่รวมตัวอย่างผลงานของเรา ให้คนที่กำลังตัดสินใจว่าจะเรียกเราไป interview หรือไม่เข้ามาดู
• Playable build — เวอร์ชันเกมของเราที่เล่นได้จริง ต่างจากแค่คำบรรยายหรือ screenshot
• Cover note (cover letter) — ข้อความสั้น ๆ ที่ส่งไปพร้อมกับ CV อธิบายเฉพาะเจาะจงว่าทำไมเราสมัครสตูดิโอนี้และเรามีอะไรมาเสนอ
• Tailoring — การปรับคำใน CV หรือ cover note ให้เข้ากับประกาศงานเฉพาะอัน โดยสะท้อนคำของประกาศงานเองอย่างซื่อสัตย์ตรงที่มันจริงกับงานของเรา
• ATS (Applicant Tracking System) — ซอฟต์แวร์ที่หลายสตูดิโอใช้สแกน จัดอันดับ หรือกรองใบสมัครด้วยการจับคู่ keyword ก่อนที่มนุษย์จะอ่าน
• Keyword mirroring — การใช้คำเดียวกับที่ประกาศงานใช้เพื่อบรรยายข้อเท็จจริงจริงเกี่ยวกับงานของเรา เพื่อให้ทั้งมนุษย์และ ATS จำได้ว่าตรงกัน
• Cold application — การสมัครสตูดิโอที่ไม่มีตำแหน่งเปิดระบุไว้และไม่มีคนติดต่อไว้ก่อนเลย
• Warm introduction (referral) — การถูกชี้แนะไปยังตำแหน่งงาน หรือใบสมัครถูกทำเครื่องหมายไว้ โดยคนที่รู้จักผลงานเราอยู่แล้ว แม้จะรู้จักแบบหลวม ๆ
• Game jam — งานสั้น ๆ ที่จำกัดเวลา (ปกติ 48 ชั่วโมงถึงหนึ่งสัปดาห์) ให้คนมาสร้างเกมเล็ก ๆ บ่อยครั้งเป็นทีมที่รวมตัวกันเฉพาะสำหรับงานนั้น
• Devlog — บันทึกความคืบหน้าการพัฒนา (development log) อัปเดตสั้น ๆ ที่โพสต์สม่ำเสมอเพื่อแสดงความคืบหน้าของโปรเจกต์
• QA (Quality Assurance) tester — คนที่เล่นเกมอย่างเป็นระบบเพื่อหาและรายงานบั๊กก่อนปล่อยเกม เป็นจุดเข้างานที่พบได้บ่อยในสตูดิโอ
• Internship — ตำแหน่งจูเนียร์ระยะเวลาจำกัดที่ออกแบบมาสำหรับคนที่ยังไม่มีประสบการณ์ทำงานมืออาชีพ มักรับสมัครล่วงหน้าหลายเดือนก่อนวันเริ่มงาน
• Junior / entry-level role — ตำแหน่งที่มุ่งเป้าไปยังคนที่กำลังสมัครงานมืออาชีพครั้งแรกในสายนี้
• Live-ops — การดำเนินงานต่อเนื่องของเกมที่เปิดให้บริการแล้ว: อัปเดตเนื้อหา อีเวนต์ และการปรับสมดุลอย่างสม่ำเสมอ ต่างจากงานที่ shipped ครั้งเดียวจบ
• Application funnel — ลำดับขั้นที่ใบสมัครผ่านไป (สมัครแล้ว, ได้รับการตอบรับ, ได้ interview, ได้ offer) โดยจำนวนใบสมัครที่รอดถึงแต่ละขั้นจะลดลงเรื่อย ๆ
• Follow-up — ข้อความสั้น ๆ สุภาพครั้งเดียวที่ส่งหลังจากช่วงเวลาเงียบ เพื่อยืนยันความสนใจอีกครั้งและถามว่ามีความคืบหน้าไหม
• Ghosting (silence) — การไม่ได้รับการตอบกลับเลยต่อใบสมัคร ผลลัพธ์ที่พบบ่อยที่สุดในเกือบทุกขั้นของการหางาน ไม่ใช่คำตัดสินเกี่ยวกับความสามารถ
• Networking — การสร้าง visibility และความสัมพันธ์ที่จริงใจในวงการอย่างต่อเนื่องตามเวลา ต่างจากการขอความช่วยเหลือจากคนแปลกหน้าที่ไม่เคยติดต่อกันมาก่อน

15. แบบฝึกหัด

1. Built the inventory and pause-menu UI in Unity (C#) for a
   3-person team project, using the UI Toolkit; reduced menu
   input lag reported in playtests from noticeable to unnoticed.

2. Ran structured QA passes across a 6-week production cycle for
   a 5-person team, filing 60+ bug reports with repro steps;
   cut the pre-launch critical bug count from 14 to 0.

3. Built a custom Unity editor tool for placing and previewing
   collectible pickups in-scene without entering Play mode,
   cutting level-dressing time roughly in half for 2 designers.