• 자격증 취득 길게 생각하기엔 너무 어려운 것 • 부자 되기 • 진로 선택 하기 • 최고의 직장에 들어가기 è나한테 왜이러세요?! 생각하는 것 자체가 공포스럽다. è 묻지마! 좋은 방향이든 나쁜 방향이든 대충 그럴싸한 해결 책만 찾으면 빨리 결정 내리고 잊어버리고 싶다.
함. 그러나 스트레스는 배로 증가.. • 뭐라도 해야겠으니.. • Agile! 일단 스토리부터 작성 à 만병통치약이 아님. 게다가 이런 경우 설계를 엉망으로 만들 수도 있음 • 에라 모르겠다. 일단 화면 구성과 API 부터.. à 초안과 완전히 다른 디자인이 나와 폭망 • 개발 초기는 널널, 말기엔 죽음의 야근..
개발자와의 괴리 • 빠른 속도로 전체 내용을 가시화 가능. 개발자도 뭘 해야할 지 즉시 파악 가능 • 가장 변화 가능성이 적은 도메인 계층을 먼저 구현, 이후 데이터 계층 à 프리젠테이션 계층 순으로 구현 • 부가적으로, • 요구사항의 변경 가능성이 줄어듦 • 서버와 클라이언트가 거의 동일한 로직을 공유 가능: 슈퍼 셋과 서브셋에 가까운 형태로
방법론 • 먼저 기능 명세를 간단히 작성 • 완료까지 무한루프 • 1번 기능을 만족하는 유닛 테스트 작성 • 1번 기능만 통과하는 유닛 테스트를 마구잡이로 작성 • 리팩토링 • (필요시)새로운 기능을 명세에 추가 • 눈 앞에 당면한 과제에만 급급해서 푸는 게, 역설적으로 더 훌륭한 코드를 만들 도록 해줌! • 참고 서적: TDD by Example
이력을 최대한 간결하게 적되, 업무에 서의 역할, 나의 중요도, (수치로 드러나는) 성과들을 명확히 표 현하도록.. • x팔림을 무릎 쓰고 여러 명의 사람에게 첨삭 부탁 • 영문 이력서는 1차로 뉴욕에서 MBA한 동생에게 리뷰 의뢰 - 신랄한 비판과 함께 첨삭 • 2차는 유료 리뷰어에게 의뢰. (역시나 신랄한 비판과 함께..)
15일: 마지막 면접 • 1월 22일: 피드백 전달 및 “packet” 송부 • 각 면접관은 면접자의 주요 답변 등을 요약해서 보고서 제 출 à 면접에 참여하지 않은 시니어 멤버들로 구성된 위원 회에서 채용을 결정 • 1월 28일: Job Offer • 1월 31일: 최종 합격 Timeline (2)