OO Design câu hỏi liên quan trong các cuộc phỏng vấn kỹ thuật [đóng]

Gần đây tôi đã tham dự một vài cuộc phỏng vấn và được các công ty yêu cầu trả lời các câu hỏi "thiết kế [mô hình chèn]" nhiều lần.

1. Đây có phải là bình thường trong ngành công nghiệp ngày nay? Tôi đã ở trong thế giới phần mềm trong hơn hai thập kỷ và đã tham dự các cuộc phỏng vấn của tôi, nhưng tôi thấy mô hình này trong các cuộc phỏng vấn chỉ mới xuất hiện gần đây.
2. Tôi cảm thấy câu hỏi rất kết thúc. Ví dụ: Tôi được yêu cầu vẽ sơ đồ lớp để "Thiết kế bãi đỗ xe". Tôi không chắc mức độ chi tiết của người phỏng vấn đang mong đợi. Đây là một thử nghiệm trực tuyến nơi tôi dự kiến ​​sẽ đính kèm một sơ đồ thị giác, vì vậy tôi không thể hỏi họ kỳ vọng của họ là gì.
3. Bạn có sử dụng những loại câu hỏi trong quá trình phỏng vấn của bạn? Chúng có liên quan đến chỉ sơ đồ lớp hay bạn cũng hỏi trình tự, sơ đồ và ERD (tất nhiên dựa trên bản chất của vị trí) Chúng có hiệu quả trong quá trình tuyển dụng của bạn không?

* Chỉnh sửa cho phản hồi của Kevin *

Ví dụ: Một câu hỏi hoàn chỉnh có thể là "Thiết kế hệ thống quản lý bãi đỗ xe có thể được sử dụng để tìm các vị trí trống"

Tôi có thể được thực hiện với 2 lớp, ParkingLotvà Slothoặc tôi có thể tiếp tục thêm IVehiclevà Vehiclevà Carvà Motorcyclecác lớp học. Tôi vẽ đường này ở đâu?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Ở một mức độ nào đó, vâng. Bất cứ ai cũng có thể đọc cú pháp hoặc sao chép / dán theo cách của họ thông qua một giải pháp. Chúng tôi muốn thuê những người có thể giải quyết vấn đề.

2. Họ hy vọng bạn ghi lại thiết kế đầy đủ để họ có thể hiểu nó (và không nhiều hơn thế).

3. Tôi hỏi mọi người họ sẽ giải quyết vấn đề XYZ như thế nào, vâng. Thông thường họ chỉ mô tả nó bằng lời nói. Tôi muốn xem nếu họ đặt câu hỏi để làm rõ yêu cầu. Tôi muốn xem cách họ giao tiếp với các lập trình viên khác. Tôi muốn xem liệu họ có thể suy nghĩ trên đôi chân của họ.

Nó đã rất hữu ích cho tôi. Tôi không muốn khỉ mã, tôi muốn các kỹ sư phần mềm.

Tôi thấy những câu hỏi này khá ngớ ngẩn. Câu trả lời đúng là "các trường hợp sử dụng là gì?" Không có trường hợp sử dụng, không cần thiết kế nào cả. Ví dụ, đây là một câu trả lời hoàn toàn hợp lý cho câu hỏi về bãi đậu xe:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Nó đáp ứng một trường hợp sử dụng rõ ràng.

Bạn thực sự chứng minh một lần sử dụng câu hỏi này trong chỉnh sửa của bạn, nơi bạn không thiết kế một mô hình khả thi.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Bạn cũng đề cập đến việc tạo Carvà Motorcyclecác lớp, điều này không có nhiều ý nghĩa mà không cần xem xét thêm. Thiết kế của bạn sẽ không được hưởng lợi từ việc có phân lớp Vehicle. Nếu bạn giới thiệu Motorcyclemà không có bất kỳ sự khác biệt nào về hành vi Vehicle, tôi sẽ coi đó là một thất bại.

Nếu bạn không phát hiện ra Vehiclevấn đề duy nhất , thì chúng ta sẽ thực hiện được khá nhiều trong một cuộc phỏng vấn trực tiếp. Nếu bạn sửa nó (có thể bằng cách làm điều đó List<IVehicle>), tôi sẽ sử dụng điều này như một điểm khởi đầu để xem xét sự phát triển của thiết kế của bạn. Có một lý do các yêu cầu là cơ bản và không có trường hợp sử dụng nào được xác định rõ ràng - đó là cách mà thế giới hoạt động.

Tôi có thể đưa ra yêu cầu mới cho bạn rằng "hai chiếc xe máy có thể đỗ trong một khe" để xem cách bạn phát triển thiết kế của mình để xử lý nó. Sau đó, có lẽ chúng ta có một cuộc trò chuyện xung quanh đồng thời (Điều gì sẽ xảy ra nếu chúng ta có hai lối vào và hai chiếc xe đồng loạt kéo lên - thiết kế của bạn có thất bại không? Làm thế nào? Chúng ta có thể làm gì để khắc phục nó?). Các cách khác để khám phá sẽ là cách triển khai bãi đậu xe được giao, tính phí đỗ xe, giá mỗi hàng (có thể các hàng gần hơn phải trả nhiều tiền hơn), thời gian đỗ xe hạn chế và cách tìm người vi phạm, v.v., v.v.

Tôi cũng sẽ coi quá trình suy nghĩ của bạn xung quanh bãi đỗ xe là dấu hiệu cho thấy khả năng chung của bạn để phân tích một cách thông minh một vấn đề. Nếu bạn phải hỏi tôi về các trường hợp sử dụng cơ bản và / hoặc đưa ra những trò kỳ quặc (như 2 cho 1 đặc biệt khi đỗ xe), tôi bắt đầu lo ngại rằng bạn chưa bao giờ thực sự sử dụng bãi đậu xe trước đây và chúng tôi sẽ có một thời gian khó khăn để giao tiếp trên bất cứ điều gì hơi phức tạp.

Tôi đã từng hỏi những điều này - trở lại khi chúng ta tạo sơ đồ lớp để tạo mã. Tôi vẫn thỉnh thoảng làm, nhưng không thường xuyên. Tôi thích câu hỏi vì nó cho phép tôi nhìn người đó suy nghĩ.

Nó được dự định để kết thúc mở. Vậy là được rồi. Không có một câu trả lời đúng. Tôi không có câu trả lời trong đầu; Tôi muốn xem nó dẫn đến đâu. Tôi nghĩ rằng đó là một câu hỏi tốt hơn để hỏi trực tiếp, không phải là "email trả lời." Đó là về giao tiếp, giả định và tương tác; không chỉ là một câu trả lời!

1. Tôi đã thấy loại phỏng vấn này ít nhất 12 năm trước. Đó là cách tiếp cận tôi đã sử dụng trong 6 năm qua. Kinh nghiệm cho thấy rằng nó chọn ứng viên tốt hơn cho công việc hơn là hỏi 20 câu hỏi và cho họ điểm số trong số 20 cách tiếp cận.

2. Một lần nữa, tôi sẽ làm cho nó rất mở kết thúc quá. Mục tiêu là cung cấp không gian cho ứng viên thể hiện khả năng. Có một ứng cử viên hỏi những câu hỏi liên quan ở giai đoạn này sẽ là một lợi thế. Là một ứng cử viên đưa ra các giả định tốt, nhưng đánh dấu rằng họ là các giả định, và sẽ cần phải được xem xét trước khi thực hiện.

3. Tôi yêu cầu tất cả các nhân viên tiềm năng thể hiện các kỹ năng họ cần cho công việc khi phỏng vấn. Đối với các lập trình viên, họ sẽ cần phải thực hiện một số mã và nói về thiết kế của họ cho nó. Nó rất hiệu quả để ngăn chặn tuyển dụng xấu, nhưng hãy chuẩn bị cho tỷ lệ thất bại 90% khi phỏng vấn.

Thiết kế một hệ thống nhỏ thực sự là một bài tập rất phù hợp để hỏi trong một cuộc phỏng vấn. Nó cho thấy các kỹ năng của bạn khi đưa ra một giải pháp phần mềm tốt cho một vấn đề tên miền.

Tuy nhiên, tôi thấy lạ khi chỉ yêu cầu đăng sơ đồ lớp trực tuyến mà không có sự tương tác của con người:

• Họ sẽ bỏ lỡ điều cốt yếu - lý do đằng sau sơ đồ và điều gì khiến bạn thiết kế mọi thứ theo cách đó.
• Không có "lan can" để ngăn người nộp đơn đi quá xa. Nếu bạn phản ánh một triển khai cuối cùng trong sơ đồ, có thể bạn sẽ có hàng tá lớp và một lược đồ không thể đọc được.
• Có thể vẽ sơ đồ lớp UML không thực sự là một kỹ năng thiết yếu, nó chỉ là một ký hiệu OO trong số các ký hiệu khác. Khả năng tạo ra các thiết kế vững chắc là.

Trong một cuộc phỏng vấn trực tiếp, các bước lý tưởng mà tôi mong đợi một ứng viên sẽ thực hiện là:

• Nói về vấn đề với nhà tuyển dụng và bắt đầu bày tỏ một giải pháp cơ bản bằng lời nói, đặt câu hỏi và điều chỉnh khi nhà tuyển dụng đưa ra các nhu cầu chính xác hơn.
• Đứng lên và phác thảo một cái nhìn tổng thể về hệ thống và cách các thành phần có thể tương tác với nhau. Có thể là phong cách thuần túy nhất của UML, có thể chỉ là hộp và vòng tròn.
• Viết một bài kiểm tra, kiểm tra chấp nhận mức cao hoặc kiểm tra đơn vị cho một trong các thành phần / lớp.
• Bắt đầu viết thực hiện tương ứng.

Hy vọng đến một lúc nào đó, nhà tuyển dụng sẽ thu thập đủ thông tin về các kỹ năng của ứng viên và gọi đó là một ngày. Mục tiêu không phải là để thực hiện một giải pháp làm việc đầy đủ (trừ khi đó là một trong những dịch vụ không được trả tiền này trong các cuộc phỏng vấn trá hình).

Các câu hỏi OOP là kết thúc mở. Không có câu trả lời đúng hay sai, nhưng có một số nguyên tắc mà người phỏng vấn mong đợi (như sử dụng hàm tạo để khởi tạo biến, giữ phương thức của bạn nhỏ, sử dụng đóng gói / thành phần / đa hình / kế thừa khi áp dụng, v.v.).

Luôn mong đợi cấu trúc dữ liệu, OOP và các câu hỏi liên quan đến cơ sở dữ liệu trong các cuộc phỏng vấn, chúng rất phổ biến. Những cuốn sách như "bẻ khóa phỏng vấn mã hóa" và "phỏng vấn lập trình tiếp xúc" có thể giúp bạn chuẩn bị.

Tôi đã được yêu cầu đưa ra một thiết kế cho một bãi đậu xe cách đây không lâu. Tôi đã không đưa ra bất kỳ trường hợp sử dụng nào ở nơi đầu tiên, nhưng đã đề cập đến một vài điều sau đó. Tôi tin rằng thiết kế của tôi không phù hợp với những gì người phỏng vấn nghĩ đến. Tôi đồng ý rằng mọi thiết kế phần mềm chỉ có giá trị trong một trường hợp sử dụng nhất định. Quay lại câu hỏi phỏng vấn này, tôi tin rằng người phỏng vấn của tôi không có kinh nghiệm thiết kế thế giới thực. Những người đó tin rằng họ biết những gì họ yêu cầu. Đó là một câu chuyện khác cho dù điều đó có thực sự đúng hay không.