Project 1- 1일 차: 포트폴리오 - 과정 중심 사고 기법 (이력서, 면접 때 참고)
개발자 - 과정중심 - 논리 기반
기술적 문제에 푸는 것만 급급하는게 아니라,
‘문제해결완료'라고만 쓸 수 없으니,
잠자는 시간을 쪼개서라도 탐구는 해야 함. 팀원들이 뭐하는거냐고 하더라도.
탐구한 사람이 결국 같은 프로젝트를 해도, 과정의 깊이가 다를 것
CTO를 설득할 수 있으려면.
탐구한 과정에 대해서 기술 블로그에 기록하고 과정 해야 함.
탐구한 과정을 기억하려고 하지말고, 어떻게 검색하고 탐구했는지를 기술 블로그에 남길 것.
- 인정하고 믿을 만하고 객관적 사실이라는걸 해줄 것.
예상은 많이 하지만, -> 이게 맞게 가고 있는건가,
내가 어떤 결과로 가고 있는지를 예상.
모르겠으면 멘토에게 항상 물어보기 -> 이렇게 하면 어떻게 결과가 나올까요
예쌍 해야지만, 실제 결과와의 차이 알 수 있음 -> 이 차이= 과정
예상, 차이, 재확인 가능 = 실력
“프로젝트 하기 전에, 이렇게 풀어나갈 거라고 기술적으로 예상을 ㅐㅎㅆ는데
이런 차이가 있었꼬,
다시 이 프로젝틀르 한다면, 나는 이렇게 할 거 같습니다"
시니어 개발자들은 결과중심주의,
신입 주니어 개발자들의 강점 = “이 세가지 특징이 잇따고 말하며됨' 경쟁력으로 .
논리 - 탐구 - 예상
[프로젝트]
이유 -> 성과
다들 결과중심적으로, 포트폴리오도 이렇게 적음
“왜 프로젝트를 했고, 어떤 성과가 있었는지"
성과 = 발전된 게 있어야 함.
그런데 이렇게 적어야 함.
이유 -> 기술적 문제 -고민 - 시도 - 결과 -> 성과
- ‘기술적 문제'를 만났다는 것 어필
- 만난게 중요한 게 아니라, 어떻게 풀어나갈지
- 고민/;
- 고민들 그중 하나 선택해서 시도,
- 그 시도의 결과를 보고
- 그 시도가 성공인지 아닌지 성과로 본다.
- 성공이라면 끝나는데, 아니라면, 다시 고민- 시도- 결과 확인 - 고민 -> 무한 반복
포트폴리오는 작품이 아니라,
개발자로서 얼마나 성장 가능성이 있는지를 보여주느 것.
작품 전시하는게 아니기에, 그 과정을 보여줘야 함 -> ‘이유 -> 기술적 문제 -고민 - 시도 - 결과 -> 성과 ‘ 기술 블로그를 남겨야 하는 이유
- Unless, 결과중심적인 포트폴ㄹ이ㅗ는 질문거리가 없음. 왜 CTO가 있지도 않은 제품을 궁금해하겟으며, 그런 결과를 궁금해하겟나
- 과정 중심적! → 기술적 문제 논리적 이유, 필요한 거 탐구하고, 탐구한 결과를 반영하는 노력 해야. 고민하고 시도한 과정에ㅓㅅ 예상 많이 해야 .
- 논리적인 근거는 어떤 근거고
- 이 과정에서 탐구하고,
- 진행과정에서의 나의 예상
- 결과
- 그 차이
프로젝트 동안의 과정 중심적 사고, flow가 다 포트폴리오에 넣어야.
=면접, 이력서 제출
여기 잇는 동기들 다 비슷한 프로젝트 하는데,
절대 같은 결과 안나옴.
내가 어떤 과정을 만들었느냐에 따라 달라짐.
위코드 동기 뿐만 아니라, 밖의 경쟁자도 이기려면, 오늘부터 만드는 과정이 포트폴리오
-> 내 과정과 포트폴리오가 얼마나 깊고 탄탄하느냐에 따라 ->그리고 그러면 반드시 실력도 는다.
과정으로 설득, 설명해야.
그래야 성장 가능성 보이고, 뽑힘.
프로젝트의 모든 결과보단, 위코드 프로젝트 하는 이유는 ,
과정을 만들기 위한 것.
“과정이 보여야 실력을 믿는다"
나 이 언어 배웟기에 얼만큼 할 줄 안다 라는 개발자들 안 맏는다.
포트폴리오 결과가 안 좋기에 취업 안 되면 어떡하지?
그 시간에 차라리 과정을 보여줘라 .
포트폴리오는 노션, → 링크로 제출하기 좋아서/ 플랫폼이 따로 없으니,
블로그는 산발적이니.
기술블로그에 다 탐구했던 내용 먼저 다 기록하고, 지금처럼.
그리고나서, 나중에 포트폴리오 적는 시점에
추출해서 하면 됨