1. 자기소개
2. 개발자 업계의 큰 그림
3. 이름의 역할
4. 채용
5. 개개인의 고민들
Tips
중간 중간 질문 타임에 질문 부탁드립니다.
History
1년 반 공부
2년 차, DevOps
[Common Question]
1. 레거시 환경
2. 조각난 경력 이어 붙이기
3. 이론 공부를 많이 하는 편인데, 균형을 맞추기가 어렵다.
[Story]
[COMMON]
1. Spring 쓰시고 대기업 SI 다니신다고 하셨는데 Tomcat 써보셨나요?
Tomcat 쓰레드들을 수백개 띄우고 있는데, 그러면 Context Switching이 많이 발생하는데 왜 그러고 있을까요?
Blocking I/O 방식을 쓰다보면 스레드가 하나의 일을 하는 동안 멈추기 때문에, Tomcat이 멀티 스레드를 쓰는 것입니다.
Spring5 WebFlux는 훨씬 더 효율적인데 왜 그런가요?
Non Blokcing I/O 방식을 쓰고 있기 때문에 스레드가 하나만 있어도 된다.
Frontend 라면 React 선언형 프로그래밍이라고 써져있는데, 선언형 프로그래밍이 뭘까요?
선언형 프로그래밍과 함수형 프로그래밍이 뭐가 다르고 어떻게 생각할까
[TOPIC]
1. 개발자 업계의 큰 그림
상상하셨던 개발자와 양극화가 발생하는 이유
기능으로서의 개발자 : 공장 노동자 -> 3년 반복 후 -> 숙련공
전문가로서의 개발자 : 전문가 (지식 노동자 : 공부를 해서 현실의 문제를 해결)
토비의 Spring, 김영한의 Spring은 너무 좋다. 하지만 동시에 너무 흔해졌기 때문에 메리트를 찾기 어려울 수 있다. 희소성을 갖춰야 값어치가 나갈 수 있습니다.
MSA하시는 분들한테 이거 물어보면 알 수 있다.
이거 해보셨나요?
무엇을 잃으셨나요?
그럼에도 왜 쓰셨나요?
트랜잭션이 보장이 안될까요?
Real MySQL 읽어보셨나요?
Thread Local
Java Spec과 MySQL Spec을 다 봐야하는데... 다 기본기이다.
면접가서 잘 봤는데 왜 떨어졌냐?
커뮤니케이션 스킬.
공부 깊이에 따른 답변의 깊이 → 그 사람의 수준을 볼 수 있다.
쓰고 있는 기술들의 두꺼운 책을 봐라.
책을 고르는 기준은 하나 잡았으면 고민하지 말고 쭉 읽어라.
고민하는 시간에 2권 읽는 것이 낫다.
결론
코딩 잘하는 것은 당연.
그 다음 스테이지는 책을 많이 읽어야 한다.
책을 읽고 개발에 접목을 해야 한다.
공부의 종류
빠른 공부 : 기술
느린 공부 : 이론
느린 공부와 빠른 공부를 적절히 섞어서 쓰는 것이 좋다.
느린 공부가 많이 쌓이면 속도가 빨라진다.
느린 공부를 하다보면 현타가 오는데, 버티는 것이 답이다.
효능감을 느끼려면 1~2 년 정도의 시간이 걸린다.
스스로에 대한 믿음을 가지고 버티는 것이 답이다.
물 경력 = 관성에 익숙해진 사람
변화를 줄 수 있는게 조금이라도 있다면 물경력이 아니다.
회사에서 성장? 회사에서 날 이끌어주길 바라는 것?
현실적으로 말이 안된다.
나름대로 노력은 하고 있지만, 현실적인 어려움이 분명히 존재한다.
워라밸이 필요하다.
워라밸로 나의 시간을 확보하고 그 시간에 공부를 해야 한다.
멘탈 관리
비교로 인한 불행을 겪지 말자
비교는 나랑 하자
뉴스레터
FaceBook 직무 커뮤니티
LinkedIn 글
Careerly 글
DevOps 도구를 많이 알고 있는 것도 무기가 될 수 있지만, 본질적인 문제를 찾고 어떻게 해결할 것인지 이런 인사이트도 무기가 될 수 있다.
코테, 알고리즘 이런거 언제 다 하나?
시간 배분을 해서 꾸준히 하는 것이 좋다.
시간도 자원이라서 배분을 해보는 것이 좋다.
시간은 한정되어 있는데 어느 정도 깊이까지 가야 하는가?
시간을 정해서 그 시간 만큼만 깊이 있게 들어가는 것.
로우 시스템(자료구조, 네트워크 등)은 처음에는 암기로 때려 박고 들어가도 좋다.
대다수의 지식은 연결되어 있기 때문에, 일정 분기점만 넘기면 내공으로서 작동한다.
뭘 하든 좋으니까 개발 쪽에 재미를 붙여봐라
자가 진단법
이론 공부를 하고 있나
프로젝트를 꾸준히 하고 있나
이 두 가지를 동시에 하고 있나?
이론 공부만 하면 입개발자, 프로젝트만 하면 코더
채용 프로세스에서 면접
공부를 많이 했는데 대답이 잘 안나와
커뮤니케이션 시간이 오래 걸림
말투가 자신감이 없음
최근 채용 기조
애매하면 떨어뜨린다.
확신이 들지 않으면 떨어뜨리는 것이 맞다.
이력서
공통 이력서를 쓰는가?
시간이 걸리더라도 회사마다 이력서를 다르게 쓰는 것이 좋다.
회사 1개당 10, 20분 정도 시간을 들여서 인재상, 비전 등을 나랑 엮어 보는 것이 좋다.
요즘은 100 군데 중에 100 군데가 다 떨어질 확률이 좋다.
이력서에 우리 회사 이름이 없으면 탈락 시킨다.
어떤 회사에서 어떤 삶을 살 수 있고 ... 회사에 어떤 도움을 받고 싶고 어떤 도움을 주고 싶은 내용들을 적는 것이 좋다.
내가 커뮤니케이션 코스트를 많이 쓸 수록, 상대방의 커뮤니케이션 코스트가 낮아진다.
내 태도가 괜찮은 사람이라는 물증을 쌓아야 한다.
블로그
난 잘하는 사람이라는 것을 어필하는 것이 좋다.
괜찮은 프로젝트에서 겪은 문제 5개 정도는 리스트업 되어야 한다.
어떤 문제가 있었고
어떤 솔루션이 있었고
솔루션들 중에서 뭘 선택했고
이 중에 어떤 성과를 얻었다.
GitHub
있으면 좋다.
퀄리티 또한 중요하다.
외부 활동
유니콘 면접 회사
기술은 안보고 인성을 본다.
회사랑 나를 엮어야 한다.
주요 기술 스텍의 부족
속도 : 난 해당 스택으로 어떤 프로젝트를 해보았다. 그래서 속도를 걱정하지 않으셔도 된다. 어떤 기능을 몇 일 안에 만들어드릴 수 있다. (자신감)
우려하는 점이 무엇인가?
그것을 찔러서 나는 어떻게 보완을 할 것인가?
이력서의 길이
짧아도 길어도 상관없으나 어떻게 하면 면접관이 읽게 만들지 쓰자
첫 장과 두번째 장에 무조건 임펙트를 넣어주자
학벌이 좋으면 1티어로 올린다.
해외 경험이 있다 그걸 1티어로 올린다.
회사에 도움이 될법한 눈길이 갈 만한 부분을 1티어로 올린다.
프로젝트 포트폴리오 준비해야할까?
포트폴리오
자랑을 많이 해야한다.
공부
공부하는 것을 좋아하고 싫어하는 것은 기업의 마인드 차이라서 모든 회사가 그렇지는 않는다.
공부한 것을 회사에서 할 것인가, 사이드 프로젝트로 한 것인가?
베스트는 회사지만 그게 어렵다면 사이드 프로젝트 하는 것이 낫다.
