Có phải White White-Board-Coding không phù hợp trong các cuộc phỏng vấn? [đóng cửa]

Đây là một câu hỏi hơi chủ quan nhưng tôi rất muốn nghe phản hồi / ý kiến ​​từ người phỏng vấn / người được phỏng vấn về chủ đề này.

Chúng tôi chia cuộc phỏng vấn kỹ thuật của chúng tôi thành 4 phần. Viết mã, đọc và phân tích mã, thiết kế phiên & mã trên bảng trắng.

Đối với phần cuối cùng, những gì chúng tôi yêu cầu người được phỏng vấn làm là viết một đoạn mã nhỏ (4-5 dòng) trên bảng trắng và giải thích khi họ đi qua nó. Hãy để tôi rõ ràng mục đích là không để bắt mọi người ra ngoài. Chúng tôi không tìm kiếm cú pháp hoàn hảo. Địa ngục nó thậm chí có thể là mã giả. nhưng vấn đề là cung cấp cho họ một vấn đề rất đơn giản và xem liệu bộ não của họ có thể truyền đạt giải pháp cho chúng ta hay không. Bởi những vấn đề đơn giản tôi có nghĩa là "Đảo ngược một chuỗi", "FizzBuzz", v.v ...

Lưu ý rằng chúng tôi luôn yêu cầu một ngôn ngữ rõ ràng đầu tiên. Chúng tôi là một ngôi nhà .NET C #. chúng tôi chỉ nói "mã giả" khi có ai đó đang trống / thực sự vật lộn với mã.

Câu hỏi của tôi là "Có phù hợp / không hợp lý khi mong đợi một lập trình viên viết một đoạn mã trên bảng trắng trong một cuộc phỏng vấn?"

Theo quan điểm của tôi, nó rất thích hợp. Nếu bạn đang muốn một công việc để thực hiện một kỹ năng cụ thể, thì nó hoàn toàn thích hợp để được chứng minh là thể hiện kỹ năng đó khi phỏng vấn.

Hiệu quả của kỹ thuật này đối với quá trình tuyển dụng là rất đáng chú ý. 90% ứng viên thất bại trong nhiệm vụ này. nhưng các nhà phát triển được tuyển dụng là tốt, và các nhà phát triển sẽ được tôn trọng trong công ty.

Nếu như một ứng cử viên phải đối mặt với kỹ thuật này, trước hết hãy thư giãn. Đó là về việc đánh giá bạn như một lập trình viên và quá trình suy nghĩ của bạn. Nó không phải là về cú pháp hoàn hảo của bạn. Nếu bạn mắc lỗi cú pháp thì tôi có thể đóng vai trò của trình biên dịch và nói với bạn rằng mã không biên dịch trên một dòng nhất định và cung cấp cho bạn một thông báo lỗi và xem cách bạn trả lời. Tương tự như vậy nếu bạn thêm một; vào một vòng lặp hoặc một câu lệnh if sẽ biên dịch, tôi sẽ chơi trình gỡ lỗi và nói với bạn qua một bước thông qua mã. Một lần nữa, nó không phải là về lỗi lầm, mà là về cách bạn sẽ đối phó với sai lầm và suy nghĩ của bạn có tốt không.

Câu hỏi của tôi là "Có phải là không phù hợp / không hợp lý khi mong đợi một lập trình viên viết một đoạn mã trên bảng trắng trong một cuộc phỏng vấn?"

Nó rất hợp lý. Một thay thế cho bảng trắng có thể là máy tính xách tay và máy chiếu, vì các lập trình viên thường sử dụng để viết mã trên bàn phím hơn là trên bảng trắng. Chỉ cần đảm bảo một môi trường phát triển như Eclipse hoặc VS hoặc Idle đã chạy với một dự án trống khi ứng viên bắt đầu, vì vậy cô ấy không phải lãng phí thời gian để tìm kiếm thông qua các ứng dụng đã cài đặt của mình.

Điều đó không phù hợp, nhưng hãy biết rằng nó có thể KHÔNG luôn luôn tiết lộ những hiểu biết thực sự về khả năng lập trình hoặc giải quyết vấn đề của người bạn đang phỏng vấn. Và tôi đoán đó chính xác là những gì bạn đang theo đuổi.

Thứ hai, lưu ý rằng luôn có nỗi sợ thất bại, liên tục làm tê liệt bộ não của người đó. "Điều gì sẽ xảy ra nếu tôi làm hỏng?", "Nếu tôi phạm sai lầm ngớ ngẩn". Phần lớn bộ não của một người đang bận rộn liên tục kiểm tra xem họ sẽ ra sao - chỉ một số ít có thể giữ được thần kinh.

Vì vậy, trong tình huống này, ngay cả những người giỏi nhất cũng có thể sẽ chùn bước.

Đối với phần cuối cùng, chúng tôi yêu cầu người được phỏng vấn làm là viết một đoạn mã nhỏ (4-5 dòng) trên bảng trắng và giải thích khi họ đi qua nó

Vậy là được rồi. Nhưng một lần nữa, chỉ vì ai đó không thể giải thích điều gì đó một cách chính xác không có nghĩa là họ không biết rõ về nó. (Giải thích là một nghệ thuật nói).

Nếu tôi là bạn, tôi sẽ làm điều này cho phần cuối ...

Thuê chúng cho một dự án rất nhỏ (nhưng thực tế). Xem cách họ viết mã, đưa ra quyết định, đồng hóa các điều kiện làm việc và các thành viên trong nhóm, v.v., và sau đó dựa vào đó, đưa ra quyết định cuối cùng.

Không phù hợp, nhưng hãy nhớ rằng một số người (và có thể là một phần lớn hơn trong đám đông lập trình viên) có thể rất căng thẳng trong một cuộc phỏng vấn. Tôi nghĩ rằng hầu hết chúng ta đều biết anh chàng từ văn phòng là một lập trình viên xuất sắc và là một người rất đáng tin cậy, nhưng anh ta sẽ tan chảy trong tình huống như vậy. Hiệu suất của anh ta không thể đo lường được trong một bài kiểm tra như vậy, vì vậy đừng biến điều này thành một bài kiểm tra đi / không đi.

Tôi cá nhân nghĩ rằng đây là một trong những điều tốt nhất bạn có thể làm. Như bạn đã nói, bạn không tìm kiếm cú pháp chính xác hoặc một cái gì đó tương tự, phần quan trọng nhất ở đây là để xem ai đó có thể giao tiếp không ... Tôi đã thấy rất nhiều nhà phát triển giỏi chỉ có thể làm việc một mình trong không gian riêng của họ ... Thật không may không thể có trong một số lượng lớn các trường hợp vì vậy có một anh chàng có kỹ năng cũng có thể NÓI những gì anh ta nghĩ một cách rõ ràng và súc tích là một thành viên có giá trị hơn trong đội sau đó một người nghĩ: "Họ sẽ không hiểu điều đó dù sao đi nữa, tôi sẽ tự làm và chứng minh sau ".

Truyền thông, giao tiếp, giao tiếp là thứ gì đó là nền tảng của mọi dự án quy mô vừa và lớn (thậm chí nhỏ hơn một khi cần nó)

Tôi nghĩ đó không phải là một điều hợp lý. Chúng tôi cố gắng tìm các ứng cử viên, những người giỏi trong nhiệm vụ mà chúng tôi muốn họ làm. Viết mã trên bảng trắng không phải là một trong số đó và tôi không nghĩ đó là bộ lọc hợp lệ để tìm ứng viên tốt.

• Mã tốt không được viết, nó được viết lại. Một bảng trắng là khá nhiều bất biến, vì thật khó để thay đổi một khi bạn viết nó. Nên dễ dàng nhất có thể để thay đổi suy nghĩ của bạn ngay khi bạn hiểu rõ vấn đề hơn.
• Trong một cuộc phỏng vấn là một tình huống căng thẳng vì nó không cần phải gây thêm áp lực cho ứng viên. Nhiều người sử dụng máy tính không có chữ viết tay tốt. IDE hiện đại cung cấp rất nhiều công cụ mà bạn đã quen sử dụng. Và việc có thể google một cái gì đó ngay khi bạn cần nó cũng là một phần trong phong cách làm việc của hầu hết các lập trình viên. Tại sao lại lấy đi tất cả những thứ này và tạo ra một môi trường nhân tạo, rằng chúng sẽ không bao giờ phải hoạt động nếu bạn đưa ra lời đề nghị?
• Chúng tôi cũng rất quan tâm đến khả năng viết các bài kiểm tra tốt, thậm chí có thể làm TDD. Điều này là không thể nhìn thấy trong quá trình mã hóa bảng trắng.

Hầu hết các manh mối mà bạn có thể thoát ra khỏi phiên mã hóa bảng trắng, bạn cũng có thể thoát khỏi phiên ghép nối - Và tôi tin rằng, ghép nối là một công cụ tốt hơn nhiều để có cảm giác, cách ứng viên giải quyết vấn đề và cách anh ta làm việc. Anh ấy có thể mang máy tính của mình và làm việc trong môi trường mà anh ấy / cô ấy thoải mái. Và nó dễ dàng hơn nhiều để áp dụng cho nhiệm vụ mà bạn muốn họ thực hiện khi họ tham gia. Ví dụ, chúng tôi có một cơ sở mã kế thừa lớn, vì vậy chúng tôi yêu cầu họ cấu trúc lại một số mã được trích xuất cho dự án thực. Và chúng tôi thực sự ghép càng nhiều càng tốt trong công việc hàng ngày của chúng tôi, vì vậy nó rất phù hợp.

Trong khi một phiên bảng trắng có thể giúp lọc các ứng cử viên xấu, nhưng nó cũng có thể lọc ra nhiều lập trình viên giỏi.

Cá nhân, tôi đi ra ngoài về bất kỳ người phỏng vấn nào yêu cầu tôi làm FizzBuzz. Tôi không biết khi nào nó trở thành tiêu chuẩn công nghiệp mới, nhưng nó thực sự lãng phí thời gian. FizzBuzz là một bộ lọc có thể được sử dụng trước một cuộc phỏng vấn, mặc dù cá nhân tôi nghĩ rằng nếu tôi phải chọn từ N ứng viên có đủ mã nguồn mở hoặc một blog tôi có thể xem, tôi chắc chắn thích nó như một bộ lọc .

Nói một cách đơn giản, tôi nghĩ trong một cuộc phỏng vấn cho vị trí lập trình (ngoại trừ có thể là đàn em hoặc thực tập), nó đã được thiết lập / xác định rằng người được phỏng vấn có thể lập trình.

Nhưng vâng, bảng trắng là hoàn hảo, mặc dù tôi nghĩ bạn nên có một loạt các vấn đề khác nhau. Ném cho họ một vấn đề trong thế giới thực và khiến họ vẽ ra một loạt các UML-ish để giải thích chiến lược tổng thể của họ để giải quyết vấn đề đó. Cung cấp cho họ một máy tính có internet, để họ có thể tìm kiếm các thư viện của bên thứ 3 mà họ có thể sử dụng làm hộp đen trong hình vuông của họ.
Trong vài phút, bạn sẽ thực sự thấy cách họ giải quyết vấn đề. Bạn thực sự có thể biến điều này thành một điều rất thú vị, bằng cách chọn các vấn đề mà bạn không nhất thiết phải có giải pháp cho tâm trí và cố gắng "giải quyết" chúng cùng nhau, để xem chúng giao tiếp tốt như thế nào và chúng có thể kết hợp đầu vào tốt như thế nào (tuy nhiên không sẽ đẩy chúng quá mạnh - một số người có thể sẽ đóng băng nếu bạn làm vậy). Và sau đó thêm một vài yêu cầu trên bay. Đây là loại giống như phát triển phần mềm mà không cần thực hiện và quan trọng nhất là - không cần gỡ lỗi, vì vậy 15 phút là rất nhiều thời gian.

Hãy để tôi trả lời với một câu hỏi khác:

Viết mã trên bảng trắng có cung cấp bất kỳ lợi thế thực sự nào trong việc đánh giá khả năng lập trình, so với việc gõ và thực thi mã trên máy tính không?

Tôi nghĩ rằng nó hoàn toàn thích hợp để yêu cầu một ứng viên viết mã trong một cuộc phỏng vấn. Tuy nhiên, với tôi, việc có thể thực thi mã là một phần quan trọng của vòng phản hồi tạo nên lập trình. Trên một tấm bảng trắng, bạn đang buộc một tay sau lưng tôi và bạn không có được bức tranh đầy đủ về cách tôi xử lý vấn đề.

Không, nhưng IMO một cách tiếp cận tốt hơn sẽ là sử dụng bảng trắng cho mục đích dự định của nó và sử dụng UML / phác thảo / ghi chú cho một số dự án hư cấu, thay vì "viết cho tôi một truy vấn sql để lấy tất cả các bản ghi" hoặc "viết một phương thức đảo ngược một chuỗi ".

Một trong những cuộc phỏng vấn tốt nhất mà tôi có là dành 20 phút để thảo luận với nhà phát triển chính kiến ​​trúc (không phải phần mềm) cho biệt thự của một nhà khoa học điên (hoàn toàn với nơi ẩn náu bí mật, tia tử thần và cũi chó). Anh ấy đã thấy cách tiếp cận của tôi trong việc giải quyết vấn đề, và vấn đề là một điều thú vị không phải là lập trình vẹt 101 điển hình được giải quyết bằng các ngôn ngữ hiện đại hàng ngàn lần. Ngẫu nhiên tôi cũng đã làm một đoạn mã như thế này trước đây, nhưng tôi cảm thấy "chịu áp lực" hơn nhiều so với phần kiến ​​trúc.

Ngày nay, rất nhiều chương trình được thực hiện theo nhóm. Đối với các nhóm làm việc, mọi người phải có khả năng giao tiếp. Một phần lớn của điều này là có thể giao tiếp trước một bảng trắng (động não, cố vấn, đánh giá mã đề xuất sửa chữa, v.v.)

Tôi sẽ tìm kiếm xem ứng cử viên có giải thích cách giải quyết vấn đề lập trình bằng cách sử dụng mã bảng trắng để hỗ trợ hay không. Nếu lời giải thích là đủ tốt, các lập trình viên giỏi khác trong phòng sẽ tự động sửa lỗi bất kỳ lỗi chính tả / lỗi nào trên bảng.

Đối với hầu hết các loại vị trí nhóm, sẽ không hợp lý KHÔNG mong đợi một ứng cử viên có thể giải thích và viết nguệch ngoạc nỗ lực của họ trong một giải pháp.

Không, đó là một điều tốt để viết mã cho một cuộc phỏng vấn, nhưng bạn nên cho phép mã bằng bất kỳ ngôn ngữ hợp lý nào vì việc đào tạo một đối thủ mã hóa bằng ngôn ngữ khác thường dễ dàng hơn so với việc viết một ngôn ngữ mà bạn muốn đến một mức độ cạnh tranh.

Tôi có thể nói nó phù hợp, nhưng trong hầu hết các trường hợp, đó không phải là cách hiệu quả để tìm ra ai giỏi lập trình và ai không giỏi. Nếu bạn muốn một công việc được thực hiện (= thuê một người có khả năng), thì cuộc phỏng vấn nên tập trung vào việc đo lường các kỹ năng thực tế. Cho đến nay cuộc phỏng vấn tốt nhất tôi đã làm như thế này:

• Chúc mừng, chào mừng bởi HR.
• Vài lời về tôi, về công ty, v.v ... và cô ấy đã giải thích phần còn lại của cuộc phỏng vấn.
• Cô ấy đưa cho tôi một chiếc máy tính xách tay với một chương trình bị thiếu vài phần, đã thất bại trong các bài kiểm tra đơn vị vì điều đó. Các phần còn thiếu được nhận xét ở đó dưới dạng văn bản, đó là về việc thực hiện một nhiệm vụ cơ bản, như tạo kết nối giữa một vài lớp và giới thiệu một logic nghiệp vụ đơn giản.
• Nếu mọi thứ suôn sẻ, các bài kiểm tra đơn vị đã trở thành màu xanh lá cây.
• Nói lời tạm biệt, và thỏa thuận trở lại trong vài ngày.
• Vào ngày hôm đó, nhà lãnh đạo đã gặp tôi và hỏi về chương trình đã hoàn thành, tôi đã làm gì và tại sao.
• Ngoài ra nhà lãnh đạo này đã hỏi về kinh nghiệm trong quá khứ của tôi, và một vài câu hỏi khác.

Vì vậy, để tóm tắt: nếu bạn đang tìm kiếm lực lượng lao động vào một mã sản xuất, hãy kiểm tra kỹ năng của họ trong môi trường thực tế. Nếu bạn tò mò về kiến ​​thức lý thuyết của họ, tốt hơn là hỏi họ về những điều này. Nếu bạn bị tước khỏi IDE, hoặc bạn lo lắng vì bạn phải lập trình trên bảng trắng trước mặt ai đó, tôi có thể hiểu, đặc biệt là trong CNTT đôi khi người hướng nội và nhiều người trong chúng ta không thể xử lý tốt các tình huống này, vì vậy, hãy trắng hội đồng quản trị hiệu quả của chúng tôi sẽ trông tồi tệ hơn thực tế.

Tôi không thấy nó không hợp lý trừ khi người được phỏng vấn có chữ viết tay xấu (hoặc tôi nên nói chữ viết) :-). Bên cạnh sự khác biệt duy nhất trong cách tiếp cận của bạn là việc sử dụng bảng và bút đánh dấu. Trong một số trường hợp người phỏng vấn làm điều này nhưng họ đưa ra một tờ giấy và bút thay thế. Trong đó có 3-4 người thực hiện cuộc phỏng vấn, tôi sẽ nói rằng cách tiếp cận của bạn sẽ tốt hơn và phù hợp hơn nhiều.