Phỏng vấn kỹ thuật và khả năng lập trình viên [đóng]

Những gì tôi sẽ nói có thể là một cuộc tranh cãi về bản chất nhưng tôi rất chán nản ngày hôm nay - và vì vậy tôi sẽ hỏi điều này.

Tôi vừa có một cuộc phỏng vấn với một công ty công nghệ lớn cho vị trí thực tập, nơi tôi được hỏi rất nhiều câu hỏi phỏng vấn định hướng thuật toán điển hình. Bây giờ, với nền tảng của mình, tôi tự coi mình là người giỏi về thuật toán (tôi cũng đạt điểm cao trong các thuật toán cấp độ sau đại học - các công cụ liên quan đến tính đầy đủ của NP và hơn thế nữa (thuật toán xấp xỉ và ngẫu nhiên), nhưng không may là tôi đã bỏ qua cuộc phỏng vấn. nghĩ về một phương pháp rất hiệu quả để giải quyết vấn đề chuỗi trong khoảng ~ 10 phút. Sau khi cuộc phỏng vấn kết thúc, tôi uống một cốc nước, ăn một quả chuối và thư giãn một lúc và thử lại vấn đề. Và đó là Trả lời Tôi có thể đến dưới 5 phút. Và điều tồi tệ nhất trong tất cả - tôi thực sự đã theo dõi và người phỏng vấn đã gợi ý về nó, nhưng quá nhiều áp lực đã nấu tôi. Toàn bộ kinh nghiệm của tôi khiến tôi suy nghĩ về các cuộc phỏng vấn công nghệ. Tôi đã có một số câu hỏi và tôi muốn đặt chúng trong diễn đàn này -

1. Có thực sự có thể đánh giá khả năng kỹ thuật của ai đó trong nửa giờ? Thành thật? Hay đó chỉ là một trò ném xúc xắc?

2. Làm câu hỏi phỏng vấn kỹ thuật đo lường khả năng giải quyết vấn đề? Điểm này rất gây tranh cãi? Là một nghiên cứu sinh, tôi biết rằng giải quyết vấn đề toán học liên quan đến việc giải quyết một điều mà bạn chưa bao giờ nghe nói trước đây. Mặt khác, các câu hỏi như - hợp nhất hai danh sách được liên kết theo thứ tự được sắp xếp hoặc in tất cả các yếu tố của cây nhị phân ở cấp thứ k trở thành "bài tập đơn thuần" khi ai đó đã thấy giải pháp hoặc giải quyết vấn đề trước đó?

3. Những người xuất hiện với màu sắc bay bổng trong các cuộc phỏng vấn này có trở thành những lập trình viên tuyệt vời không? Họ có tiếp tục và thiết kế một công cụ trò chơi đẹp mắt, thư viện đồ họa, viết các khung kết nối nhanh không? Có bằng chứng nào chỉ ra mối quan hệ tích cực giữa làm tốt trong các cuộc phỏng vấn kỹ thuật và khả năng lập trình thực tế không? Hay những cuộc phỏng vấn này hướng đến việc tìm kiếm loại người "hoàn thành công việc" (Spolsky)?

Tôi có thể đặt cược rằng rất nhiều học giả xuất bản các ý tưởng đột phá trong - ICML, VLDB, Mobicom - sẽ làm hỏng các cuộc phỏng vấn này. Nhưng tôi có thể đảm bảo với bạn rằng họ là một trong những người thông minh nhất bạn sẽ tìm thấy trên hành tinh này.

Tôi chủ yếu ở học viện (học sinh tốt nghiệp) - vì vậy tôi sẽ đánh giá rất cao một số nhận thức từ một người ở phía bên kia của hàng rào. Ai đó thực sự tiến hành các cuộc phỏng vấn?

[Ok mọi người. Cảm ơn tất cả các phản ứng tốt đẹp và chu đáo. Vì tôi không muốn hỏi một câu hỏi khác, tôi sẽ yêu cầu bạn trả lời câu hỏi này cho tôi.

Giả sử ứng viên X có một danh mục đầu tư công cộng tốt, nơi anh ta đã đóng góp cho một số dự án nguồn mở đã biết - bạn thực sự có thể đi và xác minh các bản vá của anh ta, xác minh các lỗi anh ta đã đóng và xem các thiết kế anh ta đã tạo. Trong trường hợp đó, câu hỏi là bạn sẵn sàng dành bao nhiêu trọng lượng cho công việc có thể xác minh / công khai của anh ấy so với việc anh ấy làm tốt như thế nào trong việc trả lời một số câu hỏi phỏng vấn cây nhị phân rất khó hiểu trong vòng dưới 15 phút?]

Hãy nhớ rằng ...

1. Mục tiêu chính của một quá trình phỏng vấn không phải là đi đến sự thật tuyệt đối về khả năng cá nhân của mỗi người được phỏng vấn mà là chọn ra một vài ứng viên từ một nhóm nhiều người.
2. Đó là RẤT NHIỀU, tốn kém hơn để thuê một nhà phát triển tồi hơn là để truyền lại một nhà phát triển tốt.

Vì vậy, rất nhiều lần khi phỏng vấn, các phím tắt không hoàn hảo (như các câu đố kỹ thuật) được thực hiện bởi vì như bạn đã đề cập, không có quy trình hoàn hảo để có thể đánh giá một người trong 30 phút. Nhưng vì hầu hết không có sự thoải mái khi làm việc bên cạnh bạn, bạn chỉ nên chấp nhận rằng đó là trò chơi tỷ lệ cược mà mọi người đều chơi.

Có thực sự có thể đánh giá khả năng kỹ thuật của ai đó trong nửa giờ không?

Không chính xác. Có thể loại trừ những người không thể lập trình được, và những người không thể giải thích những thứ trong CV của họ. Ngoài ra, tôi thường chỉ cố gắng đánh giá trí thông minh và sự quan tâm chung trong lĩnh vực này. Thật khó để bình luận về tình huống của bạn hơn nữa mà không biết vấn đề bạn được yêu cầu giải quyết.

Làm câu hỏi phỏng vấn kỹ thuật đo lường khả năng giải quyết vấn đề?

Đó không phải là mục tiêu của các câu hỏi kỹ thuật của tôi. Thay vào đó tôi đang cố gắng khám phá xem ứng cử viên có nắm bắt được các nguyên tắc cơ bản của khoa học máy tính hay không. Để đánh giá khả năng giải quyết vấn đề, tôi yêu cầu một ứng viên kể về một vấn đề thú vị mà họ đã giải quyết.

Những người xuất hiện với màu sắc bay bổng trong các cuộc phỏng vấn này có trở thành những lập trình viên tuyệt vời không? Hay những cuộc phỏng vấn này hướng đến việc tìm kiếm loại người "hoàn thành công việc" (Spolsky)?

Đó là về nó. Sự vĩ đại là rất hiếm. Tôi rất vui khi tìm thấy một người có thẩm quyền.

1. Đúng. Vâng, thành thật mà nói. Điều này không có nghĩa là 30 phút là đủ thời gian để có được một bức tranh hoàn chỉnh về những gì một người có khả năng. Công việc của người phỏng vấn là làm ở đó tốt nhất để cảm nhận người được phỏng vấn là ai và họ có thể làm gì. Tìm kiếm những người đưa một cái gì đó vào sơ yếu lý lịch của họ mà họ không thực sự biết là thẳng tiến. Tìm ra chính xác những gì người được phỏng vấn có thể làm, bao gồm tất cả các kỹ năng và thế mạnh của họ là không.

2. Đúng. Họ cho bạn thấy người được phỏng vấn nghĩ như thế nào. Nhận được câu trả lời đúng không phải lúc nào cũng cần thiết. Nhìn thấy ai đó giải quyết vấn đề mà họ đấu tranh cũng có ích như nhìn thấy ai đó trả lời chính xác vấn đề mà không gặp nhiều rắc rối. Tôi luôn hỏi một câu hỏi mà tôi nghĩ rằng người được phỏng vấn có thể không trả lời được.

3. Tôi không biết bất kỳ bằng chứng thực nghiệm nào nói rằng các cuộc phỏng vấn kỹ thuật tìm ra những ứng cử viên tốt nhất, nhưng đó là điều tốt nhất tôi đã thử. Những người khác nhau giỏi những thứ khác nhau và nhận được câu trả lời kỹ thuật chính xác không phải là điều duy nhất quyết định nếu ai đó được tuyển dụng. Là một phù hợp tốt cho công ty cũng rất quan trọng.

Dựa trên câu hỏi của bạn, tôi nghĩ điều lớn nhất bạn cần hiểu là những ngày phản hồi được xác định rõ ràng như một lớp thư đã kết thúc. Nhận được câu trả lời đúng chỉ là một phần của kết quả. Viết mã tốt, truyền đạt ý tưởng của bạn và lắng nghe người khác cũng quan trọng không kém. Tuy nhiên, những lĩnh vực này chủ quan hơn và cần được xử lý như vậy.

Giống như cách bạn giải quyết vấn đề, lùi lại một bước và xóa đầu. Rất nhiều thứ đi vào một cuộc phỏng vấn và người phỏng vấn biết rằng đó không phải là một hệ thống hoàn hảo. Họ đang cố gắng làm tốt nhất có thể cho công ty, giống như bạn đang cố gắng làm điều tốt nhất cho bạn.

Trong nửa giờ, bạn có thể đánh giá khả năng kỹ thuật của một người ít nhất là bằng x. Đó là, khả năng của họ có thể cao hơn họ đã chứng minh, nhưng bạn có thể khá chắc chắn rằng nó không tệ hơn. Nếu x cao hơn yêu cầu của bạn, bạn thuê họ. Vâng, thật không công bằng nếu bạn chứng minh dưới khả năng thực tế của mình. Tất cả những gì tôi có thể nói là trở nên tốt hơn trong việc chứng minh.

Nếu ai đó nói ra một câu trả lời thực tế thuộc lòng, tôi sẽ cho họ một vấn đề khó hơn. Trong học tập ghi nhớ là một kỹ năng quan trọng. Trong một công việc, nó hầu như là dư thừa khi bạn có google ngay tại đó.

Xem làm thế nào hầu hết các lập trình viên tuyệt vời được tuyển dụng, thật an toàn khi cho rằng họ đã vượt qua một cuộc phỏng vấn việc làm tại một số điểm. Không, bạn không thể biết ai đó sẽ là một lập trình viên tuyệt vời sau cuộc phỏng vấn nửa giờ. May mắn thay, hầu hết các công ty không cần lập trình viên tuyệt vời. Họ rất hợp nhau với các lập trình viên vững chắc, đáng tin cậy, những người không ngại giải quyết các nhiệm vụ ngay bên ngoài vùng thoải mái của họ.

Lý do các nhà tư tưởng đột phá có thể bỏ qua các cuộc phỏng vấn xin việc là vì cơ hội để giải quyết các vấn đề chớp nhoáng, đột phá là rất hiếm, và bạn sẽ chỉ được tin tưởng để giải quyết chúng sau khi bạn chứng minh rằng bạn có thể giải quyết vấn đề trần tục, khó khăn không thể, như tại sao phần mềm gặp sự cố khi tải quá 16%.

Rất ít người biết liệu các kỹ thuật phỏng vấn của họ có thực sự hiệu quả hay không, bởi vì họ không bao giờ tìm hiểu thêm về những người thất bại. Nhưng khi không có gì bác bỏ giả thuyết của họ, họ coi đó là sự xác nhận rằng chúng là sự thật. Vì vậy, có một yếu tố nhất định của việc ném xúc xắc.

Nếu các lý thuyết kinh tế nói rằng thị trường là hợp lý và hiệu quả là đúng, thì các công ty sẽ tìm cách thuê những người xấu khi phỏng vấn theo cách không làm cho họ xấu trong công việc. Vì vậy, một người mặc bộ đồ không phù hợp, đổ mồ hôi, tỏ ra rất lo lắng và gặp khó khăn khi làm các vấn đề kỹ thuật dưới áp lực của một cuộc phỏng vấn - nếu có bằng chứng bên ngoài họ có thể làm các vấn đề kỹ thuật và áp lực của công việc không giống như của một cuộc phỏng vấn (vì nói chung là không) - sẽ thể hiện cơ hội tốt nhất của một công ty để có được một ứng cử viên tốt hơn so với điều đó có thể thu hút và họ sẽ hành động tương ứng. (Hãy nghĩ Money-ball cho thế giới doanh nghiệp). Cuối cùng các cuộc phỏng vấn thiên vị sẽ biến mất.

Trong thực tế điều này đi ngược lại với bản chất con người. Người phỏng vấn thích người hướng ngoại tự tin, bất kể vị trí nào, và ngay cả khi cuộc phỏng vấn kỹ thuật cung cấp thông tin tồi tệ hơn sơ yếu lý lịch và tài liệu tham khảo (có lẽ là đúng trong trường hợp của bạn), họ sẽ tính đến nó.

Đối với câu hỏi của bạn:

1. Một chút nào đó. Các bài kiểm tra có tín hiệu kém về tỷ lệ nhiễu nhưng có thể được điều chỉnh để loại bỏ hoàn toàn không đủ tiêu chuẩn với chi phí của các cuộc phỏng vấn đủ điều kiện nhưng kém về kỹ thuật.

2. Xem # 1. Một phần của tiếng ồn đến từ sự thay đổi trong việc mọi người đã nhìn thấy vấn đề trước đó.

3. Xem # 1. Có lẽ có một mối tương quan tích cực nhỏ giữa các thử nghiệm này và trở thành một lập trình viên tuyệt vời.

Lời khuyên của tôi - Nghiên cứu một số câu hỏi kỹ thuật mẫu để có được sự quen thuộc cơ bản. Hãy nhớ rằng đó là một chút xí ngầu, vì vậy trong suốt cuộc phỏng vấn hãy cố gắng tự tin. Nếu bạn có thể giải thích những gì bạn đang nghĩ mà không làm sao lãng bản thân khỏi suy nghĩ thực sự thì hãy làm như vậy. Nếu nó thực sự trở nên tồi tệ, hãy thừa nhận rằng bạn cảm thấy lo lắng khi phỏng vấn và cho họ biết đó có vẻ như là điều gì đó mà bạn thường không gặp rắc rối - có thể đưa ra một ví dụ về một vấn đề tương tự nhưng khó khăn hơn mà bạn đã giải quyết.