วิธีผ่านการสัมภาษณ์เขียนโค้ดสด

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

วิศวกร backend ที่สัมภาษณ์ตำแหน่งระดับ L5 ที่ผู้ให้บริการคลาวด์สาธารณะรายหนึ่ง ได้โจทย์ทำ rate limiter ในโปรแกรมแก้ไขที่แชร์ร่วมกัน ผู้สัมภาษณ์ไม่ได้รอให้คุณเขียนอัลกอริทึม token bucket แบบตำราตั้งแต่คอมไพล์ครั้งแรก สิ่งที่พวกเขาอยากได้ยินคือความแตกต่างระหว่าง burst กับ steady-state ภาพร่างของแนวทาง O(1) เทียบกับการสแกนล็อก และเทสต์ที่ล้มเหลวซึ่งเขียนไว้ก่อน happy path บทสนทนานั้นแหละคือรอบสัมภาษณ์

รอบแบบนี้มักเกิดขึ้นใน CoderPad, CodeSignal, HackerRank หรือโปรแกรมแก้ไขที่แชร์ร่วมกันใน Zoom, Google Meet หรือ Microsoft Teams ถามเกี่ยวกับขนาดอินพุต ค่าที่ซ้ำกัน และการเปลี่ยนแปลงข้อมูล (mutation) ก่อนเริ่มพิมพ์ พูดทวนเอาต์พุตที่คาดไว้อีกครั้ง แล้วค่อยเขียนโค้ด

• อธิบายเงื่อนไขให้ชัดเจนก่อนเขียนบรรทัดแรก
• เริ่มจากแผน brute force ที่ถูกต้อง แล้วปรับปรุงหนึ่งจุด
• บอกความซับซ้อนด้านเวลาและพื้นที่ออกมาดัง ๆ
• ไล่ตัวอย่างและกรณีขอบหนึ่งกรณี
• ตั้งหลักใหม่ได้เมื่อรันแล้วล้มเหลว โดยไม่เงียบไป

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

ก่อนเขียนบรรทัดแรก ให้พูดทวนโจทย์ ระบุเงื่อนไข และไล่ตัวอย่างหนึ่งตัวด้วยมือ จากนั้นพูดแนวคิด brute force และความซับซ้อนของมัน แล้วค่อยเริ่มพิมพ์ ระหว่างพิมพ์ ให้พูดถึงค่าคงที่ของลูป (invariant) ไม่ใช่ทุกครั้งที่กดปุ่ม ถ้าคิดไม่ออก ให้บอกว่ากำลังตรวจสอบอะไรอยู่ (อินพุตที่เป็น null, off-by-one, เรียงลำดับแล้วหรือยัง) แทนที่จะเงียบไปเฉย ๆ

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

การฝึกซ้อมแบบจับเวลาที่คุณพูดตลอดทั้งกระบวนการ มีอยู่ที่หน้า สัมภาษณ์จำลอง

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

SubcueAI มีรูปแบบการช่วยเหลือสดสองแบบ และทั้งสองแบบไม่เข้าร่วมสายในฐานะ meeting bot หรือแทรก content script เข้าไปในหน้าประชุม แอปเดสก์ท็อปแบบเนทีฟสำหรับ macOS และ Windows จะจับเสียงระบบพร้อมกับไมค์ของคุณ และแสดง overlay แบบลอยที่ทำงานร่วมกับโปรแกรมประชุมบนเดสก์ท็อปได้ ส่วนเอ็กซ์เทนชัน Chromium (Chrome และ Edge) ใช้ Side Panel และจับเสียงเฉพาะแท็บประชุมเท่านั้น คือเสียงของผู้สัมภาษณ์ ไม่ใช่ไมค์ของคุณเลย จึงครอบคลุมสายที่โทรผ่านแท็บเบราว์เซอร์และไม่ถอดเสียงคุณ ส่วนเวอร์ชัน Firefox ใช้ได้เฉพาะโหมดฝึกซ้อมเท่านั้น

ถ้า overlay อยู่บนจอที่คุณไม่ได้แชร์ ผู้สัมภาษณ์จะมองไม่เห็น แต่การแชร์เดสก์ท็อปทั้งหมดจะรวมทุกหน้าต่างบนจอนั้นด้วย ขีดจำกัดที่ตรงไปตรงมาว่าผู้สัมภาษณ์เห็นอะไรได้บ้าง รวบรวมไว้ที่หน้าหัวข้อ detectability

ฝึกรูปแบบที่คุณจะต้องเขียนจริงภายใต้เวลาจำกัด เช่น array และ hash, two pointers, sliding window, binary search, BFS และ DFS, heap และการรวมช่วงพื้นฐาน ความคล่องแคล่วกับ hashmap, queue และ sort API ของภาษาที่ใช้ สำคัญกว่าการท่องจำโจทย์แปลก ๆ พูดออกมาระหว่างที่แก้โจทย์ ฝึกแบบเงียบ ๆ จะใช้ไม่ได้ผลตอนสัมภาษณ์จริง

ลองฝึกซ้อมหนึ่งครั้งด้วยชุดเครื่องมือเดียวกับที่จะใช้จริง เช่น ภาษาเดียวกัน นิสัยการใช้โปรแกรมแก้ไขแบบเดียวกัน โปรแกรมประชุมแบบเดียวกัน ถ้าบริษัทใช้ Zoom แบบแอปเดสก์ท็อป ก็ฝึกซ้อมด้วยแอปนั้น ถ้าใช้ Google Meet ในแท็บ Chrome ก็ฝึกซ้อมโดยเปิดแท็บนั้นไว้ วิธีตั้งค่า overlay บนเดสก์ท็อปและ Chrome Side Panel อยู่ที่หน้า tutorial

ถ้าคุณทำโซลูชันที่เหมาะที่สุดไม่เสร็จ ให้ส่ง brute force ที่ถูกต้อง บอกจุดคอขวด และร่างแนวทางที่เร็วกว่าไว้ คำตอบที่สมบูรณ์แต่ช้ากว่า พร้อมแผนที่เร็วกว่าอย่างชัดเจน มักจะดีกว่าไอเดียที่ฉลาดแต่ทำไม่เสร็จ