ความรู้สะสมหลายปีเริ่มเป็นข้อจำกัดน้อยลง
Rieseberg เคยทำงานที่ Notion, Stripe, Slack และ Microsoft ตอนนี้ดูแลงานวิศวกรรมของ Claude.ai, Cowork และ Claude Code Desktop เขาเล่าว่าเดือนนี้เลิกให้ผู้สมัครสอบเขียนโค้ดแล้ว ข้อสอบแบบนี้เคยบอกอะไรได้บ้าง แต่ตอนนี้ไม่บอกแล้ว
สิ่งที่เขาเห็นในทีมคือคนใหม่ค่อนข้างแซงคนที่อยู่มานานและน่าจะเขียนโค้ดเก่งกว่าได้ ผลงานไม่ได้ติดอยู่ที่ความรู้เรื่อง framework ที่สะสมมาหลายปีเท่าเดิม จึงเป็นที่มาของชื่อบทความ "Hunger beats tenure" ความอยากทำชนะอายุงาน
เขาบอกด้วยว่าคำว่า junior ไม่ค่อยตรงนัก สิ่งที่พูดถึงจริง ๆ คือคนที่ยังไม่มีสถานะหรืออำนาจในองค์กร ซึ่งบางคนอาจไม่ได้เด็กเลย
คนมาใหม่เห็นสิ่งที่คนเก่าเลิกสังเกตไปแล้ว
เรื่องที่เล่าแล้วเห็นภาพที่สุดมาจาก Notion ตอนนั้นคนในบริษัทเชื่อกันว่าโหมด offline ทำไม่ได้ ด้วยเหตุผลสองข้อ คือโครงสร้างข้อมูลซับซ้อน และ CEO คงไม่ยอมให้ดาวน์โหลดทีละหน้า ข้อแรกจริง ส่วนข้อหลังไม่มีใครเคยถาม Rieseberg ลองถามแล้วพบว่าไม่จริง
อีกเรื่องเป็นฝั่งที่เขาพลาดเอง เขาเคยอยากได้จอทีวีสำหรับ dashboard ในทีม ติดขั้นตอนในองค์กรจนเลิกไป ปีต่อมาพนักงานใหม่อยากได้แบบเดียวกัน เขาบอกว่าอย่าเสียเวลาเลย แต่คนนั้นถามไปแล้ว และจอมาส่งวันรุ่งขึ้น เขาสรุปว่าตัวเองกลายเป็นคนเก่าในองค์กรภายในปีเดียว
ของที่ทำงานได้แทนตำแหน่งได้แล้ว
ข้อเสียของคนใหม่คือไม่มีใครฟัง ที่ผ่านมาการทำไอเดียหนึ่งต้องใช้คนและเวลามาก บริษัทจึงเดิมพันกับคนที่มีสถานะแล้วเท่านั้น และถึงบริษัทจะเชียร์ AI ก็มักคาดหวังให้ junior ทำงานที่ได้รับมอบหมายให้เร็วขึ้นเท่านั้น
ข้อเสนอของเขาอยู่ในประโยคสั้น ๆ ว่า "Execution isn't expensive anymore" พอลงมือทำได้ถูกลง คนใหม่ก็ไม่ต้องรอให้ใครอนุมัติก่อน เขาทำของให้เห็นได้เลย
ห้าข้อที่เขาแนะนำ
- เริ่มจากผลต่อธุรกิจก่อน backlog ดูว่าส่วนไหนของบริษัทหาเงิน และเป้าหมายของหัวหน้าของหัวหน้าคืออะไร เขายกคำของ Patrick McKenzie ที่ว่าเราจ้างวิศวกรมาสร้างมูลค่าให้ธุรกิจ ไม่ได้จ้างมาเขียนโปรแกรม
- เลือกไอเดียที่กล้าหน่อย คิดไว้สองสามข้อที่เพิ่มโอกาสถึงเป้าหมายนั้นได้มาก
- ทำให้เสร็จในสุดสัปดาห์เดียว เขาเห็นคนหรือทีมเล็ก ๆ ข้ามเอกสาร PRD และการขอคนจากทีมอื่น ด้วย prototype ที่ใช้งานได้จริง
- เอาไอเดียเดียว คนใหม่มักใส่ทุกอย่างใน prototype เดียว ไอเดียดีสามข้อจึงจมอยู่ในไอเดียแย่ยี่สิบข้อ เป้าหมายของ prototype คือให้ผู้บริหารเห็นทั้งโอกาส และเห็นว่าเราทำต่อได้
- ใช้สายตาคนนอกให้คุ้ม คนที่เพิ่งเข้ามาเข้าใจผู้ใช้ได้ดีกว่าคนที่อยู่ในบริษัทนานจนชิน และในงาน infrastructure ก็ยังไม่รู้ว่าอะไรเขาว่าทำไม่ได้
เขาปิดด้วยตัวอย่างจาก Anthropic คนในทีมชินกับ Claude Code แบบ CLI จนต้องเป็นวิศวกรที่ค่อนข้างใหม่สองคนทำ prototype หน้าจอแบบ graphical ในสุดสัปดาห์เดียว แล้วรุ่นแรกก็ออกสู่สาธารณะในอีกประมาณแปดวัน
ส่วนการสัมภาษณ์ เขายอมรับว่ายังหาวิธีวัดฝีมือการสร้างของด้วย AI ไม่ได้ ตอนนี้ดู resume กับ portfolio หา prototype เล็ก ๆ ที่เห็นรสนิยม ความเข้าใจผู้ใช้ และการคิดอย่างมีหลักการ
บริบทของเขาต่างจากทีมเล็กในไทย
ควรอ่านโดยจำไว้ว่าผู้เขียนทำงานในบริษัทที่ขาย Claude และยกตัวอย่างจากบริษัทเทคโนโลยีใหญ่ที่มีชั้นผู้จัดการหลายชั้น บริษัทหรือทีมเล็กในไทยมักไม่มีชั้นพวกนั้นให้ข้าม คนทำงานอยู่ใกล้เจ้าของและลูกค้าอยู่แล้ว ข้อ 1 กับข้อ 4 จึงใช้ได้เลย เมื่อทำระบบให้ร้านค้าหรือบริษัทหนึ่ง การรู้ว่าเงินเข้าทางไหนและงานไหนกินเวลาคนมากที่สุดมีค่ากว่าการเก็บ ticket ให้หมด
ข้อที่ต้องระวังคือ prototype สุดสัปดาห์กับระบบที่ส่งมอบเป็นคนละเรื่องกัน ของที่ลูกค้าใช้กับเงิน ภาษี หรือข้อมูลส่วนบุคคลยังต้องมี test ต้องคิดเรื่องข้อมูลเก่า และต้องมีคนดูแลต่อ ตัวอย่างของเขาจบที่รุ่นแรกออกสู่สาธารณะในแปดวัน แต่บทความไม่ได้เล่าว่าต้องมีอะไรเตรียมไว้ก่อนหน้านั้นบ้าง ถ้าอยากเห็นอีกมุม Jason McCreary เล่าว่า test, static analysis และ CI เป็นสิ่งที่ทำให้เขาไว้ใจงานจาก agent ได้
ส่วนการเลิกสอบเขียนโค้ดก็น่าคิดสำหรับคนที่รับคนเข้าทีม ของที่เขาบอกว่าวัดไม่ได้แล้วคือทักษะที่ AI ทำแทนได้ แต่การตัดสินใจเองว่าจะเอาแบบไหนยังเป็นเรื่องของคน ซึ่งการถามให้ผู้สมัครอธิบายงานเล็ก ๆ ที่เคยทำเองและเหตุผลที่เลือกทางนั้น น่าจะบอกได้มากกว่าข้อสอบ
บทความเต็มสั้นและอ่านง่าย ลองอ่านได้ที่เว็บของ Felix Riesebergครับ
