[특강] 취업준비

data_hamster·2023년 7월 6일

행동양식 질문
기술관점 질문.

주니어 입장에서 행동양식은 그렇게 중요 X
과거에 어떤 행동들을 했는지. 경력자들에게 중요한 질문.

프로젝트, 부트캠프에 대해 물어볼 수 있음.

JOB을 잡는건 소개팅과 비슷. 나도 상대 기업이 괜찮아야 함.

면접전략.
잘못됨: 100% 준비됐을때 딱 가야지! 한번에 잘 되겠다? 확률이 낮음.
앞단에 연습을 많이 해야함.
공부와 면접을 병행하는게 좋음.

JOB을 바꾸는 타이밍은 언제?

SOCAR 등의 기술블로그 보고 - 어떻게 발전해왔는지.

인프라를 만들어줌 - 엔지니어

대용량 분산처리 - SPARK

아테나 - 아파치 프레스토를 가져다 씀.

빅데이터 기술들이 생기기 시작.

레드쉬프트, 빅쿼리, 스노우 플레이크 등의 웨어하우스 생김.
가변비용 - 비용관리의 어려움이 좀 있음.
고정비용이 좋은 경우도 있음.

ELT를 할 때 많이 쓰는 툴 DBT
대시보드에 연결해서

데이터 분석가들도 에어플로우를 알길 원하고 있음.
데이터 분석 업무는 현업 부서에서 하는 형태로 가고 있음.
마케팅 팀, 세일즈 팀에서 분석가 통해서 하는게 아니라, 본인들이 직접 분석하고자 함. - 기술의 발전도 영향이 있음. 시티즌 데이터 애널리스트, 사이언티스트 (트렌드)
쿠팡, SK 하이닉스 보면 역량이 되는 곳 보면 데이터팀을 통하지 않음.
분석가는 상대적으로 위태로운 직군.

모델의 피쳐를 배치로 할 수 없을 때가 있음. 카프카, AWS 키네시스로 리얼타임으로 변수를 넣게 됨.
지금까지 우리가 본 데이터 프로세스는 배치임.

리얼타임, 스트리밍은 데이터가 발생하는 족족 처리하는 것임. 사실은 굉장히 주기가 짧은 배치 프로세스 (1초에 1번)
메세지 큐 이벤트 큐 같은게 필요함.

프로듀서, 섭스크라이버

이런주는 하둡과 빅데이터 시스템 얘기가 있을 것임.
맵 리듀스는 잘 몰라도 됨. 하둡 - 맵리듀스가 너무 생산성이 떨어짐.
-> 하이브, 프레스토가 나옴.
모든걸 SQL로 하기 힘드니까 Pandas도 처리? 스파크. 스파크sql, 스파크스트리밍으로 카프카, 키네시스로 쌓인 데이터도 처리 가능
스파크ml. 사이킷런이 빅데이터기반으로 돌아가는 것.
파이썬으로 스몰데이터를 처리해주는 프레임워크 - 판다스, 사이킷런.
사이킷런 - 머신러닝 모델을 만들어줌.
스파크, 스파크ml - 판다스, 사이킷런을 빅데이터 기반으로 돌릴수 있게함.

월요일 수업에서 느낄건
생산성이 떨어지는구나, 못쓰겠구나 정도.
하둡에서 맵리듀스를 쓰는 회사가 있다고 하면 안가는게 좋음.
레거시가 엄청나게 쌓였다는 소리임.

데이터시스템의 고도화는 스트리밍 형태로 감.
적재, 소비 형태의 발전.
스파크스트리밍을 많이 씀.
스파크는 자바, 스칼라 언어로 만들어진 시스템. 자바, 스칼라로 컨슈머를 작성하진 않음.
40명 중에 1명 스칼라 있었음.
스칼라 쓰는 순간 컴파일, 배포 오래걸림. 나머지 39명이 파이썬 쓰는데, 고집하는건 민폐임. 팀에서 뭔가를 정했으면 따라가는게 맞음.

품질 높은 데이터로 회사의 부가가치를 높임.

디시젼 사이언스. 결정을 과학적으로.
데이터 분석가 하는 일.

데이터 인폼드 디시전 - 내가 가는 방향에서 참고하는 방향. 강사님 선호. 데이터는 과거의 기록. 과거의 기록으로 결정을 하면, 그동안 하던 일을 더 잘하게 됨. 새로운 걸 결정해주진 않음.
데이터 드리븐 디시전. - 데이터 하라는 대로.

프로덕트 사이언스.
데이터 과학자.
엔지니어는 갈수록 과학자랑 일을 많이함.

ML 엔지니어 - 머신러닝 모델을 가져다 써서 모델을 만듦. 코딩도 좀 하고.
회사에서 보통 데이터 사이언티스트

데이터 분석도 어느 시점에서 전문화가 이뤄짐
AB, 프로덕트 테스트 빼고 현업으로 넘어가는 중

프로그래밍 -> SQL

깃헙 액션을 알아야 나중에 현업갔을 때 고생을 덜함.
첫 취직 때 가장 어려웠던 기술 - Github

모든걸 알필요는 없지만, 개념적으로 아느냐가 큰 차이를 가져옴.

SaaS MRR ARR
분석가의 경우 계속 현업하고 엮임.
-> 나중에 데이터 엔지니어, 과학자가 되고 싶어함.

데이터 엔지니어
소프트웨어 엔지니어
파이썬, SQL 질문 들어옴.
백엔드에 비교헀을 때, 배치 프로세싱 하는 주니어들에게는, 사용자들에게 노출되는건 아니라 코드를 아주 잘 짤 필요는 없음.
사용자가 쓰는 프로덕트 서비스가 중단되는 게 아님. 약간 느슨한건 있음.

구글 클라우드만 쓰진 않고, 동시에 AWS를 씀.
Azure을 쓰는 회사는 거의 없음. 근데 세계 2위임. MS가 영업을 잘하기 때문에, 큰 회사들이 씀. - 코카콜라, 병원
IT만 놓고보면 AWS, 구글 클라우드.

빅데이터 분산처리 기술 이해
큰 데이터를 저장할 수 있느가?
큰 파일을 다수의 서버에 나눠저장함. - 분산 파일시스템
분산 처리 시스템이 생겨남. 스파크. (분산 파일시스템은 HDFS, S3을 채택)
분산 처리에서 가장 힘든부분은, 데이터가 서버 숫자만큼 균등하게 나눠 들어가면 병렬처리에서 이점이 생기는데, 항상 그렇지 않음. 데이터 스큐(불균등)이 생김. 큰 데이터를 나눠서 처리를 하는데 100대로 나눴는데 1대에 대부분이 들어가는 경우 발생.
분산처리 시스템은 이러한 이슈를 가짐. 데이터가 몰리면 에러도 나고 이점이 사라짐. 하둡 때부터 있어왔던 문제임.

도커는 점점 더 많이 쓰여짐. 분리된 환경에서 이미지를 만들고 실행하는게 굉장한 이점임.

주니어 때는 도커까지만 알아도 충분함. k8s를 쓸만큼 발전한 회사면 시니어 따라서 배우면 됨.

NoSQL도 배우게 됨. 더 나아가면 MlOps 모델 배포, 모니터링.
-> 난이도가 많이 올라감. 데브옵스팀은 스트레스를 많이 받음. 주말에도 밤에도 항시 대기.

테스트 돌림 - CI
자동 배포 - CD
Github Actions 많이 사용.

데브옵스가 개발자 코드에 대한 작업과 유사하게 mlops

당근마켓

배치와 스트리밍, 스파크 사용.

필요 기술.

보너스 기술.
보너스 기술은 크게 신경쓰지 말것. 자기검열이 심한 사람은, 이거 보고 아 나이거 모르는데.. 하고 이력서를 못내는 일이 발생함. 이력서를 넣지 않으면 커리어 시작이 되지 않음. 중요한건 잡 디스크립션 보고 부족한 부분만 보고 이력서을 넣지 않으면 커리어 시작이 안됨.

필요기술 - 30%라도 알고 있으면 일단 내라.

대규모 트래필 처리 -> 나 관심 많음. 긍정적으로 생각해라.
AWS 그동안 써왔음 --> 일단은 이력서를 내라. 그래야 시작이 됨.

옵션 기술을 보면
스파크, 빅쿼리있는데, 빅쿼리는 redshift. 당근마켓은 DW로 빅쿼리를 쓰는구나 하고 짐작할 수 있음. AWS도 언급되는걸로 와서 AWS도 쓰는구나.
쿠버네티스 - 주니어로써 알필요는 없지만, 도커로 이미지를 떠서 쿠버네티스에 올리는 구나.

잡디스크립션을 천천히 읽어보기.

당근페이

3년이 걸릴것임. 나 3년 아닌데. 2년까지는 그냥 내면 됨. 어느 매니저도 무경험자를 찾는다고 말을 하기 애매함. 년수를 쓰고싶은 그런게 있음. 3년은 약간 애매함. 이력서를 안내서 아무일도 안내는거랑, reject랑 똑같음.

테라폼 사용. 그냥 데이터 엔지니어라기 보단, 데브옵스적인 일을 하는 곳.
테라폼 시스템의 환경 소스를 관리해주는 오픈소스 툴.

디시전 데이터 사이언티스트

에어플로우, DBT 언급.
데이터 시스템이 많이 발전한 회사라는 것을 알 수 있음.

ML 엔지니어

여러 팀들이 있는 것 같음
피드, 광고, 검색
세 팀중 하나로 들어감.

데이터 엔지니어가 과학자랑 일을 많이 하다보면 Ml 엔지니어로 넘어감.

모델 만들고 end-to-end, 모니터링. mlops적인 포지션

오늘의 집

또 3년임

대부분 머신러닝과 관련되어 있는 것을 알 수 있음. ml 엔지니어 같음.

ELT 할줄 알아야함.
파이썬, R, 대시보드 툴.
전형적인 데이터 분석가 포지션

프로덕트 애널리스트
이벤트 읽어다가 분석.
앰플리튜드, 믹스패널.

말 그대로 우대사항
자격요건 보고 30% 된다? 일단 내보기.

채널톡

맥스님 기억에 가장 기억에 남는 회사.
이거랑 토스.
미친듯이 일하는 회사 - 토스. 11시쯤 출근 10시 정도 퇴근.
몰입도, 질문보면 미친 사람들이구나, 광신도 같았음. 번아웃이 금방 오겠구나라고 느끼는 회사.

채널톡은 열정넘치고, 질문도 넘치고, 미친느낌도 안드는 적당한 회사였음.
포지션은 데이터 엔지니어

채널톡은 루커를 대시보드로 사용.

여기는 인터뷰가 빡셈.
이런데야 말로 처음 면접하면 안되고, 다른데 좀 해보고 나중에 해야 잘 할수 있음.

스마일게이트

하둡 에코시스템에 대한 이해. 분명 맵리듀스는 쓰진 않을 것이고 하이브 사용.
카프카. 게임 시스템이기에 바로 반응하려는 이유 있음.
JVM, 파이썬 언어.
나빠보이지 않음.

이런 오프닝들을 어디서 찾는가.

Indeed 한국 사이트 쓰는게 제일 좋음. 한국 사이트들도 많이 올라옴.
하나는 데이터 엔지니어.

처음엔 내가 안갈꺼 같은데를 넣어서 연습. 질문도 많이 해보기.
생각보다 괜찮네? 그럼 시작해도 됨.
너무 큰데만 가려고 하지 말기.

airflow 같은 기술 스택을 검색해서 찾는게 도움

데이터 엔지니어는 회사마다 정의가 다름. 실제로 들어가서 보면 내가 생각하는 엔지니어 일을 안하는 곳도 많음. 구체적으로 기술 스택으로 들어가보면, 그러한 기술로 일하는 걸 알 수 있음.

다른데 보다 인디드가 괜찮을 것임.

이력서 잘 쓰기

자기 검열 하지 말기. 너무 자기검열을 하면, 내가 이걸 안다라고 쓰기 애매한데..? 하면 이력서에 쓸게 없어짐.

가독성.
오프닝을 여는 순간 굉장히 많은 사람들이 이력서를 내게되고, 일일히 자세히 보지 못함. 한눈에 들어오는 이력서는 좀 더 보게 됨. 아니다 싶으면 바로 제끼게 됨.

주니어라면,

스킬셋 정리.

자기 검열을 많이 하면 쓸게 없음. 실제 케이스를 나눠봄. 멘토로 일하시는 한분도 이력서 검토 받고 취업에 성공함.
프로젝트의 경우 너무 자세히 쓰지 말고 어떤 문제를 해결했는지 쓰기, 너무 기술적으로 쓰진 말고. 리쿠르터 들은 세부 기술까진 모를 수 있음.
해결하려는 문제가 무엇인가.
너무 많은 내용 넣으려고 하지 말고 간결하게, 링크를 걸어서 자세히 설명하는 것도 좋음.

주니어라면 첫페이지에 스킬셋. 일의 경험이 있으면 마찬가지로. 강사님은 커버레터를 별로 좋아하지 않음. 첫페이지에 많이 보이는 것이 좋음.

자기소개
이력서 내는 곳마다 조금씩 맞게 커스터마이즈 하는게 좋음.
기술/자격증
그냥 나열하지 말고 카테고리로 나눠서,
프로그래밍,
DB,
데이터 엔지니어,
컬레버레이션,
내가 도커를 몇번 써보긴 했는데 이걸 안다고 할 수 있나? 이렇게 생각말기 일단 써라.
실제로 면접 할때 솔직히 얘기하면 됨. 나 주니어고, 교육과정에서 써봤다.
협업 툴도 써본거 있으면 다 적고,
프로젝트는 기술 뒤에,
주니어 입장에선 기술을 적는게 좋음.

내가 전혀 다른 일을 해봤다. 이런 사람들이 많이 있을 것임. 사회생활 처음은 다른거 해봤다. 이거 적을까 말까. 매니저마다 호불호가 갈림. 맥스님은 다 적는 것을 선호함. 데이터 일이라는게 다른 일과 다른게 다른 경험을 가진게 조금 더 잘하는 경우가 있음. 전혀 관계가 없더라도 적어주는게 좋지 않나? 그래도 기술자격 뒤에 적는게 좋음.

스킬 해놓고 저렇게 적고 끝.
자신감이 떨어지는 분이었음. redshift, aws, airflow 다 안썼음.
조금이라도 써본거 일단 적어보라고, 키워드 나열하지말고 카테고리로 나눠봐라.
매니저는 프로젝트를 통해 기술 유추할꺼란 기대 X. 잡 디스크립션을 잘 보는게 의미가 있는게, 키워드. 카프카, airflow. 등을 더 신경써서 노출시키는 것임. 지원 포지션에 조금 더 맞게 커스터마이즈.

프론트 엔드 개발자였음.
이분도 airflow 등은 안적으심. 따로 카테코리 적으라고 하심. 너무 겸손하지 말고, 일단 읽기 쉽게 만들어보기.

미국에서 어떤 부류가 자기검열하나? 유색인종, 여성
필요역량에 정말 필요한거만 적게 함. -애플
잡디스크립션은 보통 복붙해서 가져다 씀. (필요역량, 우대사항) 검색해서 다른 회사꺼 가져다가 붙히고 씀. 그러다보면 필요하지도 않은 기술을 적을 확률이 높아짐.
30% 맞으면 일단 내봐라. 가자마자 저 기술들 다 쓸 일은 없음.

애플은 들어오자마자 안쓸 기술 적지 말라고 매니저 교육함.

연락이 안오거나 reject 됐다고 해서 세상 끝난거 아님. 기분이 좋지 않겠지만 익숙해져야 함. 맥스님 따님 60군데 넣고 10군데서 연락오고 최종은 2군데서 연락옴. 58번의 거절이 있었음. 요새는 이게 기본임. 마음 편하게 먹고 rejection을 받아들이는게 좋음.

커버 레터는 빼는게 좋다고 생각하는 주의.
과거 경력을 넣는게 좋다고 보는 주의.

요새는 줌으로 인터뷰를 함.
백그라운드, 코딩 질문. 맥스님은 SQL 질문을 하심. nps 계산하는 질문. 항상 nps sql 질문을 하심. 보고 풀면, 그 다음단계로 넘기심.
온사이트 인터뷰 -> 사무실에서 3~5명 인터뷰

질문을 잘하는게 중요. 문제를 어떻게 푸느냐도 중요. 커뮤니케이션 중요. 기술, 행동양식 질문도 들어올 것임.
잘하면 오퍼를 받음.
경력자라면 레퍼런스 체크를 함. 회사나 동료 이름 달라. 주니어는 체크할꺼 없
경력이 올라가면 평판이 중요해짐. 레퍼런스 체크에서 걸러짐. 후보자들이 보통 자기에게 좋은말 해줄 사람위주로 추천하기 마렴. 정말 평판이 안좋은 사람들 좋은얘기 해줄 사람을 못찾음. 20명 중 1명은 걸러짐. 그것만으로도 가치는 있음. 평판이 중요함. 같이 일하고 싶은 사람. 공평, 공정, 긍정적인 사람. 주니어라면 패스.

협상에서 제일 좋은 방법은? 다른 오퍼가 하나 더 있으면 좋음. 그거를 들고 여기서 이만큼 제의 받았는데 더 주세요. 사실 이렇게 하려면 인터뷰도 많이 해야함. 오퍼를 갖고 너무 왔다갔다하면 별로 안좋아함. 실리콘벨리에서 인도사람들이 이런거 잘함. 평판에 영향. 그냥 무조건 더 달라고 하는 것임. 그럼 대부분은 조금 더 줄 것임. 대부분 평균에 맞춰서 주기 때문. 조금 더 줄 여지가 있음. 안주면 안주는거고. 오퍼가 나온 시점에서 더 달라고 해서 취소하진 않음. 7~8명 인터뷰 한 다음이기 때문. 더달라고 해보고 안주면 뭐.

이 과정에서 복기를 잘해야함. 전화 인터뷰를 했다? 어떤 질문들을 했고 내가 어떻게 답변했는지. 다음에도 똑같이 답변할까? 아님 바꿔서 얘기해볼까? 따져봐야함. 특히 온사이트 인터뷰에 코딩질문, 행동양식 질문. 이력서에서의 질문은 정말 잘 따져봐야함. 이게 발전이 되어야 다음 면접 때 잘하게 됨. 처음 면접들은 이런게 안되어 있어 망치게 되어있음. 힘들게 기회를 잡았지만 망치고 끝나게 됨. 생각없는데 가서 연습을 해야함. 그런데 갔다고 해서 대충하지 말고 많이 물어보고 괜찮다? 그럼 거기서 시작하는 곳이 될수 있음.

어느 회사에서 시작하느냐가 중요하지 않음. 일단 시작하는게 중요함. 커리어는 여정이고 어디서 마무리하냐이지, 어디서 시작하느냐는 그렇게 중요해지지 않아짐.

질문을 잘 하는 습관 들이기.

행동양식 질문

시니어들,
맥스님은 impact를 좋아하심.
매니저라면 지금까지 뽑았던 사람중 가장 힘들었던 사람은? 일을 잘했던 사람은?
답을 하면 꼬리에 꼬리를 물고 진행이 됨.

STAR 형식으로 대답하기.
이러면 질문자가 여러번 꼬치꼬치 묻지 않음.
간결하게

일부러 똑같은 질문을 2명의 면접관이 하는 경우 있음. 일관성 파악.
면접관들이 모여서 다시 토론함. 일관되게 답변하는게 좋음.

기술질문

특정 기술에서 조금 솔직하게 얘기해도 됨. 질문에 대해 답을 잘 못할수도 있다. 하고 시작하면 됨.
프로젝트를 한게 있으면 이어지듯 질문. 이력서의 모든 내용은 질문이 나올 수 있다는 것을 염두에 두어야 함.

숙제를 주고 리뷰. 숙제를 주는 순간, 해서 오는 사람이 줄어듦 10명중 2명. 이런 사람들의 경우 가산점이 있다라고 볼 수 있음. 숙제를 한건지 안한건지 코드리뷰를 하다보면 알게 됨. 남이 해줬어도 이해를 하고 있으면 문제는 없음. 커뮤니케이션 스타일도 알 수 있음.

한국 스타트업 - 숙제의 난이도가 어느정도 있었고, 코드리뷰가 괜찮았으면 수습기간을 면제하는 경우도 있었음.

야후, 유데미 면접 때 가장 안좋은 케이스는 듣자마자 칠판에 코드 쓰는 사람들.
잠깐 생각하고 이 문제의 불분명한 부분이 있다면 질문을 하는 습관을 들이기. 바로 쓰는 습관은 면접관에게 좋은 인상을 주진 않음.
해법을 명확히 하는게 있다면 간단하게라도 그걸로 푸는 것임. 결과 보여주고, 시간이 남으면 조금 더 고도화 해서 나은 방법으로 푸는 방법을 보여줌. 처음부터 아주 잘 할 필요는 없음.

생각도 했지만 막힌경우, 이대로 가면 답을 하기 어려울 것 같음. 이 땐 도와달라고 하기. 문화권에 따라 너무 달랐음. 동아시아권 특. 문제 얘기하는 순간 쓰는 경우 많고, 어딘가 막히면 그거 붙잡고 있음. 인도, 백인은 커뮤니케이션을 잘 함. 여기서 막혔는데 도와주세요. 내가 이거 못풀꺼 같은데 다음 질문 주세요.
끝날 때 한번 더 어필할 필요. 기회 주면 열심히 하겠다.

이문제를 풀려면 키가되는게 1개 있음.
LEFT JOIN
NULL을 0으로 바꾸기 위해 COALESCE를 아는지.

처음부터 잘하기는 힘듦. 이런 케이스를 보면서 배우기.
어느정도 공부가 되면 면접을 병행해야 한다는 것. 이 과정이 끝날 때부터는 면접 시작해야함.

이런 문제를 받았으면 처음 뭐를 해야할까?
nums라는 파라미터가 정수만 들어있는 리스트인가요? 이걸 가정하고 짜도 되나요? 리스트인데 숫자가 아닌경우, 예외에 대해.
코딩 문제를 풀 때 항상 예외에 대해 질문.
코드가 완성되었다고 하더라도 끝내지 말고, 손으로 유닛 테스트를 만들어보기.

sum_even_numbers([1,2,3,5])

손으로 테스트 케이스 만들어서 보기.

질문하기

왜 지원했는지.
팀이 좋은 곳이라면, 면접관들이 자기 소개를 할 것임. 문화가 안좋은 회사면 소개없이 바로 질문함. 소개 없이 바로 질문한다? 조금 조심해야함.
자기 소개를 했다면, 약간 개인적인 질문을 해도 됨.

긍금한게 있으면 편하게 물어보려는 노력이 있어야 함.

좋은 질문 예

데이터 팀의 구조는 어떻게 되어있나요? (분산, 중앙집중, 하이브리드)
내 상사에게 처음 90일 동안 어떤 일을 하게 되나요? 답이 잘 나오면 준비된 곳이구나. 헤맨다면 좋은 시그널이 아님. 온보딩이 잘 안될 가능성.

맥스님 생각에 좋은 질문

회사에서 가장 좋았던 점 그리고 안 좋았던 점 하나 설명해주실 수 있나요?

작은 회사의 경우
매출 물어보면 됨. 규모가 되는 회사는 검색해서 다 나옴. 대놓고 물어보는 것임. 반응이 비밀이지만 얘기해주겠다라면 좋은 회사. 왜 이런걸 물어보냐 라면 안좋을 확률이 높음. 질문을 많이 하는게 좋음.

하는 만큼 늘게 됨. 면접관 관점에선 기억에 남는 질문자를 뽑게 되어 있음.

면접 전략

이력서를 닥치는대로 내보기.
생각보다 연락이 오는 곳이 많지 않기 때문에, 많이 뿌리는 것이 중요함.
자기검열을 하면 안됨. 잡 디스크립션을 보고, 아 내가 모르는게 투성이네. 아 이회사 별로 안정적이지 않을꺼 같은데? 내지 말자. 너무 따지지 말고 일단 내보기. 내가 필요한건 결국 하나의 회사.
99개 실패해도 1개만 잡으면 됨.
rejection을 실패라 생각하지 말기

회사는 여러개 다니게 되어 있음.
남들이 못알아주는 회사라도, 사람이 괜찮다면 시작해도 전혀 문제될 게 없음. 실무 하면서 성장하면서, 더 좋은 곳으로 가면됨.
남하고 비교하지 말기.
시작하는 곳이 중요한게 아니라, 어떤 여정을 거쳐, 어디에서 마무리하느냐가 중요.
사람들이 모여서 일하는게 중요하기에, 어떤 사람들이 있는지 중요함.

좋은 사람들이란? 많이 물어보고 어떻게 답을 해주는지 보기. 답을 더 잘해주려고 하는 곳. 질문을 많이 해보기.

직장 선택 기준

회사가 성장가능성. 작으냐 크냐는 중요하지 않음. 성장하지 않으면 사람들이 정치적으로 변함.
성장을 하는 곳은 굳이 남의 것을 뺏을 필요가 없음. 성장하는 곳에서 사람들은 훨씬 나이스함.
기왕 고통받을 거면 성장통을 겪는 것이 나음.

사람이 좋은 곳.
질문을 많이 해보면 알 수 있음.

내 매니저.
제일 중요한 요소. 미국에서 이직 얘기할 때 70%는 매니저 탓이다라고 함. 면접관이 내 매니저가 될 사람이다 싶으면 더 많이 물어봐야함. 같이 일해보기 전엔 명확히 알기 어려움. 커리어 초반에 좋은 매니저를 만나면, 좋은 걸 보고 따라함. 관계를 잘 만들어두면 이직할 때 따라감. 내 매니저라면 이런상황에서 이런 결정을 하지 않을까? 하고 판단이 서는 경우 있음.

이러한 성장하는 경험이 더 중요하다고 생각.
면접할 때 많이 물어보기.
가능하면 지인이 있으면, 그 사람을 통해 더 많이 체크해볼 수 있음.

어떻게 잘 시작할 것인가?

처음 90일이 제일 중요.
수습기간과 딱 맞음.
내 매니저 파악하고, 스타일 확인. 일들이 있다면 어느게 중요하고, 어느게 덜 중요한지 파악. 의사소통 능력이 중요해짐. 잘못되면 물어보는게 두려워짐. 이럼 내 상상대로 일을 하게 되고, 엉뚱한 방향으로 일을 열심히 하게됨. 처음일수록 더 많이 물어봐야함. 어떻게 끝나야 성공이고 실패인지.

작게라도 90동안 성공을 이룩해보기. 맡은 일을 완료해보기. 성취해보는 경험, 몰두해보는 경험.
과거에 상처가 있으면 조금 힘들수도 있음.
다른 일을 하다가 온 사람의 경우 일에서의 상처 있을 수 있어서 발목을 잡을 수 있음. 내 감정을 파악하고 있어야 함. 내가 언제 움츠러 드는가, 내가 언제 감정적이게 되는가. 이유가 뭔지 파악하려고 해야함. 나이, 경력에 따라 꼭 현명해지진 않음. 잘 안되는 일도 있고, 실패도 있고, 상처도 있을 텐데, 치유가 안되면 움츠러들 일 투성이임. 어딘가에서 새로 시작할 때 나는 어떤 상처가 있는가. 정확히 언제 움츠러드는가

뜨는 기술 따라가지 말고,
지금 현재에 집중하기.

기술지향 X -> 결과지향 O
일의 경중, 일의 성공실패를 내가 판단하지 말고 그걸 결정해주는 매니저, 리더와 의사소통을 통해 결정. 질문을 잘해야 함!!

나중에 어떤 조직의 리더가 되면, 질문을 편하게 만드는 환경이 좋음.

주니어 때는 스킬셋이 더 중요.
시니어는 행동양식
누군가가 나에게 장점이라 생각한걸 단점이라 말하면 좋은 피드백이라 할 수 있음.

생각이 많으면 보통 결정을 못함. 있는 곳에 그대로 있게됨. 후회를 최소화 하는 형태로 결정을 하던지. 40중반 전에는 해보고 싶은걸 공격적으로 해보는게 좋아보임. 그 이후는 잘하고 재밌어하는걸 하는게 좋아보임. 사실 생각보다 시간이 많음.
강사님은 석사 마치고 28년을 일했는데 아직도 50대 중반

다시 기술적인 이야기로 넘어가기