Cách tốt nhất để phân biệt một lập trình viên xuất sắc trong một cuộc phỏng vấn việc làm là gì?


82

Trong bối cảnh của một cuộc phỏng vấn: cách tốt nhất để xác định một cách đáng tin cậy khi ai đó là một lập trình viên xuất sắc . Điều này có nghĩa là anh ta là một trong những người có hiệu quả / nhanh / nhanh hơn gấp 10 - 15 lần so với các đồng nghiệp của anh ta về phía dưới của quang phổ.

Nhiều người trong chúng ta đã nghe về Vấn đề FizzBuzz như một cách để loại bỏ những người yếu thế. Chắc chắn, dành 5-10 phút để giải quyết vấn đề đó là một chỉ số nghiêm trọng cho thấy ứng viên là một ứng cử viên yếu. Tôi cho rằng một chỉ số tốt là có thể giải quyết nhanh như bạn có thể viết. Điều này dường như không đủ, mặc dù.

Có lẽ nó giống như cho anh ta một chương trình lỗi phức tạp vừa phải, và xem anh ta có thể mò mẫm nó nhanh như thế nào và xác định tất cả các vấn đề với nó?


Câu hỏi giả định rằng nó có thể được thực hiện đáng tin cậy.
Anthony


không cần thiết. một câu trả lời hợp lệ sẽ là 'không có cách nào cả'
Claudiu

Câu trả lời:


65

Tôi xin lỗi bất cứ ai không quan tâm đến câu trả lời dài dòng, nhưng tôi nghĩ điều khá quan trọng là đủ điều kiện để ứng viên của bạn trước khi bạn thuê họ. Bất cứ ai thực hiện một số lượng lớn các cuộc phỏng vấn trong ngành này đều biết rằng hầu hết các ứng cử viên sẽ không kéo dài trong 15-30 phút đầu tiên của một cuộc phỏng vấn, vì vậy hầu hết danh sách này sẽ không cần thiết. Chỉ cần ghi nhớ mức độ đắt đỏ (cả về tài chính và cảm xúc) để sa thải ai đó trước khi bạn loại bỏ danh sách của tôi là quá mức cần thiết. Tôi đã cố gắng liệt kê các chủ đề phỏng vấn của tôi ở đây theo thứ tự quan trọng.

Trí thông minh chung (trêu ghẹo não / câu đố logic)

Kiến thức khoa học máy tính

Bài tập lập trình

  • GCD , Factorial , Fibonacci , Towers of Hà Nội
  • Đảo ngược danh sách và chuỗi
  • Xác định xem danh sách liên kết đơn có vòng lặp không (bạn có thể làm điều đó chỉ với hai con trỏ không?)
  • Tìm lỗi

Kiến thức về kỹ thuật lập trình hướng đối tượng và các mẫu thiết kế phổ biến

Phân tích thuật toán (thời gian chạy O (n) độ phức tạp và yêu cầu lưu trữ)

Sử dụng các công cụ và phương pháp

Kiến thức về các lỗ hổng bảo mật và các cuộc tấn công phổ biến

Toán cơ bản

  • Hệ thống số (chuyển đổi từ cơ sở này sang cơ sở khác)
  • Lý thuyết xác suất
  • Khoảng cách giữa hai điểm trên mặt phẳng Cartesian (định lý Pythagore)
  • Căn bậc hai (Heron of Alexandria, xấp xỉ liên tiếp)

Mật mã

  • Mật mã khóa công khai
  • Mật mã khóa đối xứng
  • Hàm băm
  • Giao thức mật mã (chia sẻ bí mật, bằng chứng không kiến ​​thức)

Toán học rời rạc

  • Logic VCL
  • Đặt lý thuyết
  • Lý thuyết đồ thị
  • Lý thuyết thông tin
  • Kết hợp
  • Chứng minh (như sự tồn tại của số vô tỷ, số nguyên tố vô hạn)

Bạn cũng có thể muốn xem cuốn sách Phỏng vấn lập trình tiếp xúc . Đó là một tài liệu tham khảo tốt về chủ đề này.


10
Phew, đó phải là một cuộc phỏng vấn dài.
Rick Minerich

8
Hôm nay tôi đã cố gắng giải quyết "Cầu vượt" với đồng đội cạnh tranh Lập trình ACM của mình. Sự khác biệt duy nhất là chúng tôi phải giải quyết nó cho bất kỳ số lượng người. Chúng tôi mất khoảng 30 phút để giải quyết cho bất kỳ số lượng N người nào .. nhưng trong một cuộc phỏng vấn tôi cảm thấy như câu đố là một số liệu kém.

52
Trong một cuộc phỏng vấn, câu đố hút vì người được phỏng vấn lo lắng, không suy nghĩ thẳng, v.v ... Ngoài ra, nhiều câu đố khó hiểu là a-ha! loại những điều thực sự không cho bạn biết bất cứ điều gì về ứng cử viên.

11
Tôi thấy những vấn đề toán học có độ khó cao. Sau khi bạn hoàn thành văn bằng Khoa học Máy tính trong 10 năm, làm thế nào bạn có thể nhớ làm thế nào để chứng minh các số vô tỷ và như vậy?

14
Vấn đề với các câu đố là hầu hết mọi người không giải được chúng; họ vừa mới thấy câu trả lời trước đó. Vì vậy, các ứng cử viên hiểu biết nhất sẽ giả vờ không nhìn thấy họ và tạm dừng tìm ra câu trả lời họ đã biết. Nếu mục tiêu của bạn là thuê những người thông minh, không lừa dối người khác, thì câu đố là một lựa chọn tồi.
Kyralessa

28

Ah, câu hỏi muôn thuở.

Tôi đã thực hiện rất nhiều cuộc phỏng vấn trong năm nay (tôi có hai ứng cử viên được lên lịch vào ngày mai) và theo kinh nghiệm của tôi, tuyển dụng là về cảm giác ruột và kỹ năng con người, và ít về kiến ​​thức kỹ thuật.

  1. Dành thời gian của bạn với CV. Một số CV có thể bị từ chối trong vài giây, một số mất nửa giờ. Đôi khi tôi nghĩ về ứng viên dựa trên CV lâu hơn nhiều so với tôi phỏng vấn anh ta. Một vài lần tôi đã chuẩn bị các câu hỏi phỏng vấn cụ thể cho ứng viên đó, mặc dù tôi thường không chuẩn bị câu hỏi.

  2. Kiến thức kỹ thuật - có một mức tối thiểu tôi muốn, và điều này thường khá dễ để nói. Nếu nghi ngờ, trong cuộc phỏng vấn, hãy nói về các dự án anh ấy đề cập trong CV, và đi sâu như bạn cần. Điều này thường là quá đủ để cho bạn biết những gì anh ấy biết và những gì làm cho anh ấy đánh dấu. Giáo dục không quan trọng, vấn đề công việc trước đây, các dự án cá nhân có thể đạt điểm cao.

  3. Hỏi về những gì anh ấy muốn làm và nơi anh ấy muốn đi với sự nghiệp của mình - bạn có cần những gì anh ấy có, và bạn có thể cung cấp những gì anh ấy muốn? Ngoài ra, gần cuối cuộc phỏng vấn, tôi thường hỏi về mức lương ưu tiên. Nếu anh ấy ở ngoài phạm vi của tôi, hoặc nếu tôi sẽ không trả nhiều như vậy cho những gì anh ấy biết, đó là nơi chúng tôi kết thúc cuộc phỏng vấn.

  4. Quan trọng nhất, ứng viên phải phù hợp với đội và tôi phải cảm thấy tự tin rằng chúng tôi sẽ có thể làm việc cùng nhau. Tôi không cần phải thích anh ta, nhưng tôi phải có khả năng xử lý anh ta, và anh ta cần có khả năng xử lý tôi. Nếu không phải như vậy, tôi sẽ vượt qua, vì tôi sẽ không thể sử dụng kiến ​​thức kỹ thuật của anh ấy. Mặt khác, nếu đây là trường hợp, và nếu anh ta là người học nhanh, sự thiếu hiểu biết về kỹ thuật của anh ta sẽ không ngăn cản tôi thuê anh ta.

Tôi đã đào tạo các cô gái từ phòng nhân sự để chuyển cho tôi bất kỳ CV nào ngay khi họ nhận được chúng; Tôi lên lịch phỏng vấn cá nhân, nhanh nhất có thể (lý tưởng nhất là ngày mai sau khi nhận được CV cho CV tốt). Sau đó, anh ta nhận được cuộc phỏng vấn nửa giờ hoặc một giờ với tôi và ít nhất một đồng nghiệp (thường là sếp hoặc thành viên trong nhóm của tôi), nơi tôi làm quen với anh ta và trả lời bất kỳ câu hỏi nào. Ngay cả khi tôi từ chối đơn đăng ký của anh ấy ngay tại chỗ, anh ấy vẫn nhận được 20-30 phút tham quan công ty và tôi nói về những gì chúng tôi làm và cách chúng tôi làm điều đó. Sau đó, tôi gửi anh ta đến phòng nhân sự để kiểm tra tâm lý và một chút mã hóa giấy / SQL thực sự cơ bản. Cả hai bài kiểm tra hầu như không bao giờ đóng một vai trò quan trọng trong quyết định của tôi, đó là một xác minh mà tôi đã đánh giá chính xác trong cuộc phỏng vấn. Sau khi có kết quả, đó là cuộc nói chuyện dài 15 phút khi tôi đưa ra lời đề nghị cho anh ấy và nếu chúng tôi đàm phán các điều khoản mà cả hai chúng tôi đều hài lòng, anh ấy đã thuê.

Đây là một quá trình tôi phải đấu tranh thông qua bộ máy quan liêu của công ty, sau khi bỏ lỡ một vài ứng cử viên tuyệt vời, và nó hoạt động vì tôi là người quyết định tuyển dụng (mặc dù tôi lắng nghe lời khuyên từ cả nhân sự và đồng nghiệp, từ là cuối cùng). Nhiều người ra quyết định, quá trình lâu hơn. Quá trình càng dài, bạn càng phải là Google để có được vị trí hàng đầu.

Ngay khi tôi chắc chắn rằng đó là một trận đấu không có kết quả, tôi kết thúc cuộc phỏng vấn, anh ấy đi tour công ty và kết thúc. Điều này có thể chỉ là hai phút trên điện thoại trong khi lên lịch phỏng vấn. Ngay cả khi bạn từ chối một ứng cử viên, hãy bán công ty. Nếu bạn đã làm một công việc tốt, thuê tốt có thể thông qua truyền miệng từ ứng cử viên bị từ chối.

Ngoài ra, một mẹo. Đừng gửi thư từ chối (hoặc e-mail) cho mỗi ứng dụng bạn nhận được. Trong công ty hiện tại của tôi, tôi thường để điều đó cho HR (ngoài những người tôi nói trong cuộc phỏng vấn), nhưng có lúc nhận được phản hồi rất vui từ ứng viên bị từ chối trong dòng "THANK YOU! Bạn là công ty đầu tiên thực sự trả lời thay vì để tôi tự hỏi liệu một ngày nào đó họ sẽ trả lời! "


Thử nghiệm tâm lý?

5
@ Ink-Jet: không, kiểm tra tâm lý là chính xác - ứng cử viên được yêu cầu viết mã sẽ được duy trì bởi một người đàn ông bạo lực cũng biết địa chỉ nhà của anh ta / cô ta.

Đó là những gì tôi đọc nó lần đầu tiên, thành thật mà nói.

@Grundlefleck - vâng, điều đó đúng. :)
Domchi

2
Nếu tôi nhận được thư từ chối của bạn, tôi sẽ cảm ơn bạn. Tôi đã bị từ chối qua sự im lặng sau khi đi xa như một cuộc phỏng vấn qua điện thoại, và nó rất căng thẳng.
01d55

24

Câu trả lời này là một chút bên ngoài hộp, nhưng tôi nghĩ đó là một điểm có giá trị.

Các lập trình viên tốt nhất hiếm khi phỏng vấn. Họ không phải làm thế . Nếu công ty của bạn đặc biệt thay đổi thế giới, hoặc bí mật che giấu bí mật, hoặc một số lập trình viên mà họ tôn trọng đã đến đó, thì họ có thể nộp đơn, nhưng thông thường các lập trình viên tuyệt vời có được công việc thông qua mạng lưới các cộng sự của họ, chứ không phải bằng cách gửi bản lý lịch.

Vì vậy: cách tốt nhất để nói với một lập trình viên xuất sắc trong một cuộc phỏng vấn xin việc là anh ta không có ở đó .


2
rất đúng ... điểm tuyệt vời :)
Arnis Lapsa

5
Vậy .... đó là "người bạn biết" chứ không phải "bạn làm gì"? Các lập trình viên thực sự khủng khiếp cũng có được công việc của họ thông qua bạn bè và gia đình. Ồ, tôi xin lỗi "mạng lưới cộng sự".
Philip

17

Bất kỳ câu trả lời phải bao gồm các mẫu mã. Thuê một lập trình viên mà không thấy mã của anh ta hoặc cô ta giống như thuê một đầu bếp mà không thử nấu ăn của anh ta hoặc cô ta.


11

Có thể một lập trình viên "xuất sắc" sẽ không đến gặp bạn để phỏng vấn. Bạn có thể phải đánh cắp anh ta từ người khác.


doh! Câu trả lời này dường như đang trở nên phổ biến. Cũng giống như tôi phải bắt đầu ra ngoài và xin việc ...
interstar

9

Một cách để nói với các lập trình viên đam mê từ các lập trình viên "Tôi chỉ muốn một công việc" là hỏi họ xem họ đang đọc cuốn sách nào trong tuần này. Sau đó hỏi họ về những cuốn sách họ đã đọc trong những tuần qua.

Tôi đã thấy rằng các lập trình viên đam mê LUÔN LUÔN đọc, và thường thì danh sách sẽ bao gồm một vài chương trình / Comp. Khoa học. sách trong danh sách gần đây.

Không chỉ là theo kịp "nghề nghiệp" - các lập trình viên đam mê có khát khao và yêu thích lập trình, và có xu hướng nuốt chửng tài liệu về nhiều chủ đề khác nhau - không chỉ là bất kỳ ngôn ngữ nào họ đang sử dụng, mà cả phương pháp, ngôn ngữ khác (đặc biệt là mới hoặc "lạ" hoặc cổ đại), các khía cạnh khác của CNTT (có thể là robot, hoặc AI, hoặc trò chơi, hoặc ...)

Nếu họ không có một danh sách sách gần đây, thì có lẽ họ không phải là một lập trình viên, theo kinh nghiệm của tôi.

Chúc mừng

-R


8
Danh sách sách gần đây của tôi gần như luôn luôn là hư cấu. Đọc kỹ thuật gần đây của tôi gần như hoàn toàn trực tuyến, bởi vì đó là cập nhật hơn.

1
Tốt hơn nữa, hãy hỏi họ những cuốn sách họ đã viết trong tháng này. :)

7

Có nhiều thang đo thời gian khác nhau mà ở đó ai đó có thể "nhanh": một số người thông minh có thể giải các câu đố khó trong vài giây, nhưng một số người thông minh tạo ra rất nhiều mã tốt trong một tháng, mặc dù họ có thể không nhanh như vậy trong các câu hỏi phỏng vấn.

Hỏi các ứng viên xem họ có hoạt động trong bất kỳ dự án nguồn mở nào không, nơi bạn có thể xem lại một số mã của họ và dành thời gian đọc lưu trữ danh sách gửi thư của các dự án đó và ghi nhật ký cam kết. Điều đó sẽ cho bạn biết nhiều hơn bất cứ điều gì các ứng viên có thể chứng minh trong một cuộc phỏng vấn. (Tất nhiên điều này không thể thay thế cuộc phỏng vấn, vì không phải tất cả các lập trình viên giỏi đều làm công việc nguồn mở.)


7

Cuốn sách " Thông minh và những điều đã hoàn thành: Hướng dẫn ngắn gọn của Joel Spolsky để tìm kiếm tài năng kỹ thuật tốt nhất " có thể giúp tìm ra câu trả lời.

Mục lục:

  • Giới thiệu
  • Chương 1: "Đánh những nốt cao"
  • Chương 2: "Tìm kiếm những nhà phát triển vĩ đại"
  • Chương 3: "Hướng dẫn thực địa cho nhà phát triển"
  • Chương 4: "Sắp xếp sơ yếu lý lịch"
  • Chương 5: "Màn hình điện thoại"
  • Chương 6: "Hướng dẫn phỏng vấn du kích"
  • Chương 7: "Sửa chữa các nhóm dưới mức tối ưu"
  • Phụ lục: "Thử nghiệm Joel"

Bài viết của Joel "Hướng dẫn phỏng vấn du kích (phiên bản 3)" cũng có thể hữu ích.

Và bài báo "Xong và làm mọi thứ thông minh" của Steve Yegge về chủ đề này.


4

Hỏi họ một loạt các câu hỏi yêu cầu họ viết mã, và làm cho các câu hỏi trở nên khó hơn. Nếu họ có vẻ thích thử thách, có lẽ bạn có một cuộc sống.

Nếu họ không thể trả lời câu hỏi dễ đầu tiên, như "viết một vòng lặp" hoặc một cái gì đó dễ dàng ngu ngốc, thì bạn biết người này không thể viết mã.


4

Có mã họ trên một bảng trắng. Chỉ có cách bạn sẽ có thể nói nếu họ biết cách viết mã.


Không biết tại sao điều này bị hạ cấp. Nếu một lập trình viên không thể viết mã trên bảng trắng, điều gì khiến bạn nghĩ họ sẽ có thể viết nó trên máy tính?
Kristopher Johnson

3
@Kristopher: Nếu một lập trình viên có thể viết mã tốt trên máy tính, điều gì khiến bạn nghĩ họ sẽ có thể viết nó trên bảng trắng? Đó là những môi trường khác nhau đáng kể.
David Thornley

"Kiểm tra bảng trắng" không nhằm mô phỏng mã hóa thực tế. Đây là cơ hội để xem ứng viên nghĩ như thế nào, liệu ứng viên có thể mô tả những gì họ đang làm hay không, ứng viên tạo ra một giải pháp nhanh như thế nào, v.v. Một người chỉ nhìn vào bảng trắng mà không biết nên viết gì cùng một vấn đề tại một máy tính.
Kristopher Johnson

3

Bạn chủ yếu nên đánh giá công việc mà họ đã làm. Bất kỳ mã hoặc ý tưởng nào mà ai đó tạo ra trong một cuộc phỏng vấn đầy lo lắng là một proxy kém cho những gì họ thực sự có thể tạo ra trong một nhóm.

Để thực hiện các thách thức mã hóa, hãy sử dụng IM với một cái gì đó như codepad.com và để chúng làm điều đó một cách thoải mái tại nhà riêng của chúng. Bạn có viết nhiều mã của bạn trên một bảng trắng trước mặt sếp của bạn, với thời hạn 30 phút và tiền thưởng của bạn trên dòng không? Tôi không.

Vì vậy, cuộc phỏng vấn là vô nghĩa? Không, nhưng cần nhấn mạnh vào việc họ giải thích những gì họ đã làm và chính xác những gì họ đã đóng góp.

Bạn cũng sẽ phải chịu mọi kiểu thiên lệch tâm lý một khi bạn gặp ai đó mặt đối mặt. Đừng vô tình thuê một lập trình viên vì họ giao tiếp bằng mắt tốt hơn hoặc cao hơn người khác. Để giải quyết vấn đề này, tôi sẽ thực hiện càng nhiều cuộc phỏng vấn càng tốt qua IM / email trước khi bạn gặp họ trực tiếp.


Bạn có thể đảo ngược hiệu ứng này bằng cách nhìn vào những thành kiến ​​tâm lý của người khác trong lịch sử tuyển dụng ứng viên. Những người thấp bé đã có vị trí cấp cao và đạt được một điều có lẽ thực sự rất tốt. Những người cao với cùng một lịch sử sẽ, trung bình không quá tốt và nhận được điểm hào quang.
Tim Williscroft

2

Ngôn ngữ không thành vấn đề. Logic nào. Tôi có nghĩa là IDE và trình biên dịch rất tốt trong những ngày này mà bất kỳ lập trình viên giỏi nào cũng có thể chọn bất kỳ ngôn ngữ nào (ok có thể không phải là trình biên dịch) trong một tuần; trở nên đàng hoàng trong một vài tuần và sẽ rất tốt trong một vài tháng.

Đó là bộ não của anh ấy (cô ấy) mà bạn cần xác nhận. Và bạn làm điều đó nói chuyện của tôi. Tôi yêu cầu họ giải quyết các vấn đề đơn giản. Không phải bằng cách viết mã mà bằng cách đẩy tôi qua logic của họ để đi đến một giải pháp.

Nhưng tôi thừa nhận, nếu anh ta không thể viết một vòng lặp đơn giản đếm từ 1 đến 10, bạn sẽ gặp rắc rối.


1

Trước hết, có một cách bạn có thể có ý tưởng trước khi cuộc phỏng vấn bắt đầu:

Nếu họ có blog hoặc đóng góp cho một hoặc nhiều dự án nguồn mở, chỉ cần xem mã và bài viết họ đã viết. Trước hết, nếu họ đã thực hiện một trong hai điều này thì họ có sáng kiến ​​để hoàn thành công việc. Ngoài ra, bạn có thể so sánh những điều này với kinh nghiệm làm việc mà họ đã liệt kê trong sơ yếu lý lịch của họ và có ý tưởng nếu họ về nhà và học hỏi thêm sau khi làm việc, hoặc nếu họ về nhà và quên đi công việc sau 5 giờ chiều.

Về cơ bản, họ có đam mê lập trình hay không? Đó là câu hỏi thực sự.


1

Có một lập trình viên giỏi có mặt trong cuộc phỏng vấn là tốt nhất theo ý kiến ​​của tôi.

Chỉ có một chuyên gia có thể đánh giá nếu người nộp đơn chỉ biết nhiều câu hỏi phỏng vấn hoặc nếu anh ta thực sự nghĩ về các vấn đề và có thể đi vào chi tiết. Hãy nhớ rằng, bạn không muốn thuê người để giải các câu đố phỏng vấn, bạn muốn thuê họ để hoàn thành công việc thực tế.

Câu đố là để loại trừ những người không hiểu đúng những điều cơ bản. Nếu bạn muốn kiểm tra kỹ năng, hãy chuẩn bị một vài điều mà bạn (hoặc "lập trình viên giỏi") có thể đi sâu vào chi tiết và tập trung vào vấn đề mà người nộp đơn phải suy nghĩ một lúc. Làm thế nào để anh ta tiếp cận vấn đề mà anh ta không biết ngay giải pháp?


1

Tôi không nghĩ rằng bạn nên nói về niềm đam mê trong cuộc phỏng vấn. Thành thật mà nói, nó có vẻ như một công ty tìm kiếm "niềm đam mê" thực sự có nghĩa là "làm việc không vì tiền cho ý tưởng".

Đam mê thậm chí không đảm bảo sự xuất sắc. Ý tôi là tôi dành gần như cả đời để lập trình, đọc về lập trình, học các ngôn ngữ điên rồ như Erlang hoặc Clojure và tôi không được trả tiền cho bất kỳ thứ gì trong số đó. Tuy nhiên, tôi không biết lập trình.

Tôi nghĩ rằng lập trình viên xuất sắc nên theo dõi các dự án thành công mà họ đã tích cực tham gia. Do đó, việc lập trình viên viết bất cứ điều gì trên FizzBuzz cơ bản là không cần thiết trong cuộc phỏng vấn. Nói về các dự án trong quá khứ của họ và những gì họ đã làm. Bạn có đang thuê các lập trình viên để giải các khối Rubik và đếm số viên bi hoặc làm việc trong các dự án phần mềm dài và lớn và mệt mỏi của hơn 50 dòng coe không?


1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

Từ bài viết:


Các tiêu chí trong viên đạn

Vì vậy, tóm lại, đây là một số chỉ số và chỉ số phản tác dụng sẽ giúp bạn nhận ra một lập trình viên giỏi.

Các chỉ số tích cực :

  • Đam mê công nghệ
  • Các chương trình như một sở thích
  • Sẽ nói chuyện với bạn về một chủ đề kỹ thuật nếu được khuyến khích
  • Các dự án cá nhân quan trọng (và thường là rất nhiều) trong những năm qua
  • Tự học các công nghệ mới
  • Ý kiến ​​về công nghệ nào tốt hơn cho các mục đích sử dụng khác nhau
  • Rất khó chịu về ý tưởng làm việc với một công nghệ mà anh không tin là có quyền
  • Rõ ràng thông minh, có thể có những cuộc trò chuyện tuyệt vời về nhiều chủ đề
  • Bắt đầu lập trình từ lâu trước khi học đại học / đi làm
  • Có một số tảng băng trôi ẩn giấu của người Hồi giáo, các dự án cá nhân lớn dưới radar CV
  • Kiến thức về một loạt lớn các công nghệ không liên quan (có thể không có trong CV)

Các chỉ tiêu tiêu cực :

  • Lập trình là một công việc hàng ngày

  • Đừng thực sự muốn nói chuyện với cửa hàng, ngay cả khi được khuyến khích

  • Học các công nghệ mới trong các khóa học do công ty tài trợ

  • Rất vui được làm việc với bất kỳ công nghệ nào bạn đã chọn, tất cả các công nghệ đều tốt

  • Có vẻ không thông minh lắm

  • Bắt đầu lập trình tại trường đại học

  • Tất cả kinh nghiệm lập trình là trên CV

  • Tập trung chủ yếu vào một hoặc hai ngăn xếp công nghệ (ví dụ: mọi thứ phải làm với việc phát triển ứng dụng java), không có kinh nghiệm bên ngoài nó


bạn có phiền giải thích thêm về những gì nó làm không và tại sao bạn lại đề nghị nó như trả lời câu hỏi được hỏi? "Câu trả lời chỉ liên kết" không được chào đón tại Stack Exchange
gnat

0

Một lập trình viên xuất sắc cũng sẽ có thể làm việc với những đồng nghiệp phổ thấp hơn. Miễn là họ có thể làm bài kiểm tra và không đắm mình trong bản ngã thì bạn có một ứng cử viên tốt, phải không?

Mặc dù vậy, bài kiểm tra fizzbuzz thật là buồn cười. Giải pháp tôi có thể nghĩ đến là sử dụng toán tử modulo. Mà tôi chỉ biết từ khi làm việc ra các tọa độ ánh xạ bảng ký tự (không bao giờ được đề cập trong trường học hoặc đại học). Lập trình viên trung bình thậm chí sẽ biết về điều đó hoặc tôi đã có giáo dục tào lao?


Tôi ngạc nhiên khi bạn không bắt gặp toán tử modulo. Tôi đã được giới thiệu về nó bằng các ngôn ngữ khác nhau mà tôi đã học được trong năm.

2
Nếu bạn học chuyên ngành CS ở trường đại học, toán tử Modulo là Lập trình 101

những thứ đáng ngạc nhiên như bit-shift và modulo bị bỏ qua ở trường đại học
Claudiu

Tôi nghĩ nó phụ thuộc vào những điều họ đang cố dạy bạn ở trường đại học. Tôi không nghĩ rằng tôi đã từng sử dụng modulo trong một vấn đề thực tế, cũng không dạy nó một cách rõ ràng. Nhưng nó rất phổ biến trong loại bài tập này (và trong các đề thi).
Interstar

2
Trên thực tế, cả hai thường được dạy ở trường tiểu học; ở giai đoạn đó, chúng được gọi là "phần còn lại" và "nhân với 10".
trực giác

0

Một tiêu chí mà tôi sử dụng là để xem 'loại' ngôn ngữ và công cụ mà anh ấy đã làm việc, trong các dự án học thuật hoặc chuyên nghiệp và chính xác những gì anh ấy đạt được. Anh ta đã luôn làm việc ở cấp ứng dụng bằng cách sử dụng các thư viện tiêu chuẩn (luôn là anh chàng C # hoặc VB6?) Nếu anh ta luôn sử dụng những khái niệm cốt lõi và cơ bản này dưới một lớp trừu tượng nào đó, tôi sẽ nghi ngờ.

Điều này rõ ràng là ngoài việc làm cho anh ta viết mã. Không có gì là thay thế cho điều đó. Tuy nhiên tôi phục vụ cho thực tế là một số người có thể viết mã nhanh hơn những người khác và mọi người có thời gian trả lời khác nhau khi trong một cuộc phỏng vấn dưới ánh đèn sân khấu.


đệ quy, đồng bộ hóa quá trình, loại trừ lẫn nhau. Những công nghệ đó đều quan trọng như nhau cho dù bạn làm việc với C #, VB.NET, C hay ngôn ngữ lắp ráp.

-1 - Đây là sai lầm chết người. 'Loại' ngôn ngữ và công cụ là 100% 'không liên quan'.
Morgan Herlocker
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.