Làm thế nào để xử lý các câu hỏi phỏng vấn về phong cách lập trình [đóng]


11

Là một C ++ - lập trình viên trong các cuộc phỏng vấn, tôi liên tục thấy mình trong các tình huống là người phỏng vấn muốn thăm dò kiến ​​thức của tôi về phong cách lập trình tốt. Chúng thường tập trung vào kiến ​​thức cơ bản về OOP.

Tôi biết OOP rất hữu ích để đóng gói các khái niệm và tôi sử dụng nó hàng ngày. Tuy nhiên, vì một ngôn ngữ như C ++ cho phép nhiều phong cách khác nhau và một số cách tiếp cận C ++ như thuật toán TMP hoặc STL hoàn toàn không phải là OOP (mà giống như lập trình chức năng hơn), tôi thấy mình bị mắc kẹt trong cách "bán" kiến ​​thức về các phương pháp khác như tốt mà không đi qua như kiêu ngạo hoặc như một người nào đó mà không đánh giá cao những điều cơ bản. Tôi sợ sự nhấn mạnh này vào OOP của những người hỏi đến từ việc họ được xã hội hóa vào những năm 90 trong đó OOP được cho là thuốc chữa bệnh, nhưng đó là một quan điểm kiêu ngạo.

Làm thế nào tôi có thể làm tốt nhất các câu hỏi như thế này?


1
Chỉ có một vài khái niệm nhỏ về OOP cơ bản. Chuẩn bị một ví dụ mã đã sẵn sàng cho mỗi người trong số họ và bạn nên xóa hầu hết những điều này. Và vâng, một cuộc phỏng vấn chủ yếu là để thỏa mãn sự nghi ngờ của người phỏng vấn về kiến ​​thức của bạn về chủ đề này và đó là dịp tồi tệ nhất để có những khó khăn về ý thức hệ.
eminemence

Câu trả lời:


6

Tôi muốn nói rằng bạn phải cố gắng hết sức để trả lời loại câu hỏi này, giống như bạn nên làm hết sức mình để trả lời bất kỳ loại câu hỏi nào.

Sau này khi bạn có cơ hội đặt câu hỏi cho người phỏng vấn, bạn nên nâng cao chủ đề, đặt những câu hỏi như:

  • Bạn chỉ làm OOP?
  • Tôi sử dụng một phương pháp lập trình khác, làm thế nào nó được chấp nhận trong nhóm của bạn?

Và v.v.


5

Đừng lo lắng quá nhiều về động lực của người hỏi và chỉ cần trả lời trung thực. Hãy nhớ rằng, một cuộc phỏng vấn là một con đường hai chiều. Bạn không muốn bị mắc kẹt trong một công ty không linh hoạt về ý thức hệ hơn là họ muốn bị mắc kẹt với bạn.

Điều đó đang được nói, tôi nghĩ rằng bạn đang hơi hoang tưởng về ý định của người phỏng vấn. Một số lượng đáng kinh ngạc của các lập trình viên được cho là chuyên nghiệp không hiểu các nguyên tắc cơ bản của OOP. 99% thời gian, người phỏng vấn không cố gắng xem bạn có uống chất trợ giúp OOP hay không, mà chỉ muốn xem bạn có hiểu biết cơ bản về nó không. Ngay cả khi bạn cảm thấy một mô hình khác phù hợp hơn cho một giải pháp nhất định, người phỏng vấn muốn biết đó là một kết luận có căn cứ và không phải chịu sự thiếu hiểu biết về OOP.

Hợp lý hóa là một cơ chế bảo vệ rất phổ biến khi ai đó không hiểu điều gì đó. Nếu mọi người không hiểu một khái niệm, họ cho rằng khái niệm đó là ngu ngốc hoặc không thể áp dụng hơn là thừa nhận sự thiếu hiểu biết của chính họ. Ngay cả khi bạn thực sự nghĩ rằng OOP là một lựa chọn kém cho câu trả lời, bạn vẫn phải tự phân biệt mình với những người hợp lý hóa. Cách để làm điều đó là cả hai giải thích giải pháp OOP lý do tại sao bạn nghĩ rằng đó là một lựa chọn kém trong tình huống đó.


1
+1 cho các câu hỏi về phong cách phù hợp hơn với môi trường. . .
Wyatt Barnett

3

Tôi sẽ nhấn mạnh rằng bạn tuân theo nguyên tắc RẮN , đó là OOP và hơn thế nữa. Nó không chỉ đảm bảo rằng mã của bạn là hướng đối tượng, mà nó còn lỗi thời theo cách thay thế các đối tượng theo nguyên tắc RẮN là một nhiệm vụ tương đối đơn giản. Nó không chỉ gửi tin nhắn mà bạn biết OOP, mà nó còn chứng minh rằng bạn hiểu những điểm tinh tế về việc phân biệt mã OOP tốt với mã OOP phức tạp được viết bởi ai đó đã sử dụng để lập trình trong C và nghĩ rằng tất cả các ngôn ngữ khác nên được lập trình trong Thời trang tương tự, vì hãy trung thực, đó là điều khiến bạn trở thành một lập trình viên giỏi, không chỉ có thể sử dụng OOP.

Hãy chuẩn bị để giải thích cặn kẽ cho từng trong số năm nguyên tắc tại sao mỗi nguyên tắc lại quan trọng và điều gì có thể xảy ra với mã mà bỏ qua nguyên tắc đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.