คำถามทดสอบโจเอล # 11 คือ: "ผู้สมัครใหม่เขียนรหัสระหว่างการสัมภาษณ์หรือไม่" อะไรคือข้อโต้แย้งและคัดค้านที่จะขอให้ผู้สมัครใหม่เขียนรหัสในระหว่างการสัมภาษณ์และตัดสินใจเรื่องนี้?
คำตอบ:
ฉันไม่เห็นข้อเสีย การสัมภาษณ์มีหลายส่วนและผู้สมัครควรได้รับการรับรอง 'up the chain' สองสามครั้ง
ฉันสัมภาษณ์ประมาณ 10 คนต่อสัปดาห์ ฉันจริง ๆ จริง ๆ ขอบคุณจริง ๆ ที่ HR ได้ทำงานเบื้องหลังทั้งหมดและแสดงบันทึกย่อมากมาย ตามเวลาที่พวกเขามาถึงฉันก็ถึงเวลาที่ฉันจะทำคะแนนการทดสอบของพวกเขา
การทดสอบขึ้นอยู่กับตำแหน่งทั้งหมด โดยทั่วไปแล้วฉันพยายามตรวจสอบ:
ทักษะการเขียนโปรแกรมทั่วไป คุณสามารถใช้โอเปอเรเตอร์ได้อย่างมีประสิทธิภาพหรือไม่? คุณสามารถเข้าใจระบบตัวเลขที่มีเลขฐานที่ไม่ใช่ 10 ได้หรือไม่?
คุณรู้วิธีการทำในสิ่งที่เรากำลังว่าจ้างให้คุณทำ?
การประเมินผลงานของคุณในโครงการโอเพนซอร์ซใด ๆ
ฉันพยายามทำให้มันสั้นและสนุก เมื่อฉันเข้าไปในสำนักงานฉันคว้าคำตอบดูพวกเขาแล้วทำการสัมภาษณ์ครั้งที่สอง ในการได้รับการว่าจ้างคุณต้องผ่านการสัมภาษณ์สามครั้ง
ฉันยังวัดได้ว่าคุณจะผสมผสานกับทีมที่จะรับคุณได้ดีเพียงใด ทีมนั้นพึ่งฉันที่จะทำอย่างมีประสิทธิภาพ
มันเป็นสิ่งหนึ่งที่จะตอบคำถามในรูปแบบเมตามันเป็นอีกอย่างหนึ่งที่จะผลิตรหัส ถ้าฉันจะจ้างคุณฉันต้องเห็นคุณสร้างรหัสจริงๆ
ด้วยคำขอโทษต่อ Scott Whitlock:
จุดด้อย:
ข้อดี:
หากคุณจะจ้างนักเล่นปาหี่คุณก็จะไม่บ้าที่จะให้เขาเล่นปาหี่เพื่อคุณ หรือนักดนตรีที่คุณจะได้ออดิชั่น ไม่เช่นนั้นคุณจะได้สิ่งต่าง ๆ เช่นK-strass ยอดเยี่ยมจากyo-yo
การเดินผ่านบางสิ่งบนไวท์บอร์ดเป็นโปรแกรมเมอร์ที่เทียบเท่ากับการเล่นปาหี่อย่างรวดเร็ว
ฉันคิดว่ามันมีประโยชน์มากและฉันมักจะทำ แต่เนื่องจากผลประโยชน์ได้รับการคุ้มครองอย่างดีฉันจะพูดถึงเชิงลบเท่านั้น (ชัดเจน)
ฉันคิดว่าการทดสอบโค้ดนั้นไม่น่าเป็นไปได้ที่จะให้ผลบวกผิด ๆ กับคุณ: โอกาสน้อยที่คนที่ไม่สามารถเขียนโค้ดได้จะทำการปลอมในการสัมภาษณ์อย่างน้อยถ้าคุณมีคำถามมากมายเกี่ยวกับความยากลำบากเพิ่มขึ้น (บางทีสถานการณ์ที่เป็นไปได้มากที่สุดคือพวกเขากำลังโกงโดยขอให้เพื่อนถ้าไม่ใช่การสัมภาษณ์แบบตัวต่อตัว)
ปัญหามีมากขึ้นในด้านลบ - เท็จ: การทดสอบโค้ดจะทำให้คุณปฏิเสธคนที่เป็นผู้สมัครที่ดีที่สุดจริง ๆ หรือไม่
ความน่ากลัวบนเวที
คุณอาจมีคนที่เป็นนักพัฒนาที่ดีจริง ๆ แต่ใครเป็นกังวลมากเกี่ยวกับการสัมภาษณ์นี้และพวกเขาได้รับความกลัวเวที การแสดงภายใต้แรงกดดันมีความสำคัญในระดับหนึ่ง แต่การจัดการกับความน่ากลัวบนเวทีไม่ใช่ส่วนสำคัญของการเป็นโปรแกรมเมอร์ (เทียบกับอาชีพอื่น ๆ ) และมันจะโชคร้ายที่ปฏิเสธคนที่ทนทุกข์ทรมานจากมัน สิ่งนี้สามารถประสม: ถ้าบุคคลนั้นไม่สามารถตอบคำถามที่พวกเขารู้ว่าพวกเขาควรจะตอบพวกเขาอาจจะแน่นมากขึ้น หรืออย่างเช่นในคำถามนี้พวกเขารู้สึกว่าพวกเขาไม่สามารถพูดคุยและใส่รหัสได้ในเวลาเดียวกัน
การผ่อนปรน: เริ่มต้นด้วยคำถามเกี่ยวกับภูมิหลังเป้าหมาย ฯลฯ ก่อนที่จะข้ามไปสู่คำถามทางเทคนิค อาจเริ่มด้วยคำถามทางเทคนิคที่ง่ายขึ้นเพื่อให้ได้แรง อย่าเป็นดิ๊กในระหว่างการสัมภาษณ์ (พูดคุยเกี่ยวกับอัฒภาค ฯลฯ )
มันเป็นมาตรการที่มีเสียงดัง
คำถามเกี่ยวกับรหัสที่น่าสนใจอาจมีคำตอบที่ถูกต้องมากกว่าหนึ่งข้อ ถ้าคนคนหนึ่งเขียนคำตอบที่ถูกต้องและอีกคนหนึ่งเขียนคำตอบที่ถูกต้องและมีประสิทธิภาพมากขึ้นคุณจะต้องใส่น้ำหนักเท่าไหร่?
ในระดับหนึ่งนี่เป็นปัญหาของคำถาม "ไขปริศนา": บุคคลนั้นมีความเข้าใจอย่างถ่องแท้หรือไม่และคุณจะได้ผลลัพธ์เป็นเลขฐานสอง ความฉลาดอาจส่งผลต่อความน่าจะเป็นของการมีความเข้าใจด้านนั้น แต่การสุ่มตัวอย่างเพียงไม่กี่ครั้งก็ช่วยให้คุณสามารถวัดผลได้
สิ่งนี้รบกวนจิตใจฉันเกี่ยวกับคำถามเกี่ยวกับรหัส (แม้ว่าฉันยังคงใช้อยู่) การบรรเทาที่ดีที่สุดที่ฉันสามารถนึกได้ก็คือมีวิธีแก้ไขที่เป็นไปได้ให้มากที่สุด: บุคคลอย่างน้อยที่สุดก็สามารถเขียนคำตอบที่โหดร้าย ส่วนหนึ่งของปัญหา การตระหนักว่าดีกว่าไม่มีอะไรเป็นสัญญาณที่ดี จากนั้นหากพวกเขาค้นพบมากขึ้นพวกเขาสามารถทำให้มีประสิทธิภาพมากขึ้นหรือรหัสที่สง่างามมากขึ้น มากที่สุดหลีกเลี่ยงการถามคำถามที่ได้รับการตอบกลับแบบไบนารี
มันไม่ได้เป็นตัวแทนจริงๆ
การเขียนโปรแกรมไม่ใช่งานของการแก้ปัญหาอัลกอริทึมสิบนาทีซึ่งกันและกัน: มีงานมากขึ้นเกี่ยวกับความเข้าใจและการออกแบบระบบที่มีขนาดใหญ่ขึ้นและให้ความสนใจเป็นระยะเวลานานโดยไม่พูดถึงทักษะความสัมพันธ์ระหว่างบุคคล คำถามเกี่ยวกับรหัสไม่ได้ทดสอบสิ่งนี้จริงๆ
แต่คำถามรหัสไม่ได้เป็นคำถามเดียวที่คุณจะถาม: คุณสามารถดูภูมิหลังของพวกเขาอ้างอิงของพวกเขางานโอเพนซอร์สของพวกเขา (ถ้ามี) เพื่อหาหลักฐานของความพยายามอย่างยั่งยืนความคิดสร้างสรรค์ทักษะความสัมพันธ์ระหว่างบุคคล
การรู้วิธีแก้ปัญหาอัลกอริทึมขนาดเล็กและวิธีลดปัญหาให้เป็นรหัสเป็นเงื่อนไขที่จำเป็น แต่ไม่เพียงพอ: หากคุณไม่สามารถแก้ปัญหาเล็ก ๆ ได้และคุณไม่สามารถเขียนโค้ดที่ไม่น่าสนใจแล้วการคิดภาพใหญ่ทั้งหมดในโลกไม่ใช่ จะทำให้คุณเป็นนักพัฒนาที่มีประสิทธิผล
ทุกคนสามารถแก้ไขได้
ไม่เห็นได้ชัดว่าไม่ ในฐานะที่เป็นโพสต์ที่มีชื่อเสียง FizzBuzzชี้ให้เห็นปัญหาที่คุณอาจคิดว่าเป็นกับดักที่น่ารำคาญไม่เพียง แต่บัณฑิตจบใหม่ แต่คนที่มีประสบการณ์ในอุตสาหกรรม ฉันไม่รู้ว่าทำไม การทดสอบรหัสเป็นการวัดที่ไม่ดี (ซึ่งเป็นไปได้แม้ว่าฉันคิดว่ามันไม่น่าเป็นไปได้) หรือพวกเขาไม่ได้มีส่วนร่วมอย่างมากต่อโครงการในประวัติย่อของพวกเขาหรือพวกเขาทำได้ดีมากโดยการคัดลอกและวาง รหัสอัลกอริทึม (ซึ่งเป็นไปได้)
เป็นสิ่งที่ควรค่าแก่การยอมรับว่าคุณสามารถทำสิ่งต่างๆให้สำเร็จได้โดยไม่ต้องเขียนโค้ดอัลกอริทึมใด ๆ ผู้คนทำเงินมากมายบนแอปที่มีค่าอยู่ในกราฟิกหรือตรรกะทางธุรกิจไม่ใช่ในสิ่งที่คุณอาจเรียกว่า "การเขียนโปรแกรม" และนั่นก็ดี แต่ถ้าคุณต้องการโปรแกรมเมอร์จริงๆมันก็ไม่เหมาะ
อาจไม่ได้รับการสอบเทียบที่เหมาะสม
หากคุณมีคำถามคำตอบอาจจะดูง่ายสำหรับคุณ อย่างไรก็ตามหากคุณถามคำถามที่เทียบเคียงกันได้หรือคำถามที่ไม่ได้บิดเบือนความสนใจและพื้นหลังของคุณเองมันอาจจะยากกว่ามาก
การบรรเทา: เริ่มการทดสอบกับนักพัฒนาบางคนที่คุณรู้จักและดูว่าพวกเขาทำอะไร บางทีบางคนในทีมของคุณที่คุณรู้ว่าฉลาดมากอาจมีปัญหากับคนใดคนหนึ่งและคุณสามารถปรับเปลี่ยนได้ บางทีพวกเขาอาจคิดถึงคำตอบที่ดีกว่าหรือแตกต่างออกไป
มันเหมือนกับเรื่องไม่สำคัญมากเกินไป
ฉันคิดว่าคำถามเกี่ยวกับรหัสสามารถเข้ามาในเรื่องไม่สำคัญได้อย่างแน่นอนถ้าคุณยืนยันให้ผู้คนรู้ว่า APIs ที่ไม่ชัดเจนด้วยใจหรือได้รับไวยากรณ์ที่สมบูรณ์แบบ สิ่งเหล่านี้ล้วนมีเหตุผลที่ต้องพึ่งพาเอกสารการค้นหาเว็บหรือข้อผิดพลาดของคอมไพเลอร์ในการรับและมีความสัมพันธ์กับความเชี่ยวชาญจริงเล็กน้อย ไม่แม้แต่จะรู้ว่า API มีแนวโน้มที่จะเป็นเบาะแสที่บุคคลไม่ได้ใช้เมื่อเร็ว ๆ นี้ แต่ก็ไม่จำเป็นต้องมีปัญหาตราบใดที่พวกเขาไม่ได้โกหกเรซูเม่ของพวกเขา
ดังนั้นคำตอบสำหรับคำถามนี้จึงค่อนข้างง่าย: อย่าถามคำถามที่ไม่สำคัญและอย่าพลาดความผิดพลาดเล็กน้อย เตือนผู้สมัครว่ามีการเรียก API หรือให้ค้นหาอย่างไร แก้ไขข้อผิดพลาดทางไวยากรณ์ อย่าทดสอบคนที่จำนิยามโครงสร้างข้อมูล
คุณเปรียบเทียบอย่างไร
หากคุณมีผู้สมัครสองคนและทั้งสองตอบคำถามได้ดีคุณจะเลือกระหว่างพวกเขาได้อย่างไร คุณสามารถเลือกคนที่เสร็จเร็วที่สุด แต่บางทีคุณอาจเริ่มรับกระต่ายมากกว่าเต่า คุณสามารถทำอีกรอบและถามคำถามที่ยากขึ้นได้ แต่ฉันก็ไม่แน่ใจเหมือนกัน บางทีคุณอาจให้ทั้งสอง A + และลองเลือกระหว่างพวกเขาในเกณฑ์อื่น ๆ (หรือลองหาเงินที่จะจ้างทั้งคู่)
สิ่งหนึ่งที่ฉันคิดได้ก็คือมันยากที่จะ "ถอดรหัสเสียงดัง" ต่อหน้าคนอื่น ฉันพบว่ามันยากแม้จะพิมพ์กับใครบางคนมองข้ามไหล่ของฉันและฉันไม่ได้อยู่คนเดียว ฉันสังเกตว่าเมื่อมีคนโทรหาฉันที่เวิร์กสเตชันของพวกเขาเพื่อช่วยบางสิ่งบางอย่างพวกเขาก็เริ่มทำสิ่งที่ผิดพลาดการเลือกรหัสที่ไม่ถูกต้องแม้แต่การทำผิดพลาดอย่างจริงจัง - ไม่มีสิ่งใดที่พวกเขาจะทำ นรกฉันเคยเห็นผู้คนเริ่มใช้เมนูสำหรับการดำเนินการแบบตัดและวางเพียงเพราะพวกเขาอยู่ภายใต้การสังเกต นี่ไม่ใช่พฤติกรรมปกติและรหัสที่ฉันพูดถึงเป็นโปรแกรมเมอร์ที่ยอดเยี่ยมและค่อนข้างฉลาดนอกจากนี้
เมื่อเร็ว ๆ นี้ฉันมีการสัมภาษณ์ซึ่งผู้สัมภาษณ์ถามฉันว่าฉันจะเขียนโค้ดการดำเนินการเฉพาะได้อย่างไรและเขาก็พูดว่า "แค่แสดงคณิตศาสตร์ให้ฉันดู" ก่อนอื่นฉันต้องคิดเกี่ยวกับปัญหาก่อนเพื่อให้ได้คณิตศาสตร์มาก่อน สิ่งที่ฉันวางไว้บนกระดานไวท์บอร์ดในตอนแรกนั้นน่าอายและฉันรู้สึกว่าฉันแพ้ ณ จุดนั้น ในที่สุดฉันก็ได้เวลา A-ha และพบคำตอบ (จริง ๆ แล้วมันเกิดขึ้นกับฉันในที่สุดสิ่งที่เขาถามจริง ๆ ) แต่ "ความยุ่งเหยิง" ฉันทำก่อนที่ฉันจะไปถึงที่นั่นทำให้ฉันรู้สึกไม่สบายใจมาก อย่างไรก็ตามฉันได้งาน แต่ถ้าผู้สัมภาษณ์มีความอดทนน้อยฉันก็อาจไม่มี
ฉันคิดว่าถ้าคุณให้รหัสผู้สัมภาษณ์ให้เวลากับพวกเขาในการทำงานกับคอมพิวเตอร์บางทีแม้แต่ใน IDE ที่พวกเขาคุ้นเคย ปล่อยให้พวกเขาเขียนรหัสให้คุณแล้วพูดถึงมัน ถามพวกเขาว่าทำไมพวกเขาถึงทำสิ่งต่าง ๆ ด้วยวิธีใดวิธีหนึ่งและอาจไม่ดีกว่าอีกวิธีหนึ่ง คุณจะได้รับข้อมูลเพิ่มเติมจากกระบวนการแบบนั้นมากกว่าโดยขอให้พวกเขาฉี่ (เปรียบเปรยพูด) ลงในถ้วยตรงหน้าคุณ
ข้อด้อย: ไม่มี เมื่อใดก็ตามที่คุณใช้การตั้งค่าพีซีการออกแบบการทดสอบรหัสและการตรวจสอบจะช่วยลดอาการปวดหัวในอนาคต
ข้อดี: "เชื่อ แต่ยืนยัน" - Ronald Regan หลายครั้งที่ฉันเห็นและได้ยินผู้คนในที่สุดก็ปล่อยให้ไปจากตำแหน่งที่ซึ่งในการสัมภาษณ์คุณคิดว่าคุณได้รับดาวร็อค หลักฐานอยู่ในพุดดิ้ง; ฉันต้องการเห็นสิ่งที่พวกเขาสามารถทำได้ มันจะแสดงสิ่งที่เกิดขึ้นเมื่อคุณลงทุนเวลาและเงินจ้างคนและติดโครงการใหม่ต่อหน้าพวกเขา
จุดด้อย:
ข้อดี:
เมื่อฉันสัมภาษณ์งานปัจจุบันของฉันฉันได้รับรายการคำถามเพื่อเขียนโค้ดสำหรับผู้สรรหา ฉันประทับใจมากเพราะคำถามถูกเขียนโดยคนที่มีความรู้เชิงลึกเกี่ยวกับ SQL ดังนั้นจึงใช้งานได้ทั้งสองวิธี
คุณจริงๆต้องการที่จะมีรหัสสมาชิกผู้เขียนในการสัมภาษณ์ - ดียิ่งขึ้นพวกเขาได้รับในการเขียนโปรแกรมคู่กับสมาชิกในทีมของคุณสำหรับจำนวน X เวลา (สิ่งที่คุณสามารถจ่ายได้ในเวลา / กำลังคน)
มันเป็นวิธีการเดียวที่คุณสามารถบอกได้ว่าบุคคลนั้นสามารถใช้รหัสได้หรือไม่
ฉันชอบการเขียนโปรแกรมคู่มากขึ้นเพราะมันจะแสดงให้เห็นว่าการทำงานเป็นทีมของพวกเขาทำให้พวกเขามี IDE ที่แท้จริงในการทำงานและช่วยให้พวกเขาทำงานกับปัญหา 'ของจริง' (คนอื่น ๆ ในคู่สามารถแนะนำพวกเขา ไม่มีเหตุผลพอที่จะรู้)
เราเริ่มใช้นโยบายการจ้างงานนี้และเราพอใจกับผลลัพธ์มาก
คุณตัดสินนกด้วยขนนกและโปรแกรมเมอร์โดยใช้รหัสของเขา / เธอ
เมื่อฉันเริ่มต้นกับ บริษัท ปัจจุบันฉันทำงานให้พวกเขาขอให้ฉันเขียนรหัส C ที่สร้างหรือตรวจสอบบิตพาริตี้ของอินพุตไบนารี่บางบิต (ขึ้นอยู่กับว่าคุณกำลังเข้ารหัสหรือถอดรหัส) นี่เป็นคำถามสัมภาษณ์เพราะปัญหาเหล่านี้ได้รับการแก้ไขระหว่างการทำงาน แน่นอนฉันกำลังคิดว่าจะไม่ตรวจสอบความเท่าเทียมกัน แต่ทำงานในระดับต่ำ
คำตอบทั้งหมดจนถึงขณะนี้ (ที่ฉันอ่าน) ไม่ได้ระบุความจริงที่ว่าJoel Test ไม่ใช่แค่รายการฝึกหัดที่ดีที่สุดสำหรับผู้ประกอบการแต่รายการตรวจสอบเพื่อช่วยให้คุณประเมินนายจ้างที่คาดหวังได้ง่ายขึ้น
สิ่งคือ ... หากพวกเขาทดสอบผู้สมัครอย่างละเอียดพวกเขาอาจจ้างคนที่รู้จักสิ่งของ ... นั่นหมายถึงคุณ
แทนที่จะแก้ไขข้อผิดพลาดหลังจากพวกเขา ...
ฉันจะพูดว่า:
ข้อดี
จุดด้อย
Reverseวิธีการในตัวหรือที่คล้ายกันหรือสำหรับการทดสอบเป็นลายลักษณ์อักษรเช่น" อะไรคือข้อโต้แย้งกับFooวิธีการของBarชั้นเรียน "เมื่อคนงี่เง่าใด ๆ สามารถ Google ที่หรือใช้เอกสารประกอบ) เมื่อเทียบกับคำถามสถาปัตยกรรม / การออกแบบที่แสดง ผู้สมัครสามารถทำสิ่งต่างๆและแก้ไขปัญหาทางธุรกิจได้โปรหนึ่งคือมันแสดงให้เห็นว่าใครบางคนมีความรู้พื้นฐานของการเขียนโปรแกรมหรืออะไรก็ตาม (ครั้งสุดท้ายที่ฉันพบว่าฉันรู้สึกประหลาดใจที่คำถาม SQL ขั้นพื้นฐาน) นอกจากนี้ยังสามารถใช้เป็นพื้นฐานสำหรับการอภิปรายทางเทคนิคถามว่าทำไมผู้สมัครจึงทำเช่นนั้นและเช่นนั้นและจะปรับปรุงได้อย่างไร
ต้องใช้เวลาในการสัมภาษณ์ซึ่งสามารถใช้กับสิ่งอื่นได้ ยิ่งไปกว่านั้นการเขียนโค้ดบนไวท์บอร์ดไม่ใช่สภาพแวดล้อมทางธรรมชาติและบางคนจะมีปัญหามากขึ้นและน้อยลง มันอาจทำให้คุณพลาดนักพัฒนาซอฟต์แวร์ที่เพิ่งกังวลโดยไม่มีเครื่องมือหรือการอ้างอิงปกติ
การเขียนโปรแกรมเป็นทักษะทางเทคนิคขั้นสูงพร้อมด้วย "การส่งมอบ" ที่ชัดเจน ผู้สมัครสามารถส่งหรือไม่สามารถส่งได้ ดังนั้นจึงไม่มี "ข้อเสีย" ในการถามคำถามทางเทคนิค ทั้งหมดนี้มีไว้เพื่อกล่าวว่า "แสดงรหัสให้ฉันสำหรับแอปพลิเคชันนี้หรือ" แสดงรหัสให้ฉันสำหรับแอปพลิเคชันที่คุณได้เขียนไว้แล้ว "
การไม่ทำเช่นนั้นอาจนำไปสู่ผลลัพธ์เช่นนี้: คนรวยสัมภาษณ์ติวเตอร์เพื่อสอนลูก ๆ ของเขาให้เล่นหมากรุก ครูสอนพิเศษเปิดกระดานหมากรุกและเริ่มพูดถึง 64 ตาราง แต่ไม่ได้สัมผัสชิ้นหมากรุก เมื่อเวลาผ่านไปพ่อก็จ้างติวเตอร์ และผู้สอนก็สอนเด็ก ๆ ให้เล่น CHECKERS