Python hay Java tốt hơn cho cuộc phỏng vấn?

Bài đăng này đặc biệt dành cho những người mới đang tìm kiếm một công việc trong lĩnh vực phát triển phần mềm hoặc những người đang làm việc trên cơ sở mã dựa trên C trong các công ty hiện tại của họ trong vài năm. Chỉ để làm sáng tỏ một số khía cạnh mà cả người phỏng vấn và người được phỏng vấn đều bỏ qua theo trực giác, và sự ngu ngốc của cá nhân tôi trong quá khứ

Bây giờ, đối với những người không làm việc với C, nó không có gói "bộ sưu tập/STL" tiêu chuẩn. Có nhiều gói nguồn mở, quản lý việc không có thuốc generic, bằng cách sử dụng "void*" trên toàn bộ cơ sở mã. Tuy nhiên, hầu hết mọi người thích tạo các thư viện tùy chỉnh của riêng họ trong bất kỳ cơ sở mã C có kích thước phù hợp nào, một phần vì hầu hết các cơ sở mã C đủ lớn đều có trước các thư viện đó. Nhưng khi bạn đi phỏng vấn, hầu hết bạn có thể tìm thấy các công ty làm việc trên các ngôn ngữ OOP, nơi mà sự tồn tại của một số khung thu thập sắp xếp được coi là điều hiển nhiên

Khi tôi dự định chuyển công việc của mình, vào năm 2014 với 1-2 năm kinh nghiệm ở vị trí nặng về C, với C là ngôn ngữ chính và duy nhất của tôi, đây là cách một trong những cuộc phỏng vấn của tôi diễn ra (cũng có những sự cố tương tự khác

người phỏng vấn. Triển khai bộ đệm LFU

Tôi. Chắc chắn rồi (kiểm soát hạnh phúc của tôi, vì tôi biết điều này khá rõ) Bạn có muốn mã giả hoặc giải pháp hiệu quả không?

người phỏng vấn. Vâng, nó phải là mã làm việc

Tôi (Thở hổn hển. ). Tôi đang viết nó bằng C

người phỏng vấn. Vâng, đó không phải là một vấn đề đối với chúng tôi. (anh chàng chưa bao giờ làm dự án sản xuất hạng C, sau khi tốt nghiệp đại học)

Tôi. . Bắt đầu triển khai hàng đợi ưu tiên (đống tối thiểu) trong C

(sau 20 phút nữa)

người phỏng vấn. Này, làm gì mà lâu thế?

Tôi. Vâng, tôi đang làm nó. (trong khi đó, cố nhớ thuật toán heapify). (

(sau 20 phút nữa)

người phỏng vấn. Anh ơi, chưa xong à?

Tôi. Đúng. Đúng. sắp xong. Chỉ cần viết phương thức "đặt" cho bộ đệm

(Sau khi đợi thêm 5 phút)

người phỏng vấn. ( thấy khó chịu. ) Được rồi, để tôi xem bạn đã làm gì cho đến bây giờ?

Tôi. Chắc chắn

Người phỏng vấn (bối rối). Cái này là cái gì?

Tôi. Bắt đầu từ trang 3

người phỏng vấn. Haiinnn. ?? . Nó hầu như không có mã trị giá 30-40 LỘC

Tôi. 3 trang đầu tiên có triển khai Min heap và HashMap

người phỏng vấn. Nhưng tôi chỉ hỏi LFU cache. Tất cả điều này là không cần thiết. Đối với điều này, chúng tôi có các thư viện

Tôi. Nhưng C không có. Đó là lý do tại sao tôi hỏi bạn

người phỏng vấn. KHÔNG. KHÔNG. Bạn chỉ nên viết các hàm giữ chỗ. Thật là phí thời gian

Tôi (bối rối và kiệt sức). Nhưng bạn đã nói, mã làm việc

người phỏng vấn. vâng. vâng. nhưng tôi đoán chừng này cũng được (chỉ chọn trang thứ 4, bỏ qua 3 trang còn lại). Được rồi, có vẻ như phương thức "remove()" của bộ đệm của bạn chưa hoàn tất

Tôi. Vâng, không có đủ thời gian. Vì thế

người phỏng vấn. Hmmmm. Ừ ừ. Nhưng bạn mất 45 phút

Tôi.

Sau đó. Vật bị loại bỏ. Phản hồi của HR. "Bạn cần rèn luyện các kỹ năng DS&A của mình"

Sau đây là những bài học rút ra từ thất bại này, và trong vài năm tới

Đối với người được phỏng vấn

1. Tôi biết đó sẽ là ý kiến ​​​​không phổ biến, và cũng là điều không chính xác để nói. Nhưng đừng phỏng vấn lập trình bằng C. Tin tôi đi, học một ngôn ngữ OOP sẽ luôn hữu ích về lâu dài. Đừng hiểu lầm tôi. Vâng, C là một ngôn ngữ tuyệt vời và mọi người phải học nó. Tuy nhiên, đó là một hòn đảo đang bị thu hẹp nhanh chóng, xét về thị trường việc làm. Trừ khi bạn đang làm việc trong một lĩnh vực rất thích hợp, chỉ hoạt động trên C và bạn dự định ở lại lĩnh vực đó mãi mãi, đầu tư thời gian để học Java/C++/Python sẽ thực sự hữu ích. Nếu không, bạn sẽ sớm bị khóa trong một nhóm rất nhỏ các công ty vẫn chỉ hoạt động trên C. Hãy nhớ rằng thế giới không xoay quanh bạn (hoặc tôi), nhưng không ai ngăn cản bạn vươn xa và nắm bắt thêm kiến ​​thức. Làm nô lệ cho một ngôn ngữ lập trình cụ thể là điều tồi tệ nhất đối với chính bạn, với tư cách là nhà phát triển phần mềm. Nó không chỉ là về C. Bất kỳ ngôn ngữ nào khác lạ mắt và hấp dẫn ngày nay, có thể biến mất hoặc bị thay thế trong 10 năm tới. Tôi đã thấy điều đó xảy ra với Python chỉ trong 5 năm qua (từ - "Bạn có thể làm mọi thứ bằng Python. Google thích nó. Đó là tương lai của điện toán" để "chỉ giữ ngôn ngữ gõ-vịt-bị-nhiễm GIL chết tiệt này cho khoa học dữ liệu") Khả năng thích ứng của bạn sẽ nổi bật. Tìm hiểu thêm, và học trẻ
2. Bản mô tả công việc có thể tuyên bố rằng chúng "bất khả tri về ngôn ngữ", nhưng không phải tất cả các công ty đều "nói suông" về điều này. Người phỏng vấn cũng là con người và có thể không nhận thức được những thách thức của ngôn ngữ cụ thể của bạn. Mọi người có quan niệm riêng về "một vấn đề nên mất bao nhiêu thời gian", dựa trên khoảng thời gian có thể dành cho họ (mặc dù, điều đó có vẻ hiển nhiên, không quá rõ ràng để phá vỡ nhận thức đó). Và một sự thật nhanh chóng. Hầu hết mọi người chỉ làm việc với 2-3 ngôn ngữ trong toàn bộ sự nghiệp của họ, một trong số đó chủ yếu là Java
3. Giao tiếp tốt hơn (so với những ngày đầu của tôi). Hỏi những gì tôi đã hỏi - "Bạn có muốn một giải pháp hiệu quả không?" . Đó là một trong những loại câu hỏi "Luôn trả lời có". Đặc biệt khi người phỏng vấn của bạn tin rằng sự khác biệt duy nhất giữa mã "hoạt động" và "không hoạt động" là "cú pháp đúng" và "xử lý các trường hợp góc" và "kỹ năng của bạn". Đừng ngại hỏi những câu hỏi rõ ràng như. 1. Bạn có muốn tôi triển khai cả min-heap không?, 2. Tôi có thể sử dụng các hàm giữ chỗ cho các thao tác "tiêu chuẩn" không. Hiếm khi người phỏng vấn muốn bạn triển khai một hàm tối thiểu hoặc cây đỏ đen trong thời gian ngắn của cuộc phỏng vấn. Nhưng ai đó, người luôn có sẵn các DS này thông qua tính năng tự động hoàn thành của IDE, có thể không hiểu sự khác biệt khi bạn hỏi những câu hỏi rộng như tôi đã hỏi
4. Nói như vậy, nếu bạn đang trả lời phỏng vấn bằng C, hãy sẵn sàng triển khai heap, trie hoặc RB-tree trong cuộc phỏng vấn. Bởi vì, câu trả lời của bạn thực sự có thể hướng người phỏng vấn của bạn đến câu hỏi tiếp theo. Nó vừa tốt vừa xấu. Nếu bạn đã sẵn sàng cho điều này mà không cần nỗ lực nhiều hơn, bạn có thể quyết định một câu hỏi quan trọng trong cuộc phỏng vấn của mình. Và việc triển khai những DS này đôi khi bán rất chạy. Tôi đã từng trả lời phỏng vấn cách đây 5 năm, tôi nói với họ rằng tôi đã triển khai cây trie & RB như một phần của dự án hiện tại của mình, những người phỏng vấn không tin điều đó và yêu cầu tôi triển khai nó. Toàn bộ 1 giờ đã trôi qua trong quá trình triển khai đó và sau đó tôi nhận được một lời đề nghị. Mặc dù, không có gì đặc biệt trong cách triển khai đó, nhưng không phải tất cả những thứ tốt hay xấu, chỉ là do những nỗ lực/kiến thức cần có. Nếu bạn chỉ biết C, bạn sẽ gặp bất lợi trong một số lĩnh vực. Nhưng bạn phải biết nơi nó có thể có lợi. Ngay cả những người ở các công ty công nghệ hàng đầu cũng có thể chưa triển khai cây RB, hoặc đôi khi thậm chí là thử lại từ đầu trong toàn bộ sự nghiệp của họ và nó có thể tạo ra hiệu ứng "wow" đó, nếu bạn có thể tình cờ làm điều đó trong cuộc phỏng vấn của mình. “Biết điểm yếu, biết điểm mạnh”
5. Ngay cả khi người phỏng vấn yêu cầu bạn thực hiện các DS cơ bản sau khi xác nhận, hãy luôn đi từ trên xuống. Nó rất quan trọng. Trước tiên hãy triển khai thuật toán/giải pháp thực tế, sau đó là mã thư viện cơ bản. Có 2 lợi ích bạn nhận được

• A. Bạn có thể tập trung vào việc giải quyết vấn đề thực tế và sửa thuật toán của mình. Bởi vì trong khi giải quyết vấn đề thực tế, bạn có thể đột nhiên nhận ra rằng HashMap hoạt động tốt hơn TreeMap trong một vấn đề nhất định, nhưng nếu điều này xảy ra khi bạn đã triển khai cây RB (mất 20-30 phút) và bây giờ bạn nhận ra rằng đó là tất cả
• B. Ngay cả sau khi người phỏng vấn yêu cầu bạn thực hiện toàn bộ, họ có thể không biết sẽ mất bao lâu. Có khả năng họ sẽ nhận ra điều đó sau một thời gian. Nếu họ thay đổi ý định sau nửa giờ chờ đợi, cố gắng kết thúc mọi việc nhanh chóng, họ sẽ có thể thấy rằng bạn đã giải quyết vấn đề thực tế mà họ yêu cầu và bây giờ bạn chỉ đang triển khai mã thư viện. Bằng cách này, bạn có thể chứng minh rằng bạn đã đáp ứng các tiêu chí "ngang bằng" (so với các ứng viên khác) và hiện tại bạn đang làm thêm điều gì đó. Mặt khác, tất cả những gì họ thấy là một triển khai học thuật điển hình của các DS phổ biến, trong khi bạn có thể chưa bắt đầu giải quyết vấn đề thực tế. Trong trường hợp đó, họ không thể biết bạn có đủ tốt hay không. Thêm vào đó là thời gian eo hẹp, họ có thể quyết định rằng bạn không thể tiếp tục. Đừng mong đợi rằng người phỏng vấn của bạn có thể nhìn thấy tương lai và hành động phù hợp

6. Nếu bạn nhận ra rằng người phỏng vấn của bạn không làm việc trên C, hãy tránh tham gia vào các cuộc tranh luận cụ thể về ngôn ngữ. Nếu họ hỏi - "Điều gì xảy ra nếu bạn cố thay đổi chuỗi con trỏ ký tự?", chỉ cần đưa ra câu trả lời chuẩn, ngay cả khi bạn biết rằng nó phụ thuộc vào trình biên dịch đang được sử dụng. Người phỏng vấn của bạn có thể đang tìm kiếm "Câu hỏi phỏng vấn C hàng đầu" trên Google trong khi thực hiện cuộc phỏng vấn của bạn và có thể khớp câu trả lời của bạn với câu trả lời đó trên GeekForGeeks/StackOverFlow/Some blog. Tin tôi đi, tôi đã tham gia vào cuộc tranh luận này và thậm chí còn thách thức rằng tôi có thể chỉ ra cách nó hoạt động khác nhau, tùy thuộc vào việc nó có phải là const hay không, hoặc trình biên dịch đang được sử dụng (từ lỗi biên dịch, lỗi phân đoạn hoặc thậm chí hoạt động tốt với một số . Sau đó, tôi được cho biết - "Bạn thậm chí không biết những câu hỏi cơ bản của ngôn ngữ mà bạn cho là đang học". Vì vậy, hãy để nó trôi qua, nếu người phỏng vấn của bạn không làm việc trên C, nhận thức về chuyên môn của họ có thể dựa trên những gì ba tìm kiếm đầu tiên trên Google cung cấp khi họ phỏng vấn bạn, và điều đó không sao cả. Nếu bạn là một chuyên gia trong ngôn ngữ của họ, họ sẽ không phải làm điều đó, và bạn sẽ không đọc đến đây

Java hay Python dễ sử dụng hơn?

Sử dụng Python cho các cuộc phỏng vấn mã hóa có tốt hơn không?

Ngôn ngữ lập trình nào là tốt nhất cho cuộc phỏng vấn?