Tại sao các cuộc phỏng vấn kỹ thuật SW khó khăn không tương xứng (so với các cuộc phỏng vấn nghiên cứu)? [đóng cửa]

Đầu tiên, một số nền tảng về tôi. Tôi có bằng tiến sĩ về CS và đã có công việc vừa là kỹ sư phần mềm vừa là nhà khoa học nghiên cứu R & D, cả ở các tập đoàn rất lớn mà bạn biết rất rõ. Gần đây tôi đã thay đổi công việc và phỏng vấn cho cả hai loại vị trí (như tôi đã làm trong quá khứ).

Quan sát của tôi: Phỏng vấn công việc kỹ sư SW là cách, khó khăn không tương xứng so với phỏng vấn công việc của nhà nghiên cứu CS, nhưng công việc của nhà nghiên cứu được trả lương cao hơn, cạnh tranh hơn, bổ ích hơn, thú vị hơn và có lợi thế cao hơn.

Đây là một vòng phỏng vấn điển hình cho nhà nghiên cứu:

• Phỏng vấn qua điện thoại để xem nghiên cứu của tôi có phù hợp với nghiên cứu của phòng thí nghiệm không
• Trực tiếp: thuyết trình về nghiên cứu gần đây của tôi trong một giờ (tương đương với công việc có thể là 9 tháng) và trả lời các câu hỏi từ khán giả
• Phỏng vấn trực tiếp với khoảng 5 nhà nghiên cứu, trong đó họ hỏi tôi những câu hỏi rất hợp lý về công việc / ấn phẩm / bằng sáng chế của tôi, bao gồm: câu hỏi kỹ thuật, nơi công việc của tôi phù hợp với công việc liên quan và làm thế nào tôi có thể mở rộng công việc của mình khu vực mới

Đây là một vòng phỏng vấn điển hình cho kỹ sư SW:

• Phỏng vấn qua điện thoại nơi tôi hỏi các câu hỏi về thuật toán và có thể thực hiện một số mã hóa. Khá chuẩn.
• Phỏng vấn trực tiếp tại bảng trắng nơi họ khoan F *** ra khỏi bạn trong tiểu tiết C ++ bí truyền (ví dụ như cách gọi hàm ảo đa hình hoạt động), thuật toán (làm cho thuật toán tất cả các cặp đường ngắn nhất hoạt động cho các đỉnh 1B) , thiết kế hệ thống (thiết kế bộ cân bằng tải cơ sở dữ liệu), v.v ... Điều này diễn ra trong sáu hoặc bảy cuộc phỏng vấn. Nực cười.

Tại sao mọi người sẽ sẵn sàng đưa ra điều này? Điểm hỏi về câu đố C ++ hoặc viết mã để chứng minh bản thân là gì? Tại sao không làm cho cuộc phỏng vấn SE giống như cuộc phỏng vấn của nhà nghiên cứu nơi bạn nói về những gì bạn đã làm?

Làm thế nào là các cuộc phỏng vấn việc làm kỹ thuật cho các lĩnh vực khác, như vật lý, hóa học, kỹ thuật dân dụng, cơ khí?

Việc thiết lập tương đối dễ dàng nếu bạn đủ năng lực kỹ thuật để thực hiện nghiên cứu - bạn đã có các ấn phẩm mà người quản lý tuyển dụng có thể đọc và những ấn phẩm đó có thể gợi ý cho những người khác mà họ có thể nói chuyện để kiểm tra bạn.

Mặt khác, công nghệ phần mềm là một ngành học chứa rất nhiều sự lãng phí không đủ năng lực, người ta cần phải thực hiện nhiều công việc cần thiết để đảm bảo rằng anh chàng bạn đang thuê thực tế có thể viết mã mà bạn dự định thuê anh ta để viết.

Đi ra ngoài một chi ở đây.

Là một nhà nghiên cứu với bằng tiến sĩ, bạn đã chứng minh cho nhiều tổ chức được công nhận giá trị và phẩm chất tối thiểu của bạn như một nhà nghiên cứu. Bạn đã bảo vệ thành công một luận án trước một hội đồng của bạn bè và đã thuyết phục ít nhất một ấn phẩm được đánh giá ngang hàng để xuất bản tác phẩm của bạn.

Phát triển phần mềm, mặt khác, không có tiêu chuẩn trình độ. Mọi người thường xuyên thổi phồng cơ sở kiến ​​thức của họ. Kết quả là, các cuộc phỏng vấn phát triển phần mềm phải thực hiện tất cả các công việc mà tiến sĩ bảo vệ và đánh giá ngang hàng làm trong học viện. Họ làm cho bạn chứng minh rằng bạn thực sự biết những gì bạn đang nói về.

Hãy xem xét điều này một chút.

Nếu tôi cố gắng nộp đơn cho công việc nhà nghiên cứu CS này, tôi sẽ không xem CV / Resume của mình. Tôi sẽ không đến một cuộc phỏng vấn ở nơi đầu tiên. Tôi nhận được một lá thư "không có bằng cấp cao" được tiêu chuẩn hóa cho tôi biết rằng tôi thậm chí không đủ điều kiện để xem CV của mình.

Câu hỏi của tôi là: "Tại sao rất khó để có được bằng tiến sĩ?" Và "Tại sao tôi cần một tiến sĩ để trở thành nhà nghiên cứu CS?" "Tại sao rất nhiều rào cản và rào cản?"

Tại sao mọi người sẽ sẵn sàng đưa ra điều này?

Điểm của tất cả các công việc khóa học và nhận được nghiên cứu được in trong các tạp chí và hội nghị là gì? Tại sao tôi không thể thực hiện nghiên cứu và được trả nhiều tiền hơn so với kỹ thuật?

Tại sao phải dựa vào các trường đại học và các ấn phẩm để thiết lập thông tin đăng nhập? Tại sao không làm cho cuộc phỏng vấn nghiên cứu giống như các cuộc phỏng vấn SE, nơi mọi thứ phụ thuộc vào những gì bạn có thể nhớ lại ngay bây giờ trong cuộc phỏng vấn?

Vâng, tôi có một lý thuyết. Nghiên cứu thường được trả bằng các khoản tài trợ, vì vậy nguồn cung tiền mặt cao. Họ có một thùng tiền để chi tiêu, và họ chỉ cần tìm một ai đó để tiêu nó. Cho dù bạn có thực sự hoàn thành bất cứ điều gì ở vị trí đó hay không, công ty / tổ chức không ghi nhận khoản lỗ ròng vì dù sao đó cũng chỉ là một khoản chi phí được hạch toán. Có rất ít rủi ro trong việc thuê nhầm người. Trường hợp xấu nhất là họ vứt bỏ mọi thứ bạn đã làm.

Mặt khác, sự thành công hay thất bại của các sản phẩm hiện có nằm trên vai của các nhà phát triển hàng ngày. Đặc biệt nếu bạn đang phát triển sản phẩm, bạn là trung tâm lợi nhuận của công ty. Các nhà phát triển tốt hay xấu có tác động rất lớn vượt xa chi phí tiền lương của họ. Một nhà phát triển xấu thực sự gây ra thiệt hại. Họ có thể thiết lập lại một đội, ra mắt sản phẩm, v.v ... Hậu quả của việc thuê một kỹ sư SW tồi tệ cao hơn nhiều.

Công ty chúng tôi cũng "hỏi nhiều câu hỏi khó" và tôi sẽ giải thích lý do. Chúng tôi quan tâm liệu bạn có thực sự biết cách thực hiện một cuộc gọi chức năng ảo hay không, nhưng không phải vì nó rất cần thiết cho công việc bạn sẽ làm.

Thay vào đó chúng tôi quan tâm bởi vì chúng tôi cần biết bạn có thể học những thứ cơ bản nhanh như thế nào. Bạn khẳng định X năm kinh nghiệm? Được rồi, chúng tôi sẽ hỏi những câu hỏi khó để tìm hiểu xem bạn có kiến ​​thức vững chắc không.

Bạn không biết làm thế nào một cuộc gọi chức năng ảo được thực hiện dưới mui xe, nhưng biết mọi thứ về cấu hình và tối ưu hóa? Tuyệt vời, chúng tôi có thể thuê bạn - bạn đã có kiến ​​thức vững chắc trong một lĩnh vực và vì vậy bạn chắc chắn sẽ có được kiến ​​thức vững chắc trong lĩnh vực khác.

Bạn khẳng định X năm kinh nghiệm "phát triển, gỡ lỗi và sửa mã C ++" và không thể giải thích bằng những từ đơn giản làm thế nào một con trỏ trỏ đến một đối tượng? Xin lỗi, chúng tôi không thể thuê bạn - nếu bạn không thể làm điều đó, làm thế nào bạn sẽ giải thích các vấn đề khó khăn hơn khi chúng tôi cần đưa ra các quyết định kỹ thuật phức tạp?

Câu trả lời ngắn gọn: có rất nhiều người trên thị trường tuyên bố biết lập trình, nhưng không thể lập trình.

Nhận xét bên lề: Tôi rất ngạc nhiên khi không ai đăng một liên kết đến bài tiểu luận FizzBuzz .

Tôi sẽ đi một con đường khác và nói rằng vấn đề có thể không nhiều đến nỗi các cuộc phỏng vấn công nghệ phần mềm vốn đã khó hơn, nhưng thay vào đó, các ngành khác nhau đang tìm kiếm những điều khác nhau thể hiện trong phong cách phỏng vấn của họ.

Tôi đã phỏng vấn trên một loạt các lĩnh vực khá rộng (ví dụ: công ty khởi nghiệp, công ty nhỏ, công ty lớn, bộ phận CNTT nội bộ, công ty phần mềm, tổ chức nghiên cứu) và tất cả họ đều có một cách phỏng vấn khác mà tôi thường thấy theo mô hình sau:

• Các công ty khởi nghiệp có xu hướng quan tâm đến việc biết rằng bạn có thể bắt đầu viết mã ngay bây giờ và có thể xử lý một môi trường có nhịp độ nhanh. Vì vậy, họ có xu hướng quan tâm đến việc bạn biết bao nhiêu phần trên đầu của bạn vì họ dường như không muốn thấy bạn dành nhiều thời gian để tìm kiếm bất cứ điều gì họ cho là kiến ​​thức "cốt lõi". Thừa nhận bạn không biết điều gì đó có thể không phải là một điều tốt trong môi trường này nếu đó là điều họ mong đợi bạn biết.
• Các công ty nhỏ có xu hướng tìm kiếm những điều tương tự như các công ty khởi nghiệp liên quan đến mức độ bạn biết, nhưng không quan tâm đến việc bạn xử lý môi trường nhịp độ nhanh như thế nào (phụ thuộc vào công việc) và hơn thế nữa với loại kỹ năng mềm nào bạn mang lại và làm thế nào tốt bạn sẽ phù hợp với trí thông minh của công ty.
• Các công ty lớn và các bộ phận CNTT nội bộ dường như quan tâm nhiều hơn đến việc đảm bảo rằng bạn có một tiêu chuẩn kiến ​​thức kỹ thuật nhất định, nhưng đừng lo lắng nếu bạn không biết mọi thứ ngoài đầu vì họ dự đoán rằng sẽ có một số thời gian liên quan đến việc giúp bạn đào tạo về những gì công ty mong đợi. Vì vậy, đây là một môi trường nơi thừa nhận bạn không biết điều gì đó nhưng sẵn sàng học hỏi và nghiên cứu có thể được coi là một lợi ích.
• Trong môi trường nghiên cứu (ví dụ như hỗ trợ phát triển phần mềm cho các nhà khoa học theo kinh nghiệm của tôi) họ có xu hướng quan tâm đến việc bạn có thể viết phần mềm không, nhưng hơn thế nữa nếu bạn sẵn sàng làm những gì cần thiết để đảm bảo rằng bạn có thể học những gì họ đang làm họ không phải nắm tay bạn trong khi bạn đang cố gắng giải quyết vấn đề. Vì đó cũng là một môi trường nghiên cứu, họ cũng có vẻ quan tâm đến việc bạn quan tâm đến việc học những điều mới như thế nào.

Bây giờ, tôi đã bỏ qua việc đề cập đến các công ty phần mềm (ví dụ Google, Microsoft) vì họ có xu hướng tự làm mọi thứ và tùy thuộc vào mức độ trưởng thành của công ty và nhóm bạn đang phỏng vấn, họ đang tìm kiếm những thứ khác nhau.

Vào cuối ngày và như với hầu hết mọi thứ trong cuộc sống, tất cả phụ thuộc. Cá nhân tôi đã thấy rằng một số công ty tập trung rất nhiều vào "kiến thức sách vở" có thể phải trả giá bằng việc có thể thực sự giải quyết các vấn đề cấp cao hơn khi mà các công ty khác dường như rất quan tâm đến việc bạn xử lý tốt các vấn đề cấp cao hơn như thế nào (tức là bạn có thể thiết kế một lược đồ cho x ) và hoạt động theo giả định rằng họ sẵn sàng đầu tư ba đến sáu tháng để giúp bạn hoàn toàn đạt được tốc độ trước khi bạn sẽ hoàn toàn làm việc hiệu quả.

Một lần nữa, phỏng vấn công nghệ là tùy tiện và thất thường.

Có một sự khác biệt lớn giữa việc nướng một người trên các chi tiết vụn vặt và xem họ có biết CS của họ không. Như tôi đã nói ở trên, tôi có hơn một thập kỷ kinh nghiệm với C ++, nhưng tôi có xu hướng đánh bom các câu hỏi OOP / Thừa kế. Tại sao? Bởi vì một khi hỗ trợ cho các mẫu được thêm vào, tôi đã sử dụng C ++ hầu như chỉ dành cho Lập trình chung .

Tôi đã phỏng vấn một số công ty BigHouseHoldNameTech ở khu vực Bay & Seattle, và một trong những cuộc phỏng vấn tốt nhất liên quan đến các câu hỏi thực sự mà họ phải giải quyết trong công việc, liên quan đến cấu trúc dữ liệu và thuật toán [ví dụ: Bạn có 300 tỷ điểm dữ liệu bao gồm XYZ. Làm thế nào để bạn lưu trữ và tìm kiếm hiệu quả? ].

Điều đó khá nhiều cho bạn biết làm thế nào một ứng cử viên có thể bước vào và giúp giải quyết các vấn đề thực sự bạn đang gặp phải. Điều tồi tệ hơn nữa cũng xảy ra với một công ty BigHouseHoldNameTech khác, nhưng họ đã hỏi hàng giờ những câu hỏi cực kỳ khó hiểu mà bạn thực sự phải tìm trong một hướng dẫn [ ví dụ: mô tả sự khác biệt chính giữa PCB trong windows so với Linux - và đây không phải là ' t cho một vị trí cấp kernel ]

Các quỹ phòng hộ là kỳ quái với ý định tra tấn ... mong đợi 8 giờ để giải quyết các vấn đề loại ba lô trên bảng trắng.

Tôi là một nhà phát triển phần mềm (c / c ++) với hơn 20 năm trong lĩnh vực này. Loại phỏng vấn mà chúng ta thường thấy bây giờ (trêu ghẹo não, thực hiện cấu trúc dữ liệu, thuật toán tìm kiếm, v.v. trên bảng trắng) đã không được sử dụng để xảy ra nhiều ngoại trừ bản nâng cấp. Nếu một người làm việc cho một công ty có uy tín trong khoảng thời gian hợp lý, đó được coi là bằng chứng về khả năng viết mã của một người. Bây giờ nó trở nên rất học và tôi không chắc tại sao. Thực sự, những điều điển hình họ yêu cầu bạn viết mã, CÓ THỂ được ghi nhớ để thực hiện nó trên bảng trắng thực sự không chứng minh được điều gì. Trong một dự án công việc, bạn sẽ sử dụng internet để nghiên cứu một cái gì đó và bạn sẽ không viết btrees hoặc danh sách liên kết từ đầu.

Tôi nghĩ rằng một mốt quản lý khác của nó - giống như scrum - với cái này có lẽ được bắt đầu bởi google, amazon và microsoft. Mọi người khác sao chép giống như họ đã làm với thứ hạng của Jack Welch và ... nhớ GE?

Nếu bạn là một người quản lý tuyển dụng đọc các bình luận của tôi, điều bạn NÊN hỏi các ứng viên là LÀM THẾ NÀO họ sẽ giải quyết một số vấn đề nhất định. Thay vì yêu cầu họ viết mã bảng băm, hãy đưa cho họ một vấn đề liên quan đến bảng băm và hỏi họ sẽ giải quyết nó như thế nào.

Tôi cũng đồng ý với nhà phát triển phía trên bài đăng này, người nói rằng "hãy cho họ một vấn đề thực tế mà công ty phải giải quyết"!

"nhưng tôi có xu hướng đánh bom các câu hỏi OOP / Kế thừa. Tại sao? Bởi vì một khi hỗ trợ cho các mẫu được thêm vào, tôi đã sử dụng C ++ hầu như chỉ dành cho Lập trình chung."

Tôi cũng đồng ý với những điều trên. Khi bạn làm việc cho một công ty, bạn viết mã THEIR. Thỉnh thoảng tôi vẫn vật lộn để nhớ cuộc gọi C ++ bằng cú pháp tham chiếu ngoài đỉnh đầu vì kiến ​​trúc sư cao cấp tại công ty tôi đã làm việc 15 năm, thích sử dụng con trỏ, không phải tham chiếu. Ông là một lập trình viên C cũ mà bạn thấy. Vì vậy, đó là những gì tất cả chúng ta sử dụng.