Tại sao câu hỏi đưa ra năm điều bạn ghét về C # Cảnh rất khó trả lời trong một cuộc phỏng vấn? [đóng cửa]

Trong podcast 73 , Joel Spolsky và Jeff Atwood thảo luận, trong số các chủ đề khác, "năm điều mọi người nên ghét về ngôn ngữ lập trình yêu thích của họ":

Nếu bạn hài lòng với chuỗi công cụ hiện tại của mình, thì không có lý do gì bạn cần phải chuyển đổi. Tuy nhiên, nếu bạn không thể liệt kê năm điều bạn ghét về ngôn ngữ lập trình yêu thích của mình, thì tôi cho rằng bạn chưa biết rõ về nó. Thật tốt khi biết các lựa chọn thay thế và có một con mắt quan trọng lành mạnh cho bất cứ thứ gì bạn đang sử dụng.

Vì tò mò, tôi đã hỏi câu hỏi này với bất kỳ ứng viên nào tôi đã phỏng vấn. Không ai trong số họ có thể trích dẫn ít nhất một điều họ ghét về C #.

Tại sao? Có gì khó khăn trong câu hỏi này? Có phải vì bối cảnh căng thẳng của cuộc phỏng vấn mà câu hỏi này không thể trả lời được bởi người được phỏng vấn?

Có điều gì đó về câu hỏi này làm cho nó xấu cho một cuộc phỏng vấn?

Rõ ràng, điều đó không có nghĩa là C # là hoàn hảo. Tôi có cho mình một danh sách năm điều tôi ghét về C #:

• Việc thiếu số lượng các loại khác nhau trong tổng quát (tương tự như paramsđối số).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ Nghiêm túc ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• Việc thiếu hỗ trợ cho các đơn vị đo lường, như trong F #.

• Việc thiếu các thuộc tính chỉ đọc. Viết một private readonlytrường sao lưu mỗi khi tôi muốn một thuộc tính chỉ đọc là nhàm chán.

• Việc thiếu các thuộc tính với các giá trị mặc định. Và vâng, tôi biết rằng tôi có thể khởi tạo chúng trong hàm tạo không tham số và gọi nó từ tất cả các hàm tạo khác. Nhưng tôi không muốn.

• Đa thừa kế. Có, nó gây nhầm lẫn và bạn không cần nó trong hầu hết các trường hợp. Nó vẫn hữu ích trong một số trường hợp (rất hiếm) và sự nhầm lẫn cũng áp dụng (và đã được giải quyết trong C #) cho lớp kế thừa một số giao diện có chứa các phương thức có cùng tên.

Tôi khá chắc chắn rằng danh sách này còn lâu mới hoàn thành, và có nhiều điểm cần làm nổi bật hơn, và đặc biệt là những điểm tốt hơn nhiều so với danh sách của tôi.

^{Một số người chỉ trích một số hội đồng trong .NET Framework hoặc thiếu một số thư viện trong khung hoặc chỉ trích CLR. Điều này không được tính, vì câu hỏi là về chính ngôn ngữ và trong khi tôi có khả năng có thể chấp nhận câu trả lời về điều gì đó tiêu cực trong lõi của .NET Framework (ví dụ như một cái gì đó giống như thực tế là không có giao diện chung cho TryParse, vì vậy nếu bạn muốn phân tích một chuỗi thành nhiều loại, bạn phải lặp lại chính mình cho mọi loại), một câu trả lời về JSON hoặc WCF là hoàn toàn lạc đề.}

Nếu tôi phải đoán:

1. Một số lập trình viên thiếu tiếp xúc ngôn ngữ đa dạng. Thật khó để nhìn thấy những điều sai với ngôn ngữ khi bạn không biết rằng những điều tốt hơn tồn tại.

2. Một số lập trình viên chỉ là những con khỉ mã. Họ hầu như không phân tích các vấn đề trước mặt, chứ đừng nói gì đến việc ngôn ngữ lập trình của họ có thể tốt hơn như thế nào.

3. Rất ít người đặc biệt quan trọng. Họ thấy lợi ích và tính năng, không thiếu sót. Thật khó để họ chuyển sang chế độ suy nghĩ đó nếu cuộc phỏng vấn không diễn ra như vậy.

4. Ít nhất là xung quanh đây, bị chỉ trích quá mức được coi là một lỗ hổng cá tính gây tử vong. Thay vì là 'nhà phát triển sâu sắc luôn tìm cách làm việc tốt hơn' (như một số lĩnh vực tôi từng sống), họ là 'tên khốn đó ghét mọi thứ'. Ngay cả những người có thể nghĩ về những điều họ ghét trong ngôn ngữ cũng có thể trì hoãn trong một thiết lập cuộc phỏng vấn để có vẻ ít acerbic hơn.

Tôi sẽ tưởng tượng rằng câu hỏi rất khó trả lời trong một cuộc phỏng vấn bởi vì nó:

1. Thật bất ngờ,

2. Yêu cầu rất nhiều suy nghĩ và suy nghĩ theo một cách rất khác với cách sử dụng trong một cuộc phỏng vấn,

3. Rất khó để trả lời nói chung trong một khoảng thời gian ngắn (trừ khi được chuẩn bị trước khi phỏng vấn).

1. Thật bất ngờ

Những câu hỏi bất ngờ thực sự khó, đặc biệt là trong bối cảnh căng thẳng. Hãy tưởng tượng hộp thoại sau trong một cuộc phỏng vấn:

- Sự khác biệt giữa HashSet<T>và là List<T>gì?
- Băm được tối ưu hóa theo cách mà việc tìm kiếm một phần tử rất nhanh. Ví dụ: nếu bạn đang sử dụng set.Contains()trong vòng lặp nhiều lần, việc chuyển settừ danh sách sang hàm băm có thể giúp mọi việc nhanh hơn.
- Làm thế nào để bạn tạo một tài sản chỉ đọc?
- Tôi sử dụng một trường được đánh dấu làreadonly trường sao lưu cho một thuộc tính chỉ có một getter.
- Công dụng của là sealedgì?
- Bạn sử dụng nó cho các lớp không được kế thừa.
- Lần cuối cùng bạn gặp nha sĩ là gì?
- Gì?!

2. Nó đòi hỏi rất nhiều suy nghĩ khác nhau

Khi bạn được hỏi những câu hỏi kiểu phỏng vấn chung, bạn đang sử dụng bộ nhớ của mình để nhớ lại những gì bạn đã học được từ sách hoặc từ thực tiễn của bạn về ngôn ngữ và khuôn khổ. Bạn có thể suy nghĩ một chút để tìm câu trả lời, nhưng không quá nhiều.

Mặt khác, câu hỏi về năm điều bạn ghét đòi hỏi một suy nghĩ sâu sắc hơn. Bạn không thể nhớ lại những gì bạn đã học được từ sách và bạn không thể tìm thấy bất cứ điều gì bằng cách tương tự. Thay vì thụ động, bạn phải phê bình và tìm những gì có thể khó chịu trong ngôn ngữ bạn sử dụng.

3. Nó đòi hỏi thời gian

Thành thật mà nói, tôi có danh sách năm điều (thực sự nhiều hơn) tôi ghét về C #, nhưng tôi đã nghĩ về nó trong một khoảng thời gian dài. Một vài điều là từ thời đại .NET Framework 2; hầu hết các vấn đề tôi liệt kê cho .NET Framework 2 không còn hợp lệ vì chúng đã bị xóa, một số vấn đề với LINQ và tất cả các công cụ lập trình chức năng này, một số khác với lập trình động. Tôi không chắc chắn, nếu không chuẩn bị câu hỏi này, tôi có thể tìm thấy tất cả năm yếu tố trong một cuộc phỏng vấn.

Tôi nghĩ nó khó vì từ năm . Và ở mức độ thấp hơn, vì từ ghét .

Năm ? Điều gì nếu bạn chỉ đến với bốn? Bạn đã không trả lời câu hỏi? Nếu bạn có nhiều hơn năm thì sao? Bây giờ, tại chỗ, bạn phải tìm ra cái nào trong số năm cái tốt nhất để sử dụng.

Ghét là một từ rất tiêu cực. Đó là loại tiêu cực mà mọi người được khuyên nên tránh trong các cuộc phỏng vấn. Hơn nữa, tôi nghĩ sẽ có vẻ kỳ quặc với nhiều người khi có nhiều điều họ "ghét" về ngôn ngữ mà họ sẽ dành cả ngày để lập trình. Một số người thậm chí có thể nghĩ đó là một câu hỏi mẹo: Nếu họ thực sự làm đi với năm điều, họ sẽ bị loại vì ghét C # quá nhiều để lập trình tốt. Thật không may, loại câu hỏi lừa đảo này không phải là chưa từng nghe trong các cuộc phỏng vấn.

Thay vào đó, bạn có thể hỏi Bạn sẽ cải thiện điều gì về C # nếu điều đó tùy thuộc vào bạn? Điều này cho phép người được phỏng vấn trả lời với bất kỳ số lượng điều. Phrasing này cũng đánh đổi sự tiêu cực của từ "ghét" cho "cải thiện" tương đối tích cực.

• Hầu hết các ứng cử viên không liên quan sâu sắc đến nhiều hơn một ngôn ngữ hoặc mô hình để tương phản với ngôn ngữ . Tôi đã không làm việc với một ngôn ngữ hướng đối tượng khác trong hơn 5 năm nay và ngôn ngữ tôi đã làm việc trong (PowerBuilder), tôi đã có rất nhiềucủa peeves với. Hầu hết các chàng trai mới ra trường là (hoặc nghĩ rằng họ) những thứ nóng bỏng ở một, có thể là hai ngôn ngữ và đã nhận được "tiếp xúc" với ba hoặc bốn hơn (có nghĩa là họ đã hoàn thành ít nhất một bài tập về nhà yêu cầu nhưng ít hơn một học kỳ đầy đủ Tất nhiên học nó). Đó là không đủ kiến ​​thức hoặc kinh nghiệm để thực sự biết những gì sai với ngôn ngữ. Nhận một công việc trong thế giới thực, và sự tập trung đó thu hẹp đáng kể; bạn học được nhiều hơn về ngôn ngữ giúp bạn được trả lương hơn bất kỳ ngôn ngữ nào khác và trong quá trình đó, bạn đến để chấp nhận những gì ngôn ngữ sẽ không làm, hoặc làm theo cách kỳ lạ, đến mức bạn không thể nhớ làm nó khác đi

• Hầu hết các ứng cử viên C # -savvy so sánh nó với Java / C / C ++ đều khá hài lòng với nó . C # được thiết kế từ đầu để làm nhiều thứ tốt hơn Java (các sự kiện, cuộc gọi lại, thư viện đồ họa, cơ sở dữ liệu). Lần lượt Java được thiết kế để dễ sử dụng hơn và tập trung vào mã chính xác hơn so với C ++. Tôi chưa gặp một lập trình viên C # nào muốn quay lại C ++ trong bất kỳ môi trường nào mà hiệu suất phồng rộp và điều khiển gần mức mạch không phải là điều cần thiết quan trọng.

Nói cách khác, See-Sharpers có nó khá tốt, tất cả mọi thứ được xem xét.

Đây là danh sách của tôi:

• Tuyên bố Lambda không thể xem / đánh giá . Các cuộc gọi đến các phương thức được đặt tên có thể được cắm vào QuickWatch của VS. Vì vậy, có thể biểu hiện. Nhưng lambdas? Không (ít nhất là không trong VS2010). Làm cho gỡ lỗi chuỗi Linq là một việc vặt thực sự.

• Các giá trị tham số tùy chọn cho các loại tham chiếu khác với chuỗi chỉ có thể là null . nếu tôi đang tạo một ngăn xếp quá tải, tôi có thể muốn sử dụng các giá trị mặc định khác. Tôi có thể có thể mặc định một giá trị dựa trên thuộc tính hoặc biểu thức đơn giản dựa trên tham số khác. Nhưng tôi không thể. Vì vậy, giá trị của việc không phải tạo ra một ngăn xếp quá tải (không đáng kể với một trợ lý tái cấu trúc như ReSharper để xử lý nồi hơi) bị giảm đi khi các tùy chọn cho các tham số tùy chọn bị hạn chế rất nhiều.

• C # đang trở nên đủ tuổi để có các vấn đề mã di sản nghiêm trọng . Mã ban đầu được viết cho 1.1 sẽ khiến bất cứ ai sử dụng 4.0 phải co rúm lại trong nỗi kinh hoàng. Ngay cả mã 2.0 cũng bỏ lỡ rất nhiều. Đồng thời, các thư viện của bên thứ ba đã xuất hiện khiến những thứ như ADO.NET có vẻ thô sơ (và phần lớn "mô hình được kết nối" của ADO.NET hiện là một mô hình chống lớn). Tuy nhiên, để tương thích ngược, các schleps .NET cùng hỗ trợ cho tất cả mã cũ, xấu này, không bao giờ dám nói điều gì đó như "ArrayList là một cách ngu ngốc để làm điều đó, chúng tôi xin lỗi, chúng tôi đã từng đưa nó vào và chúng tôi đang sử dụng thay thế, sử dụng Danh sách thay thế và nếu bạn thực sự cần một danh sách các loại khác nhau, hãy khai báo nó dưới dạng List<Object>.

• Nghiêm túc giới hạn quy tắc tuyên bố chuyển đổi . Có lẽ một trong những điều tốt nhất tôi có thể nói về PowerBuilder là câu lệnh Chọn trường hợp (tương đương với chuyển đổi) cho phép các biểu thức Boolean dựa trên biến. Nó cũng cho phép các câu lệnh chuyển đổi rơi qua ngay cả khi chúng có mã. Tôi hiểu lý do tại sao cái thứ hai không được phép (nó có thể được thực hiện ngoài ý muốn hơn là mục đích) nhưng thỉnh thoảng vẫn sẽ rất hay để viết một tuyên bố như:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• Không có giao diện INumeric . Nếu đó là một con số, bạn có thể làm toán với nó. Trong nhiều trường hợp, phương thức thực tế không phải quan tâm chính xác loại nào được cắm vào; độ chính xác là trách nhiệm của người gọi. Tuy nhiên, không thể tạo một phương thức hoặc lớp chung chỉ có thể chấp nhận các loại số là GTP.

Tôi đề nghị rằng một phần của vấn đề là sợ đưa ra một câu trả lời tồi - bạn nói rằng bạn ghét X, người phỏng vấn yêu X hoặc nghĩ rằng lý do của bạn ghét X là ngu ngốc, nói rằng bạn nghĩ nó có vẻ không phải là lựa chọn ít gây tranh cãi.

Đây có lẽ cũng là điều mà hầu hết mọi người không thực sự suy nghĩ nhiều; họ có những vấn đề hiện tại và những vấn đề trong quá khứ, những vấn đề trong quá khứ do langauge gây ra đã kết thúc và vì vậy mọi người chủ yếu nghĩ về giải pháp chứ không phải vấn đề vì điều đó quan trọng hơn, và sẽ có một vấn đề hiện tại do ngôn ngữ gây ra.

Đối với một cuộc phỏng vấn tôi sẽ chỉ yêu cầu 1 hoặc 2, nhưng tôi đồng ý, nếu bạn không thể đặt tên cho bất kỳ giới hạn nào của công cụ bạn sử dụng, thì có lẽ bạn không biết rõ về nó. Chúng tôi hỏi câu hỏi chính xác này về SSIS và nó thực sự giúp tách lúa mì ra khỏi vỏ; tất cả mọi người chúng tôi đã thuê người trả lời câu hỏi này cũng trở thành một nhân viên tuyệt vời. Chúng tôi cần những người có kiến ​​thức nâng cao Actaul chứ không phải ai đó đã xem xét nó một vài lần. Và tôi sẽ đặt cược đó là những gì bạn muốn quá.

Tôi nghĩ đó là một câu hỏi hợp lệ và thực tế là rất nhiều người không thể trả lời nó chỉ là một ví dụ về việc nhiều ứng cử viên cho công việc thực sự nghèo như thế nào. Nếu ai đó không đủ khả năng phân tích để có thể tìm ra một số hạn chế của công cụ, làm thế nào họ có thể phân tích đủ để giải quyết các vấn đề lập trình khó khăn?

Nó giống như bạn nói thiếu kinh nghiệm chuyên sâu với C # và / hoặc thiếu tiếp xúc với các ngôn ngữ khác. Tôi đã phỏng vấn một số nhà phát triển, những người tự coi mình là người cao cấp, những người không thể trả lời một số câu hỏi mà ngay cả một vết xước nhẹ trên bề mặt của C # cũng nên tiết lộ cho họ.

Nếu không đào đủ, bạn sẽ không đạt đến giới hạn của ngôn ngữ và ước rằng chúng đã biến mất. Năm đầu của tôi trong trường hợp bất cứ ai thắc mắc

1. Các đối tượng bất biến đòi hỏi rất nhiều nghi lễ để tạo ra (trái ngược với một ngôn ngữ chức năng nơi các đối tượng là bất biến theo mặc định).
2. Metaprogramming rất khó để làm. So sánh loại phát ra với macro Lisp. (Dịch vụ biên dịch sẽ giúp rất nhiều cho việc này trong tương lai).
3. Các phương thức mở rộng là tuyệt vời ... thuộc tính mở rộng và toán tử mở rộng (cụ thể là toán tử ẩn và rõ ràng) sẽ tốt hơn.
4. Các biểu mẫu rõ ràng được giải quyết tại thời gian biên dịch thay vì thời gian chạy.
5. Không có trình tự phù hợp Nó sẽ sạch hơn rất nhiều so với chức năng quá tải.

Tôi nghĩ trong vòng của anh ấy về cách anh ấy nói; nếu bạn nghĩ nó bị hỏng thì có lẽ bạn không hiểu tại sao nó lại như vậy. Có thể có một lỗ hổng trong kiến ​​thức của bạn.

Trớ trêu thay, những người phỏng vấn nghĩ rằng họ đang trích dẫn "Joel vĩ đại" bằng cách sử dụng nó như một câu hỏi phỏng vấn có lẽ khá thiếu quan điểm.

Họ có thể miễn cưỡng trả lời vì họ có thể ấn tượng rằng nếu họ có thể liệt kê 5 điều họ ghét về ngôn ngữ, người phỏng vấn có thể quay lại và nói 'Ồ, chúng tôi đang tìm kiếm C #' ninja 'và bạn dường như không thích ngôn ngữ 'hoặc' Tại sao bạn lại xin việc nếu bạn không thích ngôn ngữ này? '.

Người được phỏng vấn chịu nhiều áp lực để duy trì sự tích cực trong các cuộc phỏng vấn.

Bởi vì ngôn ngữ định hình cách chúng ta suy nghĩ . Bằng cách sử dụng C # hàng ngày, bạn đã có thói quen suy nghĩ và thiết kế mã của mình theo cách tự nhiên hoạt động xung quanh các vấn đề của ngôn ngữ.

Bây giờ bạn làm điều đó mà không cần suy nghĩ, thậm chí không biết rằng bạn làm điều đó. Đây là lý do tại sao rất khó để chỉ ra những điều xấu là gì. Không còn nghi ngờ gì nữa, ngày bạn bắt đầu học C #, bạn đã tìm thấy rất nhiều vấn đề, nhưng bây giờ bạn không còn thấy chúng nữa. Thói quen là những thứ mạnh mẽ. Thói quen suy nghĩ, thậm chí nhiều hơn .

Mặt tích cực của điều này là, nếu bạn cảm thấy khó khăn khi liệt kê các lỗ hổng trong C #, thì đó phải là vì bạn là một lập trình viên C # giỏi, bạn thích ngôn ngữ và sử dụng nó nhiều hơn các ngôn ngữ khác.

Nhưng nếu bạn muốn trở nên có khả năng nhìn thấy các lỗ hổng trong C #, bạn phải thay đổi cách suy nghĩ của mình. Tìm hiểu thêm ngôn ngữ lập trình và làm quen với chúng. Nhằm mục đích cho các ngôn ngữ khác nhau nhất có thể. Bạn đã quen gõ tĩnh? Hãy thử Python hoặc Ruby. Bạn đã quen với hướng đối tượng và mệnh lệnh? Haskell là một thế giới hoàn toàn khác.

Và khi bạn quay lại C #, bạn sẽ thấy, "Tại sao tôi cần một trăm dòng C # để làm điều đơn giản này chỉ là một dòng trong Haskell?". Bạn sẽ ghét rất nhiều thứ về C #.

• C # không có các loại tham chiếu không thể rỗng.
• Không có loại dữ liệu đại số.
• Không có nội suy chuỗi.
• Cú pháp quá dài dòng ở khắp mọi nơi.
• Không có hệ thống vĩ mô.
• Kiểu suy luận bị hạn chế.
• Không có chữ viết tắt.
• Không gõ cấu trúc.
• Hỗ trợ kém cho sự bất biến.
• Cấu trúc C # dễ bị lỗi.
• Thư viện bộ sưu tập tiêu chuẩn rất hạn chế.
• Không thể xác định các ràng buộc về tham số của các nhà xây dựng.
• Không thể lập trình chung chung với các ràng buộc về toán tử toán học.
• Không có "newtype".
• Không cắt mảng, không có phạm vi chữ.
• Các chức năng không liệt kê các tác dụng phụ mà chúng có thể làm như là một phần của loại của chúng. :)

(Tất nhiên không có ngôn ngữ nào có thể có mọi thứ. Thiết kế ngôn ngữ là vô cùng khó khăn và việc thêm mọi tính năng vào cùng một ngôn ngữ không thể hoạt động. Các công cụ khác nhau cho các mục đích khác nhau.)

Vâng, câu hỏi rất khó để trả lời tốt, đặc biệt là trong một cuộc phỏng vấn. Nhưng những người có thể trả lời nó chứng minh rằng họ đã nghĩ về nó, rằng họ có một số quan điểm.