9장. 인재 채용 효과적인 선별 조건의 정의 Github 계정 블로그 오픈 소스 활동 기술 커뮤니티나 사용자 그룹 활동 내역 펫 프로젝트 내용 트위터 계정 좋아하는 기술서적 목록 참석했거나 발표했던 콘퍼런스 10장. 소프트웨어 장인 면접하기 생산적인 파트너십을 알아보는 방법 1) 회사 입장에서의 관점

항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다. 어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까? 과거 수행한 프로젝트나 업무, 기술, 또는 스스로 성취한 사항들을 이야기할 때 얼마나 열정적이고 애착을 보이는가? 실패 사례에 대해서 어떻게 표현하는가? 실패에 대해서 책임감을 느끼는가 아니면 남 탓을 하는가? 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해본 적이 있는가? 이전 업무에서 불평불만 대신 그 상황을 개선하기 위해 스스로 노력한 적이 있는가? 어떤 종류의 업무 환경을 찾고 있는가? 회사에서 그러한 환경을 제공해줄 수 있는가? 2) 지원자 입장에서의 관점

면접관은 누구인가? (프로젝트 관리자? 개발자? 팀 리더? 아키텍트?) 얼마나 많은 지원자들을 면접보고 있나? 원샷 면접인가 다단계 면접인가? 지원자에게 어떤 질문이 주어지고 있나? 특정된 질문인가 개방형 질문인가? 면접관이 기술적 질문에 대해 yes/no 단답형을 좋아하는가, 좀 더 상세하게 지원자의 생각을 파보려 하는가? 바람직한 면접 방법 좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다. 이런 종류의 면접은 지원자 입장에서 미리 준비할 수 있는 성격의 것이 아니다. 그래서 지원자의 실제 경험을 알아낼 수 있다.

1) 올바른 집중

우리의 핵심 가치는 무엇인가? 우리에게 필요한 주요 기술은 무엇인가? 더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가? 등 새로운 사람을 채용하기 전에 이러한 질문들에 스스로 대답을 준비해야 한다. 회사의 입장에서 더 중요하고 가치 있는 것에 집중해야 한다. 2) 마인드 맵핑 대화

잘 작성된 소프트웨어란 어떤 것이라고 생각합니까? 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까? 와 같은 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다. 각 항목은 마인드 맵의 노드가 되어 지원자와 면접관이 대화를 나눌 수 있다. 3) 페어 프로그래밍 면접

어떤 테스트를 자성할지 얼마나 빨리 결정하는가? (경험 수준) 개발 도구(IDE, 언어, 테스팅/목업 프레임워크, 단축키 등)에 얼마나 익숙한가? 클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가? 코드를 얼마나 깨끗하고 명료하게 작성하는가? 면접관이 제안이나 조언을 할 때 어떻게 반응하는가? 지원자가 어떤 방식으로 생각을 전개하는가? 문제 해결만이 아니라 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가? 4) 개인 컴퓨터를 지참한 면접

지원자가 좋아하는 도구가 무엇인지 알 수 있고 소중한 면접 시간을 아낄 수도 있다. 한 가지 재미있는 방법은 지원자에게 Github 프로젝트를 클론 하고 작업하게 하는 것이다. Git에 익숙한지? Git이 이미 설치되어 있는지? 컴퓨터 설정이 어떻게 되어 있는지? 어떤 도구를 선호하는지? 프로젝트를 금방 시작할 수 있는지? 테스팅/목업 프레임워크를 이미 모두 가지고 있고 사용할 수 있게 설정되어 있는지? 13장. 배움의 문화 배움의 문화 만들기 북 클럽에 가입하기 테크 런치 진행하기 그룹 토론회에 참여하기 업무 교환하기 얼마 동안만 업무 교환하기 그룹 코드 리뷰하기 코딩 실습하기 사용할 기술은 가능한 자유롭게 선택하기 내부 학습모임 만들기 회사에서의 펫 프로젝트 시간을 허용하기 외부 기술 커뮤니티와 교류하기 아무도 참여하려 하지 않는다면 모범을 보여라 관심을 보이는 사람들에게 집중하라 강제하지 마라 모두를 변화시키려 들지 말라 모임에 대한 약속을 제때 하라 허락을 구하지 마라 투덜대지 마라 리듬을 만들라 14장. 기술적 변화의 실행 준비 단순함을 추구해야 한다. 상대방의 언어로 말해야 한다. 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다. 상대방을 존중해야 한다. 경청하는 법을 배운다. 기술적 변화를 시작하는 방법 신뢰를 쌓으라 전문성을 확보하라 모범을 보여 사람들을 이끌라 신중하게 싸울 곳을 정하라 점진적으로 반복, 관찰, 수용하라 당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다.

15장. 실용주의 장인정신 단순한 설계를 위한 네 가지 법칙 모든 테스트의 통과 : 모든 테스트를 통과해야 한다. 명료성의 최대화 : 명료하고, 충분히 표현되고, 일관되어야 한다. 중복의 최소화 : 동작이나 설정에 중복이 있어서는 안 된다. 구성요소의 최소화 : 메서드, 클래스, 모듈의 수는 가능한 적어야 한다. 디자인 패턴 디자인 패턴은 분명 우리가 활용해야 할 도구 중 하나다. 무조건 사용해야 할 도구는 아니다. 레이어를 추가하거나 추상화를 위해 코드를 리팩터링 할 때 한걸음 더 나아가서 해당 문제에 흔하게 적용되는 패턴을 찾아서 적용할 수도 있다. 하지만 패턴이 먼저가 아니다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리팩터링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다. 그다음에 리팩터링으로 만들어진 솔루션이 특정 디자인 패턴과 거의 동일하다면 그 패턴을 지향하도록 리팩터링 할 수도 있다.

범용 코드는 확장성이 더 좋을지는 몰라도 특정된 코드보다 더 복잡하다. 무조건적으로 범용 코드를 추구해서는 안 된다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

16장. 소프트웨어 장인으로서의 커리어 장인의 길 : 열정 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다. 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다. 그들의 코드를 공유하고, 초보 개발자들을 멘토링 하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다. 기술 커뮤니티 활동에도 열정적이다. 뿐만 아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다. 단순히 좋은 코드를 작성하고 비즈니스 가치를 전달하는 것만으로는 좋은 개발자는 될 수 있지만 장인은 될 수 없다. 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다.

장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다.

진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는 데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지 보수할 수 있는 코드를 작성하는 데 집중한다. 장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다.

여정과 이정표 나의 커리어로부터 나는 무엇을 원하는가? 그것을 성취하기 위한 다음 단계는 무엇인가? 이 일은 나의 커리어 방향과 합치하는가? 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가? 그러한 투자에 대한 이익은 무엇인가? 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가? 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가? 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나? 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?

출처 : [https://devpad.tistory.com/11?category=773728]