장난감 프로그램 이 포함 된 GitHub 리포지토리에 무언가를 배울 때 작성합니다. 예를 들어, 알고리즘 또는 데이터 구조에 대한 정보를 읽을 때 작동하는지 이해하기 위해 빠른 구현을 작성합니다.
때로는 알고리즘과 데이터 구조 퍼즐을 풀고 저장소로 푸시됩니다.
이 저장소가 이력서에 연결될 가치가 있습니까, 아니면 실제로 채용 기회를 저해 할 수 있습니까?
답변:
한때 이력서에 "귀하의 자산 만 표시하고 부채는 표시하지 않는 대차 대조표"라고 설명되어 있습니다.
이 정의에 따라, 책임이있을 수있는 프로젝트는 제외하고 일자리를 얻는 데있어 자산이 될 프로젝트를 포함 시키려고합니다. 이것은 그들이 신청 한 직업과 관련 이 있고 최고의 작품을 과시 해야한다는 것을 의미 합니다 . 코드 "장난감 프로그램"을 고려하더라도 이것이 제대로 구성 될 수는 없습니다. 따라서 폐기 코드 나 더티 해킹은 포함하지 마십시오. 개인 저장소에 보관하십시오. 물론, 당신은 당신의 프로그램 , 프로그램 에 대한 디자인 결정 등에 대해 이야기 할 수 있어야 합니다. 저는 한 해 전에이 멋진 프로젝트를 수행했다고 주장한 후보자가있었습니다. 그렇게 좋지 않습니다.
면접관을 염두에두고 이력서를 작성해야하며, 대부분의 사람들은 면담의 가치가 있는지를 판단하기 위해 논문을 조사 할 필요가 없습니다. 직위와 관련하여 가장 관련성 높은 정보를 간결하게 제공하기를 원합니다. 콘텐츠의 신중한 우선 순위 지정이 필요합니다. 관련 정보를 가장 잘 강조하기 위해 직책별로 이력서를 사용자 정의하는 경향이 있으며, 이는이 특정 질문에 대한 합리적인 접근법이라고 생각합니다.
저수준의 일반적인 개발자 직책을 신청하는 경우 광범위한 프로그램이 유용 할 수 있습니다. 장난감 프로그램 중 하나가 자바 스크립트 프로토 타입으로 마지막으로 클릭 한 순간이나 첫 번째 LISP를 연구했을 때를 보여줍니다. 이것들은 유익 할 수 있습니다.
그러나 국방 시스템 용 컴파일러를 구축해야하는 입장을 신청하는 경우, 앞서 언급 한 예는 면접관에게 거의 도움이되지 않습니다. 그들은 다른 유형의 배경 정보 (기여 / 리드 한 컴파일러 프로젝트 등)에 훨씬 더 관심이 있습니다.
이 모든 것을 말하면, 나는 장난감 프로젝트의 관련성을 현재 위치로 측정하려고합니다. 그들이 현재 직책과 관련이있는 것 같으면 (예를 들어 직책은 git 역량이 필요하고, 직책은 자율 학습에 대한 일반적인 성향을 필요로하는 등), 저장소를 포함합니다. 그렇지 않으면 강조 할 수있는 더 중요한 정보가있을 수 있습니다.
이력서에 누군가가 비판적인 눈으로 검사하는 것이 불편하다고 느끼는 것을 넣지 마십시오. 마찬가지로, 잠재적 인 면접관이 좋은 물건을 찾기 위해 저장소를 파헤 치지 말고 잘 작성된 라이브러리 또는 코드 스 니펫이있는 작은 저장소를 사용하는 것이 좋습니다.
리포지토리에 대한 링크를 제공하는 경우 명확하게 정의 된 README 파일이 있어야 사람들이 원하는 코드의 흥미로운 부분을 지적하고 상황이 왜 정확한지 간략하게 설명 할 수 있습니다. 있습니다. 채용 과정 초기에 링크를 공개하면 디자인 결정을 정당화하지 않을 수도 있으므로 README가 귀하를 대신하여 설명 할 수도 있습니다.
고용주가 코드를 사용할 수있게하는 이점 중 하나는 코드를 사용하여 기회를 선별 할 수 있다는 것입니다.
면접은 양방향입니다. 고용주는 후보자를 평가할뿐만 아니라 실제로 고용주를 위해 일하기를 원하는지 를 결정해야합니다 .
고용주가 실제로 프로그래머의 작업 을 실제로 보지 않고 제안을 할 때, 다른 사람을 고용하기 위해 이전에 동일한 프로세스가 사용되었을 가능성이 매우 높습니다. 구직자는 프로그래머가 아닌 사람이 같은 직책을 가질 수 없었던 명백한 이유가 없을 때 오퍼를 수락하는 것에 대해 매우 조심해야 할 것입니다 (확실히 있었기 때문에).
물론, 대부분의 고용주 는 후보자들에게 코드를 작성하도록 요구합니다. 일반적으로 "이 화이트 보드에 함수 작성"또는 운이 좋으면 "이 익숙하지 않은 워크 스테이션에 함수 작성"의 형태 인 것 같습니다. 이렇게하면 "Hello World!"라고 쓸 수없는 후보를 분리하는 데 합리적인 작업을 수행 할 수 있지만, 인터뷰에서 좋은 코드를 작성할 수있는 사람과 멋진 코드를 작성할 수있는 사람의 차이에 대한 정보는 훨씬 적어집니다.
그리고 많은 (많은 사람들과는 거리가 멀지 만) 고용주들은 프로그래머가 이상적인 환경에있을 때, 그들이하고 싶은 일을하고, 특별한 지침없이 프로그래머가 생성 할 수있는 코드의 종류를보고 싶어합니다.
코드를 최대한 활용하려면 고용주가 요청하기 전에 코드 를 제공 하는 것이 좋습니다 . 관심이 없다면 다른 기회를 찾으십시오. 그들이 관심이 있다면, 어떤 프로젝트를보고 싶은지, 왜 그런지를 말하십시오 (그리고 다른 프로젝트 중 일부가 대표적이라고 생각하지 않는 이유를 설명하십시오. . 그런 다음 다음에 이야기 할 때 그들이 본 것에 대해 어떻게 생각했는지 물어보십시오.
포트폴리오 로 생각하면 CV에 해당 링크를 추가하는 것이 좋습니다. 나는한다.
이력서는 한 가지 목적, 즉 채용 과정의 다음 단계로 나아가는 것입니다. 그 목적을 방해하는 것은 나쁜 생각입니다. 전 고용 관리자로서 , 초기 심사 과정에서 단일 후보자에게 제공 한 시간 이 이력서를 읽고 파쇄 여부를 결정하는 것 이상을 허용하지 않았다고 말할 수 있습니다. 7 페이지 이력서 (정말로!)를 보낸 사람들은 원하는 관심을 얻지 못했습니다. 나를 URL로 보낸 이력서를 보낸 사람들도 그렇지 않았습니다. 나중에 나머지 후보자에 더 많은 투자를 한 후
포트폴리오는 좋은 것입니다. 이는 웹 디자인과 같은 비즈니스의 특정 측면에서 특히 그렇습니다. 그러나 그래픽 아티스트 인 경우를 제외하고는 포트폴리오를 소개해서는 안됩니다.