Làm thế nào để xử lý một cuộc phỏng vấn 'mã xấu'? [đóng cửa]

Một cuộc phỏng vấn 'mã xấu' là một cuộc phỏng vấn mà người được phỏng vấn được hiển thị một đoạn mã 'mã xấu' và được yêu cầu sửa nó hoặc chỉ ra những điều sai với nó. Tôi gặp rắc rối với các cuộc phỏng vấn này vì tôi phải mất một thời gian để đọc mã, tìm hiểu xem nó đang làm gì và chỉ ra những sai sót. Trong tình huống có áp lực thời gian, tôi có xu hướng đóng băng và tôi thấy rằng mã 'nên' hoạt động, ngay cả khi nó không hoạt động.

Cách tốt để xử lý loại phỏng vấn này là gì, và nói chung, một số kỹ thuật tốt để đọc và hiểu mã nhanh chóng là gì?

Phỏng vấn mã xấu (nếu chúng được thực hiện đúng cách) sẽ hiển thị cho bạn mã với các điều sau:

• Kỹ thuật ngôn ngữ xấu (không sử dụng usingcâu lệnh trong C # khi cần hoặc sử dụng ArrayListthay vì a List<T>)
• Một quyết định thiết kế tồi (tại sao chúng ta đi qua các chuỗi ở khắp mọi nơi, hoặc sử dụng refvà outcác tham số rất nhiều?)
• Lỗi cú pháp (Điều này thậm chí không nên biên dịch!)
• Lỗi thời gian chạy (chẳng hạn như tràn ngăn xếp gây ra bởi một thuộc tính tham chiếu đến chính nó trong C #)

Có một danh sách kiểm tra tinh thần bạn nên đi qua, nhấn từng điểm ở trên. Nếu bạn không thể xem mã và làm điều đó, đó là một điểm cần cải thiện. Bất cứ ngôn ngữ nào bạn cho là 'thành thạo', bạn sẽ có thể xem xét một khối mã và chỉ ra bốn loại lỗi đó.

Gần đây tôi đã viết về một đoạn mã thể hiện tất cả những vấn đề này , nó sẽ giúp bạn trải qua quá trình tinh thần tương tự.

Ayende đưa nó sâu hơn với loạt phim Wages of Sin của mình .

Đừng cố gắng hiểu nó một cách nhanh chóng. Mục tiêu ở đây không phải là để xem bạn có thể hiểu mã như một bậc thầy hay không, mà là để xem bạn nghĩ như thế nào.

IMO quan trọng chỉ đơn giản là nghĩ to. Vì vậy, ngay cả khi bạn đóng băng - chỉ cần nói, "Tôi đang căng thẳng ở đây, nhưng hãy để tôi vượt qua điều này từ từ".

Giả sử bạn có kỹ năng suy nghĩ thành tiếng sẽ khiến bạn chậm lại đủ để khiến đầu óc bạn tỉnh táo. Nếu các cuộc phỏng vấn đủ hiểu biết, họ sẽ thấy tình huống của bạn và giúp bạn thực hiện cho đến khi bạn suy nghĩ rõ ràng. Họ không cố gắng và lừa bạn trông thật ngu ngốc - chỉ là một kỹ thuật mạnh mẽ để xem bạn nghĩ như thế nào.

Điều lạ lùng là, "áp lực thời gian" mà bạn cảm thấy hoàn toàn tự áp đặt. Nó liên quan nhiều hơn đến cảm giác bất an của chính bạn và lo lắng về việc bạn đo lường tốt như thế nào.

Lời khuyên tốt nhất mà bất cứ ai cũng có thể đưa ra là: Thư giãn. Hãy dành thời gian của bạn, nhìn vào mã và chỉ nói về những gì bạn thấy khi bạn nhìn thấy nó. Hãy nói về những phần tốt cũng như xấu; nó sẽ giúp giảm bớt sự lo lắng của bạn và lo lắng rằng quá nhiều thời gian đang trôi qua.

Ngoài ra, việc đi qua các 'đường chuyền' khác nhau có thể giúp bạn dễ dàng phát hiện ra các chi tiết cụ thể hơn một chút. Thực hiện một lần tìm kiếm niềng răng không phù hợp hoặc lỗi chính tả. Đi qua một tìm kiếm các dòng bị xáo trộn. Lấy một cái khác tìm kiếm bánh quy ngữ nghĩa. Tập trung vào một loại "điều sai" có thể giúp bạn dễ dàng phát hiện ra những chi tiết đó và (một lần nữa) làm giảm câu hỏi bằng giọng nói bên trong của bạn xem bạn có đang thực hiện nhanh / đủ tốt không.

Trên hết, hãy nói về những gì bạn đang làm và suy nghĩ - nó sẽ giúp cả bạn và người phỏng vấn.

Tôi chưa bao giờ tham gia cuộc phỏng vấn kiểu này, nhưng khi tôi đang cố gắng thực hiện một đoạn mã phức tạp mà tôi có thể nghi ngờ là xấu, đôi khi tôi lặng lẽ nói chuyện với chính mình. Tôi thấy việc phát âm đôi khi giúp giải quyết vấn đề. Cũng trong một cuộc phỏng vấn, bạn có thể thử truy tìm các bước thực hiện dưới dạng sơ đồ hoặc một cái gì đó bằng bút chì và giấy. Điều này được sử dụng để làm việc cho tôi ở trường, đôi khi vẫn làm điều đó tại nơi làm việc. YMMV, tất nhiên ...

Tôi nghĩ rằng một nơi tốt để bắt đầu (nếu bạn không thấy bất cứ điều gì rõ ràng) sẽ là "gỡ lỗi" nó. Trừ khi bạn thấy các vấn đề có thể xảy ra ngay lập tức, một nơi tốt để bắt đầu là lập một danh sách nhỏ các giá trị thử nghiệm. Giá trị tốt là giá trị 'đường dẫn hạnh phúc' (bình thường), giá trị 'không' hoặc 'trống', null, giá trị rất nhỏ (chuỗi 1 ký tự, int 1, v.v.), rất lớn hoặc rất dài giá trị và các giá trị 'lạ' cụ thể cho loại (ví dụ: các ký tự Unicode cho chuỗi, số âm cho số nguyên, v.v.). Ở đây sẽ không hại gì khi đề cập rằng thông thường bạn sẽ viết các bài kiểm tra đơn vị bằng cách sử dụng các giá trị này để kiểm tra mã và sẽ chỉ chạy chúng để xác minh hàm.

Bắt đầu bằng cách đi qua với (các) giá trị đường dẫn hạnh phúc của bạn. Đối với một hàm bổ sung, bạn có thể bắt đầu bằng 3 hoặc 4. Kiểm tra từng dòng để tìm lỗi chính tả và lỗi logic, theo dõi các giá trị của các biến cục bộ khi bạn đi. Hy vọng, bạn tìm thấy một vài lỗi. Khi bạn hoàn thành với con đường hạnh phúc, bạn sẽ có cảm giác tốt hơn về mã và hy vọng sẽ cảm thấy bớt choáng ngợp hơn - vì vậy hãy nói điều gì đó như: "Bây giờ tôi có cảm giác tốt hơn về những gì mã này đang làm, tôi sẽ lùi lại và xem xét nó, "sau đó hãy làm điều đó - tìm kiếm những thứ nổi bật với bạn như những điều bạn sẽ làm khác đi (quyết định thiết kế tồi, biến số kém, điều tra các lỗi có thể, v.v.).

Nếu điều đó không đưa bạn đến bất cứ nơi nào hoặc nếu bạn cảm thấy không còn gì để nói, hãy quay lại danh sách các giá trị kiểm tra của bạn và xem lại nó với một giá trị mới mà bạn nghĩ có khả năng gây ra sự cố.

Điều này ít nhất sẽ giúp bạn đi.

Như Stephen Bailey đã nói, suy nghĩ thành tiếng là một kỹ thuật tuyệt vời trong tình huống này vì nó cho phép người phỏng vấn của bạn thấy quá trình suy nghĩ của bạn. Sắp xếp giải thích những gì bạn đang cố gắng tìm ra. Một điều khác bạn có thể làm là để cho người phỏng vấn biết rằng bạn sẽ đọc đúng mã trước khi đưa ra chẩn đoán về tính xấu trong mã. Tôi đã ở cả hai phía của bảng và tôi biết nó có thể gây khó chịu cho cả hai bên trong những tình huống này.

Nếu bạn cảm thấy ít áp lực hơn khi làm bài kiểm tra viết, hãy rút sổ ghi chép ra và bắt đầu ghi chú. Tôi đã rút ra một cuốn sổ tay và bắt đầu phác thảo các ghi chú như một phần của quá trình suy nghĩ của tôi trong một cuộc phỏng vấn. Có một cuốn sổ tay và cây bút làm cho bạn trông có tổ chức thậm chí. Bạn có thể viết ra một vài gạch đầu dòng của những thứ cần tìm, cú pháp, lỗi logic, sự không khớp kiểu dữ liệu, giá trị của các biến cục bộ (danh sách có thể thay đổi tùy thuộc vào loại mã bạn có, danh sách của tôi cho một đoạn SQL phức tạp sẽ khác với ai đó có một đoạn mã không phải là trung tâm dữ liệu) khi bạn thực hiện quy trình, v.v. Một khi bạn đã viết một vài trong số này, thì hãy bắt đầu tìm kiếm chúng. Theo cách đó, ngay cả khi bạn không tìm thấy tất cả các vấn đề trước khi người phỏng vấn muốn tiếp tục, anh ấy / cô ấy sẽ có thể thấy một danh sách những điều bạn sẽ kiểm tra. Nếu bạn tạo một danh sách kiểm tra trước những thứ bạn có thể muốn tìm kiếm, thì bạn sẽ cảm thấy tự tin hơn khi bắt đầu quá trình biết những thứ bạn đã lên kế hoạch để xem xét. Thông thường các qiestions này là về cách bạn sẽ tìm thấy các lỗi hơn là thực sự tìm thấy tất cả chúng.

Tôi đến hơi muộn với bữa tiệc này, nhưng một kỹ thuật bạn có thể sử dụng là viết các bài kiểm tra đơn vị cho mã được đề cập. Sau đó, bạn có thể tập trung ít hơn vào những gì sai một cách tinh vi với mã và nhiều hơn về những kết quả mong đợi mà bạn đang tìm kiếm. Tôi thà thuê một người có thể viết các bài kiểm tra tốt hơn một người có thể ngay lập tức phát hiện ra những gì sai với một đoạn mã.

Có thể có hai vấn đề:

Nó có thể là một "cuộc phỏng vấn căng thẳng" http://en.wikipedia.org/wiki/Job_interview#Stress . Người phỏng vấn đang cố gắng xem bạn đối phó với căng thẳng như thế nào vì môi trường làm việc của họ là như vậy.

HOẶC LÀ

Bạn có thể bị căng thẳng chính mình. Trong trường hợp đó, bạn sẽ phải kiểm soát sự căng thẳng này, ví dụ như hướng nội và xem làm thế nào bạn có thể giữ bình tĩnh.