Trong một cuộc phỏng vấn, tốt hơn là mã hóa một giải pháp vũ phu cho một câu hỏi khó, hoặc dành cuộc phỏng vấn kiểm tra câu hỏi một cách cẩn thận? [đóng cửa]


14

Đôi khi các câu hỏi phỏng vấn là khó, cho dù người phỏng vấn có ý định chúng hay không. Có thể đưa ra lựa chọn về việc có nên sử dụng thời gian phỏng vấn hạn chế để mã hóa một giải pháp xấu xí, kém hiệu quả, vũ phu hay dành thời gian để hiểu mọi khía cạnh của vấn đề với người phỏng vấn.

Ví dụ, Bài toán 91 tại Project Euler có thể được giải bằng một giải pháp tính toán cực kỳ khó khăn để tính toán mọi tam giác có thể, viết một bài kiểm tra isRightTrigin () và đưa tất cả các tam giác vượt qua bài kiểm tra vào một tập hợp. Nhưng hai cặp tọa độ X / Y làm cho giải pháp O (x ^ 4) có giá trị không đổi cao. Một người bạn và tôi vừa đưa ra một giải pháp thanh lịch và hiệu quả hơn nhiều, nhưng hai chúng tôi đã dành 3 giờ cho nó và vẽ ra hàng tá sơ đồ, thử nghiệm nhiều công thức, kiểm tra nhiều cách tiếp cận, v.v.

Không phải mọi câu hỏi phỏng vấn là công bằng. Ngoài ra những gì dễ dàng cho một người có thể khó khăn cho một người khác. Nếu ai đó đấu tranh với một câu hỏi, bạn sẽ ấn tượng hơn với một giải pháp xấu xí vũ phu có hiệu quả không? Hoặc hiểu vấn đề tuyệt vời và trên đường hướng tới một giải pháp thanh lịch, nhưng không có giải pháp mã hóa? Có một quy tắc như sau 20 phút bạn nên bắt đầu viết mã không có vấn đề gì?


10
Hỏi họ xem họ muốn một giải pháp vũ phu, hay một sắc thái.
Robert Harvey

Nếu họ muốn có một giải pháp không vũ phu, họ sẽ đưa ra một câu hỏi không thể giải quyết bằng vũ lực ngay từ đầu.
trừ

Câu trả lời:


9

Trước hết, một câu hỏi cần hai nhà phát triển có kinh nghiệm ba giờ để tối ưu hóa một cách thanh lịch là một lựa chọn kém cho một câu hỏi phỏng vấn. Nếu bạn hỏi nó, bạn không nên mong đợi câu trả lời hoàn hảo.

Mặt khác, đôi khi bạn học được nhiều nhất về ai đó khi bạn khiến họ đạt đến giới hạn của họ. Đó là lý do tại sao rất nhiều khóa học đại học tăng cường độ khó sau đó lên lớp. Nếu tất cả mọi người đạt 100% cho mỗi bài kiểm tra, bạn sẽ bỏ qua rất nhiều tiềm năng học tập.

Ứng cử viên lý tưởng của tôi có thể sẽ thực hiện phép tính phức tạp trước tiên, nói rằng "Ồ, đó chỉ là 6 triệu lần lặp, sẽ không mất nhiều thời gian", sau đó nhanh chóng viết giải pháp vũ phu. Sau đó, họ sẽ thảo luận về các phương pháp họ có thể thực hiện để tối ưu hóa nó, mà không nhất thiết phải thực hiện chúng trừ khi người phỏng vấn yêu cầu họ làm.

Một phần, điều này là do rất nhiều vấn đề loại euler dự án xuất hiện trong thế giới thực là những vấn đề một lần mà bạn cần phải giải quyết một lần rồi quên nó đi. Tôi muốn biết rằng ai đó tôi thuê sẽ có thể nhận ra thuật toán vũ phu chỉ mất 2 phút để viết và 10 phút để chạy hiệu quả hơn thuật toán mất 3 giờ để viết và 10 giây để chạy, nếu bạn chỉ cần để chạy nó một lần.


Câu trả lời chính xác. Caleb đã đưa ra khái niệm brute-force-trước-sau-tối ưu hóa, nhưng câu trả lời của bạn là câu trả lời duy nhất gợi ý lý do tại sao một giải pháp vũ phu có thể chấp nhận được trong trường hợp này, "Đó chỉ là 6 triệu lần lặp, sẽ không mất rất dài." Đó chỉ là vàng. Cám ơn rất nhiều!
GlenPeterson

14

Là một người quản lý tuyển dụng, nếu tôi yêu cầu bạn giải quyết vấn đề với mã ngay trước mặt tôi, tôi sẽ không làm điều đó quá nhiều để xem chính mã (mặc dù nó quan trọng) mà là để xác định cách thức và lý do tại sao bạn đã làm những gì bạn đã làm. Một trong những điều mà bạn có thể làm là không viết mã, và thay vào đó hãy thẩm vấn tôi về các khía cạnh của chính vấn đề, để giải quyết nó tốt hơn. Điều đó có ý nghĩa với tôi, và thường có ý nghĩa hơn giải pháp được đưa ra trong mã. Tuy nhiên, đó không phải là cách mọi người làm điều đó, cũng không phải là điều mọi người muốn thấy (và thực tế, tôi hiếm khi yêu cầu mọi người viết mã trong một cuộc phỏng vấn nhưng tôi đặt vấn đề lên bàn và chúng tôi nói chuyện với họ và đôi khi giả mã xuất hiện , đó là tốt cho tôi ).

Bạn nói đúng rằng không phải câu hỏi phỏng vấn nào cũng công bằng, và điều gì dễ với người khác thì khó với người khác, trong bối cảnh đó và với những ràng buộc đó, và đó là lý do tại sao những cuộc phỏng vấn đó thường không tìm kiếm giải pháp mã (mặc dù , một lần nữa, điều đó đóng một vai trò quan trọng) mà là quá trình giải pháp .

"Có một quy tắc như sau 20 phút bạn nên bắt đầu viết mã không có vấn đề gì?" Tôi sẽ trả lời điều này bằng cách nói rằng trong một thời gian ngắn suy nghĩ về vấn đề, ít nhất bạn nên làm gì đó - hỏi thêm câu hỏi, phác thảo một khung cho giải pháp hoặc nói rằng bạn không thể làm điều đó / không biết bắt đầu từ đâu.

Nếu tôi đặt một vấn đề khó khăn trước mặt bạn và giải pháp bạn đưa ra - bị hạn chế về thời gian và những gì có bạn - là vũ phu và xấu xí, thì tôi sẽ hỏi bạn một loạt câu hỏi tại sao lại như vậy, và điều gì sẽ thay đổi nó thành một cái gì đó thanh lịch hơn: nhiều thông tin hơn? thêm thời gian? Một môi trường khác nhau? Tự nhận thức và tiếp xúc với lý do tại sao bạn đã làm và những gì bạn chưa làm và có thể giải thích một cách hợp lý, là một ngôi sao vàng lớn trong cuốn sách của tôi, nhưng đó là những nhà phát triển tôi tìm kiếm. Vì vậy, "sự hiểu biết vấn đề tuyệt vời và hướng đến một giải pháp tao nhã" cũng sẽ phù hợp với tôi, nhưng không phải ai cũng vậy.


6
Thêm một triệu cho "Tự nhận thức và liên hệ với lý do tại sao bạn đã làm gì và những gì bạn chưa làm và có thể giải thích một cách hợp lý, là một ngôi sao vàng lớn trong cuốn sách của tôi" . Số lượng người, khi được hỏi "Tại sao?", Chỉ người sáng lập và không thể trả lời là không thể tin được. Khi tuyển dụng, tôi hầu như luôn thích dạy ai đó viết mã, người có thể tự suy nghĩ hơn là thuê người có thể viết mã nhưng không thể nghĩ.
Ben

Cảm ơn. Điều này là sâu sắc. Xu hướng của tôi trong công việc là phân tích trước khi chạm vào bàn phím. Nhưng dưới áp lực của một cuộc phỏng vấn, tôi rất muốn trình bày một giải pháp lập trình viên.stackexchange.com / questions / 178075 / trộm Câu trả lời của bạn cung cấp một ví dụ phản biện rất đáng nhớ.
GlenPeterson 18/03/13

4

Tôi muốn cả hai, nhưng họ có thể hiển thị một "mã chỉ hoạt động" trong một giải pháp và sau đó có thể thảo luận về các giải pháp tiềm năng để cải thiện vấn đề này hoặc vấn đề khác.

Nếu bạn yêu cầu ai đó viết mã và họ chỉ muốn nói về các giải pháp khả thi với mã không, đó sẽ là một vấn đề đáng lo ngại.

Giống như bạn đã nói, ai đó có thể đấu tranh với vấn đề cụ thể vì bất kỳ lý do gì, nhưng bạn phải tìm hiểu cách họ giải quyết chúng. Họ có thể gặp may mắn và đã nghe về một giải pháp cho một vấn đề tương tự. Nó xảy ra.

Xem ai đó đi viết đủ mã và thảo luận về nó và bạn có thể biết liệu họ có phù hợp với công việc không.


1
Tôi đoán tôi cũng muốn nghe lý do tại sao giải pháp vũ phu có thể là một vấn đề, như trong câu hỏi trên.
Christopher Creutzig

@ChristopherCreutzig - Tôi cho rằng sẽ rất khó để đưa ra các cải tiến mà ít nhất là đề xuất các vấn đề với giải pháp hiện tại.
JeffO 17/03/13

Thật. Tôi đoán tôi sẽ gãi điều đó.
Christopher Creutzig 17/03/2016

3

Có một quy tắc như sau 20 phút bạn nên bắt đầu viết mã không có vấn đề gì?

Không, nhưng nếu bạn dành 20 phút để phân tích vấn đề trước khi bắt đầu kinh doanh, có lẽ bạn đã gặp rắc rối. Một nhà tuyển dụng hỏi bạn một câu hỏi giống như câu hỏi mà bạn đã trích dẫn chủ yếu quan tâm đến cách bạn tiếp cận vấn đề, nhưng nếu họ hỏi đó là vấn đề mã hóa, họ cũng sẽ muốn xem một số mã. Nói với họ thông qua quá trình suy nghĩ của bạn ...

Vâng, cách tiếp cận rõ ràng ở đây là vũ phu. Nếu tôi có cách nhận ra một tam giác vuông cho ba đỉnh, tôi có thể chạy qua tất cả các kết hợp của hai điểm và gốc tọa độ để tìm tam giác vuông. Điều đó không khó - tôi có thể viết một hàm sử dụng Định lý Pythagore để xác định các tam giác vuông. Để dễ dàng hơn, tôi cũng sẽ viết một hàm xác định khoảng cách giữa hai điểm bằng công thức khoảng cách ...

Viết các chức năng đó sẽ mất khoảng ba phút. Bây giờ, chỉ sau vài phút cho câu hỏi, bạn đã cho thấy rằng bạn nhớ hình học cơ bản và bạn thực sự biết cách viết mã. Nó cũng cung cấp cho bạn một cái gì đó để nói về:

Vì vậy, rõ ràng chúng ta có thể đặt isRightTriangle(p1, p2, p3)hàm ở giữa bốn forvòng và lặp qua tất cả các lựa chọn có thể cho mỗi trong hai điểm biến. Hãy xem ... vấn đề yêu cầu số lượng tam giác vuông bao gồm gốc tọa độ trên lưới 50x50, vì vậy sử dụng phương pháp vũ lực khiến chúng ta kiểm tra 50 khả năng cho mỗi tọa độ của mỗi điểm. Đó là 50 ^ 4 kiểm tra ... Tôi chắc chắn chúng ta có thể làm tốt hơn, nhưng mã là rõ ràng, vì vậy hãy để tôi viết nó xuống ...

Vì vậy, bây giờ bạn viết một hàm sử dụng các forvòng lặp lồng nhau và isRightTriangle()hàm mà bạn vừa viết. Bạn đã giải quyết vấn đề, nhưng bạn cũng cho người phỏng vấn biết bạn đang đi đâu. Nếu mục tiêu của họ chỉ là thấy bạn có thể viết mã, họ có thể bảo bạn dừng lại. Nhiều khả năng, họ rất vui khi được nói chuyện với một người biết họ đang làm gì và họ sẽ muốn xem bạn mất bao xa. Vì vậy, bạn tiếp tục ...

Nó xảy ra với tôi khi tôi đang viết rằng chúng ta có thể tận dụng sự đối xứng. Chúng ta có thể phản ánh bất kỳ tam giác vuông đã cho nào xung quanh đường 45 °, vì vậy nếu chúng ta chọn kiểm tra một trong những điểm chỉ ở một bên của đường thẳng đó, chúng ta có thể đếm bất kỳ tam giác vuông nào chúng ta tìm thấy hai lần ... một lần cho tam giác và một lần cho sự phản ánh của nó. Điều đó làm giảm một nửa số kiểm tra. Ngoài ra, nhìn vào nó bây giờ, chúng ta đang lấy một căn bậc hai để tìm khoảng cách giữa hai điểm, nhưng sau đó chúng ta chỉ vuông lại một lần nữa trong isRightTriangle()...

Và như thế. Một lần nữa, họ thường không muốn thấy một giải pháp hoàn hảo, họ muốn xem cách bạn tìm đến một giải pháp. Quá trình suy nghĩ của bạn không phải là bất cứ điều gì giống như ở trên - chỉ cần có sự tự tin để suy nghĩ thành tiếng sẽ rất nhiều. Đừng đổ mồ hôi nếu bạn mắc lỗi - chỉ cần nói "hmmm, tôi nghĩ rằng tôi đã đi ra khỏi đường ray ở đây - hãy để tôi quay lại một bước ..."


1
Câu trả lời rất hay. Tôi đặc biệt thích, "Tôi chắc chắn chúng ta có thể làm tốt hơn, nhưng mã rất rõ ràng, vì vậy hãy để tôi viết nó xuống ..."
GlenPeterson 18/03/13

3

Là người quản lý, nếu tôi yêu cầu bạn viết mã dưới dạng thử nghiệm, tôi quan tâm nhất:

  • Cho dù bạn có thể viết mã
  • Phong cách mã hóa của bạn
  • Thuật toán bạn đã chọn
  • Có phải nỗ lực chỉ ra rằng bạn đã hiểu vấn đề
  • Nếu tôi thực sự nóng về một công nghệ cụ thể, bạn đã chứng minh rằng bạn ít nhiều biết đến nó.

Mục đầu tiên có vẻ điên rồ, nhưng bạn sẽ ngạc nhiên ...

Kiểu mã hóa - bằng cách đó tôi không chỉ có nghĩa là nơi bạn đặt niềng răng của bạn, nhưng những thứ như:

  • Bạn đã chọn thành phần hoặc thừa kế để giải quyết vấn đề đó? Tại sao?
  • Đối với giá trị đó, tại sao bạn chọn sử dụng enum so với chuỗi so với int (hoặc bất kỳ hoán vị nào được áp dụng)
  • Bạn đã sử dụng các thuộc tính, trường hoặc phương thức get / set cho giá trị đó chưa? Tại sao?
  • Làm thế nào bạn xử lý nhà nước trong các lớp học của bạn?
  • Bạn có hiểu làm thế nào kế thừa, giao diện và lambdas hoạt động?
  • Bạn có hiểu các quy ước tham số của ngôn ngữ (giá trị của ref so với giá trị là gì không?)
  • Bạn có biết làm thế nào để viết bài kiểm tra đơn vị?

Đây là những gì tôi thực sự không quan tâm:

  • Nó biên dịch (giả sử rằng tôi vừa đưa cho bạn notepad và không có trình biên dịch)
  • Mà bạn đã biết theo bộ nhớ thứ tự của 2 tham số đó trong một hàm đó
  • Rằng bạn có thể đọc thuộc lòng chuỗi kết nối SQL Server hoặc Oracle
  • Rằng bạn có thể viết mã hoàn hảo trong khi tôi đứng trên vai bạn xem mọi lỗi lầm.

Thành thật mà nói, tôi chưa bao giờ là một fan hâm mộ của các bài kiểm tra mã hóa - ngoại trừ như một công cụ để phân tích phong cách.


1
Tôi cũng không phải là một fan hâm mộ của các bài kiểm tra mã hóa. Các vấn đề trên Project Euler là những lời trêu ghẹo não thú vị và một cách tuyệt vời để phát triển các kỹ năng giải quyết vấn đề. Nhưng nếu bạn chủ yếu viết ứng dụng CRUD, tốt hơn là bạn nên biết liệu ứng viên có biết cách viết các truy vấn DB tốt hay không, nếu bạn ở trong thế giới .NET như tôi, làm thế nào để sử dụng đúng cách những thứ như MVC, WCF, WPF và LINQ.
jfrankcarr 17/03/13

1
Tôi sẽ thêm vào nhận xét đó rằng thậm chí không phải là vấn đề ngữ nghĩa hơn là hiểu những vấn đề mà những thứ đó giải quyết và khi nào và ở đâu chúng quan trọng và bất kỳ nhược điểm nào chúng mang theo.
Giàn khoan

@jfrankcarr - Làm thế nào để bạn xác định xem ai đó có thể viết sql với một bài kiểm tra nào đó không?
JeffO 17/03/13

1
@JeffO - Tôi thường thích làm điều đó bằng cách nói chuyện về nó dựa trên sơ yếu lý lịch của họ hoặc trên các tình huống phổ biến. Ví dụ: "Bạn đã sử dụng biến bảng hoặc bảng tạm thời trong các truy vấn của mình chưa?" hoặc "Làm thế nào bạn tích hợp các truy vấn dữ liệu cũ vào thiết kế ứng dụng mới của bạn?" Tôi có thể dùng đến các bài kiểm tra nếu tôi thuê một học sinh mới ra trường, lập trình viên, nhưng tôi thích cách tiếp cận cuộc trò chuyện kết thúc mở.
jfrankcarr

1

Trong trường hợp đó, hướng tới một giải pháp thanh lịch tốt hơn là một giải pháp tồi tệ hơn nhưng đầy đủ. Cả hai trường hợp đều tốt. Hoàn toàn ổn khi viết ra pusdocode chứng tỏ bạn hiểu vấn đề và cách bạn dự định giải quyết ngay cả khi bạn không có thời gian để thực sự viết mã chương trình.


1

Tôi nghĩ rằng bạn đang hỏi một câu hỏi mà thực sự không có câu trả lời, ít hơn là một câu trả lời 'đúng'. Lý do tôi nói điều này là nó phụ thuộc hoàn toàn vào những gì người hỏi giá trị câu hỏi.

Có thể người phỏng vấn là một người thực dụng khó tính thực sự mong muốn thấy rằng bạn sẽ có được thứ gì đó hoạt động nhanh chóng và sau đó tối ưu hóa như một hoạt động ưu tiên thấp hơn nếu bạn còn thời gian. Cũng có khả năng là người phỏng vấn đang có ấn tượng tốt nhất về các hoạt động tuyển dụng của google và không quan tâm đến bất cứ điều gì ngoại trừ thuật toán thanh lịch nhất, quyến rũ nhất và coi đó là dấu hiệu của sự yếu đuối mà bạn từng đặt từ "vũ phu" và " ép buộc "trong vòng 5 từ của nhau. Cũng có thể là người phỏng vấn đã googled "câu hỏi phỏng vấn" và tìm thấy vấn đề này trên internet 5 phút trước khi bạn đến và không biết anh ta muốn gì.

Trong mọi trường hợp, đặt cược tốt nhất của bạn có lẽ là yêu cầu làm rõ, nếu bạn không thể suy luận dựa trên thông tin ngữ cảnh những gì người phỏng vấn muốn. Bạn nói đúng rằng không phải tất cả các câu hỏi phỏng vấn đều công bằng, và trên thực tế, không phải tất cả chúng đều là những câu hỏi hay thậm chí là những câu hỏi có ý nghĩa. Một cuộc phỏng vấn là một hoạt động giảm thiểu vốn có, giống như "hẹn hò tốc độ" trong đó bạn dành một hoặc hai giờ với ai đó và hai bạn đang cố gắng đoán, dựa trên giờ đó, liệu bạn có làm việc tốt với nhau trong lần tiếp theo không 5 năm hay không. Xem xét từ quan điểm đó, tôi hy vọng nó rõ ràng hơn tại sao tôi nói thực sự không có câu trả lời cho câu hỏi của bạn về một "quy tắc".

Ai đó đang hỏi bạn một câu hỏi mà họ nghĩ sẽ cho bạn cái nhìn sâu sắc về năng lực của bạn và phù hợp với đội ngũ của họ. Bạn phải xem xét nhóm của họ, những gì bạn biết về họ, tính cách của người phỏng vấn và hàng tá yếu tố khác và đưa ra dự đoán tốt nhất về câu trả lời, cách tiếp cận và quy trình mà họ có thể coi trọng. Cá nhân, tôi muốn nói rằng bạn nên tiếp cận nó theo cách mà bạn nghĩ là ý tưởng tốt nhất. Nếu họ không đồng ý với bạn, dù sao thì nó cũng có thể không phù hợp với bạn - dễ dàng nhận ra điều đó sớm hơn sau này.


0

Người phỏng vấn sẽ yêu cầu bạn cải thiện giải pháp của bạn nào.

Và phương pháp "giải pháp vũ phu trước" có một ưu điểm không thể chối cãi: nếu bạn không tìm được giải pháp lý tưởng, bạn vẫn có thứ gì đó hoàn thành để chỉ cho họ.


1
"Người phỏng vấn sẽ yêu cầu bạn cải thiện giải pháp của bạn." Có vẻ như một canh bạc với tôi.
Craige

1
@Craige: Không hẳn. Nhưng nếu họ không đưa nó lên. Nói rằng đây là một giải pháp vũ phu và với phân tích có thể được cải thiện.
Martin York
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.