Làm thế nào để tôi thiết kế một hệ thống tùy ý trong một cuộc phỏng vấn? [đóng cửa]

Một câu hỏi phổ biến trong Tech Interview là thiết kế một hệ thống cụ thể, thường là một sản phẩm hiện có của công ty. Ví dụ: "Thiết kế Google Docs".

Câu trả lời dự kiến ​​cho một câu hỏi như vậy là gì? Ý tôi là, những hệ thống như vậy chắc chắn có một thiết kế phức tạp nằm ngoài phạm vi của bất kỳ cuộc phỏng vấn nào. Những người phỏng vấn mong đợi gì trong một thời gian ngắn như vậy?

Cái nhìn sâu sắc về cách bộ não của bạn nhìn vào vấn đề này. Dưới đây là một vài điểm bắt đầu mà tôi có thể thấy để biết cách người ta có thể cố gắng có cuộc trò chuyện này:

• Từ trên xuống - Nhìn xuống từ mức rất cao xây dựng một thiết kế và thiết kế ra thiết kế khi các thành phần khác nhau được thực hiện và đây là một số ít các thành phần mà tôi có thể thấy ....

• Từ dưới lên - Nhìn từ dưới lên, đây là các bit và mảnh mà người ta có thể xây dựng để cố gắng kết hợp lại ....

• Làm rõ yêu cầu - Đặt câu hỏi về quy mô, kích thước, ngân sách và nhóm dự kiến ​​được sử dụng cho thiết kế này. Bạn có thể cố gắng để một người mã hóa một trình xử lý văn bản rất đơn giản hoặc bạn có thể âm mưu chi hàng trăm triệu đô la để làm cho hệ thống quản lý tài liệu cuối cùng mà bạn tin là cách Google Doc đưa bạn đến mức cực đoan. Ngoài ra, ở đây còn có khả năng hỏi một câu như "Ý của bạn là gì? Bạn muốn nhân đôi bao nhiêu chức năng đó?" câu hỏi là tốt

Điều quan trọng là bạn có thể truyền đạt suy nghĩ và cách tiếp cận của mình như thế nào để giải quyết loại vấn đề này vì bạn có thể khiến người dùng tiếp cận bạn và hỏi, "Psst, bạn có thể làm điều gì đó như thế này trong 2 tuần không?" điều đó thực sự có thể xảy ra Vì vậy, cách bạn đưa ra câu trả lời quan trọng hơn câu trả lời là gì .

Ý kiến ​​cá nhân của tôi sẽ là các dự án trong quá khứ không phải là một ý tưởng tốt ở đây. Những gì người ta đang cố gắng tìm kiếm là loại sáng tạo và kỹ năng giao tiếp trong một lĩnh vực mới thay vì chỉ nhớ lại cách thức một cái gì đó đã được thực hiện trong quá khứ. Rất có thể là trong khi một cái gì đó xảy ra ở vị trí mới có thể tương tự như một cái gì đó từ quá khứ, thì có thể có đủ sự khác biệt mà giải pháp cũ không khả thi. Đây là lý do tại sao trong khi những gì có thể được xây dựng tương tự như một ứng dụng hiện có, có thể có nhiều tùy chỉnh khác nhau làm cho giải pháp hoàn toàn khác với ví dụ ban đầu.

Phỏng vấn là một con đường hai chiều. Các nhà quản lý và các nhà phát triển khác hiếm khi là bậc thầy về phỏng vấn nên tôi không chắc mình thấy giá trị khi cố gắng nói rằng họ nên là chuyên gia về vấn đề trong các cuộc phỏng vấn xin việc. Các nhà tuyển dụng tôi có thể thấy đang mong đợi biết cách thực hiện một cuộc phỏng vấn, nhưng có rất nhiều nhà tuyển dụng kém có thể được sử dụng làm ví dụ về lý do tại sao điều này không phải luôn luôn là một ý tưởng tốt.

Đặc biệt đối với các nhà phát triển cao cấp, tôi nghĩ những câu hỏi này có thể rất tốt. Chúng cho thấy rằng một nhà phát triển có khả năng chuyển từ một mô tả lớn, phức tạp sang thực hiện thực tế. Ngay cả với một hệ thống hoàn toàn xa lạ, bạn sẽ có thể thực hiện một số hoạt động thú vị cho người phỏng vấn:

• Thu thập các yêu cầu để trả lời câu hỏi (ví dụ: phạm vi)
• Chia vấn đề thành nhiều phần dễ quản lý hơn; có thể xác định các giao diện hoặc đối tượng có thể cần thiết hoặc phá vỡ logic thành front-end, back-end, DB, v.v.
• Thể hiện sự quen thuộc với cấu trúc và khái niệm đằng sau loại hệ thống đó, ví dụ: ứng dụng web trong trường hợp Google Docs
• Hiển thị những gì bạn có xu hướng tập trung vào khi có vấn đề về thiết kế (Thiết kế đối tượng? Bảng SQL? Mẫu thiết kế?)
• Cho sếp xem bản xem trước về việc phát triển một hệ thống mới với bạn, nơi mà sếp bước vào với một thông số kỹ thuật và nói, "Cần gì để xây dựng hệ thống này?"

Câu hỏi này chỉ là phiên bản cấp cao hơn của "Mô tả hệ thống phân cấp đối tượng bạn sẽ sử dụng cho việc này." "Mô tả giao diện bạn sẽ thiết kế cho việc này .." "Thiết kế một tập hợp các bảng DB quan hệ cho dữ liệu này.", V.v. sẽ được trao cho các nhà phát triển cấp trung học cơ sở. Ở các nhà phát triển cấp thấp hơn, người phỏng vấn có thể đánh giá tiềm năng phát triển lâu dài của công ty hoặc chỉ nhìn thấy những gì họ làm khi gặp phải một vấn đề lớn có thể áp đảo.

Đó là về việc nhìn thấy quá trình suy nghĩ của bạn trong hành động; họ không quan tâm đến giải pháp, nhưng cách bạn sẽ tiếp cận giải quyết vấn đề, bạn sẽ hỏi câu hỏi gì, vấn đề gì bạn sẽ xác định, v.v.

Lấy ví dụ về Google Docs, các vấn đề rõ ràng xuất hiện trong đầu là những thứ như lưu trữ, bảo mật, khả năng mở rộng, tính sẵn có, thiết kế giao diện máy khách, khả năng tương thích trình duyệt, v.v. Bạn sẽ phân chia trách nhiệm giữa máy chủ và máy khách như thế nào? Làm thế nào bạn sẽ xử lý sao lưu? Điều gì xảy ra khi một máy chủ ngừng hoạt động? Bạn sẽ làm gì với các tài liệu "bị bỏ rơi" (những thứ không được truy cập hoặc sửa đổi trong một thời gian dài)?

Một lần nữa, vấn đề không phải là giải quyết bất kỳ vấn đề nào, mà là xác định chúng, nói chuyện với chúng, động não một chút về cách giải quyết chúng, v.v.

Tôi là một trong những bên có tội thường xuyên hỏi loại câu hỏi này trong các cuộc phỏng vấn. (Đối với hồ sơ, tôi cũng hỏi những câu hỏi tương tự về "dự án yêu thích" của họ.) Lý do tôi hỏi là đó là điều chúng tôi thường làm quanh đây. Chúng tôi có các kỹ sư thiết kế từ tất cả các khía cạnh của giao diện, một người nào đó từ kỹ thuật hệ thống, ai đó từ thử nghiệm và ai đó có kiến ​​thức về các trường hợp sử dụng của khách hàng cho tính năng này. Chúng tôi đứng xung quanh một tấm bảng trắng và nói, "Được rồi, chúng ta sẽ xây dựng thứ này như thế nào?" Thường thì bạn biết rất ít về tính năng mới tại thời điểm đó và chỉ ở đó vì chuyên môn của bạn trong phần hệ thống của bạn, nhưng bạn vẫn được kỳ vọng sẽ đóng góp hiệu quả. Nó không chỉ là một bài tập học thuật giả định.

Theo như những gì tôi mong đợi, ví dụ, thiết kế một hệ thống để tải firmware mới từ máy chủ, thông qua 20 thẻ dòng được nhúng trong một văn phòng trung tâm để nâng cấp 5000 hộp hàng đầu trong trường cùng một lúc. Giả sử có rất ít dung lượng dự phòng trên liên kết giữa máy chủ và thẻ dòng.

Câu trả lời không hay:

Ừm, tôi có thể sẽ sử dụng ethernet hoặc một cái gì đó tương tự.

Câu trả lời tốt:

Làm thế nào lớn một hình ảnh chúng ta đang nói về? [Khoảng 7 MB.] Chà, bạn muốn đảm bảo dịch vụ không bị ảnh hưởng trong quá trình tải xuống. Bạn cần thêm đèn flash hoặc RAM để lưu trữ hai hình ảnh cùng một lúc. Bạn có thể muốn lưu trữ hình ảnh trên thẻ dòng của mình để tránh tải xuống cùng một hình ảnh từ máy chủ. Được nhúng, thẻ dòng của bạn có thể có CPU hạn chế, do đó bạn có thể cần phải tuần tự hóa các bản tải xuống để có đủ dung lượng cho dịch vụ. Bạn muốn một số cách để xác minh hình ảnh là tốt và quay lại phiên bản cũ nếu nó không hoạt động. Bạn cần một số cách để thử lại một vài lần và báo cáo lỗi cho con người nếu việc nâng cấp thất bại. Nếu bạn có các nhãn hiệu khác nhau của các hộp hàng đầu, bạn cần một số cách để xác định hình ảnh nào bạn cần gửi.

Đó gần như là từ để phiên âm từ của hai ứng cử viên khác nhau. Hầu hết các ứng cử viên ở đâu đó ở giữa, nhưng thường đến đó với một chút gợi ý, điều này là hoàn toàn ổn. Chúng tôi không tìm kiếm Einstein tiếp theo ở đây, chỉ là một dấu hiệu cho thấy bạn thực sự có thể suy luận một cách thông minh về các loại vấn đề chúng ta làm việc hàng ngày.

Tôi cũng hỏi loại câu hỏi này, và tôi đồng ý với hầu hết các câu trả lời khác. Có lẽ nó sẽ giúp người được phỏng vấn hiểu TẠI SAO loại câu hỏi này quan trọng? Giả sử chúng ta có một quyết định kinh doanh quan trọng để đưa ra, và để thực hiện nó, chúng ta cần xây dựng một hệ thống mới. Nếu ai đó chạy đến chỗ bạn và hỏi cần những gì để xây dựng một hệ thống X, bạn có thể cho họ một câu trả lời sâu sắc để dự đoán những thách thức và nguồn lực chính cần thiết không?

Một lập trình viên cơ sở không có ý tưởng bắt đầu từ đâu. Họ chưa sẵn sàng để bắt đầu nói chuyện mà không có thông số kỹ thuật chi tiết. Một lập trình viên cao cấp sẽ ngay lập tức thấy rằng có nhiều khía cạnh của vấn đề, và sẽ cố gắng khắc phục một thách thức. Bạn không phải kiến ​​trúc sư mọi khía cạnh, chỉ cần xác định một thách thức kiến ​​trúc và sau đó tìm ra cách giải quyết nó.

Hãy xem xét vấn đề của Google Docs:

Một điều thú vị là quy mô cắt của các yêu cầu sẽ đến. Bạn không thể chỉ có một máy chủ duy nhất và triển khai mã của mình đến đó - đây là một công việc lớn hơn. Một người được phỏng vấn thành công có thể không tham gia vào vấn đề này và sẽ mô tả các loại tài nguyên cần thiết và một số thách thức kỹ thuật khi triển khai ở quy mô đó, với một ứng dụng không chỉ có trạng thái, nó chia sẻ trạng thái qua nhiều người dùng.

Một điều thú vị khác về Google Docs là nhiều người có thể chỉnh sửa cùng một lúc. Một người được phỏng vấn thành công sẽ có thể thảo luận về các cơ chế để đảm bảo tài liệu kết quả không phải là rác và một ứng cử viên thực sự tuyệt vời sẽ nhận ra rằng các phương pháp đồng bộ hóa hoặc hợp nhất các chỉnh sửa khác nhau sẽ có tác động lớn đến hiệu suất và UX. Thậm chí có thể thảo luận về các biến thể: Trình chỉnh sửa tài liệu dùng chung để viết mã có lẽ nên sử dụng một phương pháp giải quyết xung đột khác với Google Doc thông thường, bởi vì có những hậu quả khác nhau đối với những việc xảy ra theo một thứ tự khác hoặc có cấu trúc hơi khác.

Không có cách duy nhất đúng để tạo một ứng dụng như Google Docs, bạn không phải xác định những gì bạn sẽ làm cho mỗi lần đánh đổi, nhưng thật tuyệt khi tìm thấy một khu vực có vấn đề thú vị và giải thích rõ ràng về giao dịch đó -offs có thể được.

-t.

Tôi nghi ngờ rằng những gì người phỏng vấn muốn nghe là:

Google Doc là một giao diện web cho trình xử lý văn bản. Tài liệu người dùng được nhập và lưu trữ và người dùng có thể truy xuất được trên cùng hoặc một máy tính khác.

Bạn muốn thảo luận gì thêm?

Sau đó, quả bóng là ở tòa án phỏng vấn. Nếu cô ấy muốn biết thêm chi tiết, cô ấy có thể hỏi. Những gì người phỏng vấn đang tìm kiếm là, bạn có thể nhìn vào một vấn đề hoặc một sản phẩm, và trích xuất thiết kế?

Đối với tôi, nếu người đó không bắt đầu với việc xác định các trường hợp / câu chuyện sử dụng chính thì điều đó đủ để biết họ không chuẩn bị cho một vị trí yêu cầu kỹ năng đặc biệt này.

Sau đó, họ sẽ có thể đưa ra một giải pháp kiến ​​trúc dựa trên các trường hợp sử dụng chính / câu chuyện. Hy vọng rằng họ đã sử dụng một số quy trình có hệ thống để xác định các mô-đun khác ngoài việc kéo chúng ra khỏi chúng .... Tôi sẽ không mong đợi nhiều hơn từ một tình huống phỏng vấn cho giải pháp.

Tuy nhiên, tôi có thể chọn một trong các mô-đun kiến ​​trúc và yêu cầu thiết kế chi tiết hơn, chỉ để xem liệu chúng có một số kỹ năng thiết kế hay không. Cũng thật tốt khi thấy họ xem xét các trường hợp thất bại / vấn đề hiệu suất. Nhưng tôi nghi ngờ vào thời điểm này, chúng ta sẽ chạy vào một bức tường thời gian. Vì vậy, tôi thực sự không thể phạt họ vì đã không xem xét các vấn đề này bởi vì chỉ có quá nhiều thời gian và tôi nghĩ rằng thật hợp lý khi họ cho rằng việc xem xét mọi kịch bản có thể không xảy ra trong tình huống phỏng vấn có giới hạn thời gian.

Tôi đã có một cuộc phỏng vấn gần đây, nơi tôi được yêu cầu thiết kế một hệ thống điều khiển thang máy. Về cơ bản họ muốn thấy cách tiếp cận của bạn với nhiệm vụ. Nếu bạn đang được hỏi câu hỏi này, có lẽ họ có một công việc rất cao cấp dành cho bạn. Chúc mừng.

Điều quan trọng là cách bạn giải quyết vấn đề so với giá trị của giải pháp bạn đưa ra và nếu bạn có khả năng xử lý các vấn đề lớn.

Tôi nghĩ một điều quan trọng cần làm là đặt câu hỏi về các yêu cầu. Đừng chỉ đưa ra các giả định sẽ cho phép giải pháp thú cưng của bạn hoạt động. Ví dụ, bạn có thể tình cờ biết một số phương pháp thực sự tiện lợi để in tài liệu mà bạn có thể bị cám dỗ để nhảy ngay vào mô tả. Nhưng Google Docs không in trực tiếp; nó tạo ra một bản PDF mà khách hàng sau đó in ra. Vì vậy, nếu bạn bắt đầu với điều đó, bạn sẽ giảm một nửa thời gian để giải quyết vấn đề không phải là một phần của vấn đề và đã chứng minh rằng bạn quan tâm đến việc sử dụng công nghệ nóng của mình hơn là giải quyết vấn đề của khách hàng.

Để xử lý loại câu hỏi phỏng vấn này, bạn sẽ cần có mối quan tâm chung trong việc tìm hiểu "cách mọi thứ hoạt động", không chỉ trong các dự án bạn quan tâm mà cả các dự án mà bạn cảm thấy quá xa vời với kinh nghiệm của mình.

Điều này có nghĩa là đọc blog, bài viết, http://www.infoq.com , Hacker News, v.v. Ngay cả những phần cứng vô tội vạ từ Mã hóa kinh dị.

Mặc dù thực tế là bạn sẽ quên hầu hết những gì bạn đã đọc (vì dù sao thông tin đó không được kết nối với cá nhân bạn), có thể có một số mẩu tin là "hạt giống của trí tưởng tượng" và một phần nhỏ của những hạt giống đó sẽ nảy mầm khi bạn gặp một vấn đề tương tự trong tương lai xa, rất xa.

Vì vậy, người phỏng vấn có lẽ quan tâm đến thói quen đọc sách của bạn (như một phần của sở thích của bạn) và xem liệu bạn có thói quen thường xuyên để thu thập hạt giống ý tưởng từ những nơi ngẫu nhiên.

Điểm đằng sau việc hỏi loại câu hỏi này là để hiểu rõ hơn về tâm trí của bạn. Một câu hỏi phổ biến tôi sử dụng là yêu cầu các lập trình viên thiết kế một hệ thống có thể mô phỏng PacMan.

Và vâng, tôi tìm kiếm các trường hợp sử dụng đầu tiên, nó cho tôi thấy rằng người đó đang suy nghĩ. Sau đó, để đa luồng, trước tiên hãy xem xét các cấu trúc dữ liệu (những cấu trúc có thể được sử dụng cho vấn đề, sau đó là các cấu trúc phù hợp hoặc cụ thể hơn với các quyết định).

Đây là một điều cần thiết cho các vị trí phát triển cao cấp. Thật là ngớ ngẩn và vô nghĩa khi mọi người ngồi và trả lời các câu hỏi về việc triển khai sắp xếp ở cấp độ kinh nghiệm của nhà phát triển này. Thiết kế hệ thống là những gì tôi mong đợi ở cấp độ này.