Tôi thấy nhiều công việc bổ sung đòi hỏi ít nhất x năm kinh nghiệm. Câu hỏi là làm thế nào để bạn biết khi nào một ứng viên có nhiều năm kinh nghiệm cần thiết? Bạn mong đợi điều gì từ một người có kinh nghiệm x năm (chỉnh sửa: hiệu quả làm thế nào để bạn kiểm tra xem CV không nói dối mà không dựa vào kiểm tra kỹ năng)? Người có kinh nghiệm x năm có thể làm gì mà người có y năm (với y <x) không thể làm gì (chỉnh sửa: giả sử họ có kỹ năng tương tự)?

Có thể có trường hợp với một số lập trình viên đam mê với kinh nghiệm nhiều năm có kiến ​​thức rộng lớn và làm việc trên nhiều dự án và lập trình viên khác có kinh nghiệm x năm (x> y) đã làm việc trong một vài dự án và không có nhiều kinh nghiệm.

Tại sao nó không thể được giảm xuống thành thứ như thế này "nếu bạn biết công nghệ này và bạn biết cách thực hiện công cụ đó (có thể là thiết kế, giao tiếp, ước tính, v.v.) thì bạn có phù hợp với công việc của chúng tôi không"?

Tôi biết bạn không thể thuê một sinh viên mới tốt nghiệp có kinh nghiệm 1 năm cho bài viết của một kiến ​​trúc sư doanh nghiệp nhưng tôi cũng thấy một vấn đề với sự thật mà hầu hết tất cả các quảng cáo đều yêu cầu kinh nghiệm. IMHO đam mê trước hết nên được tính đến.

Đầu tiên tôi không biết câu hỏi có phù hợp với trang web này không nhưng vì có một thẻ để tuyển dụng và kinh nghiệm nên tôi tin rằng nó có một vị trí ở đây.

Câu hỏi của bạn có thể được xử lý bằng cách chia thành hai câu hỏi phụ.

Tại sao sử dụng nhiều năm kinh nghiệm như một yêu cầu?

Bởi vì đó là một số liệu dễ kiểm chứng có mối tương quan tích cực với năng lực lập trình . Câu trả lời của Snagulus đã xây dựng chi tiết về các mối tương quan, vì vậy tôi sẽ tập trung vào "tại sao".

Sự thật phũ phàng là thường có nhiều hơn một ứng cử viên cho một vị trí nhất định. Ngoài ra, các cuộc phỏng vấn khá tốn tài nguyên, đặc biệt nếu chúng được thực hiện "đúng cách", tức là các cuộc phỏng vấn kỹ thuật được thực hiện bởi các nhân viên có năng lực kỹ thuật (trong trường hợp này là các lập trình viên).

Do đó, một số tiêu chí để sàng lọc ban đầu thông qua các CV đến cần được sử dụng, và tốt nhất là một tiêu chí có thể được xác minh bởi các nhân viên phi kỹ thuật - khi nghi ngờ, nhân sự luôn có thể gọi cho các nhà tuyển dụng trước đó và kiểm tra xem có, John Smith đã làm việc cho X năm với họ.

Tại sao không sử dụng "đam mê" như một yêu cầu thay thế?

Có ít nhất hai vấn đề với điều này:

Làm thế nào để đo lường "đam mê"?

KLOCs đăng nhập? Chúc may mắn phát hiện ra rằng, trong lập trình (và các chuyên ngành khác), nhiều lời quảng cáo không đồng nghĩa với "tốt hơn".

Nguồn mở / dự án sở thích đã hoàn thành? Không dễ dàng kiểm tra bởi HR, và rất nhiều lập trình viên có năng lực có lý do chính đáng để không hoạt động trong vấn đề đó - nghĩa vụ tốn thời gian khác, thời gian làm việc dài với mong muốn thư giãn, hoàn thành chuyên môn đơn giản trong giờ làm việc, v.v.

Số năm kinh nghiệm? Ồ, đợi đã ...

"đam mê" có thực sự là một thước đo tốt cho năng lực?

Như Robert Harvey nói trong nhận xét của mình, niềm đam mê không thực sự là biểu hiện của một chương trình có thẩm quyền. So với kinh nghiệm, đó là chất lượng chủ yếu trực giao - nghĩa là tồn tại:

• lập trình viên đam mê và có năng lực và
• lập trình viên có thẩm quyền và kỹ thuật và
• lập trình viên đam mê và không đủ kỹ thuật và
• lập trình viên đam mê và không có kỹ thuật,
• Vân vân.

Ví dụ cuối cùng rất quan trọng trong bối cảnh của chúng tôi - nhiều năm kinh nghiệm cũng cho thấy một lập trình viên nhất định đã bằng cách nào đó quản lý để hoạt động trong công việc của mình, trong khi một lập trình viên đam mê thất thường có thể, ví dụ như từ chối tham gia vào hệ thống quản lý tác vụ đơn giản nhất (nói, Scrum Post-it ghi chú), bởi vì "nó làm tôi chậm lại."

Từ chối trách nhiệm cuối cùng

Trước hết, và may mắn thay, "năm kinh nghiệm" thường được đánh giá "lỏng lẻo" - tức là nếu bạn đang xin việc với ngôn ngữ X, nhưng chỉ có kinh nghiệm "thương mại" với ngôn ngữ Y, tương tự như X, điều đó cũng thường đưa vào tài khoản.

Thứ hai, cá nhân tôi không phải là người hâm mộ "N năm kinh nghiệm" và tôi không phải là người duy nhất. Có một cách thay thế đơn giản - chỉ định "kinh nghiệm trong" . Điều đó thường đủ cho một bộ lọc, vì các ứng cử viên buộc phải ghi lại kinh nghiệm đó vào CV của họ - nếu bạn nhận được một ứng cử viên cho vị trí lập trình mà trước đây chỉ thực hiện chờ đợi (và điều này xảy ra!) Bạn biết có thể có gì đó không đúng.

"Số năm kinh nghiệm" là một thang đo xác suất hơn là thước đo của bất cứ thứ gì cụ thể. Sau nhiều năm, bạn có cơ hội gia tăng rằng một người đã gặp phải những điều như:

• Đã tham gia vào một sự kiện như khủng hoảng.
• Đã thấy một dự án từ đầu đến cuối.
• Đã thấy một dự án không bắt đầu hoặc kết thúc.
• Đã làm việc trên mã di sản.
• Đã làm việc trên một bảng trống và làm một cái gì đó.
• Đã thực hiện các quyết định thiết kế.
• Đã thiết kế một hệ thống.
• Đã viết một lỗi, phát hành một bản sửa lỗi xấu, gỡ xuống một máy chủ; Đã vặn vít lên, về cơ bản.
• Đã sửa chữa một ốc vít.
• Đã tìm thấy các trường hợp cạnh kỳ lạ trong ngôn ngữ họ làm việc và thấy một nơi mà họ quan trọng.
• Đã học được rằng những thứ hiện tại trong codebase có thể bị câm.
• Lưu ý, những thứ này là một mẫu nhỏ, không bắt buộc và cũng bao gồm hàng tá những thứ nhỏ có thể tìm thấy khi làm việc trong môi trường sống.

Một lần nữa, đó là một cơ hội, và nó phụ thuộc hoàn toàn vào / nơi / họ có được những năm kinh nghiệm đó. Một người có thể đã làm việc trong một dự án duy nhất trong một nhóm gồm vài trăm người và trở nên chuyên môn cao. Một người khác có thể đã ở trong một cửa hàng nhỏ thử nghiệm và trở thành một người tổng quát hơn khi họ đối phó với các máy chủ / cài đặt / mã hóa / QA / DBA / quản lý dự án. Cũng có những người thấy mình nhận được cùng một năm kinh nghiệm nhiều lần.

Đó là một biện pháp sơ bộ, nhưng trung bình một người sẽ được tiếp xúc với các sự kiện học tập tiềm năng hơn khi họ làm việc lâu hơn và nó hữu ích như một điểm dữ liệu sơ bộ. Phần còn lại của sơ yếu lý lịch (và quan trọng hơn là cuộc phỏng vấn) là để tìm ra những gì họ thực sự biết, và những gì họ thực sự đã làm.

Tôi sẽ trả lời điều này bằng cách giải quyết từng câu hỏi của bạn trong bài viết.

Câu hỏi là làm thế nào để bạn biết khi nào một ứng viên có nhiều năm kinh nghiệm cần thiết?

Đây thường là những gì quá trình phỏng vấn nhằm mục đích lọc ra. Nhiều cuộc phỏng vấn được thực hiện và bạn thường có thể đánh giá trải nghiệm của ứng viên đối với một số nhà phát triển nội bộ của riêng bạn.

Bạn mong đợi gì từ một người có x năm kinh nghiệm?

Bạn sẽ mong đợi họ thực hiện các yêu cầu công việc được chỉ định trong một bài đăng công việc. Ví dụ:

"Chúng tôi đang tìm kiếm một nhà phát triển PHP cao cấp với hơn 10 năm kinh nghiệm làm việc trong thiết kế và kiến ​​trúc hệ thống để tái cấu trúc các công cụ hệ thống của chúng tôi với tư cách là kiến ​​trúc sư trưởng, trong khi quản lý số lượng K của các nhà phát triển cấp cao và cấp cao và hướng dẫn họ trên đường đi. yêu cầu ... (v.v.) "

Người có kinh nghiệm x năm có thể làm gì mà người có y năm (với y <x) không thể làm gì?

Bạn đang nhìn vào kinh nghiệm sai trong trường hợp này. Các bài đăng công việc không chỉ yêu cầu số năm mà còn có kinh nghiệm về các công nghệ mà công ty đang sử dụng. Giống như bạn có thể có 10 năm kinh nghiệm trong việc phát triển C ++ và nói rằng tôi là một công ty chơi game đang tìm kiếm các nhà phát triển C ++ với thậm chí 5 năm kinh nghiệm. Bạn vẫn sẽ không phải là ứng cử viên lý tưởng của tôi bởi vì bạn chưa bao giờ làm việc trong ngành công nghiệp game trước đây. Bài đăng công việc của tôi thực sự sẽ chỉ định: X số năm kinh nghiệm trong các khía cạnh A, B, C của lập trình.

Có thể có trường hợp với một số lập trình viên đam mê với kinh nghiệm nhiều năm có kiến ​​thức rộng lớn và làm việc trên nhiều dự án và lập trình viên khác có kinh nghiệm x năm (x> y) đã làm việc trong một vài dự án và không có nhiều kinh nghiệm.

Đọc câu trả lời trước của tôi. Kinh nghiệm gắn liền với các công cụ bạn có kinh nghiệm. X số năm trong các công cụ A, B, C.

Tại sao nó không thể được nối lại thành thứ như thế này "nếu bạn biết công nghệ này và bạn biết cách làm công cụ đó (có thể là thiết kế, giao tiếp, ước tính, v.v.) thì bạn có phù hợp với công việc của chúng tôi không"?

Điều này có thể và không xảy ra. Nếu bạn có thể chứng minh bản thân thì kinh nghiệm trong nhiều năm không thành vấn đề. Đối với một anh chàng như mình, bạn có vẻ phù hợp hơn với một cửa hàng dev nhỏ hơn, nơi người phỏng vấn / nhà tuyển dụng là một nhà phát triển anh ấy / cô ấy. Các công ty lớn hơn thường có nhân sự làm loại công cụ này, đó là lý do tại sao họ yêu cầu công việc rộng đến mức về cơ bản bạn cần một tiến sĩ với hơn 15 năm kinh nghiệm để viết các chức năng nhỏ cho trang web của họ (cường điệu quá mức nhưng nó giải thích những sai sót trong tuyển dụng lập trình viên, đặc biệt là cho các công ty lớn hơn - mặc dù không phải tất cả họ đều phải chịu đựng điều này)

Kinh nghiệm nhiều năm chỉ đơn giản là một bộ lọc đưa ra ước tính "thô" về những gì được mong đợi của người sử dụng các kỹ năng mong muốn được liệt kê trong bản mô tả công việc.

Đây là những gì tôi mong đợi nhiều, nhưng những người khác có thể có những ý tưởng khác nhau:

2 năm hoặc ít hơn - Bạn sẽ có thể thực hiện các nhiệm vụ cụ thể mà bạn được yêu cầu, với nhà tuyển dụng biết rằng sẽ có một lộ trình học tập với sự giám sát hợp lý cho hầu hết các nhiệm vụ đó.

3 - 5 năm - Bạn sẽ có thể thực hiện các nhiệm vụ mà bạn được yêu cầu thực hiện mà không cần phải nắm tay nhiều vì bạn đã thực hiện các nhiệm vụ tương tự trong kinh nghiệm 0 đến 2 năm của mình. Bạn cũng nên bắt đầu thể hiện một số sáng kiến ​​"thông minh" và có thể xử lý các nhiệm vụ nhỏ hơn không nhất thiết phải được xác định rõ ràng. (ví dụ: Có thể thiết kế các mô-đun từ các yêu cầu, trong đó bạn phải tự mình theo dõi một số yêu cầu đó).

5 - 7 năm - Bạn sẽ có thể tự làm việc và có thể quyết định những "nhiệm vụ" đó ở trên là gì. Bạn sẽ có thể xử lý các tác vụ cỡ trung bình không được xác định rõ ràng. (ví dụ: Có thể thiết kế / thực hiện / bán hệ thống con). Bạn cũng nên bắt đầu lãnh đạo các nhóm hệ thống con trong phạm vi thời gian này. Đưa ra các bài thuyết trình cần thiết về các hệ thống con mà họ chịu trách nhiệm, ít nhất là cho nhóm nội bộ.

8 - 10 năm - Có thể dựa vào để được cung cấp rất lớn và / hoặc các hệ thống con quan trọng của dự án. Chuyên gia thường trú trong một số công nghệ. Có thể lãnh đạo các nhóm hệ thống con lớn. Đưa ra các bài thuyết trình về các hệ thống con mà họ chịu trách nhiệm cho khách hàng.

Hơn 10 năm - Có thể xử lý khá nhiều nhiệm vụ phần mềm được ném vào chúng, trong giới hạn của mô tả công việc VÀ hầu hết các nhiệm vụ phần mềm bán liên quan khác. Chuyên gia thường trú trong một số lượng lớn các lĩnh vực phần mềm. Có thể dẫn dắt các dự án lớn, từ yêu cầu thông qua bán tháo. Hiểu thiết kế hệ thống và không chỉ thiết kế mô-đun / hệ thống con. Có thể thiết kế hệ thống đáng tin cậy, mạnh mẽ và có thể bảo trì. Là giao diện phần mềm cho khách hàng, bao gồm các bài thuyết trình từ góc độ hệ thống. Có thể kết hợp đầy đủ các đề xuất và lịch trình đấu thầu.

Trong khi nhiều năm định nghĩa kinh nghiệm là mơ hồ, nó không chỉ vì lợi ích của người sử dụng lao động mà còn là một hướng dẫn cho người tìm việc. Do đó, nếu bạn được tuyển dụng, tuyên bố bạn có 8 đến 10 năm kinh nghiệm và đi làm và cần được nói với mọi nhiệm vụ nhỏ bạn cần làm thì tốt nhất là tương lai của bạn tại công ty là "rất hạn chế" nếu bạn thậm chí còn rất lâu dài chút nào Ấn tượng đầu tiên rất khó thay đổi, vì vậy ngay cả khi bạn trở thành nhà phát triển tốt hơn, mọi người vẫn có thể duy trì ấn tượng ban đầu của họ về bạn.

Tôi đã thấy một số lượng lớn các nhà phát triển "cấp cao" được thuê đã mất trong vài tháng hoặc trong một vài năm được đưa vào chương trình "phát triển nhân viên", đây thực sự chỉ là bước đầu tiên để trở thành người đầu tiên danh sách sa thải. Nếu những nhà phát triển tương tự đã tham gia ở mức thấp hơn (tất nhiên điều đó có nghĩa là lương thấp hơn) thì rất có thể họ đã được coi là một người thuê thành công và được coi là thực hiện đầy đủ.