[포트폴리오 특강] 회고

우리FISA 2기 Cloud Engineering 과정에서 진행된 포트폴리오 특강에 대한 회고를 해보려고 한다. 강의는 2월 29일 월요일 하루동안 진행되었으며 개발자 취준생에게 유익한 시간이었다고 생각한다.

 

Intro

강의를 여는 질문이었던 '회사는 어떤 개발자를 뽑고 싶을까?'에 대한 답변을 서로 공유해보았다.

커뮤니케이션 능력이 좋은 사람, 개발을 잘 하는 사람, 개발에 대한 용어가 잘 정리되어 있는 사람과 같은 답변이 나왔다.

이런 질문을 계속 생각해보고, 내가 작성한 자기소개서도 이런 식으로 질문을 자꾸 던져봐야 한다고 하셨다.

 

협업 경험

1. 요즘 라이브 코딩을 하는 곳이 늘어나고 있는 추세다.

2. 면접에서 실무자와 실제로 같이 일하는 것처럼 페어 프로그래밍을 한다.

3. 현업에서 같은 화면을 보거나 같은 것을 고민할 때도 많다.

 

이렇게 애자일 프로세스처럼 한 사람이 키보드를 잡고 세 사람이 아이디어를 던지는 연습도 해보는 것을 추천해주셨다. 각자 하는 게 속도는 빠르겠지만 한번 해보는 경험이 중요하다는 것을 강조하셨다. 이렇게 현업에서 하는 고민을 미리 해보는 걸 이번 교육 과정 내에서 경험해봐야겠다는 생각이 들었다.

 

커뮤니케이션 능력이 좋은 사람

기업은 왜 커뮤니케이션 능력이 좋은 개발자를 원할까?

 

소프트 스킬

기술적으로 실력이 출중한 개발자들이 모인 팀에서 커뮤니케이션에 어려움을 겪는 경우는 어떤 케이스일까?

기술적으로 우수한만큼 복잡한 대화가 오고 가기 때문에 서로가 알고 있는 도메인 지식의 충돌로 인해 회의를 해도 잘 정리가 잘 되지 않는다.

 

커뮤니케이션 능력이 좋은 사람들은 기술적으로든, 문서로든, 말이든 상대방이 보기 편한 방식으로 전달한다. 그림을 그릴 수도 있고, 잘 정리된 문서로 제공할 수도 있다.

 

이 방법으로 팀에서 발생한 트러블 슈팅 문서를 조직에 공유한다면 모든 조직의 퍼포먼스가 올라가는 기대효과를 얻을 수 있다.

 

업무 공유

Q. 만약 각자가 잘하는 것만 한다면 어떤 문제점이 있을까?

A. 업무를 담당한 사람이 부재 시 문제가 생기므로 내가 하는 일에 대한 업무 공유하는 시간을 가지면서 인수인계를 해야 한다. 서로의 담당 기능을 바꿔서 하루 이틀이라도 해보는 방법도 좋을 것 같다.

 

 

 

회고의 중요성

3개월 전에 쓴 코드도 까먹기 마련이다. 잘 기록하는 것도 물론 중요하지만 그만큼 정리하는 것이 중요하다.

 

 

회고 예시

1. 오늘 한 일에 대한 회고를 한다. 미처 달성을 못한 부분, 오래 걸릴 줄 알았지만 빨리 해결한 부분에 대해 서로 공유하면서 팀에 대한 룰을 만들어 나간다.

2. 운영에 대한 배포 주기(2주) 마다 할 수도 있다.

 

이렇게 회고를 하는 습관이 있다면 프로젝트 소요 시간 등 업무 파악 능력을 기를 수 있다.

 

 

 

공고 분석

원티드, 로켓펀치, 점핏 등 개발자 채용 사이트에서 주요 유니콘/스타트업/중견기업 공고를 분석하기

해당 기업이 직무 기술서를 토대로 역설계

e.g. Agile 프로세스에 대한 이해가 있는 사람

유튜브, 기술 블로그, 블라인드, 연혁 등 매체에 공개된 정보를 정리해두기.

회사 임직원이 남긴 글들을 참고하여 회사의 중점 사업, 분위기, 인재상을 구체화

 

 

피드백

마지막으로 내 이력서를 피드백 해주셨다. 

1. 수상 시 어떤 이유로 수상을 했는 지에 대한 설명이 필요하다.
2. 실패 경험 기재도 상관없다. 단, 배운 점과 보완해야 할 점, 보완한 후 다음 프로젝트에 적용한 결과를 적는 편이 낫다.
3. Java의 객체지향적 사고, MVC 구조 및 디자인 패턴에 대한 이해도를 향상시킬 수 있었습니다. -> MVC 구조를 왜 사용했고, 어떻게 적용했는지 납득시킬만한 이유가 있어야 함.
4. 기업 지원 동기 -> 기업의 장점이 타 기업과의 차별성이 있으면 신뢰성이 더해짐.
5. 스토리 라인이 중요하다. 면접관에게 신뢰를 줄만한 이야기들.

왜? 라는 질문을 끊임없이 던져보는 방법, 내가 했던 모든 내용을 다 펼쳐보고 처음부터 다시 써보는 방법으로 포트폴리오를 보완했다.