over-engineering เป็นสัญญาณเตือนหรือไม่ [ปิด]

ดังนั้นเราจึงนำเสนอแบบฝึกหัดการเข้ารหัสที่ตรงไปตรงมากับผู้สมัครใหม่ที่มีข้อกำหนดที่กำหนดไว้อย่างดี บางครั้งเราได้รับการแก้ปัญหาซึ่งไม่สามารถแก้ปัญหาได้จริง ๆ แต่ถูกออกแบบมาเพื่อแก้ไขปัญหาที่รับรู้ - บ่อยครั้งที่อยู่นอกขอบเขตของการฝึก

ตอนนี้คำถามของฉันคือนี่เป็นสัญญาณเตือนภัยหรือไม่?

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

IMHO เมื่อฉันสัมภาษณ์มันเป็นการออกกำลังกายที่สมบูรณ์ที่สุดที่ฉันพบ

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

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

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

ฉันจะบอกว่านี่เป็นสัญญาณเตือนที่ชัดเจน แต่ไม่จำเป็นต้องตัดสิทธิ์ผู้สมัคร

มีสองปัญหาแยกกันที่ผู้สมัครดูเหมือนจะมี:

1. พลาดจุดของการออกกำลังกาย - นี่เป็นเรื่องที่น่าตกใจ ทักษะการเขียนโปรแกรมทั้งหมดในโลกจะไม่สร้างผลลัพธ์ที่ดีหากมีคนไม่สามารถแก้ปัญหาที่พวกเขากำลังแก้ไขได้อย่างถูกต้อง ฉันพบว่าวิศวกรที่มีประสิทธิผลมากที่สุดคือคนที่สามารถระบุปัญหาที่แท้จริงที่จะแก้ไขแม้ว่ามันจะไม่ใช่ปัญหาที่เกิดขึ้นก็ตาม การมีความสามารถในการคิดวิเคราะห์อย่างถี่ถ้วนเกี่ยวกับคำถามที่ถูกถามและอาจปรับเปลี่ยนเป็นสิ่งที่ง่ายกว่าในการแก้ปัญหาเป็นทักษะที่สำคัญ ไม่มีจุดเมื่อปัญหาระบุอย่างชัดเจนควรเป็นธงสีแดงขนาดใหญ่
2. การ overengineering วิธีแก้ปัญหา - นี่เป็นปัญหารองและมักจะเป็นผลลัพธ์ของปัญหาแรก มีโรคที่แตกต่างกันสองสามอย่างที่สามารถมีผลลัพธ์นี้ ก่อนอื่นไม่เข้าใจปัญหาอย่างถ่องแท้หรือการคัดเลือกอย่างกว้างเกินไปอาจส่งผลให้เกิดวิธีการแก้ปัญหาที่ซับซ้อนเกินไป เรื่องนี้เกี่ยวข้องอย่างชัดเจนกับประเด็นแรกข้างต้น ประการที่สองพยายาม "อวด" โดยคิดผ่านสถานการณ์ในอนาคตที่อาจไม่เกี่ยวข้องกันจริงๆ นี่อาจเป็นปัญหาได้เพราะมันบ่งบอกว่าผู้สมัครไม่เข้าใจคุณค่าของความเรียบง่ายในการแก้ปัญหาและชะลอความซับซ้อนจนกว่าจะมีความจำเป็นอย่างแท้จริง นี่คือสิ่งที่สามารถแก้ไขได้ด้วยคำแนะนำที่ดี แต่ต้องระวังเมื่อนำใครบางคนเข้ามาในองค์กร

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

ลองทบทวนปัญหาอีกครั้งด้วยตัวเองและดูว่ามันอาจไม่ชัดเจนและอาจทำให้คนอื่นหลงทางผิดในขณะที่พวกเขาสร้างคำตอบ

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

นี่คือบางสิ่งที่อยู่ด้านบนของหัวของฉันซึ่งความต้องการของคุณอาจไม่ได้กล่าวถึง:

• มาตรฐานการเข้ารหัส

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

• การจัดการข้อยกเว้น

• ชื่อที่สื่อความหมายตัวแปรคลาสวิธีการ

• การใช้ภาษาตามสำนวน

• การออกแบบเชิงวัตถุที่เหมาะสม

• ให้ความสนใจกับปัญหาการเกิดพร้อมกันที่เป็นไปได้

• การเขียนกรณีทดสอบสำหรับรหัส

คุณสนใจสิ่งเหล่านี้เพียงอย่างเดียวโดยไม่ระบุอย่างชัดเจนหรือไม่? ผู้สมัครจะรู้ได้อย่างไรว่าคนที่คุณห่วงใยและที่คุณไม่รู้

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

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

IMHO คำตอบนั้นชัดเจนใช่มันเป็นสัญญาณเตือนถ้า

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

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

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

สมมติว่าการฝึกเขียนรหัสไม่ทำให้เกิดความวุ่นวายอย่างมากดูเหมือนว่าวิธีที่เขาล้มเหลวคือการตีความปัญหาผิด ๆ และออกไปสู่วัชพืชที่พยายามแก้ไขปัญหาที่ไม่ได้อยู่ที่นั่น ใช่นั่นเป็นสัญญาณเตือน

อาจจะ.

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

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

หากวิธีการแก้ปัญหานั้นถูกต้องก็จะมีความชัดเจนน้อยลง โดยส่วนตัวแล้วฉันคิดว่าผู้คนจำนวนมากพาYAGNIไปไกลเกินไป หากคุณสามารถใช้ปัญหาที่เฉพาะเจาะจงและสร้างโซลูชันทั่วไปโดยไม่เพิ่มความซับซ้อนหรือเป็นอันตรายต่อการบำรุงรักษาทำไมไม่สร้างโซลูชันทั่วไป (คิดว่าการย้อนกลับสตริงเทียบกับการย้อนกลับคอลเลกชันใด ๆ ) การเรียงลำดับของ "over-engineering" นั้นดีในความคิดของฉัน

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

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

อาจแต่พิจารณาสิ่งต่อไปนี้:

• การสัมภาษณ์ยาก:ผู้คนตกอยู่ภายใต้ความเครียด สิ่งนี้ควรนำมาพิจารณาอย่างจริงจังในปัญหาที่คุณให้กับใครบางคน

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

• บางครั้ง Less is More:ฉันอยากจะมีสัญลักษณ์แสดงหัวข้อย่อยประโยคและหรือตัวอย่างที่แสดงความต้องการหลักและจากนั้นการสนทนากับใครซักคนเพื่อถามคำถามและอาจยื่นมือออกไปหากจำเป็น ฉันเดาว่าสิ่งที่ฉันพยายามจะพูดคือคุณควรตรวจสอบข้อกำหนดการทดสอบของคุณก่อนว่าไม่ซับซ้อนเกินไปสำหรับปัญหาง่ายๆ

• ทักษะการสื่อสาร:คุณควรทดสอบความสามารถของผู้สมัครในการสื่อสารและถามคำถามที่ชาญฉลาดเกี่ยวกับปัญหาก่อนและเมื่อคุณรู้ว่าพวกเขาแสดงให้เห็นว่าพวกเขาเข้าใจปัญหาแล้วคุณสามารถกำหนดพวกเขาในการดำเนินการ

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

สิ่งเหล่านี้อาจเกิดจากวิธีที่คุณพูดคำถามและวิธีการสัมภาษณ์ทั้งหมดในมุมมองของคุณ

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

มีวิธีที่จะดูว่าใครบางคนมีแนวโน้มที่จะเป็นสิ่งที่ over-engineering ยกตัวอย่างโค้ดของบางสิ่งที่ซับซ้อนเกินไปและขอวิธีแก้ไขที่ง่ายกว่า เมื่อมีคนเสนอวิธีแก้ปัญหาที่คุณไม่คิดว่าจะได้ผลนี่เป็นโอกาสที่ดีในการดูว่าพวกเขาโต้ตอบกับการวิจารณ์อย่างไร โดยส่วนตัวแล้วฉันต้องการเห็นคนที่เปิดรับความคิดใหม่ ๆ และปรับแก้ปัญหาให้ดีขึ้นกว่าคนที่จะทำผิดพลาดซ้ำแล้วซ้ำอีก

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

มันขึ้นอยู่กับ แต่โดยทั่วไปแล้วไม่

การออกแบบโดยทั่วไปเป็นทักษะที่เรียนรู้ด้วยประสบการณ์ คำอธิบายความก้าวหน้าของ Aaronaughtที่เชื่อมโยงโดย Marjan เป็นสิ่งที่ดี

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

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

เมื่อพิจารณาถึงความก้าวหน้าข้างต้นผู้สมัครที่มีวิธีแก้ปัญหาแบบวิศวกรรมเกินอาจจะดีกว่าผู้สมัครด้วยวิธีง่ายๆ

นอกจากนี้: คุณกำลังจ้างตำแหน่งระดับใด วิศวกรรมที่เกินจากรายการหรือผู้สมัครระดับกลางมีปัญหาน้อยกว่าวิศวกรรมที่เกินจากผู้สมัครระดับอาวุโส

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

หากโปรแกรมเมอร์แก้ปัญหา แต่เพิ่มรหัสเพิ่มเติมให้พิจารณาพื้นหลังของโปรแกรมเมอร์เนื่องจากพื้นที่บางส่วนของการเขียนโปรแกรมต้องการความอดทนมากกว่าคนอื่น ๆ

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