ประสบการณ์ถูกปฏิเสธจากสัมภาษณ์แบบมอบหมายงานของ Kagi Search

 (bloggeroo.dev)
4 คะแนน โดย GN⁺ 2025-05-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เน้นย้ำถึงความไม่มีประสิทธิภาพของ take-home assignment ที่ใช้ในการ สัมภาษณ์นักพัฒนาซอฟต์แวร์ และปัญหา การสิ้นเปลืองเวลาของผู้สมัคร
  • ระหว่างกระบวนการสมัครงานกับ Kagi Search ได้พบกับ ข้อกำหนดงานที่กว้างและคลุมเครือเกินไป
  • เมื่อเสนอแผนการดำเนินงานที่เป็นรูปธรรม กลับพบว่า ผู้จัดการไม่มีฟีดแบ็กที่ชัดเจน และมีการสื่อสารที่ไม่มีประสิทธิภาพ
  • หลังส่ง โปรเจกต์ที่ตั้งใจพัฒนาอย่างมาก ก็รู้สึกว่าไม่ยุติธรรมจากการถูกปฏิเสธโดยไม่มีเหตุผลชัดเจน รวมถึงการเปลี่ยนเกณฑ์ประเมิน
  • เสนอทางเลือกสำหรับ กระบวนการจ้างงานที่ดีกว่า (เช่น การรีวิวโค้ดแบบเรียลไทม์) และชวนตั้งคำถามต่อการเรียกงานสัมภาษณ์แบบมอบหมายที่เกินพอดี

บทนำ

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

สมัครงานกับ Kagi Search

  • ได้ ส่งเรซูเม่ เพื่อสมัครตำแหน่งนักพัฒนาแบ็กเอนด์ของ Kagi Search
  • ความต้องการของตำแหน่งมีดังนี้
    • มีประสบการณ์สร้างระบบแบ็กเอนด์
    • ใช้งานภาษา Go ได้
    • มีประสบการณ์ขยายและดูแลระบบแบ็กเอนด์ขนาดใหญ่
    • สามารถทำงานร่วมกับเพื่อนร่วมทีม เช่น SRE ได้
    • เข้าใจเทคโนโลยีคอนเทนเนอร์ เช่น Docker

การแจ้งงานสัมภาษณ์และข้อกำหนด

  • หลังผ่านการคัดกรองเอกสาร ก็ได้รับอีเมลแจ้ง take-home assignment
  • หัวข้องาน: "สร้างอีเมลไคลเอนต์แบบเรียบง่ายที่ได้แรงบันดาลใจจากเทอร์มินัล"
    • เลือกได้ว่าจะทำเป็นเทอร์มินัลหรือเว็บแอป
    • ต้องมีฟังก์ชันพื้นฐานสำหรับดู/ส่งอีเมล
    • เลือกได้อย่างอิสระว่าจะใช้แบ็กเอนด์อีเมลจำลองหรือจริง (IMAP/POP ฯลฯ)
    • ต้องรองรับเฉพาะข้อความ plaintext ไม่จำเป็นต้องมี rich text
    • การส่งงาน: ต้องมี GitHub repository, เวอร์ชันที่ deploy แล้ว, และเอกสารวิธีติดตั้ง
  • ขาดแนวทางที่ชัดเจน และขนาดของโปรเจกต์ก็ค่อนข้างใหญ่
  • แต่ก็ยังตัดสินใจทำงานชิ้นนี้เพราะชื่อเสียงของบริษัท

การสื่อสารกับผู้จัดการ

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

ข้อเสนอและแผนงาน

  • แผนการดำเนินงาน:
    • เว็บแอปที่พัฒนาด้วย Go
    • deploy ผ่าน AWS ECS Fargate พร้อมใช้ SSL
    • เชื่อมต่อบริการส่งอีเมล Postmark
    • เพิ่มฟังก์ชันล็อกอิน/ยืนยันตัวตน
    • รับส่งอีเมลและแสดงผลบน UI
  • เหตุผลในการเลือกเทคโนโลยี:
    • ใช้เทคโนโลยีที่หลากหลายและเกี่ยวข้องกับบทบาทฝั่งแบ็กเอนด์
    • สร้างระบบจริงโดยใช้เครื่องมือ Infra-as-Code
    • ไม่ใช่แค่เชื่อมต่อ API แบบง่าย ๆ แต่ทำให้ใกล้เคียงบริการจริงมากขึ้น
  • องค์ประกอบหลักที่พัฒนา:
    • Pocketbase (backend/DB), TEMPL (เทมเพลต), Pulumi (IaC), Postmark (บริการอีเมล)
    • มีการทำ pagination, ระบบล็อกอิน ฯลฯ
    • Stretch Goal: ความเสถียร เช่น การสำรองและกู้คืนข้อมูล
  • สรุป: ได้อธิบายรายละเอียดและเหตุผลไว้อย่างเพียงพอล่วงหน้า และคาดหวังว่าจะได้รับการพิจารณาและคำตอบที่ชัดเจน

การตอบกลับจากผู้จัดการและปัญหาด้านการสื่อสาร

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

การลงมือทำโปรเจกต์

  • ได้พัฒนาครบทั้งตามข้อกำหนดและตามข้อเสนอที่วางไว้ โดยทุ่มเวลาเต็มหนึ่งสัปดาห์
  • ส่งทั้งวิดีโอเดโมโปรเจกต์, GitHub repository และเอกสารอย่างละเอียด

การแจ้งปฏิเสธและฟีดแบ็กที่ได้รับ

  • หลังได้รับอีเมลปฏิเสธแบบอัตโนมัติ เมื่อขอฟีดแบ็กก็ได้รับคำตอบว่า:
    • “มีผู้สมัครคนอื่นส่งผลงานที่แข็งแกร่งกว่า”, “การแข่งขันในการจ้างงานสูงมาก”
  • ประเด็นปัญหา
    1. หาก ชอบโซลูชันที่เรียบง่ายกว่า ก็น่าจะแจ้งไว้ได้ตั้งแต่แรก
    2. หาก ข้อเสนอมีจุดอ่อน ก็น่าจะให้ฟีดแบ็กได้ตั้งแต่ตอนนั้น
    3. แม้หลังปฏิเสธแล้ว ประกาศรับสมัครก็ยังคงเปิดอยู่ จึงมองว่าไม่ใช่แค่การแข่งขันธรรมดา แต่เป็นการเรียกร้องให้ผู้สมัครใช้เวลามากเกินไป
    4. หลังส่งโปรเจกต์แล้วกลับยกระดับข้อกำหนดให้เข้มขึ้นอีก จนเหมือนว่างานที่ส่งไปกลายเป็นการยกระดับมาตรฐานเสียเอง

บทสรุปและประเด็นปัญหา

  • วิธีการแบบนี้ ไม่ยุติธรรมต่อผู้หางานจำนวนมาก และอาจกระทบถึงความมั่นคงในการดำรงชีพจริง ๆ
  • เน้นว่าจำเป็นต้องกล้าปฏิเสธหรือตั้งคำถามกับ การเรียกงานที่มากเกินไปโดยไม่มีค่าตอบแทน
  • มี กระบวนการจ้างงานที่ดีกว่า เพื่อทดแทนงานแบบโปรเจกต์ เช่น การรีวิวโค้ดแบบเรียลไทม์
    • สามารถดูความสามารถในการแก้ปัญหาในการพัฒนาจริงได้ผ่านการรีวิวโค้ดแบบ asynchronous/synchronous
    • ชี้ให้เห็นช่องว่างระหว่างโจทย์สไตล์ Leetcode กับความต้องการในงานจริง
  • เรียกร้องให้ปรับปรุงวัฒนธรรม การทำให้ผู้หางานหมดไฟและการประเมินอย่างไม่เป็นธรรม

ข้อเสนอเพื่อกระบวนการจ้างงานที่ดีกว่า

  • เสนอทางเลือก เช่น การรีวิวโค้ดแบบเรียลไทม์ เพื่อ ประเมินความสามารถของนักพัฒนาได้อย่างมีความหมายมากกว่า
  • ย้ำว่าควรเปลี่ยนจากการเน้นแก้ปริศนาอัลกอริทึมแบบจับเวลา ไปสู่การประเมินความสามารถจริงและทักษะแก้ปัญหามากกว่า

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

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

 
GN⁺ 2025-05-16
ความคิดเห็นจาก Hacker News
  • ขอแสดงความคิดเห็นอย่างตรงไปตรงมาในมุมคนจ้างงาน โดยส่วนตัวไม่ชอบงาน take-home งานแบบนี้ทำให้เสียเวลาทุกฝ่าย ถ้าเป็นขั้นตอนสุดท้ายของการคัดเลือกก็พอเข้าใจได้ แต่การใช้เพื่อคัดคนออกตั้งแต่ต้นนั้นไม่มีประสิทธิภาพ
    1. มีคำถามเข้ามามากเกินไป ส่วนหนึ่งของงานคือการใช้วิจารณญาณแก้ปัญหาท่ามกลางความคลุมเครือ ถ้าดูจากเงื่อนไขที่ให้มา แค่ลงทุนสักวันสองวัน ทำโปรเจกต์โลคัลง่าย ๆ ระดับเล็กก็น่าจะพอแล้ว
    2. การเขียนและแชร์ข้อเสนอละเอียดเกินไปมาก ดูเหมือนผู้สมัครอยากแสดงความรอบคอบ แต่ในมุมบริษัทอาจมองว่าไม่มีประสิทธิภาพและสิ้นเปลืองเวลา
    3. ผลงานที่ออกมานั้นใช้งานได้ก็จริง แต่ลงแรงกับโครงสร้างพื้นฐานและการเก็บงานมากเกินไป พอไม่ผ่าน สุดท้ายก็กลายเป็นเสียเวลา
    4. เหมือนจะมีข้อกำหนดว่าเป็นอีเมลไคลเอนต์ที่ได้แรงบันดาลใจจากเทอร์มินัล แต่ในผลงานกลับมองไม่เห็นทิศทางนั้น
      ยอมรับในความสามารถและความหลงใหลในการทำงานของผู้สมัคร แต่อยากเสนออีกมุมมองหนึ่ง
    • รู้สึกว่าท่าทีของผู้เขียนบล็อกชวนให้ขัดใจเล็กน้อย แค่อ่านจากบทความก็ให้ความรู้สึกว่าคงทำงานด้วยยาก ตัดสินใจเองได้ไม่ค่อยดี และต้องการไกด์ไลน์ที่ชัดเจน เหมาะกับองค์กรใหญ่แต่ไม่ค่อยเหมาะกับสตาร์ตอัป
      “พัฒนาอีเมลไคลเอนต์ที่ได้แรงบันดาลใจจากเทอร์มินัลเพื่อให้ลูกค้าทดสอบอัลฟา” เป็นคำขอที่สมเหตุสมผลสำหรับวิศวกรสตาร์ตอัปช่วงเริ่มต้น ต่อให้มีสเปกเพิ่มอีก หลายอย่างก็ยังขึ้นอยู่กับการตัดสินใจของวิศวกรเอง ผู้สมัครดูต้องการความแน่นอนมากเกินไป
      การที่ผู้สมัครอยากรู้ล่วงหน้าว่า Kagi จะให้ฟีดแบ็กอะไรหลังส่งงานเสร็จ ไม่ใช่สัญญาณที่ดีนัก เพราะเป็นสถานการณ์ที่ให้คำตอบชัดเจนไม่ได้อยู่แล้ว พวกเขาน่าจะกำลังประเมินใบสมัครอยู่เป็นร้อยเป็นพัน
    • ผู้เขียนทำงานได้ดี แต่ล้มเหลวกับเงื่อนไขที่ไม่ได้พูดตรง ๆ ว่า “อย่าพยายามมากเกินไป”
      ถ้าไม่จำเป็นต้องขอให้ช่วยทำความชัดเจนข้อกำหนด งั้นก็คงไม่ต่างจากให้ “ทายเลข 1 ถึง 10” แล้วคัดคนที่เดาผิดออก
      ฉันไม่เห็นด้วยกับการคัดตกเพราะทุ่มเทกับงานและเก็บรายละเอียดดี
      งานกำกวมแบบนี้จริง ๆ แล้วก็เป็นอีกวิธีหนึ่งในการคัด “cultural fit” เท่านั้น
    • ฉันคิดว่าแนวทางของผู้สมัครที่พยายามตรวจสอบไอเดียของตัวเองคล้ายกับวิธีทำงานวิศวกรรมยุคนี้ ทีมที่ดีควรอธิบายเอกสารออกแบบฟีเจอร์เป็นภาษาอังกฤษ ขออนุมัติ แล้วค่อยลงมือทำ
      วัฒนธรรมแบบ “เขียนโค้ดก่อน ฟีดแบ็กค่อยว่ากัน” เป็นประสบการณ์ที่ทำร้ายเส้นทางอาชีพมากที่สุดอย่างหนึ่ง ผู้สมัครคนนี้ทำตามแนวปฏิบัติซอฟต์แวร์สมัยใหม่ (ฉันเป็นคนจ้างงานในบริษัทที่มีวิศวกรมากกว่า 1,000 คน)
    • ในมุมคนจ้าง งาน take-home ที่ฉันชอบคืองานที่ทำเสร็จได้ภายใน 30 นาที เกณฑ์ประเมินชัดเจน และเปิดให้มีหลายแนวทางพร้อมการชั่งน้ำหนัก trade-off
      ตอนหางานครั้งก่อนฉันเองก็เคยตกเพราะงาน take-home ที่กว้างมากจนไม่รู้ว่าส่วนไหนคือเกณฑ์ประเมิน หลังจากนั้นก็เกิดอาการต่อต้านงานแบบนี้อย่างหนัก
    • คิดว่าเหตุผลที่ตกคือข้อเสนอมีขนาดใหญ่เกินไป ในคำแนะนำก็ไม่ได้ขอข้อเสนอ และถ้าส่งรายละเอียดมากไปก็อาจถูกตีความกลับว่า “ขาดความสามารถในการขับเคลื่อนงานด้วยตนเอง” พอเป็นแบบนั้น คุณภาพโค้ดก็ไม่มีความหมายอีกต่อไป
      บริษัทไม่ควรปล่อยให้เสียเวลาไปมากกว่านั้น ควรจบงานตั้งแต่จุดนั้นจะดีกว่า
    • น่าเสียดายที่ทุกวันนี้วงการขาดความสามารถในการทำความเข้าใจ requirement จนกลายเป็นคัดนักพัฒนาด้วยความสามารถอ่านใจแทน
    • การที่ผู้สมัครส่งไม่ทันเดดไลน์ก็เป็นปัญหาเหมือนกัน การช้าโดยไม่มีคำอธิบายพิเศษก็ถือว่าตกแล้ว เป้าหมายของงานคือการออกแบบทางแก้ที่เหมาะสมภายในเวลาที่กำหนด
    • เรื่องข้อ 4 ที่พูดถึงเทอร์มินัล ในเวอร์ชันเต็มที่ผู้เขียนแชร์มีคำอธิบายส่วนนั้นอยู่
    • การถกเถียงแบบนี้พอมองจากผลลัพธ์แล้วมันพูดง่ายเสมอ ต่อให้ใช้กลยุทธ์ตรงข้ามคือไม่ยืนยัน requirement และทำแค่ขั้นต่ำ ผลก็อาจออกมาเหมือนกัน ในสถานการณ์แบบนี้ก็มีคนพูดในอีกทางได้เสมอว่า “ควรเชิงรุกกว่านี้ในการทำให้ requirement ชัดเจน”
  • หลังจากดูโค้ดและวิดีโอเดโมแล้ว ความรู้สึกคือใช้เวลาไปพอสมควรกับการทำเว็บแอปสองหน้าในหนึ่งสัปดาห์
    ฟีเจอร์อีเมลพื้นฐานที่สุดอย่างการเปิดเมลก็ยังไม่มี ทั้งที่สมัครตำแหน่งวิศวกรแบ็กเอนด์ แต่กลับใช้ผลิตภัณฑ์ภายนอกอย่าง postmark และ turso และยังขาดฟังก์ชันพื้นฐานอย่างการจัดรูปแบบ plain text การแสดงผล โฟลเดอร์ ฯลฯ
    มีฟีเจอร์เสริมอย่างหน้าแอดมินกับล็อกอินก็จริง แต่โครงสร้างข้อมูลขั้นต่ำอย่างแผนที่เมลเฮดเดอร์ก็ยังไม่มี
    อาจเป็นวิศวกรที่ดีได้ แต่ตัดสินว่าไม่เหมาะกับตำแหน่งนี้
    ข้อเสนอประกอบงาน take-home ก็ดูแปลกผิดปกติเกินไปด้วย
    พอกลับไปอ่านประกาศเดิมอีกครั้ง ก็เห็นว่าระบุชัดว่าเป็น “minimal terminal-inspired email client” และยก aerc, mutt, himalaya เป็น reference นี่ถือว่าเป็นการตีความ requirement ผิดอย่างชัดเจน
    • พอเห็นคำว่า “ตีความ requirement ผิด” ก็สงสัยว่าตกลงพลาด requirement ข้อไหนกันแน่
      ต้องการอีเมลไคลเอนต์แบบเทอร์มินัลหรือเว็บแอป พร้อมฟีเจอร์พื้นฐาน ซึ่งฉันคิดว่าเขาทำครบแล้ว
      ส่วนที่บอกให้ได้แรงบันดาลใจจากเครื่องมือแบบเทอร์มินัลนั้นเป็นเรื่องอัตวิสัย ถ้าเป็นตำแหน่งแบ็กเอนด์ การไปใส่ใจกับ UI มากอาจไม่มีประสิทธิภาพก็ได้
    • ผู้สมัครลงทุนเวลาไป แต่สุดท้ายได้เพียงอีเมลปฏิเสธฉบับเดียว มันเป็นเรื่องน่าเสียใจ
      ถ้าอย่างน้อยได้ฟีดแบ็กก็น่าจะช่วยให้เติบโตได้ แต่ในความจริงบ่อยครั้งก็ทำได้ยาก
      เลยยิ่งทำให้รู้สึกคาใจกับงาน take-home ผู้สมัครและคนจ้างควรเคารพเวลาของกันและกันมากกว่านี้
    • มีประโยคว่า “Email client can either be in the terminal (i.e. a TUI) or a web app” อยู่จริง
  • การประเมินแบบ take-home มีประโยชน์ แต่ต้องมีการจำกัดเวลาเสมอ
    แค่ 2–3 ชั่วโมงก็ประเมินผู้สมัครได้พอแล้ว ถ้ามีกรอบเวลา ผู้สมัครก็น่าจะเสนอวิธีแก้ที่เหมาะสมภายในกรอบนั้นได้ และบริษัทเองก็น่าจะสื่อได้ชัดว่าต้องการอะไร
    นอกจากนี้ บริษัทควรบอกให้ชัดว่าประเภทคำตอบเป็นแบบ ‘อะไรก็ได้’ หรือ ‘ต้องการคำตอบที่ดีที่สุด’
    เพราะเจตนาของงาน take-home อาจต่างกันไปว่าจะเน้นให้ผ่านการทดสอบ เน้นความครบของภารกิจ หรือเน้นคุณภาพโค้ด ผู้สมัครเลยอาจสับสนได้
    • ในมุมคนจ้าง คิดว่างานของ Kagi ใหญ่เกินไปและไม่ให้เกียรติเวลาของผู้สมัคร
      แถมยังเสี่ยงคัดคนที่ยุ่งและมีเวลาน้อยออกไปโดยไม่ตั้งใจ
      บริษัทเราจะให้โจทย์ ETL ง่าย ๆ แล้วจำกัดเวลาไว้ 4 ชั่วโมง
      แม้ทำไม่เสร็จก็ยังพอรับได้ และใน follow-up จะมีช่วงรีวิวโค้ดกับถามตอบ
      ความสามารถจริงดูได้จากการคุยต่อยอดหลังจากนั้น
    • ผู้สมัครอาจใช้เวลามากกว่าที่ระบุไว้จริงมาก แล้วคนจ้างจะรู้ได้อย่างไร
      ต่างจากงาน onsite ที่ทุกคนใช้เวลาเท่า ๆ กัน งาน take-home ทำให้แต่ละคนเสียเปรียบจากการจัดสรรเวลาที่ไม่เท่ากัน
      ถ้าอย่างนั้นทำ onsite coding 1 ชั่วโมงยังดีกว่า อย่างน้อยทั้งผู้สมัครและผู้สัมภาษณ์ก็ลงทุนเวลาเท่ากัน เป็นการเคารพคุณค่าของเวลาทั้งสองฝ่าย
    • ฉันคิดว่า live review ดีกว่า live coding มาก ถ้าจะทำ live coding จริง ๆ ก็อยากให้เป็นแบบใช้แล็ปท็อปของตัวเอง ทำงานอยู่ไกล ๆ 45 นาที แล้วค่อยกลับมารีวิวมากกว่า
  • จริงอยู่ที่คำตอบจากบริษัทไม่เป็นมิตรและไม่ค่อยช่วยอะไร แต่ใน requirement ก็ระบุคำว่า ‘ได้แรงบันดาลใจจากเทอร์มินัล’ ไว้อย่างชัดเจน
    ในวิดีโอเดโมกลับเห็นเพียงเว็บแอปทั่วไป ทั้งที่มีการระบุชัดให้ได้รับแรงบันดาลใจจากอีเมลไคลเอนต์เทอร์มินัลที่มีอยู่แล้วอย่าง aerc, mutt, himalaya
    เลยสงสัยว่าฉันพลาดอะไรไปหรือเปล่า
    • ถ้าในอีเมลปฏิเสธอธิบายเหตุผลให้ชัดกว่านี้ก็คงดีกว่า แต่ตั้งแต่การออกแบบโจทย์ก็กำหนดให้มี reference ของเทอร์มินัลไคลเอนต์โดยตรงอยู่แล้ว
      UX แบบเฉพาะของเทอร์มินัลไคลเอนต์ยังเป็นพื้นที่ที่ไม่มี “คำตอบที่ถูกต้อง” ชัดเจน จึงเป็นไปได้ว่าพวกเขาตั้งจุดนั้นไว้เป็นเกณฑ์ประเมิน
    • เมื่อเห็นว่าเน้นภาษา Go ก็ยิ่งสงสัยว่าการทำ CLI ใช้ไม่ถึง 20 บรรทัดแท้ ๆ ทำไมถึงเลือกไปทุ่มกับเว็บ GUI
    • มีคำแนะนำว่า “Email client can either be in the terminal (i.e. a TUI) or a web app”
  • เพิ่งเจอประสบการณ์คล้ายกันในการสัมภาษณ์ล่าสุด ส่งโปรเจกต์งานที่ดีมากไป แต่ไม่ได้มีการคุยถึงโปรเจกต์นั้นเลย กลับได้รับแจ้งไม่ผ่านทันที
    ฉันเชื่อว่าถ้าขอให้ทำงาน take-home ก็ควรต้องมีการนัด follow-up เสมอ
    ฉันใช้ Kagi แบบเสียเงินอยู่แล้ว แต่จากเรื่องนี้กำลังคิดจะยกเลิกบัญชี
    ถ้าไม่มีเวลาคุยกับผู้สมัครตั้งแต่แรก ก็ไม่ควรขอให้ทำงานแบบนี้เลย
    • งาน take-home ไม่ได้ต้องใช้แรงจากผู้สมัครอย่างเดียว แต่คนสัมภาษณ์ที่ประเมินก็ต้องใช้แรงมากเช่นกัน
      ถ้าถึงขั้นรีวิวแล้ว ฉันคิดว่าผู้สมัครก็ควรมีสิทธิ์ได้รับฟีดแบ็ก
      แต่ในความจริง เมื่อมีผู้สมัครเก่ง ๆ หลายสิบคนและต้องเลือกเพียงคนเดียว การไม่ผ่านก็ไม่ได้แปลว่า “ฝีมือไม่พอ” เสมอไป
      ในทางกฎหมายด้วย คำตอบอย่างเป็นทางการว่า ‘ทำไมเลือก A และไม่เลือก B’ มักลงเอยด้วยการหยิบจุดด้อยมาติเท่านั้น
    • คงจะดีกว่านี้ถ้าบริษัทเปิดเผยเกณฑ์ประเมินให้ชัด หรือให้ฟีดแบ็ก การเสียเวลาโดยไม่มีฟีดแบ็กจากความล้มเหลวเป็นสิ่งที่ยอมรับไม่ได้
      หลายบริษัทจัดการเรื่องนี้ได้ดีกว่า
    • ก็ยังสงสัยว่าเรียกได้ว่าเป็น “ทางออกที่ยอดเยี่ยม” จริงหรือไม่ เพราะดูเหมือนจะเมิน requirement เรื่องอีเมลไคลเอนต์แบบขั้นต่ำที่ได้แรงบันดาลใจจากเทอร์มินัลและ reference ที่ให้มาไปทั้งหมด
      ถ้าความเข้าใจ requirement คลาดเคลื่อนมาก การข้ามขั้นตอนพูดคุยต่อก็เป็นเรื่องที่เกิดขึ้นได้
  • กรณีนี้เป็นตัวอย่างคลาสสิกของการอ่านเจตนาแฝงในโจทย์ผิด
    บริษัทต้องการคนที่มีความเป็นอิสระและตั้งเป้าหมายให้ตัวเองได้
    ความคลุมเครือมีไว้เพื่อดูความสามารถของผู้สมัครในการสำรวจคำตอบจากหลายมุมและคลี่คลายมันออกมา
    • โจทย์นั้นตั้งใจไว้สำหรับคนที่สามารถส่งโซลูชันที่เรียบง่ายที่สุดแต่ยังฉลาดและใช้งานได้
      เพราะบริษัทที่ขับเคลื่อนด้วยโปรโตไทป์ย่อมมีคนบางแบบที่ไม่เหมาะ ผู้สมัครบางคนอาจคิดแค่ 10 นาทีแล้วทำสิ่งที่ดีที่สุดเท่าที่ทำได้ภายใน 60 นาที
    • ถ้าเป็นโปรเจกต์ R&D แล้วเอาแต่ย้ำว่า “ให้เล็กที่สุด” ก็ยังไม่รู้เลยว่านี่คือโปรโตไทป์หรือของสำหรับผู้ใช้จริง ต้องใส่ใจ UX แค่ไหน สุดท้ายก็กลายเป็นเกมเดาใจว่าผู้ประเมินให้ความสำคัญกับอะไร
    • ในงานแบบนี้ที่บอกว่า “ไปตีความเอาเอง” คนที่ไม่ถามเพื่อให้ requirement ชัดหรือไม่ถามคำถามเพิ่มก็อาจตกได้
      แต่สำหรับนักพัฒนา ความสามารถในการถามคำถามแบบนี้เป็นคุณสมบัติที่สำคัญมาก จึงยิ่งทำให้คาดหวังกับวิธีจ้างงานมากขึ้นและผิดหวังมากขึ้น
    • ฉันคิดว่า “misreading the subtext” นั้นจริง ๆ แล้วมีเขียนอยู่ใน requirement เลย
    • ในวงการการศึกษา การโทษแต่นักเรียนว่า “ไม่เข้าใจ” เป็นข้อสรุปที่ง่ายเกินไป
      ทั้งที่สาเหตุจริงคือคำอธิบายที่กำกวม
      ครูที่ยอดเยี่ยมจะทำให้คนเข้าใจได้มากที่สุดเท่าที่จะทำได้ ถ้ามีนักเรียนสับสนจำนวนมาก ปัญหาก็อยู่ที่คนออกโจทย์
      นักศึกษามหาวิทยาลัยไม่ควรถูกคาดหวังให้แก้โคอันแบบพระเซน
  • เนื่องจากผู้เขียนมาโพสต์เอง ฉันอยากอธิบายบริบทจากประสบการณ์ที่เคยทำงานที่ Kagi
    เมื่อก่อน Vlad เป็นคนประเมินผู้สมัครเอง และโจทย์ก็เป็นสไตล์นี้
    พอบริษัทโตขึ้น ดูเหมือนตอนนี้คนอื่นเป็นผู้ประเมินแล้ว
    Vlad มีรสนิยมแบบ HN และอยากร่วมงานกับผู้สมัครที่เขารู้สึกว่า “เท่”
    เช่น ถ้าเขียนเอกสารออกแบบยาว ๆ ว่า “จะใช้ Galactor และโปรเจกต์นี้พร้อม flop แล้ว” มันจะให้ผลตรงกันข้ามโดยสิ้นเชิง
    กับ requirement เรื่อง “ได้แรงบันดาลใจจากเทอร์มินัล” เขามักคาดหวังรายละเอียดระดับคีย์ลัดคีย์บอร์ดและองค์ประกอบต่าง ๆ แบบที่แอปเทอร์มินัลจริงมี
    จะบอกว่านี่เป็นตัวกรองที่ดีหรือไม่ก็ยังถกเถียงกันได้ แต่ถ้าคุณเข้าใจบริบทนี้และมีศักยภาพจะผ่าน งานนี้ก็คงดูง่าย
    อยากให้ Kagi สื่อสารบริบทนี้ให้ดีขึ้น เสียดายที่เสียเวลาไป แต่หวังว่าคุณจะเจอบริษัทที่เหมาะกับสไตล์ของคุณ
    • หลายบริษัทมักมองหาคนที่คิดแบบเดียวกับตัวเอง
      ทีมที่ขาดความหลากหลายอาจติดอยู่กับกำแพงเดิม ๆ และไปต่อไม่ได้
      ฉันคิดว่าปรากฏการณ์นี้พบได้บ่อยโดยเฉพาะในสตาร์ตอัป และเกี่ยวข้องกับเหตุผลที่ 9 ใน 10 ล้มเหลว
    • รู้สึกว่าปัญหาคือ Vlad ทำให้คนจำนวนมากเสียเวลาเกินไปเพื่อหาคนที่ “เท่”
      งานที่ให้คะแนนโดยไม่มีเกณฑ์ชัดเจนเป็นเรื่องไม่ยุติธรรม
      สุดท้ายก็ไม่ต่างจากโจทย์แฝงที่ให้ “เดาคำตอบในหัวฉัน”
      มันให้ความรู้สึกว่าไม่ค่อยใส่ใจผู้คนเท่าไร
    • มีคำถามว่า “ฉันจำเป็นต้องรู้เรื่องพวกนี้ล่วงหน้าจริง ๆ เหรอ?”
      ถ้าวัฒนธรรมเป็นแบบนี้ ทุกคนต้องไปสืบข้อมูลแบบสายลับกันเองหรืออย่างไร
      ถ้าผู้สมัครแบบ “ไม่เท่” อย่างฉันได้รับสัญญาณที่ชัดเจนและรีบไปหาบริษัทอื่นได้ ก็น่าจะดีกว่า
  • หลังจากลองรีวิวโค้ดด้วยตัวเอง ตั้งแต่ไฟล์แรกก็เห็นคอมเมนต์ที่เหมือนคัดลอก sample code มาโดยไม่มีจุดประสงค์ คำอธิบายที่ไม่สอดคล้องกัน และถ้อยคำที่สะท้อนถึงการขาดความรอบคอบ
    รายละเอียดที่ตกหล่นแบบนี้ทำให้ฉันจะหยุดรีวิวต่อ
    • แอปนี้ถูก deploy บนโดเมนของฉันเองและไม่มีปัญหาเรื่องประสิทธิภาพ ส่วนที่เป็นงานแบ็กเอนด์อย่าง authentication และ infrastructure ก็ทำได้ดี แต่ฉันไม่เห็นด้วยกับคำวิจารณ์ที่ว่าควรใส่ใจคอมเมนต์ในโค้ดให้มากกว่านี้
    • ประเด็นสำคัญในกรณีนี้ไม่ใช่การไม่ผ่าน แต่คือกระบวนการจ้างที่ไม่มีไกด์ไลน์ชัดเจนและไม่ให้ฟีดแบ็กเลย ซึ่งไม่ให้เกียรติเวลาของผู้สมัครแม้แต่น้อย
  • เคยมีประสบการณ์คล้ายกันกับ DuckDuckGo แต่ได้รับค่าตอบแทนเล็กน้อยในทุกขั้นตอนของการสมัคร
    ตั้งแต่ข้อเสนอด้านดีไซน์แบบง่าย ๆ ไปจนถึงงานลงมือทำจริง ทุกอย่างมีการจำกัดเวลาอย่างชัดเจน
    สุดท้ายก็ไม่ผ่าน และไม่ได้รับเหตุผลที่ชัดเจน
    แม้น่าจะเป็นเพราะมีผู้สมัครเยอะมาก แต่ประสบการณ์แบบนี้ก็ยังทิ้งร่องรอยทางอารมณ์ไว้นาน ฉันเข้าใจความรู้สึกของ OP
  • ขอมองในฐานะผู้สัมภาษณ์สายวิศวกรรม ทั้ง leetcode และ take-home ต่างก็ใช้เวลามากและให้ข้อมูลไม่มากพอ
    แต่ถ้าฉันเป็นคนจ้าง ก็คงไม่รับผู้เขียนเหมือนกัน
    สตาร์ตอัปต้องการคนที่ทำงานได้รวดเร็วและใช้วิธีที่ปฏิบัติได้จริง
    ฉันเคยมีเพื่อนร่วมงานที่ออกไปเก็บความเห็นจากรอบตัวแล้วจมหายทำคนเดียวอยู่หลายวัน สุดท้าย requirement เปลี่ยนไปแล้ว ซึ่งไม่ดีกับทุกฝ่ายเลย