Vì vậy, hãy nhớ rằng đây là một câu hỏi phỏng vấn chứ không phải là một kịch bản thực tế thực tế, tôi tin rằng cách tiếp cận chính xác (và có lẽ những gì người phỏng vấn đang tìm kiếm) là hỏi một câu hỏi rõ ràng hoặc viết "Không thể được thực hiện "và tiếp tục. Đây là lý do tại sao.
Những gì người phỏng vấn hỏi:
Viết hàm được đảm bảo không bao giờ trả lại cùng một giá trị hai lần. Giả sử rằng chức năng này sẽ được truy cập đồng thời bởi nhiều máy.
Người phỏng vấn cần gì:
Ứng viên này có đánh giá hiệu quả các yêu cầu và tìm kiếm đầu vào bổ sung khi được yêu cầu không?
Không bao giờ giả định.
Khi một kỹ sư được trao một yêu cầu (thông qua SOW hoặc Thông số kỹ thuật hoặc một số tài liệu yêu cầu khác), một số là hiển nhiên và một số khác hoàn toàn không rõ ràng. Đây là một ví dụ hoàn hảo về sau này. Như các câu trả lời trước đã chỉ ra, không có cách nào để đáp ứng yêu cầu này mà không đưa ra một số giả định chính về bản chất của câu hỏi hoặc (b) về bản chất của hệ thống, bởi vì yêu cầu không thể được đáp ứng như đã viết (nó là không thể).
Hầu hết các câu trả lời thực hiện một nỗ lực này hoặc nỗ lực khác để giải quyết vấn đề thông qua một loạt các giả định. Một người đặc biệt khuyên bạn chỉ nên hoàn thành nhanh chóng và để khách hàng lo lắng về điều đó nếu nó sai.
Đây thực sự là một cách tiếp cận tồi. Là một khách hàng, nếu tôi đưa ra một yêu cầu không rõ ràng, và kỹ sư bỏ đi và xây dựng cho tôi một giải pháp không hiệu quả, tôi sẽ buồn vì họ đã đi làm và tiêu tiền của tôi mà không cần hỏi tôi trước. Đó là kiểu ra quyết định ung dung thể hiện sự thiếu tinh thần đồng đội, không có khả năng suy nghĩ phê phán và phán đoán kém. Nó có thể dẫn đến bất kỳ cách nào gây ra hậu quả tiêu cực, bao gồm mất mạng trong một hệ thống quan trọng về an toàn.
Tại sao đặt câu hỏi?
Điểm nếu bài tập này là tốn kém và mất thời gian để xây dựng theo yêu cầu mơ hồ. Trong trường hợp của OP, bạn đã được giao một nhiệm vụ bất khả thi. Hành động đầu tiên của bạn là yêu cầu làm rõ - điều gì là bắt buộc? Mức độ duy nhất là cần thiết? Điều gì xảy ra nếu một giá trị không phải là duy nhất? Câu trả lời cho những câu hỏi này có thể là sự khác biệt giữa vài tuần thời gian và vài phút. Trong thế giới thực, một trong những yếu tố chi phí lớn nhất trong các hệ thống phức tạp (bao gồm nhiều hệ thống phần mềm) là không rõ ràng và các yêu cầu kém hiểu biết. Điều này dẫn đến các lỗi tốn kém và tốn thời gian, thiết kế lại, sự thất vọng của khách hàng và nhóm và phủ sóng truyền thông nếu dự án đủ lớn.
Điều gì xảy ra khi bạn giả định?
Với nền tảng của tôi trong ngành hàng không vũ trụ, và do tính chất dễ thấy của các sự cố hàng không vũ trụ, tôi muốn đưa ra các ví dụ từ lĩnh vực này để minh họa các điểm quan trọng. Chúng ta hãy kiểm tra một cặp nhiệm vụ trên sao Hỏa thất bại - Tàu quỹ đạo Khí hậu Sao Hỏa và Tàu địa cực Mars. Cả hai nhiệm vụ đều thất bại do sự cố phần mềm - bởi vì các kỹ sư đưa ra các giả định không hợp lệ, một phần, do các yêu cầu không rõ ràng và giao tiếp kém.
Mars Climate Orbiter - trường hợp này thường được trích dẫn là những gì xảy ra khi NASA cố gắng chuyển đổi tiếng Anh sang đơn vị Số liệu. Tuy nhiên, đó là một đại diện quá đơn giản và nghèo nàn về những gì thực sự xảy ra. Đúng, đã có một vấn đề chuyển đổi, nhưng đó là do các yêu cầu giao tiếp kém trong giai đoạn thiết kế và sơ đồ xác minh / xác nhận không phù hợp. Hơn nữa, khi hai kỹ sư khác nhau nhận thấy vấn đề vì rõ ràng từ dữ liệu quỹ đạo bay, họ đã không nâng vấn đề lên mức phù hợp vì họ cho rằng đó là lỗi truyền. Đội ops nhiệm vụ đã được nhận thức về vấn đề này, có đủ thời gian để sửa nó và cứu nhiệm vụ. Trong trường hợp này, có một điều kiện logic không thể không được công nhận cho những gì nó đã dẫn đến thất bại nhiệm vụ tốn kém.
Tàu đổ bộ sao hỏa- trường hợp này ít được biết đến hơn, nhưng có thể còn lúng túng hơn do sự gần gũi tạm thời của nó với sự thất bại của Tàu quỹ đạo Sao Hỏa. Trong nhiệm vụ này, phần mềm đã điều khiển dòng dõi được hỗ trợ của tên lửa đẩy vào bề mặt sao Hỏa. Tại một điểm cách mặt đất 40 mét, chân của tàu đổ bộ được triển khai để chuẩn bị hạ cánh. Ngoài ra còn có một cảm biến trên chân phát hiện chuyển động (để báo hiệu khi chúng bị va chạm) để báo cho phần mềm tắt động cơ. Dự đoán tốt nhất của NASA về những gì đã xảy ra (vì có nhiều lỗi hỏng hóc và dữ liệu không đầy đủ) là các rung động ngẫu nhiên ở chân do triển khai đồng thời và kích hoạt không đúng cách cơ chế tắt máy 40m trên bề mặt, dẫn đến sự cố và phá hủy $ 110 Tàu vũ trụ M. Khả năng này đã được đưa ra trong sự phát triển, nhưng không bao giờ được giải quyết. Cuối cùng, nhóm phần mềm đã đưa ra các giả định không hợp lệ về cách mã này cần chạy (một giả định như vậy là tín hiệu giả sẽ quá ngắn để được chọn, mặc dù các thử nghiệm cho thấy điều ngược lại), và các giả định đó không bao giờ bị nghi ngờ cho đến sau sự thật.
Xem xét bổ sung
Phỏng vấn và đánh giá con người là một công việc khó khăn. Có một số khía cạnh của một ứng cử viên mà một người phỏng vấn có thể muốn khám phá, nhưng một trong những điều quan trọng nhất là khả năng suy nghĩ nghiêm túc của một cá nhân. Vì nhiều lý do, không phải ít nhất trong số đó là tư duy phê phán được định nghĩa kém, chúng ta có một thời gian rất khó để đánh giá các kỹ năng tư duy phê phán.
Là một giảng viên kỹ thuật, một trong những cách yêu thích của tôi để đánh giá khả năng suy nghĩ nghiêm túc của học sinh là hỏi một câu hỏi hơi mơ hồ. Các sinh viên sắc nét hơn sẽ chọn ra tiền đề sai lầm của câu hỏi, lưu ý nó và hoặc trả lời được đưa ra tiền đề hoặc từ chối trả lời hoàn toàn. Thông thường, tôi sẽ hỏi một câu hỏi tương tự như sau:
Bạn chọn một bản vẽ từ đống công việc của bạn. Bản vẽ chứa nhiều loại chú thích khác nhau, nhưng những điểm quan trọng nhất đối với bề mặt nằm ngang và nói "Hoàn toàn phẳng". Bề mặt rộng 5 "dài 16" và phần được làm bằng nhôm. Làm thế nào bạn sẽ máy phần để tạo ra tính năng này?
(Nhân tiện, bạn sẽ bị sốc khi tần suất xuất hiện một thông số kém như vậy ở nơi làm việc.)
Tôi hy vọng rằng các sinh viên sẽ nhận ra rằng không thể tạo ra một tính năng hoàn hảo và họ sẽ nêu điều này trong câu trả lời của họ. Tôi thường sẽ thưởng một điểm thưởng nếu họ nói rằng họ sẽ quay lại nhà thiết kế và yêu cầu làm rõ trước khi thực hiện phần này. Nếu một học sinh tiến hành cho tôi biết làm thế nào họ sẽ đạt được 0,001 độ phẳng hoặc một số giá trị tạo thành khác, tôi sẽ không có điểm nào. Điều này giúp tôi đưa ra quan điểm với các sinh viên của mình rằng họ cần phải nghĩ về bức tranh lớn hơn.
Dòng dưới cùng
Nếu tôi đang phỏng vấn một kỹ sư (hoặc nghề nghiệp tương tự), tôi đang tìm kiếm một người có thể suy nghĩ chín chắn và đặt câu hỏi về những gì đã được đặt trước mặt anh ta. Tôi muốn ai đó đặt câu hỏi "Điều này có ý nghĩa không?" .
Không có nghĩa gì khi yêu cầu một phần hoàn toàn bằng phẳng, bởi vì không có thứ gì là hoàn hảo. Không có nghĩa gì khi yêu cầu một hàm không bao giờ trả về giá trị trùng lặp, vì không thể đảm bảo như vậy. Trong lập trình, chúng ta thường nghe thấy cụm từ "rác vào, rác ra". Nếu bạn được giao rác cho các yêu cầu, trách nhiệm đạo đức của bạn là dừng lại và hỏi bất kỳ câu hỏi nào giúp bạn khơi gợi ý định thực sự. Nếu tôi đang phỏng vấn một ứng cử viên, và tôi đưa ra cho họ một yêu cầu không rõ ràng, tôi sẽ mong đợi những câu hỏi làm rõ.