‘Not a real engineer’ ไม่ใช่วิศวกรตัวจริง (2019)

 (twitchard.github.io)
1 คะแนน โดย GN⁺ 2023-12-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทกวีร้อยแก้วสั้น ๆ เริ่มจากคำประกาศว่า “You are not a real engineer” แล้วนำ การแจ้งผลไม่ผ่านการสัมภาษณ์ มาซ้อนทับในบริบทเดียวกับภาพของสัตว์ประหลาดในตำนาน
  • ผู้ถูกกล่าวถึงถูกวาดให้เป็น สิ่งมีชีวิตเหนือธรรมชาติ ที่สูงเท่ามนุษย์ มีหัวเป็นสิงโต มีปีกสิบหกปีก มีดวงตาหลายร้อยดวง และมีเข็มขัดเอวเป็นงู
  • ลมหายใจเหมือนเมฆพายุ เสียงเหมือนเสียงคำรามของสายลม และย่างก้าวที่ทำให้หญ้าเหี่ยวเฉา ยิ่งตอกย้ำพลังอัน overwhelming ของสิ่งนั้น
  • ตอนท้ายมีถ้อยคำปฏิเสธการรับเข้าทำงานว่า “ในขณะนี้จะยังไม่เสนอตำแหน่งนี้ให้” ตามด้วยเหตุผลว่า “กำลังมองหาคนที่มีความเป็นเทคนิคมากกว่า”
  • เมื่อแม้แต่สิ่งมีอยู่ที่ทำลายล้างได้ก็ยังถูกปฏิเสธด้วยเหตุผลว่าไม่ใช่ คนที่มีความเป็นเทคนิคมากกว่า ความไร้เหตุผลของมาตรฐานคำว่า “วิศวกรตัวจริง” จึงถูกเผยให้เห็น

คำบรรยายที่ขยายไปสู่สิ่งมีชีวิตในตำนาน

  • ประโยคเปิดคือ “You are not a real engineer” เป็นการประกาศตรง ๆ ต่อผู้ถูกกล่าวถึงว่า ไม่ใช่วิศวกรตัวจริง
  • จากนั้นผู้ถูกกล่าวถึงค่อย ๆ ถูกขยายเป็นสิ่งมีชีวิตที่มีรูปร่างมนุษย์และหัวสิงโต มีปีกสีขาวสิบหกปีก และมีดวงตาหลายร้อยดวงเหมือนคบเพลิง
  • เข็มขัดที่เอวเป็นงู ลมหายใจคือการรวมตัวของเมฆพายุ และเสียงใกล้เคียงกับเสียงคำรามของสายลม
  • เบื้องหน้าย่างก้าวของมัน หญ้าต่างเหี่ยวเฉา และลิ้นสีดำราวห้วงเหวลึกก็นำ จุดจบ มาสู่ทุกสิ่งที่สัมผัส

จุดหักมุมจากถ้อยคำปฏิเสธการรับเข้าทำงาน

  • ตอนจบพลิกจากคำบรรยายอันน่าเกรงขามไปสู่ถ้อยคำปฏิเสธอย่างสุภาพในกระบวนการจ้างงานแบบฉับพลัน
  • หลังคำว่า “ในขณะนี้จะยังไม่เสนอตำแหน่งนี้ให้” ก็มีเหตุผลต่อท้ายว่า “กำลังมองหาคนที่มีความเป็นเทคนิคมากกว่า”
  • เมื่อภาพเชิงตำนานก่อนหน้า collide กับ ประโยคปฏิเสธการรับเข้าทำงาน ธรรมดาในตอนท้าย ก็เผยให้เห็นความเปราะบางของคำว่า “วิศวกรตัวจริง”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-04
ความคิดเห็นจาก Hacker News

  • ช่วงนี้ผมเลิกคิดจะจ้างวิศวกรระดับอัจฉริยะมาทำตำแหน่งที่ 80% ของเวลางานคือการสร้าง แอปพลิเคชัน CRUD แล้ว
    มันเปลืองเงิน เปลืองพูลคนเก่ง ไม่ดีกับผู้สมัคร และเป็นความเสี่ยงระยะยาวต่อบริษัทด้วย คนแบบนั้นสุดท้ายก็มักจะเบื่อ แล้วเริ่มออกแบบเกินจำเป็นเพื่อให้ได้ใช้สมอง
    สำหรับวิศวกรส่วนใหญ่ แค่เขียนงานสร้าง·แก้ไข·ลบ·อ่านข้อมูลให้ถูกต้องในระดับฐานข้อมูลและ API เรียก API จากฟรอนต์เอนด์ และมีการจัดการข้อผิดพลาดที่เหมาะสมกับแนวทางดีบักที่พอใช้ได้ ก็เพียงพอแล้ว

    • ผมเคยเป็น hiring manager ให้หลายทีม แต่เรื่องนี้ไม่ได้ง่ายขนาดนั้น จริงอยู่ที่งานเทคนิคที่ไม่ใช่ระดับ John Carmack ไม่จำเป็นต้องใช้ John Carmack
      แต่ผมก็เคยเห็นโปรแกรมเมอร์ที่ “พอใช้ได้” ทำผลงานได้แค่ “พอถูไถ” และก็เคยเห็นโปรแกรมเมอร์ที่ดีกว่าทำงานได้ เร็วกว่า 5 เท่า โดยไม่ต้องใช้เวลาทำงานนานขึ้น 5 เท่า แทบจะบริหารตัวเองได้เอง ไม่ต้องให้ QA คอยตามเช็กว่าทิกเก็ตที่ปิดไปนั้นจบจริงไหม และเมื่อเกิดปัญหาก็แก้ได้อย่างสร้างสรรค์โดยไม่ต้องให้ใครไปคลี่ Git repository แทน
      ไม่จำเป็นต้องถึงขั้นสมองกระจัดกระจายเกินไป แต่โปรแกรมเมอร์ที่ดี/ยอดเยี่ยมสร้างความแตกต่างได้มาก แม้ในโปรเจกต์ที่ดูธรรมดาในเชิงเทคนิค
    • ในโลกของ SPA และไมโครเซอร์วิส ทุกวันนี้ คนที่เพิ่งพูดถึงนั่นแทบจะเป็นคำอธิบายของวิศวกรระดับอัจฉริยะแล้ว

  • ช่วงหลังผมอินกับ Steve Howe และเห็นว่าเขาซึ่งถูกนับเป็นหนึ่งในมือกีตาร์ที่ดีที่สุดตลอดกาล เคยพูดทำนองว่าอยากให้นักกีตาร์โฟกัสกับการเป็นนักเล่นดนตรี ความต่างระหว่าง coder กับ engineer ก็คล้ายกัน
    ผมเคยเห็นโปรแกรมเมอร์ที่เก่งทางเทคนิคกว่าผมหลายคน แต่พวกเขาไม่ได้เป็นวิศวกรที่ดีกว่า ปัจจัยสำคัญคือผมเป็นผู้ก่อตั้งธุรกิจและมีพื้นฐานด้านการตลาดอยู่บ้าง
    หลายบริษัทประเมิน ทักษะที่ไม่ใช่การเขียนโค้ด ซึ่งทำให้คนคนหนึ่งเป็นวิศวกรจริง ๆ ต่ำเกินไป เหมือนจ้างคนขายเนื้อแทนเชฟ แล้วสงสัยว่าทำไมอาหารถึงไม่อร่อย

    • ก็จริงในระดับหนึ่ง แต่โดยทั่วไปแล้วมันค่อนข้างขัดกับลักษณะมาตรฐานของคนที่เข้าสู่งานวิศวกรรม
      การจบปริญญาตรีสายเทคนิค แล้วไปทำงานที่อย่าง Ingersoll Rand หรือ Boeing ในฐานะวิศวกร #52354 เป็นผู้เชี่ยวชาญในโดเมนที่ซับซ้อนแต่จำกัด แล้วเกษียณหลัง 30 ปี ก็เป็นเส้นทางอาชีพที่ยอดเยี่ยมได้ นั่นก็เป็นนิยามของ “วิศวกร” ที่ใช้ได้เหมือนกัน และแม้คนแบบนั้นอาจดูน่าเบื่อ แต่ก็มีโอกาสสูงที่จะมีชีวิตที่เติมเต็มในระดับส่วนตัว
      ช่วงนี้ผมคิดเรื่องนี้บ่อย ผู้บริหารมักมอง วิศวกรมาตรฐาน เป็นศูนย์ต้นทุน ส่วนคนแบบในบทความนี้มีคุณค่าที่ต่อยอดเกินงานวิศวกรรมไปถึงแผนกอื่นที่สร้างรายได้โดยตรง จึงหลุดพ้นจากคำวิจารณ์แบบนั้นได้
      ผมเองก็น่าจะเป็นวิศวกรแนวคล้าย ๆ กัน แต่พยายามเปลี่ยนความดูแคลนต่อภาพจำแบบนั้นให้เป็นท่าทีที่ร่วมมือมากขึ้น
    • แต่นั่นแหละคือตลาด นายจ้าง 99% ไม่ได้ต้องการวิศวกร แต่ต้องการ coder ที่ใช้เฟรมเวิร์กใหม่ ๆ ราคาถูก
      ตลาดจริงให้ค่ากับ coder Spring Java สูงกว่าวิศวกร C++ ที่ทำงานกับฮาร์ดแวร์
    • มีตัวอย่างอะไรบ้างของทักษะที่ไม่ใช่การเขียนโค้ดที่ทำให้เป็นวิศวกรที่ดีขึ้น?
    • เสริมเล็กน้อย Howe เก่งมากและเป็นหนึ่งในสุดยอดก็จริง แต่ Paco De Lucia อยู่เหนือกว่าเยอะ

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

    • ผมได้เรียนรู้ว่าสิ่งสำคัญคือต้องเข้าใจว่า การสัมภาษณ์ และกว้างกว่านั้นคือการหางาน ไม่ใช่กระบวนการที่เป็นกลางและยุติธรรม ผลลัพธ์ก็ไม่ได้เด็ดขาดหรือทำซ้ำได้
      คนที่ objectively ดีกว่าอาจได้งาน หรือผู้สมัครในอุดมคติอาจถูกปัดตกตั้งแต่ phone screening ก็ได้ สุดท้ายมันใกล้เคียงกับเรื่องโชค และคนที่บอกว่าไม่ใช่ก็มักมีทั้ง survivor bias และความไม่อยากยอมรับว่ากระบวนการเองมีข้อบกพร่องปนอยู่
      การตัดสินทำนองว่าผู้สมัครมีประสบการณ์ยังทำโจทย์ระดับ FizzBuzz ไม่ได้ ก็สะท้อน ความคิดแบบ cargo cult ที่รบกวนการจ้างงานอยู่เช่นกัน ผมรู้จักวิศวกร FANG ที่ต้องฝึก coding golf และคำถามอัลกอริทึม·โครงสร้างข้อมูลเป็นสัปดาห์ ๆ ซึ่งไม่ได้คล้ายงานวิศวกรรมซอฟต์แวร์จริงเลย เพื่อผ่านสัมภาษณ์รอบแรก
      ผมถึงขั้นคิดว่าปัญหาเหล่านี้ใกล้เคียงกับการเตะบันไดทิ้งมากกว่าการประเมินทักษะเทคนิคเสียอีก ครั้งหนึ่งผมเคยถูกคัดออกอัตโนมัติจากตำแหน่ง C++ ทำเดสก์ท็อปแอป เพราะไม่รู้จัก placement new และคนรู้จักที่สมัครตำแหน่งแบ็กเอนด์ก็สร้าง Spring service ตั้งแต่ศูนย์จน integration test ผ่านทั้งหมด แต่ถูกปฏิเสธเพราะไม่มีคอมเมนต์ใน controller มีผู้สัมภาษณ์ที่เอาเรื่องซึ่งแก้ได้ด้วยคอมเมนต์หนึ่งบรรทัดใน PR มาทำเหมือนเป็นโจทย์เทคนิคใหญ่โตแล้วใช้คัดคนออก

  • คนที่จ้างงานก็ทำพลาดเหมือนกัน การจ้างคนให้สำเร็จเป็นเรื่องยากจริง ๆ
    บางครั้งมันก็ช่วยคุณให้พ้นจากที่ทำงานร่วมกับคนที่คุณคงไม่ได้ชอบอยู่ดี พวกเขาก็ไม่ได้เก่งนักในการสร้างข้ออ้างที่ฟังขึ้นว่าทำไมถึงไม่จ้าง และส่วนใหญ่ก็เป็นเรื่องโชค
    เช่น อาจรู้สึกว่า “ดูไม่เหมือนผู้สนับสนุนทรัมป์” เลยคิดว่าคงเข้ากันแบบสบาย ๆ ไม่ได้ ถ้าคุณไม่ใช่พวกเดียวกับเขาจริง ๆ จะมีเหตุผลอะไรที่อยากทำงานที่นั่นนักหนา?
    การหางานทำให้ผมหดหู่เสมอ และผมก็ไม่รู้คำตอบอื่นนอกจากอย่าไปตั้งความหวังกับงานใดงานหนึ่งมากเกินไป ขณะเดียวกัน โอกาสที่ดูไม่ได้น่าทึ่งนักก็ไม่ควรมองข้ามง่ายเกินไป
    หัวหน้าคนแรกในงานปัจจุบันของผมแย่มาก และคนดี ๆ ก็มีไม่เยอะ แต่พวกเขาออกจากบริษัทไปแล้ว และผมก็ได้เลื่อนตำแหน่ง เรื่องแบบนี้จะคาดเดาได้อย่างไร ผู้สรรหาก็คาดเดาคุณไม่ได้เหมือนกัน ทั้งกระบวนการค่อนข้างสุ่มและชวนอึดอัด
    เวลาผมเป็นฝ่ายสัมภาษณ์ ผมมีลำดับความสำคัญ ข้อแรก หัวหน้าผมเคยแนะนำสั้น ๆ ว่า “พยายามจ้างคนดี ๆ” ผมอยากทำงานกับนักพัฒนาที่ดี เป็นคนใจดี ช่วยเหลือกัน และเข้ากันได้ มากกว่าคนที่เชื่อว่าทุกอย่างต้องเป็นไปตามใจตัวเอง และตัวเองเป็นอัจฉริยะที่ผลิตผลงานได้มหาศาลจนควรมีอำนาจเต็ม
    ข้อสอง ผมดูว่าผู้สมัครสนใจซอฟต์แวร์ หรืออย่างน้อยสนใจอะไรบางอย่างหรือไม่ ถ้าไม่มีความกระตือรือร้นแม้แต่นิดเดียวต่อซอฟต์แวร์ เทคโนโลยี หรืออะไรบางอย่างที่เกี่ยวข้องกับงาน แล้วเขาจะเรียนสิ่งจำเป็นที่ไม่มีอยู่ในเรซูเม่ได้อย่างไร คนไม่ได้มาเป็น “ผลิตภัณฑ์สำเร็จรูป” แต่ควรคาดหวังว่าต้องเรียนรู้

    • ถามว่าถ้าไม่ใช่พวกเดียวกับเขาจริง ๆ แล้วจะอยากทำงานที่นั่นทำไม? ก็เพราะต้องจ่ายค่าเช่าไง บางครั้งก็อยากกินอาหารเป็นความฟุ่มเฟือยด้วย

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