- นักพัฒนารายหนึ่งสมัครตำแหน่งแบ็กเอนด์ของ Kagi Search และใช้เวลาประมาณหนึ่งสัปดาห์แบบเต็มเวลาเพื่อพัฒนา ไคลเอนต์อีเมลที่ให้ความรู้สึกเหมือนเทอร์มินัล แต่หลังส่งงานก็ถูกปฏิเสธโดยไม่มีการสัมภาษณ์ต่อ
- โจทย์เปิดกว้างให้เลือกได้ทั้ง TUI หรือเว็บแอป, ฟังก์ชันพื้นฐานสำหรับอ่าน·ส่งอีเมล, แบ็กเอนด์จำลอง หรือเลือกใช้ IMAP/POP/JMAP ทำให้ผู้สมัครต้องตัดสินใจเองว่าขอบเขตการพัฒนาและเกณฑ์ประเมินควรอยู่ตรงไหน
- ผู้สมัครส่งแผนละเอียดล่วงหน้า ซึ่งรวมถึงเว็บแอป Go, AWS ECS Fargate, SSL, Postmark, ล็อกอิน, Pulumi, Pocketbase, TEMPL ฯลฯ แต่ฝั่ง Kagi ไม่ได้แจ้งเกณฑ์ผ่านที่ชัดเจน
- เมื่อขอฟีดแบ็กหลังถูกปฏิเสธ ได้รับคำตอบเพียงว่ามี “ผลงานที่เรียบง่ายกว่าและแข็งแรงกว่า” และได้รับแจ้งว่าโดยปกติในขั้นตอนนี้จะไม่ให้ฟีดแบ็กรายบุคคล
- ประสบการณ์นี้แสดงให้เห็นว่า การสัมภาษณ์แบบทำโจทย์โดยไม่มีค่าตอบแทน และโจทย์โค้ดดิ้งแบบจำกัดเวลา อาจทดสอบเวลาและเงื่อนไขชีวิตของผู้สมัครมากกว่าความสามารถด้านวิศวกรรมจริง
การสมัครและการได้รับโจทย์
- ผู้สมัครส่งเรซูเม่ไปยังตำแหน่งแบ็กเอนด์ของ Kagi Search โดยสรุปบทบาทระบุทักษะต่อไปนี้
- ประสบการณ์สร้างระบบแบ็กเอนด์
- ความชำนาญใน Go
- ความเข้าใจในการขยายและบำรุงรักษาระบบแบ็กเอนด์
- ความสามารถในการทำงานร่วมกับ SRE และสมาชิกทีม
- ความเข้าใจเทคโนโลยีคอนเทนเนอร์ เช่น Docker
- ต่อมาได้รับอีเมลจาก Kagi ให้ทำ Kagi Developer Assessment เป็นขั้นตอนถัดไป
- URL ของโจทย์ถูกส่งผ่าน HackMD
- เนื้อหาระบุว่าเมื่อทำเสร็จให้ติดต่อกลับ จากนั้นจะตรวจสอบ และหากผ่าน จะหารือแนวทางและโซลูชันในการสัมภาษณ์รอบถัดไป
ข้อกำหนดของโจทย์และเกณฑ์ประเมินที่เปิดกว้าง
- เป้าหมายของโจทย์คือการสร้าง “ไคลเอนต์อีเมลที่ให้ความรู้สึกเหมือนเทอร์มินัลแบบขั้นต่ำ”
- เงื่อนไขการพัฒนาค่อนข้างเปิดกว้าง
- ไคลเอนต์อีเมลสามารถทำเป็น TUI ในเทอร์มินัลหรือเป็นเว็บแอปก็ได้
- ต้องมีฟังก์ชันพื้นฐานสำหรับอ่านและส่งอีเมล
- ใช้แบ็กเอนด์จำลองได้ เช่น DB, in-memory ฯลฯ หรือใช้แบ็กเอนด์จริงอย่าง IMAP/POP/JMAP ก็ได้
- ไม่ต้องรองรับข้อความแบบ rich text จัดการเฉพาะข้อความธรรมดาก็พอ
- มีการแจ้งว่าเกณฑ์ประเมินไม่ได้รวมแค่ความสามารถในการเขียนโค้ด แต่รวมถึง ความสามารถในการรับมือกับความกำกวมและปัญหาแบบเปิด ซึ่งจำเป็นต่อโปรเจกต์ R&D อย่าง Kagi Labs ด้วย
- เงื่อนไขของผลงานมีดังนี้
- พัฒนาในรูปแบบที่แสดงศักยภาพของตนในฐานะนักพัฒนา
- นำโปรเจกต์ที่เสร็จแล้วขึ้น GitHub repository และ deploy ไว้ที่ใดที่หนึ่งเพื่อให้ทดสอบได้ง่าย
- เขียนวิธีตั้งค่าไว้ใน README
การสื่อสารกับผู้รับผิดชอบการสรรหา
- ผู้สมัครเห็นว่าข้อกำหนดกว้างเกินไป จึงส่งคำถามไปยังผู้รับผิดชอบการสรรหา
- ผู้รับผิดชอบตอบว่ามีผู้สมัครจำนวนมาก บางคนทำเฉพาะพื้นฐาน ขณะที่บางคนให้ฟีเจอร์เพิ่มเติม เอกสารที่ดี คำอธิบายการตัดสินใจ การ deploy เดโม และแผนในอนาคตด้วย
- เมื่อถามว่าฟีเจอร์เพิ่มเติมแบบใดจะได้รับการประเมินสูง ผู้รับผิดชอบตอบว่า “นั่นเป็นส่วนหนึ่งของการประเมิน” และจะดูว่าผู้สมัครคิดฟีเจอร์เพิ่มเติมอะไรขึ้นมา
- ผู้สมัครจึงตัดสินใจเขียนแผนการพัฒนาผลงานทั้งหมดอย่างละเอียดและส่งไปก่อนเริ่มเขียนโค้ดจริง
- คาดหวังว่าหากข้อเสนอได้รับการยอมรับ ก็อาจเข้าใกล้การสัมภาษณ์ทางโทรศัพท์หรือข้อเสนอจ้างงานมากขึ้น
- หลังเห็นผลลัพธ์ ผู้สมัครสรุปว่าความพยายามในการปรับเงื่อนไขให้ตรงกันล่วงหน้าไม่ได้มีความหมายมากนักต่อผู้รับผิดชอบการสรรหา
แนวทางพัฒนาที่ผู้สมัครเสนอ
- แกนหลักของข้อเสนอคือไคลเอนต์อีเมลบนพื้นฐาน เว็บแอป Go
- deploy บน AWS
- ใช้ ECS Fargate
- ใช้ SSL/HTTPS
- ผสานรวมกับผู้ให้บริการส่งอีเมล
- ยืนยันตัวตนผ่านหน้าล็อกอิน
- ส่งอีเมลผ่านฟอร์ม
- แสดงอีเมลขาเข้าใน UI
- ในข้อเสนอระบุวันส่งมอบเป็น EOD วันอาทิตย์ที่ 30 มีนาคม และเขียนว่าเป็นกำหนดการที่ช้ากว่าจุดครบ 2 สัปดาห์นับจากอีเมลแรกอยู่ 2 วันทำการ
- เทคโนโลยีที่เลือกมีดังนี้
- แบ็กเอนด์ Go: ใช้ Pocketbase และ TEMPL
- Infrastructure as Code: ใช้ Pulumi โดยเลือก TypeScript SDK
- ผู้ให้บริการอีเมล: ใช้ Postmark
- UI: แบ่งหน้าอีเมลขาออก·ขาเข้า, หน้าล็อกอิน, บัญชีสำหรับเดโม 2 บัญชี
- เหตุผลในการเลือกเอนเอียงไปทางการแสดงขอบเขตทักษะให้กว้างตามบทบาทและขอบเขตการประเมิน
- แม้เป็นบทบาทแบ็กเอนด์ แต่การเพิ่มเว็บฟรอนต์เอนด์ช่วยแสดงขอบเขตความสามารถด้านเว็บเทคโนโลยีได้
- ฐานข้อมูลเกี่ยวข้องกับบทบาทแบ็กเอนด์
- การ deploy บน AWS และ Infrastructure as Code เชื่อมโยงกับการอภิปรายเรื่อง IaC, Docker, networking และ resilience
- บริการอีเมลอย่าง Postmark ช่วยลดความซับซ้อนของการผสานรวม IMAP/POP ขณะที่ยังคงฟังก์ชันไว้
- ผู้สมัครถามว่า “หากทำเสร็จแล้ว คาดหวังปฏิกิริยาแบบใดจาก Kagi ได้บ้าง” แต่คำตอบหยุดอยู่ในระดับว่า “น่าสนใจมากและตั้งตารอดูงานที่ส่งมา”
ผลงานที่ส่งและการถูกปฏิเสธ
- ผู้สมัครระบุว่าได้พัฒนาทุกอย่างตามที่เสนอไว้ และงานทั้งหมดใช้เวลา หนึ่งสัปดาห์แบบเต็มเวลา
- เดโมเว็บแอปพลิเคชันถูกอัปโหลดไปยัง YouTube และโค้ดถูกเผยแพร่บน GitHub พร้อมเอกสาร
- หลังได้รับอีเมลปฏิเสธอัตโนมัติและขอฟีดแบ็ก ฝั่ง Kagi ตอบดังนี้
- โดยปกติในขั้นตอนนี้จะไม่ให้ฟีดแบ็ก
- มีผลงานที่เรียบง่ายกว่าและแข็งแรงกว่า จึงตัดสินใจเดินหน้ากับผู้สมัครเหล่านั้นต่อ
- แต่ละตำแหน่งได้รับความสนใจและใบสมัครจำนวนมาก ทำให้กระบวนการคัดเลือกแข่งขันสูงมาก
- ขอให้ติดตามตำแหน่งในอนาคตและสมัครใหม่อีกครั้ง
คำถามที่ยังค้างหลังถูกปฏิเสธ
- ผู้สมัครมองว่าหากต้องการ “โซลูชันที่เรียบง่ายกว่า” ก็สามารถบอกได้ตั้งแต่ตอนที่เขาส่งข้อเสนอเมื่อวันที่ 18 มีนาคม
- หากโซลูชันไม่เหมาะกับบทบาท ผู้สมัครก็เห็นว่าสามารถตัดสินได้เช่นกันตั้งแต่ขั้นข้อเสนอวันที่ 18 มีนาคม
- ผู้สมัครเขียนว่า ณ วันที่ 13 พฤษภาคม ซึ่งผ่านไปหนึ่งเดือนครึ่งหลังถูกปฏิเสธ ประกาศรับสมัครงานก็ยังคงอยู่
- ยอมรับว่าบริษัทอาจใช้ประกาศเดียวกันเพื่อเติมหลายบทบาทได้
- แต่เห็นว่ายากที่จะมองว่าเป็น “การแข่งขันที่ตำแหน่งผู้ชนะถูกเติมเต็มไปแล้ว”
- ผู้สมัครเขียนว่าเดิมทีคำสั่งของโจทย์ระบุว่าการ deploy เดโมเป็นสิ่งที่มีไว้ก็ดีแต่ไม่บังคับ แต่หลังจากส่งงานแล้ว คำสั่งถูกเปลี่ยนให้การ deploy เป็นข้อกำหนดที่เข้มงวด
ข้อเสนอสำหรับวิธีคัดเลือกที่ดีกว่า
- ผู้สมัครวิจารณ์ว่า โจทย์แบบไม่มีค่าตอบแทน เป็นภาระหนักต่อผู้หางาน โดยเฉพาะคนที่ว่างงานและเงินเก็บกำลังลดลง
- ผู้สมัครมีมุมมองเชิงลบต่อการสัมภาษณ์แบบ LeetCode เช่นกัน
- ระบุว่าไม่นานมานี้ในบทบาทที่ใช้ Clojure ได้ทำโจทย์ “coin change” และภายใน 50 นาทีผ่านเทสต์ได้ประมาณครึ่งหนึ่ง แต่มีเวลาไม่พอสำหรับการพัฒนาส่วน backtracking
- เสนอทางเลือกเป็น live code review
- เห็นว่าสามารถทำได้ทั้งแบบ asynchronous หรือ synchronous
- สามารถอธิบายปัญหาและหัวข้อของโปรเจกต์ซอฟต์แวร์จริงด้วยการพูดคุยได้
- แสดงความรู้ของวิศวกรซอฟต์แวร์ที่มีประสบการณ์ได้ดีกว่า
- แม้ไม่ได้คัดค้าน live coding ทั้งหมด แต่เห็นว่าความสามารถในการแก้ knapsack ภายใน 50 นาทีห่างไกลจากงานวิศวกรรมในชีวิตประจำวัน
- แนะนำว่าหากไม่ได้อยู่ในสถานการณ์ที่จำเป็นเร่งด่วน ควรปฏิเสธบทบาทที่要求งานไม่มีค่าตอบแทนประเภทนี้
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ถ้ามองจากมุมผู้ว่าจ้าง ผมไม่ชอบ กระบวนการคัดเลือกแบบให้ทำโจทย์งาน ด้วยเหตุผลเหล่านี้ มันเสียเวลาทุกฝ่าย และแม้จะพอใช้ได้ในขั้นตอนสุดท้ายก่อนรับเข้าทำงาน แต่ไม่เหมาะจะใช้เป็นตัวกรอง
อย่างไรก็ตาม ความสามารถและความจริงใจดูชัดเจน และนี่เป็นเพียงการลองเป็นฝ่ายโต้แย้งจากอีกมุมหนึ่ง
คำขอว่า “ช่วยทำอีเมลไคลเอนต์สไตล์เทอร์มินัลที่นำไปทดสอบอัลฟากับลูกค้าสักไม่กี่รายได้” เป็นคำขอที่สมเหตุสมผลสำหรับวิศวกรในสตาร์ทอัพระยะต้น และรายละเอียดปลีกย่อยก็ย่อมต้องฝากไว้กับวิศวกร
โดยเฉพาะคำถามว่า “อยากรู้ว่าหากทำจนเสร็จแล้วจะคาดหวังปฏิกิริยาแบบใดจาก Kagi ได้บ้าง” นั้นไม่ดีนัก ในสถานการณ์ที่ต้องดูผลงานส่งเข้ามาหลักร้อยถึงหลักพัน ไม่มีทางให้คำตอบที่แน่นอนได้
ถ้าการพยายามทำให้ข้อกำหนดชัดเจนเป็นพฤติกรรมที่ไม่ต้องการ ก็ไม่ต่างจากให้เลือกตัวเลขระหว่าง 1 ถึง 10 แล้วคัดคนที่เลือกผิดออก
แบบทดสอบด้วยโจทย์งานมีไว้เพื่อแสดงความสามารถ แต่ถ้าไม่มีคำแนะนำที่เฉพาะเจาะจง จะเดาได้อย่างไรว่าต้องแสดงให้เห็นถึงระดับไหน
การขัดเกลางานมากเกินไปจะเป็นเรื่องแย่ก็ต่อเมื่อมันขัดขวางการส่งมอบ และการคัดออกเพราะ “ทำให้เนี้ยบเกินไป” ให้ความรู้สึกเหมือนถูกตัดตกเพราะทำงานดีเกินไป
แบบทดสอบที่คลุมเครือแบบนี้สุดท้ายดูเหมือนเป็นอีกวิธีหนึ่งในการคัดคนออกด้วยเหตุผลว่าไม่ใช่ วัฒนธรรมที่เข้ากันได้ มากกว่า
สภาพแวดล้อมแบบ “ทำก่อน รีวิวทีหลัง” เป็นหนึ่งในที่ที่เป็นพิษที่สุดในอาชีพการงาน และสิ่งที่แย่ที่สุดคือทุ่มเวลาหลายวันสร้างฟีเจอร์แล้วมารู้ทีหลังว่าเป็นฟีเจอร์ที่ไม่มีใครต้องการ
ดังนั้นการอธิบายฟีเจอร์เป็นลายลักษณ์อักษรและขออนุมัติก่อนจึงแทบจะเป็นมาตรฐานอุตสาหกรรมในการปล่อยโปรเจกต์ และผู้สมัครรายนี้ก็ทำตามแนวปฏิบัติด้านซอฟต์แวร์ที่องค์กรสุขภาพดีปฏิบัติกัน
ในฐานะผู้จัดการจ้างงานของบริษัทที่มีวิศวกรมากกว่า 1,000 คน ผมก็มองแบบนั้นเช่นกัน
แน่นอนว่าควรให้เฉพาะผู้สมัครบางคนที่ผลลัพธ์จะมีผลต่อการตัดสินใจรับหรือไม่รับเท่านั้น
ตอนหางานครั้งล่าสุด ผมได้รับโจทย์กว้างๆ แบบนี้ และแม้จะเป็นงานที่ผมมีคุณสมบัติเกินด้วยซ้ำ แต่ก็ถูกปฏิเสธเพราะเดาไม่ได้ว่าส่วนไหนคือสิ่งที่จะถูกให้คะแนน
ต่อไปดูเหมือนโอกาสที่จะได้งานด้วยวิธีอื่นนอกจากการแนะนำจะต่ำ แต่ก็ทำให้ผมไม่ค่อยอยากทั้งรับโจทย์แบบนี้หรือออกโจทย์แบบนี้อย่างมาก
โจทย์นี้มีไว้เพื่อดูความสามารถในการถามคำถามบางส่วน จดสมมติฐาน แล้วลงมือทำงานที่คลุมเครืออย่างมั่นใจ
เป็นไปได้มากว่าหลังจากอีเมลฉบับนั้นถูกส่งไป โค้ดก็ไม่สำคัญแล้ว และบริษัทควรหยุดกระบวนการ ณ จุดนั้นเพื่อไม่ให้ผู้สมัครเสียเวลาลงมือทำโจทย์
ตอนดูโค้ดและดูวิดีโอเดโม ความคิดแรกคือ “ใช้เวลาหนึ่งสัปดาห์ทำเว็บแอปสองหน้า และยังขาด ฟังก์ชันอีเมลพื้นฐานที่สุด อย่างการเปิดอ่านข้อความเลย”
ดูจากข้อกำหนดแล้ว คนนี้สมัครตำแหน่ง “Email Backend Engineer” แต่ส่วนแบ็กเอนด์อีเมลจริงกลับใช้ผลิตภัณฑ์ third-party อย่าง Postmark และ Turso
องค์ประกอบพื้นฐานอย่างรูปแบบอีเมลแบบ plain text, การดูข้อความ, กล่องโฟลเดอร์ อย่างน้อยกล่องขาเข้าและกล่องส่งแล้วหายไป แต่กลับใส่ฟังก์ชันเสริมอย่างหน้าล็อกอิน หน้าแอดมิน และแบ็กเอนด์เฟรมเวิร์กเข้ามา
ในฐานข้อมูลฝั่งแบ็กเอนด์ไม่มีแม้แต่แมปของอีเมลเฮดเดอร์
เขาอาจเป็นวิศวกรที่ยอดเยี่ยมก็ได้ แต่ดูไม่เหมาะกับตำแหน่งเฉพาะนี้ และถ้าเป็นผมก็คงปฏิเสธเช่นกัน
ดูประกาศต้นฉบับแล้ว หัวข้อคือ “The project is to build a minimal, terminal-inspired email client” และระบุชัดเจนว่าให้ได้แรงบันดาลใจจากเครื่องมืออีเมลบนเทอร์มินัลที่มีอยู่ เช่น aerc, mutt, himalaya
นี่ดูเป็นระดับที่อ่านข้อกำหนดไม่เข้าใจ จึงดูเหมือน รับเข้าทำงานไม่ได้
ดูเหมือนทั้งสองอย่างถูกตอบสนองเพียงพอแล้ว
การได้แรงบันดาลใจจากเครื่องมือที่มีอยู่เป็นเรื่องอัตวิสัย และในโจทย์ของตำแหน่งแบ็กเอนด์ เขาคงไม่ได้คิดว่าการใช้เวลากับ user interface เป็นวิธีที่ดีที่สุดในการแสดงฝีมือ
ผมเข้าใจว่าในตำแหน่งยอดนิยม ถ้า recruiter ต้องคัดกรองคนหลักร้อย มันอาจไม่เป็นจริงได้เสมอไป แต่นั่นแหละที่ทำให้กระบวนการแบบให้ทำโจทย์งานไม่ดี
ผู้สมัครอาจเสียเวลาหลายชั่วโมงในชีวิตโดยไม่ได้อะไรกลับมาเลย ดังนั้นทั้งสองฝ่ายควรเคารพเวลาของกันและกัน
เข้าใจได้ว่าคำตอบสั้นมากและไม่ค่อยช่วยอะไร แต่ในข้อกำหนดระบุชัดเจนว่าให้สร้างไคลเอนต์อีเมลที่ ได้แรงบันดาลใจจากเทอร์มินัล
ถ้าดูวิดีโอที่แชร์ไว้ https://www.youtube.com/watch?v=yY1sVXMkP_o จะเห็นเหมือนเว็บแอปอีเมลธรรมดา ๆ ที่ไม่ได้มีอะไรเป็นพิเศษที่ได้แรงบันดาลใจจากเทอร์มินัล
ถ้าต้องการอย่างใดอย่างหนึ่งระหว่าง TUI จริง ๆ หรือเว็บแอป ก็มีความเป็นไปได้สูงว่าเว็บแอปก็ควรมีสไตล์แบบเทอร์มินัลด้วย
ในส่วน “Inspiration” ของข้อกำหนดทั้งหมดระบุไว้ว่า “ให้ได้แรงบันดาลใจจากเครื่องมืออีเมลบนเทอร์มินัลที่มีอยู่ เช่น aerc, mutt, himalaya”
ถึงอย่างนั้นพรอมป์ก็ระบุไคลเอนต์บนเทอร์มินัลอื่น ๆ เป็นแรงบันดาลใจไว้อย่างชัดเจน
นอกจากนี้ ข้อกำหนดเรื่องไคลเอนต์บนเทอร์มินัลยังเปลี่ยนสิ่งที่ต้องประเมินไปมาก UI อีเมลบนเว็บเป็นพื้นที่ที่เป็นที่รู้จักมานานแล้ว แต่ประสบการณ์ผู้ใช้ของไคลเอนต์บนเทอร์มินัลยังไม่ใช่พื้นที่ที่ “แก้ได้สมบูรณ์” แล้ว
มีความเป็นไปได้สูงว่าในตารางประเมินจะให้น้ำหนักมากกับ การตัดสินใจด้านการออกแบบไคลเอนต์บนเทอร์มินัล ซึ่งผลงานที่ผู้สมัครส่งมาไม่ได้แตะเลย
การประเมินแบบให้ทำโจทย์อาจมีคุณค่าในกระบวนการสัมภาษณ์ แต่จำเป็นต้องมี การจำกัดเวลา อย่างแน่นอน 2–3 ชั่วโมงก็เพียงพอที่จะได้ข้อมูลที่ต้องการแล้ว และถ้ามากกว่านั้นก็แทบจะเป็นการคัดแต่เด็กจบใหม่ที่ไม่มีครอบครัวที่ต้องดูแล งานอดิเรก หรือความรับผิดชอบอื่น ๆ
ถ้าจำกัดไว้ที่ 3 ชั่วโมง กรณีแย่ที่สุดผู้สมัครก็เสียเวลาแค่ 3 ชั่วโมง และกรณีที่เป็นไปได้มากกว่าคือเขาคงเสนอแนวทางหรือคำตอบที่ต่างออกไปโดยสิ้นเชิงให้เหมาะกับเวลานั้น
ผู้สมัครเองก็ควรถามให้ชัดด้วยว่า “ต้องการคำตอบอะไรก็ได้ หรือคำตอบที่ดี”
บางโจทย์ดูแค่ว่าผ่านชุดทดสอบหรือไม่โดยไม่สนวิธีการ แต่บางโจทย์แม้จะทำได้เพียง 80% ของข้อกำหนดก็ยังชอบโค้ดที่ดีกว่า เคยเห็นผู้สมัครตัดสินใจผิดได้ทั้งสองแบบ
โจทย์แบบนี้อาจคัดคนที่สามารถเสียเวลากับโปรเจกต์ได้มาก ๆ ออกมา และทำให้คนที่ยุ่งจริง ๆ ซึ่งก็คือคนที่น่าจะอยากได้ กลับถอดใจไป
เวลาคัดความสามารถด้านวิศวกรรมข้อมูล ผม/ฉันให้ โจทย์ ETL ง่าย ๆ ให้ดึงข้อมูลจากไฟล์ ZIP แปลงข้อมูล แล้วใส่ลงในฐานข้อมูลอะไรก็ได้
เว้นจุดกำกวมไว้บ้าง และใส่องค์ประกอบซ่อนอยู่ในชุดข้อมูล เช่นค่า null ที่ไม่คาดคิดหรือ CSV ที่ฟอร์แมตผิด เพื่อดูความสามารถในการทำงาน
จำกัดเวลาไว้ 4 ชั่วโมง แต่ไม่ได้ให้คำแนะนำเมื่อเวลาไม่พอ ซึ่งนั่นเป็นข้อเสนอที่ดี
ในสายคุยหลังจากนั้นจะดูโค้ดด้วยกันแล้วถามแนวทางปรับปรุง เช่น “ถ้าชุดข้อมูลใส่ในหน่วยความจำไม่หมดล่ะ?” และจุดนั้นจึงกลายเป็นการประเมินทางเทคนิคจริง ๆ
เพราะไม่มีหลักประกันว่าผู้สมัครทุกคนใช้เวลาเท่ากัน เรื่องนี้จึงกลายเป็นปัญหาเชิงทฤษฎีเกม และโดยทั่วไปผู้สมัครจะเสียเปรียบไม่ทางใดก็ทางหนึ่ง
ในหลายกรณี คำตอบที่ถูกคือใช้เวลาเพิ่มทำคำตอบที่ขัดเกลามาก แต่ไม่ขัดเกลาจนเกินไป แล้วทำเป็นว่าทำเสร็จภายในเวลาที่จำกัด
แม้แต่ 3 ชั่วโมงก็เป็นเวลาที่ยาวมากสำหรับผู้สมัครที่ยังไม่รู้ด้วยซ้ำว่าจะได้คุยกับคนถัดไปหรือไม่
ในการสัมภาษณ์ 1 ชั่วโมง เราสามารถให้ทำโจทย์เขียนโปรแกรมไปพร้อมกันและรับประกันได้ว่าผู้สมัครจะไม่เสียเวลาเพิ่มเติม
ถ้าผู้สมัครต้องการ ก็อาจให้ส่งคำตอบที่ปรับปรุงแล้วภายหลังได้ และโดยปกติ ณ จุดนั้นเราก็มองความสามารถในแง่ดีอยู่แล้ว จึงบอกได้ว่า “ถ้าอยากทำก็ทำได้ แต่ผ่านแล้ว”
หากรักษาการลงทุนเวลาของผู้สมัครกับผู้สัมภาษณ์ให้เท่ากัน ก็จะทำให้เราเคารพเวลาของผู้สมัครเหมือนที่เคารพเวลาของตัวเอง
ถ้าผู้จัดการฝ่ายจ้างงานไม่เคารพเวลาของผู้สมัคร ก็ดูมีแนวโน้มต่ำที่จะเคารพเวลาของพนักงานด้วย
ช่วงหลังไปสัมภาษณ์มาหลายที่ และประสบการณ์ก็คล้ายกับเรื่องนี้มาก ผม/ฉันเสนอวิธีแก้โจทย์ที่ยอดเยี่ยม แต่ถูกปฏิเสธโดยไม่มีการพูดคุยถึงผลงาน
ในฐานะคนที่เคยดำเนินกระบวนการคัดเลือกแบบให้ทำโจทย์หลายครั้ง ผม/ฉันเชื่อว่าถ้าให้ใครทำโจทย์ที่บ้านแล้ว ก็ต้องคุยเรื่องโค้ดกับเขาอย่างแน่นอน
ถ้าได้รับโจทย์แบบนี้ ขอแนะนำอย่างยิ่งให้ยืนยันว่ามีการคุยต่อหลังจากนั้นหรือไม่โดยไม่ขึ้นกับผลประเมิน และถ้าไม่เห็นด้วยก็อย่าทำ “การบ้าน” นั้น
พูดตรง ๆ คือทีมจ้างงานจำนวนมากมีระดับต่ำ จนการทำคำตอบที่ดีอาจกลายเป็นผลลบได้ด้วยซ้ำ อาจถูกปัดตกด้วยเหตุผลน่าหงุดหงิดว่าทีมจ้างงานไม่ถึงระดับนั้น
ผม/ฉันเป็นผู้ใช้ Kagi ตั้งแต่ช่วงแรก ๆ แต่เรื่องนี้ทำให้กำลังพิจารณายกเลิกบัญชี ถ้าไม่มีเวลาคุยกับผู้สมัคร ก็ไม่ควรให้เขาทำงานตั้งแต่แรก
โจทย์แบบนี้ต้องใช้ความพยายามมากไม่ใช่แค่จากผู้สมัคร แต่จากคนที่ดำเนินการและทีมจ้างงานด้วย และถ้าได้ตรวจโปรเจกต์แล้ว ก็สมเหตุสมผลที่จะคาดหวังฟีดแบ็กหรือคำตอบเมื่อมีการร้องขอ
แต่ก็มีความเป็นจริงอยู่ ถ้าตำแหน่งหนึ่งมีผู้สมัครยอดเยี่ยม 20 คน คนเก่งจำนวนมากก็ต้องถูกปฏิเสธ นั่นไม่ได้หมายความว่าพวกเขาขาดความสามารถหรือ “ล้มเหลว”
ถ้าตามกฎหมายต้องอธิบายว่าทำไมเลือก A แต่ไม่เลือก B การบอกว่า “ทั้งคู่ยอดเยี่ยม แต่ต้องเลือกคนหนึ่ง” ทำได้ยาก และสุดท้ายก็มักไหลไปสู่การหาแม้แต่ข้อบกพร่องที่ไม่มีอยู่จริง
ในวัฒนธรรมองค์กรอเมริกันมักเห็นวิธีแบบนั้นบ่อย และ Kagi ก็มีฐานอยู่ที่ Palo Alto
การตกจากโจทย์ไม่ใช่ปัญหา แต่การเสียเวลาของใครสักคนโดยไม่คืนอะไรกลับมาเลยนั้นยอมรับได้ยาก
มีบริษัทจำนวนมาก รวมถึงสตาร์ทอัพยอดนิยม ที่จัดการเรื่องนี้ได้ดี
ผลงานดูไม่ค่อยเหมือน “ไคลเอนต์อีเมลสไตล์เทอร์มินัลขั้นต่ำ” และดูเหมือนเพิกเฉยต่อเครื่องมือที่ให้ไว้เป็นแรงบันดาลใจโดยสิ้นเชิง
ถ้าเข้าใจข้อกำหนดผิดไปมากขนาดนี้ เป็นผม/ฉันก็คงไม่ใช้เวลากับการถกเถียงเหมือนกัน
นี่เป็นกรณีคลาสสิกของการ อ่านบริบทแฝงผิด บริษัทต้องการคนที่สามารถสร้างงานและเป้าหมายของตัวเองได้อย่างเป็นอิสระ
ความกำกวมของโจทย์ไม่ได้มีไว้ให้ซักถามทางอีเมลหลายรอบ แต่เป็นผืนผ้าใบว่าง ๆ เพื่อให้เห็นว่าผู้สมัครรับโจทย์ที่ค่อนข้างกว้าง แล้วสำรวจพื้นที่ของปัญหาด้วยตัวเองและสร้างผลงานออกมาอย่างไร
มันคล้ายมากกับเวลาทำงานในมหาวิทยาลัยแล้วเห็นนักศึกษาที่ไม่เข้าใจโจทย์ ได้คะแนนที่ไม่คาดคิด แล้วมาบ่น
ในสถานการณ์สัมภาษณ์ที่อยากทำให้ดูน่าประทับใจ คนที่กล้าทำตัว “ขี้เกียจ” นั้นหาได้ไม่บ่อย
ถ้าเป็นบริษัทที่มีแนวทางปล่อยการทดลองเร็วและเน้นโปรโตไทป์ บางคนก็อาจไม่เหมาะจริง ๆ และนั่นแย่สำหรับทุกฝ่าย
บางทีผู้สมัครบางคนอาจใช้เวลา 10 นาทีคิดว่าจะทำอะไรได้ภายใน 60 นาที แล้วใช้ HTTP authentication กับฟอร์ม ทำเป็นแบ็กเอนด์ Go เล็ก ๆ ให้รันได้ ก่อนส่งไปพร้อมอีเมลสั้น ๆ คนแบบนั้นอาจดูดีกว่ามากในกระบวนการนี้
ไม่มีทางรู้ว่านี่คือโปรโตไทป์ที่ทิ้งได้ ของที่จะให้ผู้ใช้จริงเห็น จะถูกตำหนิเรื่องประสบการณ์ผู้ใช้ที่ไม่สมบูรณ์ หรือแค่อยากดูอะไรบางอย่าง
สุดท้ายมันกลายเป็นการฝึกเดารสนิยมของผู้รีวิว
ในทางกลับกัน ก็คงมีคนที่ตกเพราะไม่ผลักดันให้ข้อกำหนดชัดเจนขึ้นเรื่อย ๆ ซึ่งนั่นเป็นคุณสมบัติสำคัญของวิศวกร
ชีวิตไม่ยุติธรรมก็จริง แต่เราคาดหวังจากผู้จัดการฝ่ายสรรหามากกว่านั้น และก็เลยผิดหวังซ้ำ ๆ
นักศึกษาอาจเข้าใจผิดเพราะอ่านใจคนไม่ได้ และคำสั่งเขียนไว้แย่มากก็ได้
ครูที่ดีคือคนที่ทำให้นักศึกษาจำนวนมากที่สุดเข้าใจได้ ส่วนครูที่แย่คือสิ่งตรงข้าม
ภายใต้ครูที่ดีที่สุด เกณฑ์การให้คะแนนโปร่งใสตั้งแต่แรก จึงไม่ต้องสงสัยคะแนน
ถ้านักศึกษาจำนวนมากสับสน ตัวหารร่วมอาจเป็นครูก็ได้
พระสงฆ์ในพุทธศาสนาอาจเรียนรู้ด้วยการแก้ปริศนาธรรมอันลึกลับที่เรียกว่าโคอัน แต่ไม่ควรนำวิธีเดียวกันไปใช้กับนักศึกษามหาวิทยาลัยที่จ่ายค่าเล่าเรียน
ดูเหมือนผู้เขียนจะมาโพสต์เอง จึงขออธิบายบริบทของปฏิกิริยาที่ได้รับ เคยทำงานที่ Kagi มาก่อน และเคยผ่านแบบทดสอบเป็นโปรเจกต์ลักษณะคล้ายกัน
ตอนนั้นบริษัทยังเล็กมาก Vlad ตรวจผู้สมัครเอง และใช้โปรเจกต์แบบนี้เป็นโจทย์ ตอนนี้บริษัทใหญ่ขึ้นแล้ว เขาอาจไม่ได้ดูเองโดยตรง แต่แก่นดูเหมือนยังคล้ายกัน
ถ้าได้คุยกับ Vlad เขาแทบจะเป็นต้นแบบของคนคอมเมนต์ใน Hacker News และการสัมภาษณ์ก็ใกล้เคียงกับการเช็กบรรยากาศว่า “ดูเป็นคนโอเคไหม”
สำหรับเขา การเขียนเอกสารออกแบบยาว ๆ ว่า “จะใช้ Galactor ทำให้ florp-ready และจะ fleem” คือสิ่งตรงข้ามกับความเท่
ถ้าโจทย์คือ “ไคลเอนต์อีเมลสไตล์เทอร์มินัล” โปรเจกต์ที่เกือบเต็มคะแนนน่าจะเป็นของที่ทุกฟีเจอร์มีคีย์ลัด และอธิบายในย่อหน้าเดียวว่าการวาดหนึ่งเฟรมใช้เวลาไม่เกิน 2ms
ผู้สัมภาษณ์อาจมองว่าผู้สมัครมี วิธีคิดแบบองค์กรใหญ่ เกินกว่าจะทำงานที่ Kagi
แน่นอนว่าวิธีคัดเลือกแบบนี้ดีหรือไม่เป็นอีกเรื่อง Vlad ต้องการคนที่คิดเหมือนเขา และการสัมภาษณ์แบบนี้ก็มีปัญหาที่ถูกถกเถียงและศึกษากันมานานมาก
แต่ถ้าเข้าใจเรื่องนั้นและมีพื้นที่พอจะรับมือกับกระบวนการแบบนี้ได้ โจทย์ก็ถือว่ามีเหตุผลอยู่จริง ๆ Kagi น่าจะสื่อสารจุดนี้ได้ดีกว่านี้
เสียดายที่ต้องเสียเวลาไปมาก แต่หวังว่าจะหาที่ที่เหมาะกับวิธีทำงานของคุณมากกว่าได้
ถ้าจะให้ได้มุมมองใหม่ต่อปัญหา จำเป็นต้องมี ความหลากหลายทางความคิด ถ้าทุกคนคิดแบบเดียวกัน เมื่อคนหนึ่งติดขัด ทุกคนก็มีแนวโน้มจะติดขัดตาม
นี่ดูเหมือนเป็นปัญหาที่พบบ่อยในสตาร์ทอัพ และอาจเป็นสัญญาณที่แสดงให้เห็นว่าทำไมสตาร์ทอัพ 9 ใน 10 แห่งจึงล้มเหลว
มันต่างจากการทดสอบความสามารถ ที่นี่ต้องได้คะแนนสูงในตัวชี้วัดที่ไม่ได้บอกไว้จึงจะผ่าน
มันไม่ต่างมากจากการให้โจทย์ว่า “ลองเขียนโค้ดอะไรก็ได้ เพราะต้องรับมือกับความกำกวมให้ได้” แต่จริง ๆ แล้วให้เดาสิ่งที่ผมคิดไว้ในหัว
เป็นวิธีที่ไม่คำนึงถึงผู้คนอย่างมาก และไม่ได้ส่งสัญญาณที่ดีเกี่ยวกับคนชื่อ Vlad ด้วย
ต้องไปขุดโซเชียลมีเดียของคนในบริษัทเพื่อหาคำตอบนี้หรือเปล่า
ถ้าสุดท้ายผมแสดงให้เห็นพอแล้วว่าไม่เท่ แต่พวกเขาก็ยังบอกให้ “ดำเนินการต่อ” เพื่อสนองความอยากรู้อยากเห็นของตัวเอง ก็หวังว่าพวกเขาจะได้รับการปฏิบัติแบบเดียวกับที่ปฏิบัติต่อคนอื่น
ขอบคุณสำหรับคำอธิบาย และไม่ได้มีเจตนาร้าย แค่หวังว่าจะได้เห็นโพสต์แบบนี้เร็วกว่านี้
ต่อไปงานที่มี “take-home” ควรถูกจัดเป็น งานสำหรับเด็กเท่ ไปเลย แบบนั้นวิศวกรที่น่าเบื่อแต่มีประสบการณ์จะได้กดดันให้บริษัทเปลี่ยนวิธี ถ้าบริษัทต้องการแรงงานของเราจริง ๆ
ถ้าบริษัทไม่เปลี่ยน เราก็อนุมานได้ว่าบริษัทที่ “เสนอ” บทบาทนั้นเป็นบริษัทแบบไหน
ลองดูโค้ดเพื่อดูว่าถ้าเป็นผู้รีวิวจะมองอย่างไร
ไฟล์แรกที่เปิด คงหยุดตั้งแต่เห็นตรงนี้: https://github.com/Sleepful/mymail/blob/main/app/router/page...
คอมเมนต์แรกไม่เกี่ยวกับงานเลย แปลกมาก และดูเหมือนคัดลอกมาจากตัวอย่างในบล็อก ไม่ว่าอย่างไร การปล่อยไว้แบบนั้นก็แสดงถึงความไม่รอบคอบ
ถ้อยคำในบรรทัดที่สองไม่สอดคล้องกับบรรทัดที่สาม
ผมคงหยุดรีวิวตรงนี้ นี่คือ การขาดความใส่ใจต่อรายละเอียด และไม่ได้แสดงความสามารถในการคิดอย่างชัดเจน
แต่สิ่งที่ได้รับกลับมาคืออีเมลปฏิเสธว่าง ๆ
ในสถานการณ์นั้น ผมเห็นด้วยได้ยากกับคำบอกว่าควรใช้เวลาเพิ่มกับคอมเมนต์ในโค้ด
ในฐานะผู้สัมภาษณ์สายวิศวกรรม ผมอยากพูดว่า ผมไม่ชอบทั้ง LeetCode และการสัมภาษณ์แบบให้ทำโจทย์เป็นโปรเจกต์ ทั้งคู่ใช้เวลามาก แต่ให้ข้อมูลน้อย
ถึงอย่างนั้น ในกรณีนี้มีโอกาสสูงที่ผมจะปฏิเสธผู้เขียนเหมือนกัน Kagi Search เป็นสตาร์ทอัพ และที่แบบนี้มักมองหา นักปฏิบัติที่มองโลกในแง่ดี ซึ่งเคลื่อนที่ได้เร็ว และสามารถรักษาสมดุลระหว่างความลึกกับความกว้างได้
ครั้งหนึ่งเคยมีเพื่อนร่วมงานที่รวบรวมอินพุตแล้วเก็บตัวอยู่หลายวันเพื่อสร้างวิธีแก้ปัญหาออกมา แต่ระหว่างนั้นข้อกำหนดกลับเปลี่ยนไปแล้ว มันไม่ใช่ประสบการณ์ที่สนุกสำหรับใครเลย
ผมเกลียดกระบวนการคัดเลือกแบบให้ทำโปรเจกต์จริง ๆ
ประโยคอย่าง “โปรเจกต์นี้ไม่ได้ทดสอบแค่การเขียนโค้ด แต่ยังทดสอบความสามารถในการรับมือกับความคลุมเครือและปัญหาปลายเปิดด้วย” ฟังดูเหมือนจริง ๆ แล้วหมายถึง a) โจทย์ถูกออกแบบมาแย่มากจนไม่ได้ทำ rubric สำหรับประเมินไว้ด้วยซ้ำ หรือ b) สภาพแวดล้อมการทำงานวุ่นวายมากจนไม่มีการกำหนดสเปกหรือข้อกำหนดใด ๆ ให้ชัดเจน
ยิ่งไปกว่านั้น คำสั่งอย่าง “โชว์ทักษะทางเทคนิค” กับ “นำเสนอวิธีแก้ที่ใช้งานได้จริงและทำงานได้” ขัดกันเอง วิธีแก้ที่ดีและเรียบง่ายไม่ได้หวือหวา
การที่ทำ HTTP request ได้ และทำหน้าจอแก้ไข CRUD พื้นฐานได้ แทบไม่ได้บอกอะไรเลย เครื่องมือ AI ก็ทำของแบบนี้ได้เร็วและคุณภาพค่อนข้างดี
สิ่งที่อยากเห็นคือวิศวกรจะ implement business logic ที่ขรุขระอย่างไร
มันจะกลายเป็น if ซ้อนกันเป็นล้านชั้นกับคอมเมนต์ “มีมังกรอยู่ตรงนี้” หรือจะหารูปแบบที่เหมาะสมจนได้โค้ดที่อ่านและใช้เหตุผลตามได้
สิ่งนี้มีคุณค่ากว่าในงานจริงมาก ให้สัญญาณในการสัมภาษณ์แรงกว่า AI เดาถูกได้ยากกว่า และใช้เวลาน้อยกว่า
การสร้างวิธีแก้ที่ดีและเรียบง่ายอาจเป็นวิธีแสดงฝีมือได้เช่นกัน
ผมมองว่านั่นเป็นบทบาทสำคัญของ Senior Software Engineer
รูปแบบนี้อาจไม่ใช่วิธีที่ดีที่สุดในการทดสอบเรื่องนั้น แต่ “อยากดูว่ารับมือกับความคลุมเครือได้ไหม” ไม่ได้แปลว่างานทุกอย่างคลุมเครือ
มันอาจหมายความว่างานทุกอย่างต้องผ่านกระบวนการจาก “ข้อกำหนดที่คลุมเครือ” ไปสู่ “สเปกที่ชัดเจน”