프로그래머의 Github 프로파일을 어떻게 평가 하시겠습니까? [닫은]


54

오픈 소스 커뮤니티의 많은 사람들은 채용시 후보의 Github 프로파일을 강력하게 고려한다고 말합니다.

나는 Github에서 활발히 활동하고 있으며, 내 자신의 몇 가지 프로젝트와 다른 사람들에게 공헌하고 있습니다. 그러나 내가 고용주 인 것처럼 내 자신의 프로필을 보면, 나는 많은 소음을 봅니다. 복제 한 적이 있지만 결코 기여한 적이없는 프로젝트 등.

사람들의 Github 프로파일을 평가한다면 어떻게합니까? 그리고 개발자로서 다른 작업을 수행해야합니까? 예를 들어, 현재 작업하지 않는 복제 된 저장소를 삭제합니까?


1
본인이 시작한 프로젝트와 자신이 기여한 프로젝트를 공개하고 싶습니다. 소스 코드는 디자인, 코딩 기능에 대한 충분한 증거입니다. 정규 업무 이외의 프로젝트에 대한 열정도 선호도를 나타냅니다. atleast에 대한 몇 가지 조언은 작업 토론을 시작합니다.
Abi

3
당신이 그것에 기여하지 않을 경우 왜 프로젝트를 포크합니까? 이것은 GitHub에서 많이 일어난 것 같습니다. 원본 작성자가 리포지토리를 삭제하기로 결정할 때 소스 코드가 사라지지 않도록해야합니까?
Htbaa

5
@Htbaa-가끔 뭔가를 포크하여 소스 코드를 찔러서 기여할 수도 있다고 생각합니다. 때때로 나는 공헌하게됩니다. 나는 그렇지 않습니다.
Nathan Long

답변:


51

GitHub 프로필, 트위터 스트림 및 블로그를 모두 프로그래밍 인터뷰 / 후보 심사 프로그램의 품질 지표로 사용했습니다. 그들은 모두 자신의 방식으로 다른 신호를 생성합니다.

지원자 10 명 중 9 명이 단일 오픈 소스 프로젝트에 단일 패치를 제출 한 적이 없습니다. 깨진 문서를 업데이트하더라도 개발자의 상위 단계에있게됩니다. 그것은 당신이 어떤 오픈 소스 패키지에 대해 잘 알고 있으며, 무엇이 잘못되었는지 알고 패치를 제출할만큼 충분히주의를 기울이고 그 패키지의 관리자는 자신의 작업이 포함되기에 충분하다고 생각합니다. 일반화로서, 더러워진 것을 발견 한 것보다 더 나은 상태로두기 위해 주도권을 잡는 것으로 나타났습니다.

정말 간단하게 들리지만 10 명의 개발자 중 9 명은이 모든 중요한 단계를 수행하지 않아도됩니다.

따라서 하나의 패치 만 허용됩니다. 분기당 2-3 개의 간단한 패치를 사용하는 것이 더 좋습니다. 그보다 더 나은 것은 주목할만한 일을하는 것입니다.

  1. 중요한 오픈 소스 프로젝트에 대한 실질적인 기여 (최고 0.1 % ~ 1 %)
  2. 모든 프로젝트에 소액의 기여 내역 연장 (후보자의 상위 5 %)
  3. 비교적 알려지지 않은 패키지에 대한 단일 단일 라이너 패치 (후보의 10 % 이상)

같은 주에, 항상 술을 마시고 영화를 보려고하는 개발자는 평범한 직원을 고용하는 경향이 있습니다. 모든 3 번째 메시지가 기술에 관한 트윗 스트림은 그의 기술에 관심을 갖고 끊임없이 해결책을 추구하는 일종의 광포적인 폐차장 개 개발자를 향하고 있습니다.

블로깅은 또한 품질을 나타내는 훌륭한 지표이지만 기술력보다는 커뮤니케이션 스타일을 나타냅니다. 블로그 기사 # 1을 작성하는 데 귀찮은 프로그래머는 몇 명입니까? 동일한 종류의 1 % / 5 % / 10 % 컷오프가 여기에 적용됩니다.


5
"따라서 승인 된 단일 패치는 훌륭해 보인다. 분기당 2-3 개의 간단한 패치의 오랜 역사가 훨씬 더 좋다." 분기 된 프로젝트에 대해 승인 된 풀 요청을보기 위해 다른 사람의 프로필에서 어디로 가나 요?
Nathan Long

Nathan Long, 당신이 기고자들에게 가면 그의 이름을 볼 수있을 것 같아요?
MIdhun Krishna

그들이 더 강력한 검색을했기 때문에 (이전에는 가능하지 않았기 때문에)이 질문을 겪었습니다
Garry Shutler

2
"동일하게, 항상 술을 마시고 영화를 보려고하는 개발자는 평범한 직원을 고용하는 경향이 있습니다."그렇습니다. 일과 삶의 균형이 균형 잡힌 사람들을 원치 않는 것은 분명합니다.
whatsisname

10

개발자로서 Github 계정에서 다른 작업을 수행하지 않을 것입니다. Github 계정을 빠르게 평가할 수 없다는 것은 귀하의 문제가 아닙니다. 엄밀히 말하면 Github의 문제도 아닙니다. 개발자 평가가 아니라 협업 소프트웨어 개발을위한 것입니다.

Github 데이터로 작업하는 사용자 평가를위한 특수 도구가 있어야합니다. 지금은 타사 사이트를 사용할 수 있습니다. 예를 들어 http://coderwall.com이 있습니다 -프로필을 한 번 살펴보면 개발자가 패치를 제출했는지 여부, 다른 사람이 프로젝트를 포크 한 경우 사용하는 언어 수 등이 표시됩니다.

또 다른 옵션은 Github API를 사용하여 홈페이지에서 자동으로 요약 정보를 생성하는 것입니다. 포크 및 감시자가 여러 개인 프로젝트 목록, 마지막으로 업데이트 한 시간 등


6
"Git은 개발자를 평가하기위한 것이 아닙니다." Andreessen Horowitz에게 GitHub에 1 억 달러를 투자했다고 말합니다 . " 모든 사람에게 엔지니어 모집에 사용하는 것을 물어 보면 누구나 GitHub를 사용합니다 ." 그냥
말하면

8

GitHub 프로파일을 기반으로 후보를 평가할 때주의하십시오. GitHub는 CV가 아닙니다. 여러 가지 이유로 화려한 프로필을 가지고 있지 않은 훌륭한 엔지니어가 많이 있습니다. 폐쇄 소스 회사에서 일했거나 가족, 취미 등과 같은 다른 활동에 더 많은 시간을 할애 할 수 있습니다.

오픈 소스 프로젝트에 대한 기여가 후보자에게는 도움이 될 수 있지만 (@marshally 언급 한 바와 같이) 구식 방식으로 평가하고 고용해야합니다.

이 스레드를 읽은 직후에 우연히 만난 몇 가지 참조 :


2
아멘. 백 개의 프로젝트를 포크하고 1000 개의 깨진 문서 패치를 제출 한 사람은 고용하려는 사람이 아닙니다. 그는 유용한 것을 얻지 못했습니다. 유일한 진정한 기준은 구식으로 누군가 이야기하고 이해하는 데 시간이 걸리는 것입니다. 우리 산업의 대중 문화가 로봇과 같은 개발자들을 대접하기를 원하더라도 우리는 여전히 사람들입니다. (글쎄, 우리 대부분)
gbjbaanb

1
GitHub 프로필의 통계 만 고려할 필요는 없습니다. 실제로 코드를 살펴보고 그들이 좋은 프로그래머인지 판단 할 수 있습니다.
Siyuan Ren

5

나는 당신이 할 수 있다고 생각합니다. 그가 실제로 github에서 활동하고 있는지 아닌지, 활동 스트림을 보면서 약간의 시간이 걸릴 필요가 있다고 생각합니다.

푸시, 이슈 등이 어떻게 장난이 아닌 실제로 활동하고 무언가에 대해 작업하고 있음을 나타내는 큰 지표입니다.

누군가 당신을 평가하려고한다면, "진정한"그림, 엉터리 코드 및 좋은 코드를 봐야합니다. 나는 최근에 인터뷰를했고 인터뷰어는 저에게 github 계정을 개설 해달라고 요청한 후, 내 repos 중 하나를 살펴보면서 1 년 전에 제가 배우고있는 언어로 쓴 엉터리 코드를 살펴 보았습니다.

그래서 그는 나에게 물었다. 어떻게 이것을 개선 할 수 있는가? 나는 그것을 개선하는 방법을 알았 기 때문에 그의 모든 대답에 올바르게 대답했지만, 실제로 프로젝트를 고칠 필요는 없었습니다.

stackoverflow.com 계정도 마찬가지입니다. 평판 등이 있기 때문에 더 분명합니다.


4

나는 개인적으로 그들의 프로필 자체를 볼 때 가치가 보이지 않습니다. 알다시피, 체감 할 가치가없는 잡음 비율이있는 경향이 있습니다.

나는 최근에 첫 데브 작업을 신청하고 제외했으며 그들이 사용한 과정이 매우 공정하다고 생각했습니다. 프로필과 비슷한 것에 대해 묻는 대신 CV에 등재하기로 선택한 프로젝트에 집중했습니다.

후보자로부터 얻을 필요가있는 것은 몇 가지뿐입니다. 주요한 것들은 그들이 개발할 수 있고, 동기가 부여되고, 어떻게 똑딱 거리는가입니다. 이 모든 것은 사전 인터뷰 나 1 차 대화에서 얻을 수 있으며, 전화 나 현장 인터뷰에서 1 시간이 소요될 수 있습니다.

아이디어는 응시자가 대화를하고 그들의 열정이 어디에 있는지 알아내는 것입니다. 이보다 편안한 스타일로 인해 개발과 관련하여 사용하는 모든 서비스에 대해 내 프로필을 보내는 것보다 훨씬 더 많은 것을 열 수있었습니다.

테크 인터뷰에 먼저 출연하지 않는 것이 좋았습니다. 그들은 좋은 "팀"을 찾고 기술을 평가하는 올바른 태도를 가진 것 같았습니다.


3
나는 성격의 적합성과 열정이 중요하다는 데 동의하지만, 많은 사람들이 당신이 말한 것처럼 "개발할 수 있는지"를 결정하는 것이 얼마나 어려운지에 대해 글을 썼습니다. 누군가의 코드를 읽는 것이 인터뷰 전에 그들이 할 수있는 최선의 방법이라는 것이 일반적인 지식 (적어도 내가 작업하는 루비 세계에서는) 인 것 같습니다. 더 깊게 가려면, 그들에게 그들을 데려 가서 그들과 프로그램을 짝지 으면서 그들의 개성과 문제를 얼마나 잘 해결하는지 보여줍니다. 따라서 둘 중 하나도 아닙니다. 누군가의 프로필이 유용한 도구가 될 수 있다고 생각합니다. 문제는 다시 평가하는 방법입니다.
Nathan Long
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.