Làm thế nào là các kỹ năng được sử dụng trong các câu hỏi phỏng vấn điển hình được áp dụng trong công việc thực tế? [đóng cửa]


13

Đối với các công việc phát triển ứng dụng SQL và C #, người phỏng vấn thường đặt câu hỏi về các giao diện danh sách cây, biểu đồ và danh sách được liên kết bằng cách sử dụng C và con trỏ thuần. Trong 3 năm tôi làm việc, tôi chưa bao giờ phải thực sự

tìm đường dẫn đến nút thứ 1 ở bên phải của một nút đã cho, đó là bội số của nút đã cho

ví dụ

Tôi có thể thấy rằng những kỹ năng này có thể được sử dụng trong các công việc mà bạn cần viết trình biên dịch, trình điều khiển và làm việc trên nhân hệ điều hành. Khác với những thứ đó, những kỹ năng này được sử dụng ở đâu?


5
Nếu bạn vật lộn với các cấu trúc dữ liệu cơ bản nhất, thì bạn sẽ phải vật lộn hầu hết thời gian lập trình.
Mert Akcakaya

Câu trả lời:


15

Đọc một số câu trả lời của Joel dưới đây.

Đặc biệt lưu ý một cái gì đó như Schmiel họa sĩ. Trong công việc, bạn có thể không bao giờ phải viết lại một danh sách được liên kết, nhưng bạn chắc chắn nên biết về cách thức hoạt động của nó, để bạn có thể tránh Schmiel.

Về cơ bản, nếu bạn đang đi đến bác sĩ, bạn sẽ muốn bác sĩ đó đã nghiên cứu về giải phẫu. Mặc dù cô ấy chỉ kê đơn cho bạn một số AntiHistamine, một bác sĩ sẽ học được ở trường y rằng một số loại thuốc có hại cho những người bị 'gãy xương mãn tính diamadabada cho phụ nữ thấp kém' hoặc bất cứ điều gì. Loại kiến ​​thức chuyên sâu về MỌI THỨ trong chuyên ngành đó đôi khi có thể tạo ra sự khác biệt giữa sống và chết, và trong Công nghệ thông tin giữa sống và chết của sản phẩm hoặc công việc.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... dành ít nhất một học kỳ để đến gần máy hoặc bạn sẽ không bao giờ có thể tạo mã hiệu quả bằng các ngôn ngữ cấp cao hơn. ..."

"... bạn đang lập trình dựa trên sự mê tín, theo như tôi quan tâm: một bác sĩ y khoa không biết giải phẫu cơ bản, đưa ra các đơn thuốc dựa trên những gì mà bác sĩ bán hàng dược sĩ nói sẽ làm việc."

http://www.joelonsoftware.com/articles/ColiticAdvice.html


22

Họ không phải. Nhiều cuộc phỏng vấn được thực hiện bởi những người không biết cách tìm kiếm các nhà phát triển khéo léo và không biết những câu hỏi nào họ nên hoặc không nên hỏi.

Hầu hết những người phỏng vấn không đặt câu hỏi kỹ thuật nào cả, và tập trung nhiều hơn vào những điều vô nghĩa nhưng có thể đo lường được , chẳng hạn như số lượng dự án bạn tham gia (nhiều hơn là tốt hơn cho những người phỏng vấn) hoặc bằng đại học (cao hơn là tốt hơn cho họ ). Họ rất vui khi thuê một người lãng phí năm năm học đại học mà không học được gì và sau đó mất mười năm để làm hàng tá trang web thương mại điện tử, nhưng họ sẽ không thuê một người từ bỏ trường đại học sau vài năm và đang làm việc trên một vài dự án lớn về mặt kỹ thuật.

Đặt ít nhất câu hỏi lý thuyết là tốt hơn sau đó không hỏi. Điều này có lợi cho việc xác minh rằng người đó có đủ kiến ​​thức lý thuyết và không phải là một lập trình viên có thể có một vài năm kinh nghiệm với lập trình, nhưng không thực sự hiểu những gì đang diễn ra. Các nhà phát triển không có kiến ​​thức lý thuyết này thường không biết sự khác biệt giữa danh sách, danh sách được liên kết một tra cứu hoặc bộ băm và sử dụng chúng thay thế cho nhau.

Câu hỏi hay (kỹ thuật), câu hỏi xấu

Trong các cuộc phỏng vấn, bạn có thể gặp các câu hỏi từ rất tốt đến cực kỳ xấu:

  1. (Có hại) "Độ dài của dòng chương trình làm việc dài nhất bạn đã viết bằng ngôn ngữ đó là bao nhiêu?"

    Câu hỏi này hoàn toàn sai. Tôi đã giải thích tại sao trong một câu trả lời khác . Công ty nơi người phỏng vấn đặt câu hỏi như vậy có cơ hội mạnh mẽ để đánh giá năng suất của các nhà phát triển ở LỘC / tháng. Nếu tôi phải đưa ra một lời khuyên: bạn không cần công việc như vậy.

    Ví dụ này khác với những điều vô nghĩa nhưng có thể đo lường được mà tôi đã trích dẫn khi bắt đầu câu trả lời của mình. Ở đây, người phỏng vấn cũng cho thấy rằng anh ta thậm chí không có hiểu biết cơ bản nhất về các số liệu bằng cách chọn một số liệu nổi tiếng là có hại.

  2. (Xấu) "Dennis Ritchie là ai?"

    Có ít nhất một số văn hóa thực sự rất hữu ích, nhưng hỏi những câu hỏi đó bỏ lỡ vấn đề. Nếu công ty tìm kiếm các nhà phát triển tài năng có khả năng xử lý các dự án phát triển phần mềm và viết mã, thì thực tế là họ không biết tên của người đã tạo ra C và Unix không nên quá quan trọng.

  3. (Tốt) "Các tính năng mới của .NET 4.5 là gì?"

    Câu hỏi này thú vị hơn nhiều so với câu hỏi về Dennis Ritchie. Nếu ứng viên không thể nói về các tính năng mới trong .NET 4.5, tại sao anh ta tự gọi mình là nhà phát triển C #? Thiếu kiến ​​thức như vậy:

    • Cho thấy rằng người đó có thể không thực sự quan tâm đến cả ngôn ngữ lập trình cũng như cộng đồng .NET.

    • Chỉ ra rằng người đó có thể thiếu một số kiến ​​thức quan trọng về các tính năng của C # /. NET mà các nhà phát triển khác sử dụng nếu không phải hàng ngày, ít nhất là thường xuyên.

    Xem thêm câu trả lời của Jerry Coffin trong đó có phân tích chi tiết hơn về loại câu hỏi này.

  4. (Trung bình) "Cái nào nhanh hơn, SSD hay RAM?"

    Điều này có thể hữu ích và cho thấy nếu người đó có đủ kiến ​​thức về phần cứng, nhưng, một ứng cử viên không thể trả lời câu hỏi này không nên bị từ chối.

  5. (Trung bình) "Làm thế nào ngăn xếp và hàng đợi được thực hiện?"

    Đây là loại câu hỏi mà bạn nói về. Chúng chỉ mang tính lý thuyết, thậm chí có thể quá lý thuyết, nhưng biết những gì đang diễn ra dưới mui xe có thể giúp viết mã tốt hơn.

    Tôi sẽ không từ chối một ứng cử viên không thể trả lời câu hỏi này, nhưng sẽ kiểm tra kỹ hơn nếu anh ta thực sự biết nội dung, ví dụ bằng cách hỏi một câu hỏi liên quan nhưng ít lý thuyết hơn:

  6. (Tốt) "Làm thế nào bạn có thể đi qua một cái cây mà không sử dụng đệ quy?"

    Nếu ứng viên trả lời câu hỏi này, nói về FILO / FIFO và về những lợi ích và hạn chế của việc sử dụng ngăn xếp so với đệ quy cho giao dịch cây, thì thực sự không có vấn đề gì khi anh ta không thể trả lời câu hỏi trước đó.

    Đặt câu hỏi này cũng là một cách tốt để phát hiện các ứng viên đã dành nhiều năm làm bằng CS, nhưng không có kinh nghiệm thực địa.

Làm thế nào để đặt câu hỏi kỹ thuật tốt?

Nhận xét của kojiro rất thú vị và xứng đáng nhận được câu trả lời dài hơn:

Đôi khi bạn cần thuê một ai đó chính xác bởi vì họ nên biết nhiều về một chủ đề hơn bạn, vì vậy theo định nghĩa, bạn không đủ điều kiện để thực hiện cuộc phỏng vấn. Bạn không thể đáng tin cậy để được giúp đỡ ngay cả khi thực hiện cuộc phỏng vấn vì lý do tương tự. Điều tốt nhất bạn có thể làm là cố gắng đặt câu hỏi dựa trên bất cứ nơi nào sự hiểu biết của bạn giao thoa với miền vấn đề và hy vọng bạn gặp may mắn.

Tìm những câu hỏi hay có thể là một thách thức, đặc biệt là khi bạn thuê nhà phát triển đầu tiên của bạn hoặc khi bạn thuê một nhà phát triển được kỳ vọng sẽ giỏi hơn tất cả các nhà phát triển thực sự làm việc trong công ty.

Dưới đây là ba gợi ý có thể giúp:

  1. Tìm một người bạn / đồng nghiệp mà bạn tin là có kỹ năng và yêu cầu anh ta thực hiện các đánh giá. Điều này đòi hỏi rất nhiều sự tin tưởng, nhưng có thể mang lại lợi ích cho công ty của bạn rất nhiều.

  2. Tìm một chuyên gia tư vấn mà bạn tin là có kỹ năng và yêu cầu anh ta hỗ trợ bạn hoặc thực hiện phần kỹ thuật của cuộc phỏng vấn.

  3. Nhập "câu hỏi phỏng vấn" trong Google. Nó hoạt động khá tốt, và thường giải thích các câu trả lời có thể. Thí dụ:

    • Python : mười câu hỏi đó có vẻ khá tốt. Chúng có thể hơi cơ bản, nhưng sẽ giúp lọc 95% ứng viên mà bạn không muốn tuyển dụng.

    • SQL của Dave Pinal, xuất sắc như thường lệ.

    • C # : hơi quá cơ bản, nhưng một lần nữa, họ sẽ lọc 95% ứng viên,

    • JavaScript : các câu hỏi có nhiều kết thúc mở hơn, có thể không phải là điều tốt cho các câu hỏi kỹ thuật nếu bạn muốn cuộc phỏng vấn ngắn và giữ nhiều thời gian hơn cho các câu hỏi phi kỹ thuật mở. Danh sách này vẫn giúp lọc dễ dàng các ứng cử viên không hiểu các khái niệm cơ bản trong JavaScript.

    Hạn chế của phương pháp này là ứng viên có thể sử dụng kỹ thuật tương tự để đào tạo cho cuộc phỏng vấn. Nếu anh ta xem xét mọi câu hỏi của trang web đầu tiên anh ta tìm thấy trong Google, anh ta có thể đạt điểm cao, mà không thực sự có các kỹ năng cần thiết.


Có một số nhà phát triển sẽ không thể giải thích cây B là gì (ngoài ra đó là "một số cấu trúc dữ liệu"), nhưng vẫn có thể phát triển chính xác.


Tôi không thích nó, nhưng đó là sự thật. Đôi khi bạn cần thuê một ai đó chính xác bởi vì họ nên biết nhiều về một chủ đề hơn bạn, vì vậy theo định nghĩa, bạn không đủ điều kiện để thực hiện cuộc phỏng vấn. Bạn không thể tin cậy sự giúp đỡ ngay cả khi thực hiện cuộc phỏng vấn vì lý do tương tự. Điều tốt nhất bạn có thể làm là cố gắng đặt câu hỏi dựa trên bất cứ nơi nào sự hiểu biết của bạn giao thoa với miền vấn đề và hy vọng bạn gặp may mắn.
kojiro

Hoặc bạn có thể yêu cầu trợ giúp cho một nhà tư vấn hoặc ai đó mà bạn tin là có kỹ năng để thuê các nhà phát triển khác. Tất nhiên, điều này đặt ra một câu hỏi: làm thế nào để bạn biết rằng nhà tư vấn / bạn bè đủ trình độ cho nhiệm vụ này.
Arseni Mourzenko

"số năm bạn đã học ở trường đại học (nhiều hơn là tốt hơn)" ... điều này tốt như thế nào?!? Vì vậy, nếu phải mất 15 năm để có được bằng cử nhân, tôi sẽ tốt hơn so với người có bằng 3 năm? "Không có sinh viên" không nên được ưu tiên hơn những người có thể học xong đại học thường xuyên (tôi đã sử dụng thuật ngữ "sinh viên thất bại" từ đây , hy vọng bản dịch là chính xác.) Nếu bạn không có ý này, có lẽ bạn nên làm rõ bởi vì nó không rõ ràng những gì bạn muốn nêu ở đó.
Bakuriu

@Bakuriu: thực sự, điều này trái ngược với ý tôi. Tôi chỉnh sửa câu trả lời để làm cho nó rõ ràng hơn.
Arseni Mourzenko

2
FWIW Tôi không thể nói với bạn bất cứ nơi nào gần với tất cả các tính năng mới của .NET 4.5 và tôi đã viết một số trong số chúng. Nếu tôi muốn biết nội dung đó, tôi nhập "các tính năng mới của .NET 4.5" vào công cụ tìm kiếm và nó cung cấp cho tôi một danh sách.
Eric Lippert

6

Từ kinh nghiệm của tôi trong công ty của tôi, nơi tôi đã thực hiện nhiều cuộc phỏng vấn, rất có thể người phỏng vấn không có manh mối về cách làm điều đó đúng. Vì vậy, họ đã chuẩn bị một bộ câu hỏi kỹ thuật và tính điểm của điều đó và làm cho hồ sơ của bạn. Điều này tuy nhiên có nhiều nhược điểm và không nên được thực hiện vì những lý do sau:

  • Bạn hỏi kiến ​​thức điểm. Nếu lập trình viên tình cờ chưa bao giờ làm điều gì trong lĩnh vực đó, anh ấy / cô ấy vẫn có thể là một đồng nghiệp xuất sắc, nhưng không biết câu trả lời cụ thể đó. Ngược lại: nếu ai đó đã chuẩn bị cho cuộc phỏng vấn và tìm thấy câu trả lời cho câu hỏi cụ thể đó trên mạng, bạn sẽ có câu trả lời đúng, nhưng người đó có thể không có manh mối nào về chủ đề thực tế.

  • Mọi người lo lắng trong các cuộc phỏng vấn việc làm. Bộ não có tính năng tuyệt vời này để tắt nhiều khu vực cấp cao hơn (như logic) nếu hoảng loạn, điều đó có nghĩa là: nếu bạn lo lắng, bạn có thể không cung cấp chất lượng câu trả lời trong tình huống hàng ngày. Một số người có thể đối phó với một tình huống căng thẳng như một cuộc phỏng vấn, nhiều người không thể.

  • Với một câu trả lời đúng, duy nhất, bạn kiểm tra kỹ năng của người đó để tìm câu trả lời cụ thể đó. Đây là một trong nhiều kỹ năng mà đồng nghiệp cần, nhưng không phải là một và chỉ yêu cầu. Do đó, một hoặc hai trong số những câu hỏi đó là đủ để kiểm tra lĩnh vực kiến ​​thức đó, và sau đó các kỹ năng khác nên được truy vấn. Một cuộc phỏng vấn chỉ chứa các câu hỏi giải quyết vấn đề kiểm tra cùng một kỹ năng nhiều lần.

Câu hỏi nhiệm vụ lập trình tốt là gì?

Những câu hỏi "Bạn có thể viết một chương trình ngắn" nổi tiếng có một vấn đề lớn là hầu hết các lập trình viên không thể viết một dòng mã mà không có IDE của họ giúp họ. Nhưng đó là trong các tình huống làm việc hàng ngày không có vấn đề gì cả, bởi vì lập trình viên luôn có IDE giúp anh ta. Vì vậy, hãy hỏi những điều như "Tìm lỗi", "Viết 50 dòng mã làm ..." hoặc thậm chí các câu hỏi đơn giản cần phải tính đến, rằng người nộp đơn không có sẵn công cụ của mình (IDE, Google).

Ví dụ, tôi có thể trả lời bạn bất kỳ câu hỏi nào trong vòng 1 phút nếu tôi có Google giúp tôi, nhưng không có kết nối Internet, tôi dường như bất lực. Tôi gọi đó là bộ nhớ thuê ngoài, và thay vì cản trở tôi, nó giúp tôi tập trung vào những gì thực sự quan trọng - hiểu cơ chế lót - bởi vì mọi thứ khác có thể được tìm kiếm. Nhưng đừng hỏi tôi về chi tiết từ bất kỳ API ngẫu nhiên nào, vì tôi không biết những API đó, tôi có Google cho điều đó.

Điều đó nói rằng, một câu hỏi nhiệm vụ lập trình tốt không nên tập trung vào việc biết API hoặc các kỹ năng mã hóa đặc biệt trừ khi đây là một yêu cầu tuyệt đối cho công việc. Kiến thức có thể thu được, vì vậy tốt hơn là tìm hiểu xem người đó giỏi kiến ​​thức như thế nào hơn là hỏi những gì anh ấy / cô ấy đã biết.

Một câu hỏi hay cho một nhiệm vụ lập trình nên ngắn gọn, đơn giản, có thể được mã hóa trong mọi ngôn ngữ chỉ với một vài dòng mã và đặc biệt - sẽ cho bạn biết càng nhiều càng tốt về cách người đó làm việc và tìm câu trả lời. Thí dụ:

"Viết một hàm bằng ngôn ngữ bạn chọn lấy một mảng các số nguyên và sắp xếp lại chúng theo cách mà số nguyên đầu tiên sau số cuối cùng và tất cả các số nguyên khác thay đổi theo."

Đầu tiên, bất kỳ ứng viên nào cũng nên hỏi vào thời điểm này là: "Xin lỗi ... bạn có thể vui lòng giải thích nhiệm vụ không?". Bởi vì không có lập trình viên nào được đưa ra một mô tả rõ ràng về những việc cần làm bao giờ. Tiếp theo là lời giải thích, rằng mã trong các câu hỏi nên thực hiện dịch chuyển sang trái nội dung của mảng với phần tràn được thêm vào bên phải.

Nhiệm vụ này rất đơn giản, đến nỗi bất kỳ ai tốt nghiệp bất kỳ hình thức cấp độ lập trình nào cũng có thể trả lời đúng. Điều này tính đến việc lập trình viên phải làm việc mà không có công cụ của mình và việc lo lắng sẽ làm giảm khả năng suy nghĩ logic. Tuy nhiên, nó vẫn cho bạn biết cách mọi người giải quyết vấn đề chỉ từ cách đặt câu hỏi và từ cách mọi người tiếp cận nó, đơn giản vì sự dịch chuyển trái là trái với bản năng 'trái sang phải' và buộc mọi người phải suy nghĩ một giây

Có rất nhiều câu trả lời cho câu hỏi này, vì vậy hãy xem xét kỹ cách phát triển mã là phần quan trọng, chứ không phải nếu giải pháp thực sự hoạt động. Người nộp đơn kiểm tra null? Làm thế nào là tràn được lưu trữ? Là một vòng lặp hoặc một mem-set được sử dụng? Làm thế nào để người nộp đơn xác minh tính chính xác của mã? Câu hỏi đơn giản này cho bạn biết toàn bộ tiểu sử về cách người đó làm việc.

Câu hỏi kiến ​​thức chung tốt là gì?

Câu hỏi hay rất dễ trả lời, cho phép có nhiều câu trả lời (được gọi là 'câu hỏi mở') và cho phép bạn tìm hiểu càng nhiều càng tốt về người nộp đơn trong thời gian ngắn bạn có.

Ví dụ:

(Hỏi một lập trình viên C ++): "Bạn biết những ngôn ngữ nào khác ngoài C ++?"

Đây là một câu hỏi cấp độ đầu vào, giúp người nộp đơn có cơ hội công bằng để bảo lãnh tại thời điểm này nếu anh ta không biết gì về chủ đề được hỏi. Một 'không' tại thời điểm này tốt hơn là hành hạ anh ấy / cô ấy bằng một vài câu hỏi mà tất cả anh ấy / cô ấy phải trả lời: "Xin lỗi, tôi không biết gì về điều đó."

Ngoài ra, nó còn cho bạn biết trước hết những ngôn ngữ mà người khác biết, ngoài ra bạn còn biết người đó quan tâm đến thế nào để có cái nhìn rộng hơn về thế giới lập trình, hoặc nếu bạn có ai đó chỉ có ngôn ngữ duy nhất (và do đó là tính năng / kỹ thuật ) lượt xem.

(Tiếp theo sau đó, giả sử anh ta biết Java): Ba điểm khác biệt hàng đầu giữa C ++ và Java trong vấn đề của bạn là gì? "

Đây là một câu hỏi mở cho phép có nhiều câu trả lời, vì vậy người nộp đơn có cơ hội tốt để tìm ít nhất ba câu hỏi. Yêu cầu ba (ý kiến ​​cá nhân) hàng đầu không chỉ giới hạn các câu trả lời có thể, mà còn buộc người nộp đơn phải sắp xếp dựa trên mức độ ưu tiên. Vẫn là (hoặc nên) dễ trả lời.

Đây là một câu hỏi đơn giản kiểm tra rất nhiều kiến ​​thức chuyên sâu về các ngôn ngữ lập trình khác nhau. Làm thế nào sâu là kiến ​​thức về những chủ đề thực sự? Từ những câu trả lời đó, bạn có thể nói rất nhiều về kiến ​​thức và sự hiểu biết thực tế về cơ chế cơ bản của ngôn ngữ lập trình. Người đó đã chi bao nhiêu với các chi tiết bẩn hoặc nếu anh ta / cô ta chỉ là người liên kết các hàm API khác nhau mà không có manh mối thực sự xảy ra bên dưới những chi tiết đó.

Khái niệm câu hỏi cấp độ tiếp theo là câu hỏi kiến ​​thức chuyên sâu đơn giản cũng có thể được sử dụng cho hầu hết các chủ đề khác. Luôn luôn trong chương trình này: câu hỏi bảo lãnh, câu hỏi xác minh, câu hỏi chuyên sâu. Một ví dụ khác (từ một cuộc phỏng vấn Java):

  1. "Làm thế nào bạn đánh giá kinh nghiệm của bạn với phát triển đa luồng?"
  2. "Hãy đặt tên cho những gì bạn nghĩ là ba điều quan trọng nhất cần xem xét khi phát triển một ứng dụng đa luồng."
  3. "Vui lòng đặt tên ba lớp từ API Java có thể giúp bạn phát triển các ứng dụng đó và đưa ra một mô tả ngắn về những gì chúng được sử dụng cho."

Ba câu hỏi này sẽ cho bạn biết nhiều hơn bất kỳ câu hỏi kỹ thuật nào mà người nộp đơn thực sự biết về các chủ đề đó, trong khi công bằng để trả lời xem xét kiến ​​thức điểm và mức độ căng thẳng.

Vì vậy, lần tới khi ai đó hỏi bạn 20 câu hỏi mã hóa liên tiếp, bạn sẽ biết rằng về cơ bản người đó không có ý tưởng nào về cách phỏng vấn ai đó đúng cách. ;)


Đây thực sự là lời khuyên tốt về cách phỏng vấn imo. Thực sự mong muốn nhiều người theo dõi nó.
Evicatos

5

Cảnh báo: đây được viết dưới dạng (loại) một nhận xét về câu trả lời của @ MainMa, nhưng 1) quá dài để phù hợp với một nhận xét và 2) Tôi nghĩ rằng nó bổ sung một góc nhìn hơi khác về các câu hỏi mang tính xây dựng nên bản thân nó là một câu trả lời thực sự .

Trong câu trả lời của mình, @MainMa phân loại "Các tính năng mới của .NET 4.5 là gì?" như một câu hỏi "tốt".

Tôi có ý kiến ​​khác. Khi anh ấy nói, tôi muốn nói đây là một câu hỏi khá tầm thường. Một câu hỏi hay sẽ giống như: "Mã bạn viết hôm nay khác với mã bạn viết N năm trước như thế nào?" (đối với một số giá trị của N ít hơn số năm kinh nghiệm được liệt kê trong sơ yếu lý lịch, tốt nhất là khoảng 3 đến 5).

Khi anh nói, câu hỏi là về ghi nhớ. Ứng viên này đã ghi nhớ danh sách tính năng hoàn toàn chưa? Theo quyền, người trích dẫn danh sách của Microsoft chính xác nhất sẽ là người chiến thắng.

Điều bạn nên quan tâm là lập trình của anh ấy. Làm thế nào điều này đã ảnh hưởng đến mã của mình? Anh ấy thực sự sử dụng những tính năng nào ? Quan trọng hơn nữa, liệu anh ta có thể hiện sự phán đoán tốt về việc khi nào nên sử dụng các tính năng mới nào và khi nào những tính năng cũ đủ hoàn hảo?

Chỉ có thể nói "LINQ" cho bạn biết hầu như không có gì hữu ích về ứng viên. Có thể nói: "LINQ đã giúp làm cho mã của tôi gọn hơn và dễ đọc hơn vì tôi có thể diễn đạt các khái niệm X, Y và Z một cách sạch sẽ và trực tiếp, nơi trước đây tôi phải nhảy qua các vòng lửa sau để làm những việc đó." (hoặc một cái gì đó tương tự) cho bạn biết rất nhiều về ứng cử viên, loại mã anh ta viết, phán đoán, tính linh hoạt, v.v. Nó cũng cung cấp cho bạn nhiều cơ hội hơn cho các câu hỏi tiếp theo về cách người này nghĩ về các vấn đề, viết mã, nghĩ về mã, v.v. Cuối cùng, nó cho bạn ý tưởng tốt hơn nhiều về việc liệu đây là một ứng viên thực sự có N năm kinh nghiệm hay ai đó có một năm kinh nghiệm, lặp đi lặp lại N lần.

Tóm tắt: việc có thể trích dẫn một danh sách tính năng từ một vài năm trước là vô ích, và cho bạn biết một chút về ứng cử viên có khả năng sử dụng thực sự. Sự tiến bộ của một ứng viên với tư cách là một lập trình viên có thể sẽ được nhiều người quan tâm hơn, vì vậy tốt hơn hết là hỏi về điều đó trực tiếp hơn.


+1. Tôi hy vọng ứng viên không liệt kê danh sách các tính năng mới, nhưng để giải thích những tính năng nào anh ta sử dụng và tại sao; nhưng câu trả lời của tôi không giải thích nó đủ, trong khi của bạn thì có.
Arseni Mourzenko

@MainMa: Điều đó không làm tôi ngạc nhiên - đó là lý do tại sao tôi lặp lại "khi anh ấy nói câu đó" một vài lần trong câu trả lời của tôi.
Jerry Coffin

3

Thực tế là hầu hết các nhiệm vụ hàng ngày hầu hết các nhà phát triển làm trong cuộc sống chuyên nghiệp của họ là tầm thường; Điều đó có nghĩa là một số câu hỏi bạn gặp phải trong một cuộc phỏng vấn xin việc có thể không bao giờ đối mặt với bạn trong thực tế, nhưng điều đó không có nghĩa là không có lý do gì để hỏi những câu hỏi đó.

Giả sử có một vị trí mở trong công ty của bạn và bạn hiện đang phỏng vấn mọi người. Bạn đã có 20-30 nhà phát triển trong hàng đợi. Vậy làm thế nào bạn sẽ chọn ứng cử viên tốt nhất cho vị trí đó? Giả sử nhiệm vụ khó khăn nhất mà họ phải thực hiện trong công việc đó là mở tệp từ hệ thống tệp, đọc từng dòng dữ liệu, sửa đổi một chút và đưa nó trở lại tệp gốc.

Bạn sẽ hỏi họ làm thế nào bạn sẽ mở một tập tin? Tôi cá là bạn không thể thấy sự khác biệt lớn giữa các câu trả lời. Vì vậy, bạn phải đưa ra một giải pháp để phân biệt giữa các nhà phát triển, những người chỉ biết cách mở tệp và những người có thể phát triển ứng dụng thời gian thực tồi. Ngay cả bạn không muốn họ xây dựng một ứng dụng như vậy, nhưng bạn vẫn muốn thuê ứng viên tốt nhất.

Giống như bất kỳ điều gì khác trong cuộc sống của chúng tôi, có một số điểm mà bạn nhận ra rằng bạn cần phải đi và tìm hiểu thêm. Nếu bạn không biết danh sách liên kết là gì, với tôi là một lập trình viên, điều đó có nghĩa đen là bạn chưa thực sự đạt đến điểm đó trong cuộc sống chuyên nghiệp của mình để cảm thấy rằng bạn cần phải đi và học điều cụ thể đó. Tại sao? Đơn giản vì bạn không bao giờ tham gia vào một dự án đủ lớn để yêu cầu bạn cải thiện kỹ năng của mình đến mức đó. Nếu bạn ở cấp độ đầu vào, bạn có thể nói rằng tôi thực sự không có bất kỳ kinh nghiệm làm việc nào cho công việc cụ thể này, nhưng nếu bạn biết điều đó có nghĩa là bạn đủ tự động lực để tự cắt giảm mức trung bình ít nhất.


2

Các kỹ năng cần thiết để thực hiện các nhiệm vụ này hiếm khi quan trọng. Các kỹ năng thể hiện trong cách tiếp cận để trả lời câu hỏi và trong các cuộc đối thoại tiếp theo là toàn bộ vấn đề.

Khi tôi phỏng vấn các nhà phát triển, tôi tìm kiếm (a) thông minh (b) hoàn thành công việc (c) sẽ phù hợp. Có một mức độ kiến ​​thức kỹ thuật cơ bản cần có để hoàn thành bất kỳ vai trò nào, phải sẵn sàng học hỏi và tiếp thu mới kỹ năng. Cuộc phỏng vấn là về việc kiểm tra những hộp đó.

Sở thích của tôi là đọc mã được viết bởi một người nộp đơn. Tôi không thích các câu hỏi phỏng vấn đóng hộp, nhưng chúng cung cấp một cái gì đó để nói về việc không có mã. Tôi thích hỏi về RAII hoặc IOC hoặc việc triển khai IDis Dùng thay vì danh sách và bộ sưu tập, nhưng mọi thứ sẽ làm miễn là chúng tôi có thể có đủ kỹ thuật .

Nỗi sợ hãi tồi tệ nhất của người phỏng vấn là thuê một người thực sự không biết nhiều về tiền mã hóa. Bạn phải nói về một cái gì đó ngoài kinh nghiệm làm việc để loại bỏ hàng giả.


1

Những câu hỏi này là để sàng lọc những người không thể lập trình. Đôi khi, những người không thể lập trình nhưng biết nhiều thứ lặt vặt áp dụng cho các công việc phát triển và việc họ viết một cái gì đó hữu ích và không tầm thường là quá tốn thời gian cho một cuộc phỏng vấn.


1

Tôi có thể thấy rằng những kỹ năng này có thể được sử dụng trong các công việc mà bạn cần viết trình biên dịch, trình điều khiển và làm việc trên nhân hệ điều hành. Khác với những thứ đó, những kỹ năng này được sử dụng ở đâu?

Làm thế nào về việc viết công cụ tìm kiếm, máy chủ web, trình duyệt web, trình xử lý văn bản, bảng tính, trình chỉnh sửa hình ảnh, chương trình vẽ, máy chủ cơ sở dữ liệu, tin sinh học, chương trình giao dịch, trò chơi, mô phỏng vật lý, v.v.

Tôi sẽ cấp cho bạn rằng phần lớn các công việc phần mềm liên quan đến việc lấy dữ liệu từ cơ sở dữ liệu, đưa nó lên màn hình, chỉnh sửa nó, loại bỏ nó khỏi màn hình và đưa nó trở lại cơ sở dữ liệu. Tuy nhiên, ngay cả khi đó, cuối cùng bạn cũng có thể chạy vào một ứng dụng mà các ràng buộc không thể được thỏa mãn bởi các tính năng tích hợp của nền tảng. Tại thời điểm đó, bạn có thể từ bỏ hoặc tiếp cận hộp công cụ thuật toán và cấu trúc dữ liệu của mình và thực hiện giải quyết vấn đề.


0

Các đối tượng lý thuyết được sử dụng để thuận tiện vì bạn phải biết việc triển khai danh sách / biểu đồ / cây trung bình là gì để biết cách giải quyết vấn đề truyền tải ngẫu nhiên, nhưng những câu hỏi này hoàn toàn không phải về các đối tượng lý thuyết.

Họ đang có khả năng làm việc với mô hình trừu tượng, hiểu một vấn đề trừu tượng và giải quyết nó bằng thuật toán dưới bất kỳ hình thức nào. Đây là kỹ năng phát triển thuần túy ở đó, vì vậy nó chắc chắn có giá trị. Đây là lý do tại sao những câu hỏi này có ý nghĩa, không phải vì chúng được cho là tình huống thực tế chính xác.

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.