최소 x 년의 경력이 필요한 많은 일자리가 추가되는 것을 보았습니다. 문제는 응시자가 몇 년의 경험이 필요한지 어떻게 알 수 있습니까? x 년 경험이있는 사람에게 기대하는 바는 무엇입니까 (편집 : 기술 점검에 의존하지 않고 이력서가 거짓말을하지 않는지 효과적으로 확인합니까?) x 년 경험이있는 사람은 y 년 (y <x 인 사람)이 할 수없는 일을 할 수있는 방법은 무엇입니까 (편집 : 비슷한 기술이 있다고 가정)?

y 년의 경험을 가진 열정적 인 프로그래머가 많은 지식을 가지고 있고 여러 프로젝트에서 일한 경험이 있고 x 년의 경험 (x> y)을 가진 다른 프로그래머가 거의없는 프로젝트에서 많은 경험을 가지고 있지 않은 경우가있을 수 있습니다.

왜 "이 기술을 알고 있고 그 일을하는 방법 (디자인, 커뮤니케이션, 견적 등)을 알고 있다면 우리의 업무에 적합하다"고 말하면 안될까요?

엔터프라이즈 아키텍트를 위해 1 년의 경력을 가진 새로운 졸업생을 고용 할 수는 없지만 거의 모든 광고가 경험을 요구한다는 사실에도 문제가 있습니다. IMHO는 먼저 열정을 고려해야합니다.

먼저 질문이이 사이트에 적합한 지 알지 못했지만 채용 및 경험에 대한 태그가 있기 때문에 여기에 자리가 있다고 생각합니다.

질문은 두 개의 하위 질문으로 나누어 처리 할 수 ​​있습니다.

왜 수년간의 경험을 요구 사항으로 사용합니까?

쉽게 검증 할 수있는 메트릭 이기 때문에 프로그래밍 역량과 양의 상관 관계 가 있습니다 . Snagulus의 답변은 이미 상관 관계의 세부 사항에 대해 자세히 설명하고 있으므로 "이유"에 중점을 둘 것입니다.

어려운 사실은 일반적으로 주어진 입장에 대해 둘 이상의 후보자가 있다는 것입니다. 또한 인터뷰는 특히 "적절하게"수행 된 경우 기술적으로 유능한 직원 (이 경우 프로그래머)이 수행합니다.

따라서 들어오는 CV 를 처음으로 체포하는 일부 기준을 사용해야하며 비 기술적 직원이 확인할 수있는 기준을 사용해야합니다. 의심스러운 경우 HR 직원은 항상 이전 고용주에게 전화하여 예, John Smith가 그들과 X 년.

대신 "열정"을 요구 사항으로 사용하지 않는 이유는 무엇입니까?

이것에는 적어도 두 가지 문제가 있습니다.

"열정"을 측정하는 방법?

KLOC가 기록 되었습니까? 프로그래밍 (및 기타 분야)에서 더 많은 지식이 "더 나은"것과 동일하지 않다는 것을 알게 되니 행운을 빌어 요.

오픈 소스 / 취미 프로젝트가 완료 되었습니까? HR에 의해 쉽게 확인되지 않으며, 많은 유능한 프로그래머는 다른 시간이 걸리는 의무, 긴장을 풀고 싶어하는 긴 근무 시간, 근무 시간 동안 간단한 전문적인 성취 등 그와 관련하여 비활성해야 할 정당한 이유가 있습니다.

수년간의 경험? 아 잠깐만 ...

"열정"이 실제로 역량에 대한 좋은 지표입니까?

Robert Harvey가 자신의 의견에서 밝힌 것처럼 열정은 실제로 유능한 프로그래밍을 나타내는 것이 아닙니다. 경험과 비교할 때, 그것은 주로 직교 품질 입니다.

• 열정적이고 유능한 프로그래머 및
• 감정적으로 그리고 기술적으로 유능한 프로그래머 와
• 열정적이고 기술적으로 무능 프로그래머 와
• 열정적이고 기술적으로 무능한 프로그래머
• 등

마지막 사례는 우리의 맥락에서 중요합니다. 수년간의 경험은 주어진 프로그래머가 어떻게 든 자신의 직무에서 기능을 수행했음을 보여줍니다. (예 : Scrum Post-it 메모)는 "느려집니다."

최종 면책

우선, 다행스럽게도 "경험 년"은 종종 "느슨하게"평가 됩니다. 예를 들어, 언어 X를 사용하여 일자리를 신청하고 있지만 언어 Y에 대해서는 "상업적"경험 만 있고 X와 유사합니다. 고려.

둘째, 개인적으로 나는 "N 년의 경험"의 팬이 아니며, 유일한 사람은 아닙니다. "experience in"을 지정하는 간단한 대안이 있습니다 . CV에서 경험을 문서화해야하기 때문에 일반적으로 필터로 충분합니다. 이전에는 웨이터 만 수행 한 프로그래밍 위치에 대한 후보를 얻는 경우 (이는 발생합니다!) 무언가 잘못되었을 수 있습니다.

"경험 년"은 구체적인 척도보다 확률 척도입니다. 몇 년이 지나면 다음과 같은 일이 발생했을 가능성이 높아집니다.

• 위기와 같은 행사에 참여했습니다.
• 처음부터 끝까지 프로젝트를 보았습니다.
• 프로젝트 시작 또는 종료에 실패했습니다.
• 레거시 코드에서 작업했습니다.
• 빈 슬레이트에서 일하고 무언가를 만들었습니다.
• 디자인 결정을 구현했습니다.
• 시스템을 설계했습니다.
• 버그를 작성하고 잘못된 수정 사항을 발표했으며 서버를 중단했습니다. 본질적으로 망했다.
• 스크류 업을 수정했습니다.
• 그들이 일하는 언어에서 이상한 경우를 발견하고 중요한 곳을 보았습니다.
• 현재 코드베이스에있는 것들이 바보 일 수 있음을 알게되었습니다.
• 이러한 것들은 필수가 아닌 작은 샘플이며 실제 환경에서 작동하는 것을 발견 할 수있는 수십 개의 작은 것들도 포함합니다.

다시 말하지만, 그것은 우연한 일이며 전적으로 그들이 수년간의 경험을 얻은 / where /에 달려 있습니다. 한 사람이 수백 명의 팀으로 구성된 단일 프로젝트에서 일하면서 고도로 전문화 될 수있었습니다. 또 다른 하나는 시범적인 소규모 상점에 있었을 수 있으며 서버 / 설치 / 코딩 / QA / DBA / 프로젝트 관리를 처리 할 때 일반인이 될 수 있습니다. 같은 해의 경험을 반복해서 얻는 사람들도 있습니다.

대략적인 척도이지만, 평균적으로 사람은 더 오래 일할수록 더 많은 잠재적 인 학습 이벤트에 노출 될 수 있으며 예비 데이터 포인트로 유용합니다. 이력서의 나머지 부분 (및 더 중요한 인터뷰)은 실제로 알고있는 것과 실제로 수행 한 것을 파악하기위한 것입니다.

나는 게시물에있는 각 질문을 해결함으로써 이것에 대답 할 것입니다.

문제는 응시자가 몇 년의 경험이 필요한지 어떻게 알 수 있습니까?

이것은 일반적으로 인터뷰 프로세스가 필터링하는 것을 목표로합니다. 여러 번의 인터뷰가 진행되며 일반적으로 사내 개발자 중 일부에 대한 후보 경험을 평가할 수 있습니다.

x 년 경험이있는 사람에게서 무엇을 기대하십니까?

작업 포스트에 지정된 작업 요구 사항을 충족시킬 것으로 예상합니다. 예를 들면 다음과 같습니다.

"우리는 시스템 설계 및 아키텍처 분야에서 10 년 이상 경험을 쌓은 수석 PHP 개발자를 찾고 있습니다. 시스템 설계 및 아키텍처를 수석 아키텍트로 시스템 툴을 재구성하는 한편 K 개발자 및 주니어 개발자를 관리하고 그 과정을 안내합니다. 필요합니다 ... (등 등) "

x 년 경험이있는 사람은 y 년 (y <x 인) 사람이 할 수없는 일을 할 수 있습니까?

이 경우에 잘못된 경험을보고 있습니다. 채용 공고는 몇 년을 요구할뿐만 아니라 회사가 사용하는 기술에 대한 경험도 가지고 있습니다. C ++ 개발에 10 년의 경험이 있고 5 년의 경험을 가진 C ++ 개발자를 찾는 게임 회사라고 말하십시오. 이전에는 게임 업계에서 일한 적이 없기 때문에 여전히 이상적인 후보자가 아닙니다. 내 직업 게시물은 실제로 다음을 지정합니다 : 프로그래밍의 A, B, C 측면에서 X 년 경험.

y 년의 경험을 가진 열정적 인 프로그래머가 많은 지식을 가지고 있고 여러 프로젝트에서 일한 경험이 있고 x 년의 경험 (x> y)을 가진 다른 프로그래머가 거의없는 프로젝트에서 많은 경험을 가지고 있지 않은 경우가있을 수 있습니다.

이전 답변을 읽으십시오. 경험은 여러분이 경험 한 도구와 연결되어 있습니다. A, B, C 도구에서 X 년.

왜 "이 기술을 알고 있고 그 일을하는 방법 (디자인, 커뮤니케이션, 견적 등)을 알고 있다면 우리의 업무에 적합하다"고 다시 시작할 수없는 이유는 무엇입니까?

이것은 일어날 수 있고 일어난다. 자신을 증명할 수 있다면 수년간의 경험은 중요하지 않습니다. 자신과 같은 사람의 경우 면접관 / 채용 담당자가 개발자 인 소규모 개발자 상점에 더 적합합니다. 더 큰 회사는 일반적으로 HR이 이러한 유형의 작업을 수행하므로 작업 요구 사항을 너무 넓게하여 기본적으로 웹 사이트에 작은 기능을 작성하기 위해 15 년 이상의 경험을 가진 박사 학위가 필요합니다 (과장 과장이지만 결함에 대해 설명합니다) 프로그래머 모집, 특히 대기업의 경우-이 질병으로 고통받는 것은 아니지만)

수년간의 경험은 단순히 직업 설명에 나열된 원하는 기술을 사용하여 사람에게 기대되는 것에 대한 "거친"추정치를 제공하는 필터입니다.

여기에 내가 기대하는 것이 많지만 다른 사람들은 다른 아이디어를 가질 수 있습니다.

2 년 이하-대부분의 작업에 대해 공정한 감독이 필요한 학습 곡선이 있음을 알고 고용주와 함께 특정 작업을 수행 할 수 있어야합니다.

3 ~ 5 년 – 0 년에서 2 년의 경험에서 이미 유사한 작업을 수행 했으므로 많은 손을 들지 않고 수행해야 할 작업을 수행 할 수 있어야합니다. 또한 "스마트 한"이니셔티브를 보여주고 명확하게 정의되지 않은 소규모 작업을 처리 할 수 ​​있어야합니다. (예 : 요구 사항을 직접 추적해야하는 요구 사항에서 모듈을 설계 할 수 있어야합니다).

5-7 년-스스로 작업을 수행하고 위의 "작업"이 무엇인지 결정할 수 있어야합니다. 명확하게 정의되지 않은 중간 규모의 작업을 처리 할 수 ​​있어야합니다. (예 : 서브 시스템을 설계 / 구현 / 판매 할 수 있어야 함). 또한이 시간 범위에서 서브 시스템 팀을 이끌 기 시작해야합니다. 최소한 내부 팀에게 책임이있는 서브 시스템에 대한 프리젠 테이션을 제공하십시오.

8-10 년-프로젝트의 매우 큰 및 / 또는 중요한 서브 시스템을 제공받을 수 있습니다. 여러 기술의 상주 전문가. 대규모 서브 시스템 팀을 이끌 수 있습니다. 고객이 담당하는 서브 시스템을 프리젠 테이션하십시오.

10 년 이상-작업 설명과 대부분의 다른 반 관련 소프트웨어 작업 내에서 소프트웨어 작업을 거의 처리 할 수 ​​있습니다. 많은 소프트웨어 영역의 상주 전문가. 요구 사항에서 매각을 통해 대규모 프로젝트를 이끌 수 있습니다. 모듈 / 서브 시스템 설계 만이 아니라 시스템 설계를 이해합니다. 안정적이고 견고하며 유지 관리가 가능한 시스템을 설계 할 수 있습니다. 시스템 관점에서의 프리젠 테이션을 포함하여 고객과의 소프트웨어 인터페이스입니다. 입찰 제안 및 일정을 적절하게 정리할 수 있습니다.

수년간의 경험 정의는 모호하지만 고용주의 이익을위한 것이 아니라 구직자를위한 지침이기도합니다. 따라서, 당신이 고용되면, 당신이 8-10 년의 경험을 가지고 직장에 와서 당신이해야 할 모든 작은 일을 들려야한다고 주장 할 때, 회사에서 당신의 미래는 "매우 제한적"입니다. 전혀. 첫인상은 변하기 어렵 기 때문에 개발자가 더 나아지더라도 사람들은 여전히 ​​자신에 대한 인상을 유지할 것입니다.

나는 몇 달이나 몇 년 안에 사라진 "고급"개발자들이 상당히 고용 된 것을 보았습니다. "직원 개발"프로그램은 실제로 첫 번째로 빠른 길입니다. 정리 해고 목록. 동일한 개발자가 낮은 수준 (물론 저임금을 의미 함)에 들어간 경우, 성공적인 고용으로 간주되어 제대로 수행 된 것으로 간주 될 수 있습니다.