안녕하세요, 전에 질문 글 올리고 답변에 대해서 매우 감사하고 있는 Evan입니다!
사실, 다음 주에 여행을 떠나기 전 일요일 같은 때에 제 Coding interview 준비 방법의 결함에 대해서 더 깊게 알아가고자 합니다.
제가 질문을 하고, 다른 사람들의 답변을 보고 다른 job seeker 분들도 많이 배울 수 있지 않을까해서 이런 곳에 다가 질문을 올립니다.
질문 글 올리게 되는 계기:
주변의 Software Development과 프로그래밍에 자부심을 느끼고 사랑해서 tech 관련 meetup을 열어주는 소프트웨어 장인들, staff engineers, CTO 에게 Data Structure / Algorithm 인터뷰 팁 등을 물어보면, whiteboard에다가 DS / Algo 코딩 문제만으로 Software Engineer 를 뽑는다는 것은 사실상 많은 tech 기업들의 hire process가 broken 해서 안타깝다고 그러더라고요.
하지만, 현실적으로 크게 성장하고 있는 tech 기업들이 Software Engineer (특히 Entry level) 들을 Hire 하는데 가장 크게 의존하고 있는 수단, Coding interview 에 대한 구체적 조언을 주질 못합니다. 스태프급 엔지니어가 하나당 45분 짜리 알고리즘 인터뷰에서, logical thinking, creative problem solving skills(efficient / concise codes), how to overcome technical difficulties, test & debug skills 을 본다는 건데, 이 인터뷰 준비 방법에 큰 결함이 있는지 집고 넘어가고 싶습니다.
Quora 에서 Leetcode 500개 풀어도 unemployed 인 사람에게의 조언을 읽었는데, "정답을 외우지 말고 먼저 생각하면서 풀어라", "Communication skill에 문제가 있다" 등등 구체적으로 그 사람의 공부 방법에 대한 지적이 잘 보이지 않습니다. Coding interview 에 대한 Resource 와 코딩 인터뷰의 형태, 토픽들은 너무 많은데, 올바른 공부 방법, 잘못된 방법에 대한 예시와 처음에 못했던 사람의 공부 방법 교정으로 인하여 Top tech company에 들어간 사례 등을 찾기가 어렵습니다.
CS department 입학을 같이해도, 정말 잘하는 애들은 계속 잘해서 시간이 남으니, 더 어려운 문제를 풀면서 더 좋은 곳에 들어가고, 나머지는 그냥 학교 수업 근근히 따라가면서 준비를 많이 못하지만 Coding interview를 잘 요구하지 않는 government related 나 Software Engineer가 cross-side 인 곳 (신분문제가 있는 사람들은 해당 X) 으로 취업해도, 실력이 급격하게 향상해서 격차를 극복하는 친구를 보지 못했습니다.
한국 수능 대비를 따지자면, 공신 강성태, Studycode 조남호 (그 분들 맹신 X) 의 학생들 보면, 아무리 과거에 공부를 못했어도, 공부 방법에 대한 큰 결함 발견과 교정으로 인해서 (중하위권 -> 최상위권) 역전사례와 팁을 알려주는 영상들이 많은데, coding interview 나 software development 이쪽에서는 이러한 사례를 잘 설명하고 교정 멘토링 같은게 많이 없어서 안타깝습니다. 주변 Tech career mentoring / coding interview prep meetups 에서는 Algorithm 가르치고, mock interview 약간 해주고, leetcode 질답해주는게 대부분 입니다.
저의 인터뷰 피드백은 주로:
1) Interviewer가 문제를 설명하면, 5분 이내로 빨리 이해를 못하는 등 새로운 문제 이해하는데 좀 걸림. (새로운 문제에 대한 긴장하면 듣고 빨리 이해하는데에 문제)
2) 문제를 이해하고 접근 방법을 알아내면, Pseudocode랑 코드 설명을 잘한다. (다른 non-English speaker 들에 비해 영어로 의사소통은 크게 문제가 안됨)
3) 코드에 문제점 발견했다 싶으면, 즉시 바꾸고 해결하려는 자세는 좋아보인다.
4) 문제를 구조적으로 해결하려고 하고, 나만의 솔루션을 만들어 나가는데에 큰 문제가 있다. (Ex. Tree problems in Recursive ways) -> Leetcode 혼자해도 마찬가지
5) 인터뷰 경험이 좀 있어서 그런지, 문제를 듣고 바로 코드 쓰려고 하지않고, 마지막에 코드 쓴 뒤, 테스트하려는 자세와 Efficiency를 점차 optimize 하려는 자세는 좋아보인다.
6) 온사이트때, 초반에 나만의 솔루션을 잘 만들어 나가지 못하고(4번), 시간이 절반정도 흐르면, 누구보다 멘탈관리 크게 어려움.
지금까지 해오던 방법(주로 인터뷰를 Java로 선택. Python은 Syntax가 별로 완벽하지 못하다 생각해서 안함):
너무 지루하고 절망에 빠져 포기해왔지만, 1달 반 전까지 하루 6-8시간에 interview prep 투자.
https://www.quora.com/What-should-I-know-from-the-CLRS-3rd-edition-book-if-my-aim-is-to-get-into-Google/answer/Jimmy-Saade?share=1&srid=TAJ1
에 나오던데로, CLRS 통해 개념을 대략 잡고 너무 어려운 부분은 GeeksforGeeks로 리뷰.
Hackerrank, geeksforgeeks 등 문제를 몇 십개 푼 뒤, Leetcode 총 128개 완료함 (질 안 좋은 easy 문제 skip하고 Medium 절반까지 품).
일반적으로, leetcode 코딩 문제 1개당 45분을 잡고, 첫 10-15 분 아무 코드도 작성 못하겠다 싶으면, leetcode discussion board에서 가장 most voted 한 답변의 코드 손바닥으로 가리면서, 한줄 보고 내 코드쓰고, 그 다음 모르겠다 싶으면, 다음 줄 보는 식으로, 공부. 어느새부터 특히 medium 문제들 같은 경우인내심이 사라져서 10-15분 동안 모르면 답을 보려고함.
DS -
Array: 기본 문제는 하도 풀어보니까 바로 나옴. DP 로 넘어가면, 정말 힘들어해서 결국 O(n^2)로 끝내고 잘 optimize 못하니까 무작정 외우려고 함.
Sets & Maps: 가장 자신 있는 분야. 처음부터 정말 되도록 O(n)으로 끝내겠다는 생각으로 접근을 함.
LinkedList, Stack & Queue: 문제풀다가 못 하겠다 싶으면, 개념 review 하는식.
*Recursion: 처음에 개념 잡기가 너무 어려워서, 제게 있어서 가장 큰 복병. 이거 때문에, 거의 제 모든 CS 코스 프로젝트에서 요구하는 recursion 때문에 전공성적 엉망. 오답 체크할때, 그 문제의 표를 그려가면서 어떻게 backtrack되고 부분의 값이 어떻게 나오는지 track 하는 식으로 하나하나 이해해서 코드가 왜 맞는지에 대해 이해함. 그런데, leetcode 풀거나 인터뷰 문제 나오면 처음에 recursive 부분에 접근할때, 머릿속으로 backtrack 하는 과정을 거치지 않고 intuitive 하게 생각하고 코드부터 쓰고 그 다음에 backtrack 함. 별 짓을해도 recursion 어떻게 마스터하는지 헷갈림.
*Trees & Graphs: Queue 를 이용한 Iterative way에 익숙해진 뒤로, recursive 쪽 연습에 주력. BFS(Level-order traversal) 과 DFS(In / Pre / Post order) 선택 뒤, 어떤 order 할건지 선택한 뒤, function 만드는 과정에 집중, 역시 제 recursion의 결함으로 테스트시, backtrack하는 표를 그려가면서 디버그함.
오죽 부족하다 싶으면, tree easy 문제를 다시 한번 풀 정도.
Dynamic Programming (DP): 누구한테나 어렵고 문제를 구분할 수 있는 개념이 너무 방대함. 그러나, House robber 같은 너무 유명한 문제는 recursion 필요없어서 많이 반복하면서 optimization 하는 과정을 외우다시피 반복해왔음. 그러나, 꼬은 문제나 더 어려운 DP는 recursion을 기초로 한다는데, Recursion을 먼저 마스터 뒤, 이용해서 어떻게 optimize 할지 모르겠음.
Backtracking & Greedy: Recursion 이 약하단 생각에, Geeksforgeeks 예제 중에서 코드 한줄한줄 보면서 이해하고 끝냄.
Algo-
Sorting (Insertion, Bubble, Selection, Heap, Merge, Quick): 이해하고 외워도 계속 까먹으니, youtube video의 motion 보면서 상기하고 계속 외워댐.
Shortest Path: 예제보면서, 코드봐도 계속 까먹음.
Sorting과 Shortest Path는 코드보고 계속 외워대도 계속 쉽게 까먹어서 차마 이와 관련된 코딩 인터뷰 문제 풀 수 없을 지경입니다.
Data Structure / Algorithm 개념, Problem solving 쪽을 마스터하면, 그 때 Python에 더 배우고 익숙해져서 코딩 인터뷰 랭귀지를 Python으로 넘어갈 계획입니다.
다시 말하자면, 저는 이런 곳에서 이 질문으로 당장 완벽한 코칭을 기대하지는 않습니다. 어차피 여기서 제 수준을 완벽하게 표현할 길도 없지만, 여러 조언(의견)과 결함의 지적을 바탕으로 하여, candidate 자신의 문제점에 clarify하고 자신의 코칭 방법을 개발하는건 자신의 몫이라 생각합니다.
조언 감사드리겠습니다.
글로 읽어서는 구체적으로 어떤 부분이 문제인지 쉽게 판별은 안되네요.
위에 글만을 읽어서는
1. 아무리 생각중이어도 인터뷰어를 심심하게 만드는건 안좋습니다. 20초 이상 침묵이 계속되면 대부분 bad sign압니다. 해결책이 안떠 오르더라도 내가 지금 무슨 생각을 하고 있다. 어떤 부분 막혀서 이걸 해결하려고 있다 등 계속 수다를 떨어줘야 합니다. 그래야 인터뷰어 입장에서도 어느 타이밍에 어느정도의 힌트를 줘서 인터뷰를 진행할지 알 수 있거든요.
2. 코드의 퀄리티가 매우중요합니다. 실력자는 한 5줄 정도만 봐도 인터뷰이가 얼마나 많은 코딩 경력을 가지고 있는지, 얼마나 좋은 코드 (잘 되어 있는 오픈소스 등)를 많이 봐 왔는지 바로 알 수 있습니다. 알고리즘 등은 수험 준비를 해서 익힐 수 있지만 몸에 밴 코딩 퀄리티는 단시간에 해결하기 어렵습니다.
3. 인터뷰는 똑똑하고 알고리즘 잘 외우는 사람을 뽑는 과정이 아니고 자기랑 일해서 재미있을 사람, 내 발목 안잡을 사람을 뽑는 과정입니다. 아무리 똑똑해도 문제를 풀어가는 토론과정이 재미없거나, 자신의 생각만을 밀어붙이거나 이러면 꽝입니다.
4. 정직함이 매우 중요합니다. 혹시 내가 이미 아는 문제가 나왔다고 아싸!를 외치고 일필휘지로 풀었다면 인터뷰 피드백에는 분명히 "이 사람 아는 문제인데 안다고 말안했음" 이라고 적혀 있기 마련입니다. 매우 유사한 문제를 며칠전에 인터뷰 공부하면서 풀어봤거나, 이전 인터뷰이가 유사한 걸 물어봤다면 솔직하게 이야기하는게 좋습니다. 대부분의 준비된 인터뷰어는 이런 상황에 대처하기 위해 같은 질문에 대해서 plan a에서 plan d까지 준비해 놓고. 혹은 부정직한 사람을 잡아내도록 함정 카드까지 준비해놓고 나오는 경우가 많습니다. 그런데 안걸리러면 처음부터 까놓는게 좋아요.
제가 요즘에는 바빠서 인터뷰쪽은 손 놓고 있지만, 오늘 한가하시면 마일모아 쪽지 보내주세요. 시간 있으시면 오후에 폰으로 목인터뷰 한시간 정도 봐드릴께요.
일필휘지 ㅋㅋ
옛날 글씨로 공무원 뽑을 때도
글자 다섯자보면
얘가 어디서 누구 밑에서 얼마나 배운 놈인가가 쫙~~
개골님 홍익인간요
글씨로 공무원 봅은 적이 있었나요?
갑자기 뜬금 포 질문 죄송합니다. 근데 이렇게 코딩 고수님들은 자녀 코딩 교육은 어떻게 하시는 지 궁금합니다. 베이지역에 킨더부터 코딩교육 열풍이 부는 거 같은데 어떤 관점을 가지고 계신지 궁금하네요...
제 주변에서 자녀에게 코딩을 가르친다는 소프트웨어 엔지니어 분들은 본적이 매우드문데요. 가르치는 경우에는 아이가 정말로 코딩을 좋아하는걸 보이는 경우 한정인듯해요. (다들 축구 클럽에 집어넣고 발레하고 이런 이야기는 많이 듣습니다만. 어딘가 코딩 클럽 보냈다는 이야기는 들어본적 없습니다)
그리고 학교에서도 코딩을 배워왔다 이런 이야기를 못들어본걸로 봐서는 뭔가 살짝 와전된개 아닐까 싶어요.
빠른 답변 감사합니다. 제 주변은 그런 분들이 많네요... 대부분 부모들이 이과쪽이 아니고 아이들이 새로운 시대에 뒤쳐지지 않을까하는 상당한 불안감들이 있는 것 같습니다... 실제도 중고등학교 용 코딩 부트 캠프에 애들이 많이 모인다고도 하구요... 저는 계산용 코딩을 하는 사람으로서 답변하기 좋은 위치에 있지않아 언제나 불편한 주제가 되더라구요... 답변 감사합니다
제 아이가 다니는 베이지역 초등학교의 경우 부모의 직업이 대략 Software Engineer, Hardware Engineer, IT Finance, IT Lawyer, IT HR 뭐 이럭식입니다... 문/이과 상관없이 어떻게든 IT회사랑 연결되어 있구요.
그래도 아직 초등학교 안에서 누가 코딩에 뛰어난 재능을 보인대더라 이런 이야기 들어본적도 없고... 그런거 시키면 "우와 그집 애들 잘 가르친다" 보다는 "우와 그집 참 특이하네" 이렇게 볼 것 같아요 ㅋㅋ
네.. 답들 자세히 달아주셔서 감사합니다. 저의 작은 커뮤니티를 바탕으로 너무 확대 해석했나봅니다 ㅎㅎ 좋은 주말 되세요!
4. 안걸릴 자신 있으면요? 적당히 해메면서;;;
솔직히 말하고 쌩판 첨보는 문제 풀 자신있으면 족보를 왜 보겠어요 ㄷㄷ
인터뷰를 보시는 분들은 (interviewer) 대체로 어느정도 직급/연차가 되시나요??
1. 회사마다 다 다르겠지만. 제가 다니는 회사의 경우 어떤 문제가 public online page에 많이 거론되면 alert가 뜨고 문제가 banned 됐다고 표시됩니다. 그럼 인터뷰어의 입장에서는 두가지인데요. 밴됐으니까 딴 문제를 찾던가 (일반적으로 제대로 plan A부터 plan D까지 다 고려한 calibration된 인터뷰 문제를 고안하는데 1-2개월은 걸립니다) 아니면 익숙한 문제를 계속 내는대신 작정하고 함정을 파 놓는겁니다. 생각하시는거 이상으로 인터뷰 내는 사람도 많은 고민을 하고 문제를 내는거고, 생각하시는 것 보다 훨씬 consistent하게 이런 유형의 치팅을 잘 잡아냅니다 ;;;
2. 저희 회사의 경우에는 인터뷰 대상자와 동일 레벨 혹은 1레벨 정도 위의 사람이 일반적으로 들어갑니다. 다시 말씀드리지만 인터뷰는 코딩을 하는자리가 아니라 "이사람이 나랑 같은 팀에서 일했을 때 내 발목을 잡을까 아닐까"를 가늠해보는 자리입니다.
흐흐흐 뻘질문에 정성스런 답글 감사드려요
Evan님 sorting이나 shortest path는 이해하고 외워도 계속 까먹는다고 하셨는데. 이 부분을 좀 구체적으로 설명 해주실 수 있나요?
글 내용을 보니 cs 프로젝트를 하셨다는 걸로 보아 전공은 cs이신거죠?
약간의 백그라운드를 더 알면 더 좋은 답변을 드릴 수 있을 것 같아요!
솔직히, Sortings / Djikstra's shortest path를 제대로 구현하지 못하는 자신이 CS 졸업생이라고 하기 부끄럽습니다.
저 위와 같은 것들은 1-2학년 때 이미 배운 것들입니다.
아직 프라이버시 때문에 어디 졸업했다 말하기 그렇지만, CS top 13안에 드는 학교 저번 12월에 졸업한 CS major recent graduate 입니다.
인턴했지만, 졸업전 오퍼를 못 받은게 큰 화근이 되어서, 지금까지도 비자 해결해줄 수 있는 곳에 오퍼를 못 받은 상태입니다.
Data structure 제가 어떻게 공부하고 있는지 위에 설명을 드렸습니다.
인터뷰에서 직접적으로 Sorting 과 shortest path 부분에서 문제가 나온 적이 없고 죄다 Data Structure 부분에서 나오다보니, 외우고 이해하는 정도로 끝내다보니,
위 2개 토픽은 돌아서면 까먹고, 동영상보고 이해하고 다시 외우는 것을 반복합니다.
6개월 동안 Entry level position 인터뷰 준비우선 순위 잡을때, 위 2개 토픽 관련된 leetcode 예제도 계속 풀어야 필요가 있습니까?
아님 위 2개 토픽은 그냥, 이해하고 외워서 알면 도움이 되는 정도입니까?
다른 분들이 좋은 댓글 많이 달아 주셨는데요. 저도 인터뷰어로 가끔 들어가고 제가 보는 관점은 다른 분들과 많이 다를 수도 있다는 점을 먼저 염두 해두셨으면 합니다.
junior를 interview 할 때는 개념적으로 아주 명확하게 이해하는지를 보고 문제에 나온 "문제"와 이미 알려진 개념들을 이용해서 어떻게 도출 해 나가고 활용해 나가는지를 주로 보거든요. 많이 사용하지 않는 자료 구조나 알고리즘을 빠르게/바로 구현할 수 있는지를 보지는 않아요. 문제를 푸는데 사용하는 자료 구조나 알고리즘의 핵심 적인 아이디어를 떠올릴 수 있고 그걸 이용해서 문제를 풀 수 있다는걸 보여주고 나면. 그 다음 부터는 모르는 부분에 대해서 힌트를 줘가면서 기본 아이디어에서 구체적인 구현까지 진행해 나가는 과정들을 보는 편이죠.
Evan님이 자료 구조, 알고리즘을 나열해서 잘 아는 것과 잘 모르는 것, 공부 방법등을 나열 하셨는데요. 저는 그 부분이 좀 많이 이상하다는 생각이 들어요.
예를 들어 "정말 되도록 O(n)으로 끝내겠다는 식으로 접근을 함" 이렇게 얘기를 하셨는데. 이거는 시간 복잡도 찍어 놓고 문제 내는 경우엔 문제를 "빨리" 풀 수는 있겠지만. 인터뷰어가 이 문제는 O(n)에 풀리는 문제이고 특정 알고리즘을 아는지 확인해보는 식으로 문제를 잘 내지 않는 다고 생각해요. 적어도 두개에서 세 가지 방법으로 푸는 방법이 있는 문제를 내고 하나를 모른다고 해서 인터뷰 0점 받는 식으로 안하거든요. 다양한 해결책 사이에서 pros and cons를 비교해야 될 수도 있고 다양한 알고리즘이나 자료 구조를 응용하는게 핵심적일 수도 있거든요.
"일반적으로, leetcode 코딩 문제 1개당 45분을 잡고, 첫 10-15 분 아무 코드도 작성 못하겠다 싶으면, leetcode discussion board에서 가장 most voted 한 답변의 코드 손바닥으로 가리면서, 한줄 보고 내 코드쓰고, 그 다음 모르겠다 싶으면, 다음 줄 보는 식으로, 공부. 어느새부터 특히 medium 문제들 같은 경우인내심이 사라져서 10-15분 동안 모르면 답을 보려고함."
이 부분이 어찌 보면 좀 핵심적인거라고 생각해요. 코딩은 정리된 생각을 나타내는 거에 불과하고 인터뷰 시에도 그 점을 먼저 보거든요. 방어적인 코딩이나 코드를 아주 예쁘게 만들면 플러스 점수가 있겠지만 그건 어디까지나 플러스인거고요. 중요한건 생각을 이해하는건데 말씀 하신 것처럼 남들이 적은 코드만 보는 경우는 이 사람이 왜 이렇게 생각 했는지까지는 알기가 어려워요. 더군다나 각자 코딩 스타일이 다른데 그걸 1줄씩 잘라서 본다면 전체적인 생각의 맥락을 알 기가 더 힘들겠죠. 아니 불가능하죠.
가장 기본적인 것들을 잘 이해한 상태에서 더 복잡한 것들을 차근차근 쌓아 나가는 형태로 지식을 쌓아야, 어떤 복잡한 문제가 나오더라도 이를 기본적인 형태로 쪼개도 보고 이런 저런 방법으로 돌려 보면서 문제를 "간단하게" 만들어서 해결할 수 있다고 생각해요. 알고리즘이나 자료 구조를 외우는 방법으로는 그 알고리즘을 그대로 사용하는 문제가 나오지 않는 담에는 인터뷰에서는 큰 활용도가 없다고 생각해요. top tech company일 수록 그런 직접적인 지식을 물어보는 질문을 하지는 않을꺼라고 생각하고요.
지금 당장 job이 안 구해지는 상태에서 쪽집게 과외 같이 이런식으로 해보세요 하는 답변을 기대 했으리라고 생각해요. 밑에 분이 junior 인터뷰에 기술적인 얘기를 많이 적어 주셨는데요. Evan님이 적어 주신 내용을 봤을때 지금 concurrency나 performance programming을 더 공부해서 익히는건 제 생각엔 모래성을 더 높게 쌓는것 같다는 생각이 들어요.
도움이 안 된다고 생각하실 수도 있지만 제 조언은 이래요. 굉장히 많은 부분들을 그냥 외웠다고 하셨는데요. 이 부분을 어떻게든 극복을 하셔야 된다고 생각해요. 인터뷰어 입장에서도 이 사람이 아는 문제를 풀고 있다는거 확인 할 수 있거든요. 문제를 굉장히 잘 풀었는데 문제를 아주 조금만 비틀면 아예 막혀 버리는거죠.
코딩 문제 계속 풀어보시는게 중요하고요. 문제에 대한 접근 방법을 이 문제는 이 알고리즘이 답이다라는 식으로 접근하지 말고, 다양한 알고리즘과 자료 구조를 다 생각해보고, 시간이 되시면 그걸 다 코드를 적어 보시면 더 좋고요. 또, 지금부터는 코드 적으신거. 왜 한 줄을 이렇게 적었는지. 다르게 적는 방법은 없는지. 다르게 적었다면 어떤 면에서 좋고 나쁜지. 함수 하나만 가지고도 pros and cons를 모든 면에서 분석 해보시고. 이 부분을 함수로 뺄지 말지 이런 것도 하나 하나 매우 세밀하게 살펴보시고요. 기본적인 자료 구조와 알고리즘은 관련 된 문제를 수십개를 풀어서라도 굉장히 철저하게 이해 하시면 좋겠습니다.
저는 Evan님이 쓰신 글을 보고 깜짝 놀랬어요. 다음 문장인데요.
"Coding interview 에 대한 Resource 와 코딩 인터뷰의 형태, 토픽들은 너무 많은데, 올바른 공부 방법, 잘못된 방법에 대한 예시와 처음에 못했던 사람의 공부 방법 교정으로 인하여 Top tech company에 들어간 사례 등을 찾기가 어렵습니다.
CS department 입학을 같이해도, 정말 잘하는 애들은 계속 잘해서 시간이 남으니, 더 어려운 문제를 풀면서 더 좋은 곳에 들어가고"
저는 이게 너무 사실 같거든요. 처음에는 아주 작은 차이, 아주 사소하게 빠른 이해력을 가지고 있거나, 남들보다 10% 시간을 더 써서 좀 더 개념을 확실하게 알아 두면, 나중에 갈 수록 이게 승수의 법칙처럼 눈덩이처럼 불어나서 단기간 안에 그 차이를 따라 잡을 수 없다고 생각하거든요. 이런 것들은 어찌 보면 자신의 학습 인생이라고 할 수 있는데. 몇 가지 사소한 팁으로 인생이 바뀌기는 힘들잖아요? 정말 거대하게 잘못된 점이 있어서 그걸 바로 잡았다고 하면 역시 인생을 산 긴 시간 만큼 긴 시간을 들여서 자신의 궤적을 다시 그려야 되는 그런 문제라고 생각이 들어요. 단계적으로 진행하고 인내심이 필요하다는 점을 말씀 드리고 싶어서 하는 얘기 입니다.
+1
흔히 Leetcode를 공부하다보면, discussion board에서 주로 자기들 방식대로 푼 정답을 올려놓지, 순수하게 힌트에 대한 질답을 올려놓는게 아니라서요. (특히 Easy ~ medium)
인터뷰때는 하도 안풀리다보면, 힌트 정도는 물어볼 수 있잖아요.
그런데, 릿코드 보드에서는 순수하게 힌트와 질답을 올려놓는 공간이 아니기도하고, 힌트만을 찾아보기는 힘드니까, 한줄봐서 힌트를 찾아내고 approach 어떻게 해야될지 감을 얻어서 코드 쓰고, 다음줄 보고, 쓰는 식으로 해왔던 것 같아요.
내 생각을 표현하는 방법이 코딩인데, 한 줄씩 봐가면서, 힌트 얻고하는건 그렇게 좋지 않는 것에 대해 배웠습니다.
어느 일정 시간이 지나도 이해를 못하거나, 답이 도저히 안나오면 남의 코드를 참고하고 다시 되돌아가야 하지만, 그 인내심이 갈수록 부족해져서, 일정 시간 전에 도저히 생각이 안나도, 바로 남의 코드를 참조해버리는 잘못된 습관이 굳혀진 것 같습니다.
사실 학부때, 성적때문에, 프로젝트 제때 끝내놓아야한다는 부담감에, 인내심이 많이 사라져서 순전히 제 로직으로 고민해보는 시간이 짧아지고, 남의 코드를 참조해버리는 습관이 생겨버린 것 같습니다.
저도 외우는 것에 대해서 탐탁치 않게 여겨왔습니다만, 제한된 시간에 할 것은 많은데, 계속 이해 안되는 것 계속 붙잡고 있느니 일단 외워버린 다음에, 그거 나중에 나올때 다시보면 이해가겠지 이런 생각으로 공부해온 것 같습니다. -> 다른 과목 공부해오던 것 알고리즘 공부법에 적용 해왔는데 이게 맞는지 헷갈리기도 합니다..
도저히 이해가 안가고 시간이 없을때 외우는 것도 좋은 방법이라고 할 수 있습니까?
가장 중요한 고민은,
양치기(많은 leetcode 문제풀면서 문제당 1-2가지 풀이과정만 철저히 습득) VS 질치기(적은 유명한 문제들 뽑아서 4-5가지 풀이과정 철저한 습득 뒤 텀을 두고 반복해서 풀기) 입니다.
저도 수능 수학공부 했었을때, 1.5 년만에 내신 7등급 -> 수능 수학 만점, 전과목 몇개 틀린 사람의 비결을 보고 성적 향상을 많이 하던 경험이 있어요.
수능 수학 25번 / 이과 논술 수학문제같이 어려운 같은 문제들이 각각 4-5가지 서로 다른 풀이과정을 모두 분석해서, 적은 수의 어려운 문제들의 풀이과정을 깊게 공부해서 다양한 각도로 생각해보는 능력을 길러야한다는 것입니다.
하지만, 졸업하고나서, top 회사의 interviewer 친구랑 엔지니어들한테 들은 조언은 양치기를 하라고 그러더라고요.
"올림피아드나 시험치는 것하고 다르게 인터뷰에서는 시험 기출문제의 다양한 솔루션들을 반복해서 연습을 해온 Practitioner 를 원하지 않는다. 정말 새로운 문제이나 challenge에서 candidate 만의 창의적, 효율적인 코드를 짤 수 있는가의 능력을 보는 것이다. 따라서, Leetcode나 hackerrank에서 나온 문제를 짧은 텀두고 반복보다는 최대한 많은 양을 풀어내어, 전에 경험 못했던 새로운 것을 풀어내는데 집중해라." 라고 하는데, 이게 정말 맞는지 의문이 가기도 합니다.
알고리즘 인터뷰 마스터하는데 있어서 어느 쪽을 좀 더 추천합니까?
자잘한 skill이나 스타일들은 사람마다 다 다릅니다. 하지만, 인터뷰나 각 시험이 원하는 공통적이고 본질적인 방법에는 누구나 다 끼워맞춰야한다고 생각합니다. 최상위권들은 그 본질적인 방법을 미리 알아내어서 훈련을 해온 분들이고요.
일단 매일매일 주니어 캔디딧 인터뷰어 보는 사람 & Hiring Committe(진) 로써 몇가지만 말씀 드리면요,
1) Java로 계속 보세요. Java Interviewer가 일반적으로 가장 쉬운 문제 냅니다. 제가 다니는 회사에 (G사) 각종 언어 최강 고수들 밀집해 있는데. 다른 회사 가서 인터뷰 뭘로 보니 하면 Java로 본다고 많이들 합니다. 일단 C++에 비해서 할 수 있는게 없어요. 그래서 언어 레벨 자체에 크게 물어볼게 없습니다.
2) DS에 몇가지 빠졌는데요? 일단 Heap이 없네요. Size n의 이미 sorted 되어 있는 k 개의 리스트들 합쳐서 소팅하기 이런 국민문제 대응하실려면 아셔야 됩니다.
3) Set & Map에 O(n) 생각하시는거 보니깐 해쉬셋, 해쉬멥 말씀하시는 건가요? 요새 NavigableSet은 아셔야 됩니다. 실제 인터뷰가서 BSTish 한걸 구현 안하죠. 그냥 이거 써야죠.
4) 그리고 Backtracking 보다는 Suffix Array, Fenwick Tree, KMP등이 훨씬 더 빈출입니다. Backtracking은 마지막에 보셔도 되요. 좋지 않는 학교들은(제가 나온 학부? ㅋㅋ) 애초에 배우지도 않는 알고리즘입니다. (Stanford도 Programming Abstraction 에서 배우는거 아닌가요?)
5) 코딩 퀄러티 높이는 방법중에 좋은 것은 내공 9갑자의 코딩을 보는 겁니다. 어딨냐면 자바 그 자체죠. 초고수들이 만들어 놓은 해쉬맵, 소팅등을 보다보면 알아서 내공이 늡니다. 그래서 자바는 해쉬셋이 결국 해쉬맵이지 하면, 코드 하나도 안 읽어본 사람은 저한테 화냅니다. 둘이 얼마나 다른지 아냐고! 어 이런.. 그리고 Dual Pivot Quicksorting 이랑 Timsort 2개를 쓰는데 왜 쓰는지도 코딩을 보다보면 알게 됩니다. 그리고 아무래도 계속 보고 따라 쓰다보면 습작하다가 닮아간다고 코드가 닮아가죠. 그러면 한마디로 초고수 코드를 비슷하게 써내려가고 있으니 인터뷰어는 좋아할 따름입니다.
마지막으로 제가 인터뷰 준비할때 읽었던 책등 좀 알려드리고 마무리할께요.
1) Java Concurrency in Practice Ch1 ~ Ch7: 읽고 나시면 응 쓰레드는 그냥 계속 만드는건 아닌가요? 이런 답변 안 하게 되는 참된 자신의 모습 볼 수 있게 됩니다.
2) Java Performance The Definitive Guide Ch1 ~ Ch2: Java 7 부터 지가 알아서 코드를 지워주는데 그거에 대한 대표적인 예가 설명되어 있고, 그래서 단순한 for loop에서 함수 몇번 돌리고 시간 재는 (생활코딩등에 막 올라오죠..저렇게 시간 재고 뭐가 느리네 빠르다 하는) 마이크로 벤치마크 하면 개 노답이란걸 알려주고 약간의 솔루션을 줍니다. Ch3 넘어가는 내용은 인터뷰어도 아마 잊어먹어서 Ch1 ~ Ch2까지만 물어본다고 95% 확신합니다.
3) Effective Java 3rd Edition: 이건 코드 갈무리하거나 여러 개념 얘기할시 자신을 뒷받침할때 좋습니다. Effective Java Chapter X에 나온 내용에 따르면 이라고 얘기할때, Joshua가 틀렸다고 얘기할 인터뷰어는 소수일 껍니다.
4) Cracking the coding interview: 대부분의 회사에서 이제 ban 당하지 않았을까요? 거의 역사서로 치자면 사기일 듯 하네요. 그래도 기본 잡는데 괜찮은 듯 하구요. 한국어판도 있습니다.
5) Elements of Programming Interview in Java: (저는 C++ 버젼으로 공부) 이거 Cracking the coding interview 보다 수준도 높고 해설도 좋습니다. 그리고 저자 사이트에 질문하시면 잘 받아주는 걸로 알아요.
이 외에 리트코드는 한 300개 넘게 푸시면, 이제 들어가는 시간당 얻는 아이 실력이 느네 비율이 매우 줄어서, 관련 책, 블로그등 보시면서 다른 내공을 기르시는 것도 좋아보입니다. (제가 준비할 시절만 해도 under 400이라 저는 다 풀고 가기 신공을 했었는데요, 이젠 700개라 이건 뭐 고시도 아니고 하루에 하나씩 해도 2년 걸리겠네요. 300 넘으시면 리트코드는 하산하시는게 맞는 듯 하네요)
너무 글이 좀 길었지만, 지나가는 하나의 two cents 라고 생각해 주세요.
대작이네요 대작..
이런 꿀팁을 직접 주신다니...
이대로 전공 준비하고, 그리고 같이 일하고 싶은 사람의 모습으로 보이면
만사 okay라고 확신합니다. ㅋㅋㅋ...
위에 누가 말씀해주셨던 것처럼.. 진짜 경력직 뽑지 않는 이상, 같이 일하고 싶은 사람처럼 보이는것(우리 회사 같은 느낌)은 한국 회사 취업에도 중요합니다.
딱 이야기하는거 보면 바로 알죠, 어? 이미 우리 회사 사람 같다.
아니면 이 친구는 우리 회사 적응 잘 못하겠다..
저도 배우고 갑니다 ㄷㄷㄷㄷ
우와 감사합니다~~~
와.. .학부에서 Suffix Array, Fenwick Tree, KMP 이런 알고리즘을 배우나요? 좋은 정보 감사합니다...
KMP 는 아주 간단하게 배우고 끝냈습니다.
저희는 upper level algorithm 코스에서 KMP나 Floyd-Warshall 등 배웠습니다.
저 학부 다녔을때, KMP 는 Snap이나 Dropbox 같은 곳 제외하고 intern이나 University grad 포지션에서 잘 안낸다고 해서 이거 리뷰를 잘 안했습니다.
지금은 이거 잘 기억도 안납니다ㅠ
어머, 밥 안사먹어도 되서 좋은 쥐모사에 다니시는군요 ㅇㅅㅇ 친하게 지내 보아요
저도 공부 좀 해야 하는데 나날이 게을러져서 큰일입니다 ㅜㅜ
저도 공부법을 줄줄히 늘어놓은 것이라, Heap을 깜빡했네요.
Heap 중요하다는데, Heap은 Heapify / Heapsort 이 부분 계속 영상보고 이해 -> 암기를 계속 반복해서 머리에 익혀야 합니까?
어떤때에 Heap을 쓸지가 아직도 이해가 안갑니다. Array나 Bucket sort 등으로 대신 data 를 저장을 해서, Heap을 잘 쓰지 않습니다.
Sets & Maps에서 HashSet / HashMap을 말하는 것입니다. 이와 관련된 문제 나올때, Key와 Value 저장해서 뽑아쓸 때 이거 이용하거나, 아니면 Array이용한 Hash 방법으로 써서 최대한 O(n) 만드는 것을 목표로 풉니다. NavigableSet 은 Concurrent Programming 배울때 대충 넘어갔는데, 다시 꼭 배워놓겠습니다.
그리고, 내공 9갑자의 코딩이라면, leetcode 디스커션 보드에서 Most voted 한 코드 말씀하시는 겁니까??
저희는 Knight Tour 포함한 Maze 등에 써먹는 Backtracking을 먼저 배우고, KMP / Floyd Warshall 등을 배웠습니다. 저랑 제 친구들은 entry level 준비할때, KMP / Floyd 잘 안나온다고 시간 없다고 스킵하고 다른 토픽(DS) 위주로 공부했습니다.
솔직히, 어려운 알고리즘 문제를 내게되면, 1문제를 45분 안에 잘 끝내기도 어렵다면서 Python으로 푸는게 대세인데, Java 로 한다고 하면 문제를 약간 쉽게 낸다고 하는 것을 잘 몰랐습니다.
Java Concurrency in Practice 이 책.. 사실 제 Concurrent programming 교과서에요! 이 책 첫 단원만 보다가 그냥 슬라이드로 봤지만, 코스 때만 보고, 인터뷰나 Thread 복습할때는 안봤습니다.
https://www.quora.com/How-can-I-get-a-job-at-Facebook-or-Google-in-6-months-I-need-a-concise-work-plan-to-build-a-good-enough-skill-set-Should-I-join-some-other-start-up-or-build-my-own-projects-start-up-Should-I-just-focus-on-practicing-data-structures-and-algorithms
Elements of Programming Interview in Java 이 책 위 링크 친구한테 소개받고, 저도 따라서 산거에요.
애들 위와 같은 방법으로 구글 인터뷰 4주만에 준비하는 법 도전하다가 위 책 문제의 test cases 가 제 맥에 잘 안돌아가서 포기했어요ㅠㅠ
CTCI..
너무 유명한 책이지만, 테스트를 하는데 있어서 Leetcode가 훨씬 효율적이라, 미디엄보다가 짱박았어요..
감사합니다. 6개월 안에, 인터뷰 마스터를 꼭 해야되는 입장인데, 귀한 조언 주셔서 감사합니다.
내공 높은 코딩이라면, Java Collections Framework도 예가 될 수 있겠네요. 하나하나 실제 ArrayList는 어떻게 구현되어 있는지, LinkedList는 어떻게 구현되는지 읽는 겁니다. 읽다보면, 평소에 전혀 궁금하지 않았던 것들, 예를 들면 LinkedList도 List니깐 자바가 소팅을 시켜주는데, 잠깐만 링크드 리스트인데 nlong에 되나? 이런거, 즉 다시 말씀드리자면 평소에 그냥 넘어갈 것들, 거기 코멘트로 친히 디벨러퍼가 어떻게 해결했다 다 써놨습니다. 이런거 읽다보면 내부의 로직을 알게 되죠. 이게 본인은 모르는데 대화하다가 인터뷰어가 캐치하게 됩니다. 그러면 여기서 인터뷰어는 이 지원자는 학교 숙제를 넘어서 무언가를 하는 애구라라는걸 바로 캐치합니다.
또 예를 들자면, 해쉬맵에서 hashcode 다음에 equals을 어떻게 적용하는지 또 친히 써놨습니다. 이걸 읽고나면 Goldman Sachs 의 예전 인터뷰 문제였던 hashCode는 항상 값은 값을, 그리고 equals는 항상 false를 리턴하는 애를 계속 집어 넣으면 어떻게 될까라는 문제 같은거 그냥 1초만에 '자신' 있게 대답하죠. 보통 틀린 사람들은, 참 지엽적인거 물어본다라고 생각한 문제들, 알고보면 인터뷰어가 일관되게 물어보는 것은 앞의 예와도 같습니다.
자네는 학교 숙제만 하나 VS 아니면 더 공부를 하나?
즉 마모식으로 말씀드리면 자네는 마모님이 추천한 카드만 신청하나 VS 아니면 따로 카드를 알아보나? 입니다.
전자면 beyond 마모가 아니므로, 마모님께 돈을 주고 컨설팅을 받지 후자의 인물을 뽑을 필요가 없습니다. 실제로도 비슷하겠죠.
사실, Java Collections Framework에 있는 API 하나하나가 어떻게 구현이 되어있는지에 대한 것들을 그냥 지나치기가 쉬운 것 같습니다.
그 API들을 진짜 James Gosling이 직접 구현을 하나하나 했는지 모르지만, 우리가 계속 쓰는 것들의 뼈대가 중요하다는 것을 깨달았습니다.
교수 입장에서는, 다른 개념 제대로 가르칠 것이 너무 많은데, 무수한 API 중에서 몇 개 뽑아다가 API가 어떻게 구현되어 있는지 일일히 설명할 시간 없다는 것도 이해가 가는 것 같습니다.
저희 같은 경우들도 프로젝트 빨리 끝내고 좋은 점수 받기 위해서, 간결하고 좋은 API 막 뽑아다가 쓰고 끝나지만, 어떻게 구현되어있는지에 대해 깊게 호기심을 갖고 공부해보고 그러지는 않았던 것 같습니다.
해쉬맵의 hashcode 같은 경우도 간과하기 쉬운 것 같습니다. 많은 분들이 큰 코드 문제를 짧은 시간에 효율적으로 풀기 위해서 map 내의 function 하나에 그렇게 깊게 생각할 겨를이 없어하는 것 같습니다.
꿀팁 감사합니다!!
제가 자바는 잘 몰라서 그러는데 혹시 파이썬은 어떻게 생각하시나요? 아직 학생이라 요즘 인턴 인터뷰 준비 중인데 자바를 따로 배워둬야 할 정도로 파이썬과 큰 차이가 있을까요? 곧 G사랑 백투백으로 폰 인터뷰도 있는데 걱정이네요..
저도 궁금하네요. 전에 인터뷰 보다가 스트링 관련 문제가 있었는데 자바로 하려니까 substring에 StringTokenizer에... 너무 wordy 해져서 메소드 이름 적다가 끝났어요. 이런 경우는 파이썬이 더 낫지 않나요?
Python의 inbuilt function으로 너무 짧게(1-3줄?) 끝날 것 같은 문제들은 Python 안쓰는게 낫다고 알고 있어요.
차라리 자바를 써서, 어떠한 로직 쓰는지 설명하고 디버그하는 과정을 잘 보여야한다고 알고 있어요.
Leetcode medium 수준의, Best case 가 O(n^2)인 수준의 문제같이 복잡한 코딩 문제 같은 경우는, Python으로 좀 간결하게 코드써서,
로직을 보여주고 마지막에 테스트하는데 시간을 아끼는 것도 좋을 것이라고 생각해요.
남의 글에 뭍어서 질문글 써서 죄송합니다. 서치하다가 이게 나와서 여기가 딱이다 싶어서요.
자바는 자바스크립트 아니고 자바이겠지요?
FAANG 으로 인터뷰 준비를 갑자기 해야 하는데요.
Linkedin 으로 연락 오고 아무 준비 없이 1차 인터뷰에 너무 가볍게 시작했다가 낭패 볼뻔 하다가 겨우 턱걸이 한것 같아요.
2/3 차는 코딩 인터뷰라고 하는데요.
1. 지금 회사 일이 바빠서 준비 시간을 넉넉히 달라고 하니 문제 없다 하는데 몇달 이후로 잡아도 될까요?
2. 저는 perl 로 준비하려고 하는데 javascript 는 조금 해도 java 는 맹탕인데요. Python 으로 준비하는게 나을까 싶기도 하고, 아예 C/C++ 로 하는게 나을지.. 어느쪽이 난이도가 제일 쉬울까요?
3. 학교 졸업한지가 꽤 되어서 새로운 DS 에 약한데요. 요즘 hot 한 DS 나 algorithm 이 뭐가 있을까요? 오늘 대충 나온 건 hash, heap, queue, stack, linked list, bfs, dfs, tree depth, O(n) 이런 전통적인 것들이었는데 코딩 인터뷰에는 새로운 DS 를 알아야 할것 같아요.
4. 아무리 아이디어 이리 저리 내고 하려는 의지를 보여도 코드가 주어진 시간안에 안나오면 꽝이겠죠?
인터뷰어는 hacking ** 사이트를 참조해서 준비하라 하던데요. 이런 인터뷰도 한지가 꽤 되어서 새로 시작해야 하나 말아야 하나 싶네요.
일단 시간 세이브할겸, 질문 던져 놓고 더 찾아 보겠습니다.
1. 저는 처음 연락온게 7-8월인데 온사이트는 2월에 했어요.
2. Perl은 요새 쓰는데가 거의 없을텐데요. 인터뷰어들이 모를 가능성이 높아요. 그 job description에 언어 얘기 없나요? 전반적으로 자바/python 이 가장 많이 쓰이고요. C++로 인터뷰 보는 사람도 드물다고 하더라고요.
그리고 언어 무관이라고 하는데 인터뷰 들어올 만한 사람들이 주로 쓰는 언어로 봐야 좀 서로 이해하는 데 오버헤드가 적어요.
3: leetcode.com 가셔서 유료결제 하시고 prepping 해당회사 인터뷰 한번 보시고 회사이름으로 검색하셔서 frequency순으로 정렬하세요. 제 경험상 자주 나오는 문제 위주로 하셔도 한 반정도는 완벽하게 똑같은 문제가 나오고요. 나머지 문제도 비슷한 문제가 나옵니다.
4. 힌트 주고 하긴 하는데요. 요새 다들 잘 푸는 느낌이라서...
요즘 회사가 너무 바빠서 이직 생각도 안하고 있었는데 물 들어 올때 배젓는다고 연락이 온김에 인터뷰 해볼까 했더니 부담이 되네요. 이제 바쁜 일중 몇개 털어서 다시 준비해봐야겠어요. 상세한 팁 감사합니다.
Recursion 은 코드를 단순화하기 위해서 쓰는 거라고 생각하면 쉬워요..... 마지막 ending condition 하나만 funcion 앞부분에 지정해두고 같은 내용의 function을 argument를 바꾸어서 계속 돌리는 거에요...
리커션을 그렇게 저도 단순화하려 하지만, 리커션이 여러개을 이용한다던가, helper function을 길게 만들었을때, 언제 recursion 을 끊어야할지가 헷갈리기도 합니다.
단순화해서 생각하면, backtrack 할때, 리커션을 끊는 부분에서(loop을 끊는데에 비유) 실수하는데, 이러한 문제점에 대해서는 어떻게 생각합니까?
저같은 경우 뭐든지 단순화해서 이해하면 응용문제도 쉽게 풀수 있더라구요.
위에서 말했듯이 recusion의 경우 함수 시작부분에 ending condition을 정해놓는 경우가 대부분이에요.
예를 들어 어떤 tree의 height를 구하는 문제를 풀려고 한다면, int getHeight(Node n) 정도로 정의할 수 있고, 이건 n 노드를 root로 하는 subtree의 height를 구하는 것을 목표로 삼으면
1. ending condition: Leaf node 이면 더이상 recusion이 필요없으니 leaf node인 경우 바로 return 해주고
2. recusion은 node n 의 each child node c를 기준으로 getHeight(c)를 돌리면 되요.
3. 그리고 child node가 있으면 height이 하나 늘어나니까 getHeight(c)값에 1를 더해서 return 하면 되죠
다시 말해 어떤 부분의 code가 중복되는지 먼저 파악한다음 ending condition이 무엇인지 생각해보고 그 틀에 맞추어보려 노력하면 얼추 되더군요.. dynamic programming의 경우에는 계산식이 3-4가지라서 if문이 몇개 더 들어가지긴 하지만 대부분의 경우 큰 틀은 이거랑 비슷할 거에요...
제가 인터뷰할때 즐겨내던 recursion문제가 있는데 stack reverse 혹은 stack sort 입니다. 추가 data structure를 쓰지 않고요. 그럼 stack frame을 사용할 수 밖에 없는데 당연히 recursion 밖에 해결방법이 없고, 두개의 다른 recursive function의 정의되어야 합니다.
제 생각에 recursion의 핵심은 큰 문제를 작은 문제로 분해/표현하는 부분인 것 같습니다. 예로 드린 stack reverse 문제를 보자면, f(n)을 f(n-1)으로 표현할 수 있게 되는 순간 문제는 다 풀리게 되는 것 처럼요. 다른 예로는 merge sort: f(n) = 2*f(n/2) + g(n/2), 또는 recursion의 기본인 fibonacci: f(n) = f(n-1)+f(n-2) 도 있고요.
Recursion문제는 f(n)을 더 작은 차수의 문제로 표현하는 능력을 보는 데 의미가 하나 있구요. 사실 보통 recursion문제는 거기서 끝나지 않죠. Tail-recursive를 이해하는지 보기위해 iterative로 해결하라고 한다든지, 조금 더 나아가서는 time complexity를 구하라고 합니다. Recursion의 time complexity는 문제에 따라 꽤나 복잡해질 수 있는데 arithmetic/geometric progression 으로 해결되거나 아니면 master theorem(method) 으로 구해지기도 합니다. GFG에 보시면 Analysis of Algorithm 이라는 시리즈가 있는데 function/loop/recursion의 기초부터 tail-recursion, master theorem까지 갑니다. 이정도 완벽히 이해하시고 나서 recursion 문제를 집중적으로 좀 더 보시면 어떨까 합니다.
bfs보다 dfs로 접근하시라는 비유를 들면 어떨까요. 방대한 분야를 조금씩 다양하게 보시는 것 보다는 한 분야씩 깊이있게 핵심까지 완벽하게 master하면서 가시는 것이 long term으로도 이 분야에 자신감을 갖게 해드리지 않을까 싶은 생각이 듭니다. 이건 비단 인터뷰 공부에만 해당되는 건 아닌 것 같아요.
무슨 이야기인지 모르겠습니다만, 시간내어 귀한 답변 주신 분들 다들 감사드립니다. 꾸벅.
+1
오, 제가 Evan 님께 쓴소리를 아랫글에서 했었는데 그럴 필요가 없었군요....저보다 코딩 준비를 훨씬 철저하게 잘하고 계시네요. 전 코딩이 싫어서 지금까지 준비 안하고 버텨왔는데 이제 졸업 얼마 안 남은 (hopefully) 상황에서 테크쪽 회사 들어갈라고 보니까 코딩 엄청 물어보더라구요 ㅠ 슬슬 하고 있는데 내가 왜 이걸 해야 하나 회의감이 물 밀듯이 밀려옵니다. ㅠ 코딩은 제가 훨씬 못하기 때문에 조언 드릴께 없고 저도 덕분에 이 글 스크랩 해놓고 많이 배워야 하겠습니다.
아, 아니에요ㅠㅠㅠ 감사합니다..
코딩 인터뷰는 그 동안 박사과정 동안 논리력 build 정말 잘해오셨다면, 금방 배우실 수 있을거에요.
엄청난 논리력으로 무장했다는 가정하에, GeeksforGeeks 나 CLRS로 개념정리 다 해놓으면, Elements of Programming in Java 로 4주만에(혹은 몇개월만) 구글 인터뷰 준비할 수 있다고 알고 있어요. CS전공 아닌데, 그렇게해서 간 친구들도 좀 봤어요.
저도 들은게, 개념 양 많아서 공부해도 자꾸 까먹기도 하고 오퍼 뒤 industry based programming 할때 잘 안쓰니까, 이거 시간 충만할때, 짧은 시간에 정말 빡쎄게 준비해서, 원하는 곳 들어가라고 하더라고요.
시간 있을 때 집중적으로 투자해서 하라는 말이 이해가 갑니다. 이거 정말 연구에는 별로 도움이 되지 않는 것이거든요. 시간낭비하고 있는게 아닌가 자꾸 생각이 드네요 ㅎㅎ 지금도 leetcode로 문제 풀고 있었네요.
흠.... 저의 말도 안되는 실력으로 보자면, 이건 기준이 인더스트리 마다 참 다르다는 생각이 듭니다.
아마도 FANG 쯤 되는 곳들은 leecode니 이런 것들을 봐야 하는지 모르겠지만,
은행 쪽은 코딩 그렇게 안봐요. 인터뷰 들어가서 직접 코딩 시켜본건 linked list 한번 만들어 봐 정도? 오히려 코딩을 보고 싶으면, 미리 onsite 오기 전에 github로 프로젝트 하나 넣어 두고, 어떻게 봐꿔봐라 혹은 에러 있는거 넣어 놓고, 에러없어 작동하도록 해라 정도?
기존의 앨고리듬을 코딩으로 짜는거야, 구글 해보면 다 나오는데, 그걸 직접 코딩을 해봐라 시키는 건 좀 non sense 아닌가 싶기도 하구요 (제생각)
대신에 언제 어떻게 각 앨고리듬을 써야 하는지 왜 그걸 써야 하는지 등의 각 앨고리듬별 장단점 등을 물어보긴 하죠.
기본적인 컨셉을 얼마나 잘 이해 하고 있는지, 그리고 그 컨셉을 얼마나 잘 적용하는지, 설명 할 수 있는지를 주로 봅니다.
예를 들면 디자인 패턴 같은 경우 언제 어떻게 써봤나 혹은 어떻게 써야 하는지
시스템이나 object 디자인을 어떻게 해야 하고 왜 그렇게 했느냐 등을 물어보지.
직접 코딩을 해보라 하지 않지요.
즉, high level을 보고 사람의 능력을 봐요. 사실 은행에서는 그정도로 coding geek이 필요 하지 않아서요.
차라리 sql query 물어보죠. ㅋㅋㅋ
아... 파이떤의 경우에는 간단한 애널리시스를 코딩 해 보라고 내본적은 있습니다. 상대적으로 python 코드가 간단해서요.
그런데 사실 이건 파이떤 코딩을 봤다기 보다는 어떤 패키지를 써서 애널리시스를 어떻게 하는지 보기 위함이 더 컸어요.
사실, 은행 쪽은 비자 안해주는 곳들이 대다수라고 알고 있어요.
Bloomberg 제외하고, CS 학부출신 Software Engineer 한테 비자랑 영주권 준다고 하는 곳들 못 봤어요.
동부 은행권들에서 커리어페어나 Tech Talk 정말 많이 들어오는데, 대놓고 영주권 / 시민권만 레쥬메 받는다고 못 박기도해요ㅜㅜ
제 친구들 인터뷰 경험들은 바로, National defense / 정부 관련, 은행권들에서 SDE 뽑을때, 온사이트에서 프로젝트에 대한거 물어보면 과거 프로젝트 줄줄줄 잘 설명하면 붙는다고 그러더라고요...
컬쳐핏이랑 성격에 비중을 좀 더 두는 듯 하더라고요.
그래서, 신분문제 있는 저같은 경우는, SDE 자리 지원할때, 대충 Defense / Aero / Bio / Satellite / Government related (대다수 버지니아디씨멜랜드 회사들) / Bank & Consulting related 제외해버리니까, 어디 주로 지원해야될지 대략 각이 잡혀요.
위와 같은 곳들 온라인 application 이나 레퍼럴로 폰 / 온사이트 인터뷰 가면, 신분으로 갈라버리는데, 제외하고 다른 곳의 인터뷰 준비하는게 더 효율적인 것 같아요.
비교적 최근에 코딩인터뷰 준비한 사람으로서 짧은 조언 몇가지 첨부 하자면요..
- 실전 연습이 굉장히 중요합니다. 반드시 시간 재고 문제 푸는 연습하시고 최소 일주일에 한번은 pramp.com 통해서 mock interview를 하시는걸 추천합니다. 또 문제를 풀면서 혼자서 하는 생각을 계속 말로 표현을 하는 연습을 하셔야 합니다. 그냥 보드에다가 답만 써 내려가고 설명을 못하면 정답을 맞췄더라도 좋은 점수를 받기는 어려운것 같습니다.
- 다른건 몰라도 시간을 아끼기 위해선 코드 써내려 가는 시간이 적은 python 이 압도적으로 유리합니다. 물론 익숙하시지 않다면 드냥 가장 익숙하신 언어로 마스터 해서 인터뷰 보시는게 좋습니다.
- 암기는 반드시 “시간압축”을 위해서만 사용해야 합니다. 즉, 어떤 문제가 시간이 충분히 주어진다면 풀 수 있지만 구현하는 데 있어서약간 햇갈리는 부분이 있어서 귀납적으로 검증을 하는 부분이 있다면 그 루틴 부분만 딱 외워서 시간을 압축하는 식으로 연습하시먄 됩니다. 통으로 어떤 알고리즘을 외우는건 문제를 풀면 계속 비틀어서 다시 challenge 를 해오는 인터뷰 특성 때문에 중간에 생각이 꼬여버릴 위험이 있는것 갔습니다.
저도 인터뷰 준비중인데 많은분들의 댓글에서 조언을 많이 얻어가네요 감사합니다 ㅎㅎ
확실히 비자 스폰서해주는 회사들이 예전보다 많이 줄어들어서 취업이 힘드네요 ㅠ
흔히 Leetcode를 공부하다보면, discussion board에서 주로 자기들 방식대로 푼 정답을 올려놓지, 순수하게 힌트에 대한 질답을 올려놓는게 아니라서요. (특히 Easy ~ medium)
인터뷰때는 하도 안풀리다보면, 힌트 정도는 물어볼 수 있잖아요.
그런데, 릿코드 보드에서는 순수하게 힌트와 질답을 올려놓는 공간이 아니기도하고, 힌트만을 찾아보기는 힘드니까, 한줄봐서 힌트를 찾아내고 approach 어떻게 해야될지 감을 얻어서 코드 쓰고, 다음줄 보고, 쓰는 식으로 해왔던 것 같아요.
내 생각을 표현하는 방법이 코딩인데, 한 줄씩 봐가면서, 힌트 얻고하는건 그렇게 좋지 않는 것에 대해 배웠습니다.
어느 일정 시간이 지나도 이해를 못하거나, 답이 도저히 안나오면 남의 코드를 참고하고 다시 되돌아가야 하지만, 그 인내심이 갈수록 부족해져서, 일정 시간 전에 도저히 생각이 안나도, 바로 남의 코드를 참조해버리는 잘못된 습관이 굳혀진 것 같습니다.
사실 학부때, 성적때문에, 프로젝트 제때 끝내놓아야한다는 부담감에, 인내심이 많이 사라져서 순전히 제 로직으로 고민해보는 시간이 짧아지고, 남의 코드를 참조해버리는 습관이 생겨버린 것 같습니다.
저도 외우는 것에 대해서 탐탁치 않게 여겨왔습니다만, 제한된 시간에 할 것은 많은데, 계속 이해 안되는 것 계속 붙잡고 있느니 일단 외워버린 다음에, 그거 나중에 나올때 다시보면 이해가겠지 이런 생각으로 공부해온 것 같습니다. -> 다른 과목 공부해오던 것 알고리즘 공부법에 적용 해왔는데 이게 맞는지 헷갈리기도 합니다..
도저히 이해가 안가고 시간이 없을때 외우는 것도 좋은 방법이라고 할 수 있습니까?
가장 중요한 고민은,
양치기(많은 leetcode 문제풀면서 문제당 1-2가지 풀이과정만 철저히 습득) VS 질치기(적은 유명한 문제들 뽑아서 4-5가지 풀이과정 철저한 습득 뒤 텀을 두고 반복해서 풀기) 입니다.
저도 수능 수학공부 했었을때, 1.5 년만에 내신 7등급 -> 수능 수학 만점, 전과목 몇개 틀린 사람의 비결을 보고 성적 향상을 많이 하던 경험이 있어요.
수능 수학 25번 / 이과 논술 수학문제같이 어려운 같은 문제들이 각각 4-5가지 서로 다른 풀이과정을 모두 분석해서, 적은 수의 어려운 문제들의 풀이과정을 깊게 공부해서 다양한 각도로 생각해보는 능력을 길러야한다는 것입니다.
하지만, 졸업하고나서, top 회사의 interviewer 친구랑 엔지니어들한테 들은 조언은 양치기를 하라고 그러더라고요.
"올림피아드나 시험치는 것하고 다르게 인터뷰에서는 시험 기출문제의 다양한 솔루션들을 반복해서 연습을 해온 Practitioner 를 원하지 않는다. 정말 새로운 문제이나 challenge에서 candidate 만의 창의적, 효율적인 코드를 짤 수 있는가의 능력을 보는 것이다. 따라서, Leetcode나 hackerrank에서 나온 문제를 짧은 텀두고 반복보다는 최대한 많은 양을 풀어내어, 전에 경험 못했던 새로운 것을 풀어내는데 집중해라." 라고 하는데, 이게 정말 맞는지 의문이 가기도 합니다.
알고리즘 인터뷰 마스터하는데 있어서 어느 쪽을 좀 더 추천합니까?
자잘한 skill이나 스타일들은 사람마다 다 다릅니다. 하지만, 인터뷰나 각 시험이 원하는 공통적이고 본질적인 방법에는 누구나 다 끼워맞춰야한다고 생각합니다. 최상위권들은 그 본질적인 방법을 미리 알아내어서 훈련을 해온 분들이고요.
인터뷰어들간에 의견의 차이가 있을 수 있으니까 어디까지나 참고로 하셨으면 좋겠습니다.
도저히 이해가 안 가고 시간이 없을 때 외우기 시작하면 성적은 어느 정도 받을 수 있겠습니다. 이게 나쁜 방법인지 아닌지는 누가 얘기해 줄 수 있는건 아닌것 같고 본인의 철학이라고 생각해요. 시험을 본 이후에 회사에서 같은 경우는 외운 것 보다는 잘 이해한 지식의 가치가 훨씬 더 높은데. 시험 보고 나서 어떻게 했는지 그 점이 중요하겠습니다.
전에 경험하거나 보지 못했던 새로운 것을 풀어낼려면 기본적인 알고리즘에 대한 철저한 이해가 있어야 하지 않을까요? 기본적인 알고리즘에 대한 철저한 이해를 어떻게 할 지가 핵심이라고 생각이 되는데요. 물론 다른 분들의 경우는 그렇게까지 깊이 공부할 필요가 없다 이렇게 생각 하실 수도 있는데 어디까지나 제 의견은 이렇고요.
저는 Evan님에게 하나에 대한 이해를 높이고 다음을 넘어가는 방법을 추천 드렸는데요. 이건 Evan님의 경우는 암기를 위주로 하셨다니까 저는 위와 같은 얘기를 한 것 이고요. 지금 단계에서 교과서에 나오지 않는 어떤 알고리즘을 더 안다 혹은 모른다가 인터뷰에 큰 도움이 되지가 않을 것 같아서 그랬습니다.
인터뷰에 대해 구체적으로 얘기를 해보자면 문제를 접근할때 top candidate이라면 이 문제는 shortest path를 이용하면 풀 수 있다 혹은 recursion을 쓰면 되겠다 싶은 idea가 생기면 그 다음에 그걸 어떤식으로 전개 할지는 사실상 자동적으로 되는 거거든요. 어려운 점은 이 문제를 어떻게 풀지 idea를 얻는 부분이고요. 인터뷰 연습으로 얻을 수 있는건 자동으로 전개를 해나가는 방법 정도라고 생각이 들어요. idea를 떠올리는건 누가 가르쳐주거나 단기간의 연습으로 되는 문제는 아니라고 생각하거든요.
양이냐 질이냐는 제가 보기엔 그냥 본인의 스타일 문제 인 것 같습니다. 많은 양의 문제를 풀다 보면 결과적으로 각각의 알고리즘에 대한 이해도가 높아져서 질이 높아 질수도 있고, 반대로 하나의 알고리즘을 다양하게 접근해나가면서 마스터 한 뒤 다음 알고리즘으로 넘어가는 식으로 지식의 양을 넓혀가는 방식도 마찬가지로 가능할 것 같습니다. Top tech company를 목표로 한다면 학교에서 배우는 정도는 완전히 마스터 해야 되니까 양이냐 질이냐 따질 문제는 아닌 것 같습니다. 본인 공부 스타일에 맞춰 둘 다 해야겠죠.
흠..저는 Amazon에서 engineer로 일하고 있고 종종 인터뷰도 보러가는데요..
두루뭉실하게 말하자면 저는 보통 '똘똘한' 사람을 선호해요.
보통 leetcode같은거 달달 외우는 사람들, 처음에 딱 문제 내어줬을때 잘 푸는데 거기서 한 걸음 더 들어가면 헤매는 경우가 대부분이예요. (scaling은 어떻게 처리할건지, peak traffic을 어떻게 할건지, distributed architecture로는 어떻게 바꾸면 좋을지 등..)
똘똘한 사람들은 (비록 답이 완벽하지 않을지라도) 인터뷰어와 토론을 통해 어떻게 하면 더 좋은 solution을 낼 수 있을지 고민하는 경우가 많죠.
가끔은 인터뷰어도 답이 없는 문제를 들고가는 경우도 많구요, 그럴땐 이 사람이 커뮤니케이션을 어떻게 하는지 주어진 상황을 어떻게 활용하는지 같은게 더 중요한거죠.
꼭 뭔가를 '마스터' 하겠다는 생각보다는(할 수도 없을 뿐더러)..사고력이 유연한게 훨씬 도움이 되는 것 같아요.
갠적으로 CS는 외운다고 되는 분야가 아니라고 생각해요.
내가 인터뷰어면 어떤 사람을 뽑고싶을까(=같이 일하고 싶을까) 잘 생각해 보심이..
혹시나 만약에 답이 없는 문제에 부딪쳤을때, 인터뷰어가 딱히 인터뷰 시간 내에, follow-up 문제를 갈 수가 있느냐 없느냐에 포커스를 두지 않는다는 말씀이신가요? 첫 번째 문제를 클리어하고 follow-up 문제가는 부분에 대해서 좀 더 설명해 주시겠습니까?
FAG 에서 일했으며 (아직도 일하고 있으며) 1주일에 3명은 인터뷰 보고 주로 Senior Engineer 와 종종 Entry Engineering Manager 레벨도 봅니다.
저도 처음 인터뷰이일때 그랬지만 많은 분들이 생각하기에 Coding 위주의 문제로 어떻게 실력있는 사람이냐는 걸 아냐고 하는데 인터뷰를 많이 보다 보면 처음 5분 정도만 봐도 이사람이 되겠다 안 되겠다 보입니다. 그 말인 즉슨 뭐 수수께끼 같은 알고리즘 문제를 다 푸는걸 보겠다는게 아닙니다. 수많은 인터뷰어 패널들과 피드백을 놔눠봤는데 공통점은 하나입니다. 그 사람이랑 같이 일하겠느냐 입니다. 그럼 FAANG 같은 탑 테크 회사들에 다니는 사람들은 어떤 사람들이랑 일하고 싶을까요? 그냥 두리뭉실하게 하나 맡겨 놓으면 알아서 user requirement 분석부터 시스템 디자인, 프로젝트 리드, 솔루션 딜리버리, 최적화, 유저 테스팅, 트라블슈팅을 전반적으로 할줄 아는사람을 뽑겠죠. 심지어 쥬니어 레벨도 어느 정도 깊이 있는 시스템 디자인을 할 줄 아는 사람을 원합니다. 그런 것들을 Coding 문제로 어떻게 아느냐 하면 이 사람이 어떻게 풀어 나가는가 보면 됩니다. 본문에 있는 누군가의 조언에 전적으로 동의합니다. 답만 달달 외우면 아는 문제 나오면 땡잡았다 하고 아무 말 없이 술술 풀어나가겠죠. 그럼 땡입니다. 왜냐하면 앞서 말씀드린 같이 일하고 싶은 사람의 능력 중 제대로 뭐하나 보여주는 것이 없기 때문이죠. 심지어 인터뷰어가 끼어들 틈도 안 주기때문에 collaboration 능력도 못 봅니다. 그래서 대부분 처음 5분만에 어느 정도 윤곽이 나온다는 거죠.
실제로 gift exchange, road conflict prediction, car service center scheduling 과 같은 듣도 보도 못한 알고리즘 문제를 척척 다 푸는 코딩 박사 뽑아놨더니 프로젝트 3~4개월 동안 디자인만 하고 진척이 없어서 도태한 사람들 꽤 있습니다. 일단 들어가기만 하는게 다는 아니잖아요?
제가 여태까지 OK 한 비율은 10% 정도입니다. 10명 보면 1명은 OK 인거죠. 그 중에 전체 panel 의 피드백을 통과해서 offer 까지 가는 비율은 거기서 또 10프로 정도인 것 같습니다. 그렇게 offer 를 받은 사람들의 공통점이 꼭 있습니다.
1. 어떤 문제가 나오던지 일관성이 있습니다. algorithm, system design, project leading 모두 가장 기본적으로 처음해야 하는 것은 user requirement analysis 입니다. 단순히 알고리즘 구현하는 문제에서 어떻게 그렇게 하느냐 하면 평소 복잡한 시스템을 구현해 본 적이 없거나 프로젝트 리드를 제대로 해본 적이 없을 가능성이 큽니다. 최소 입력 포맷이나 사이즈라던지 어떤 결과를 원하냐는지에 대한 것은 기본 중의 기본 질문이죠.
2. 그 다음은 무엇이냐, 이제 원하는 걸 알았으니 당연히 코딩 들어가야겠죠? 그럼 땡입니다. 당연히 다음은 나의 플랜을 인터뷰어에게 말해 주는 것입니다. 팀원들과 active 하게 같이 일해본 사람들은 이게 몸에 베어 있습니다. 내가 아무리 잘하면 뭐합니까? 인터뷰어가 못 알아들으면 꽝이죠. 가장 이상적인 것은 데이터 스트럭쳐 디자인과알고리즘 오버뷰, 구현 방식을 간단하게 인터뷰어와 설명한 다음에 서로 의견을 나누는 것입니다. 인터뷰어가 보고자 하는 것마다 다를 수 있겠지만 많은 인터뷰어들이 플랜이 optimal한 솔루션이 아닐 경우 대부분 더 좋은 방법은 없느냐 라든지 피드백을 줍니다. 그런게 아니더라도 최소한 collaboration 능력 면에서 합격하고 들어가는거죠. 코딩하는 중간중간에도 무엇을 할것인지 인터뷰어에게 계속 알려주는 것이 중요합니다.
3. 이것은 아주 중요한 팁인데 간단한 알고리즘 leetcode easy - medium 정도 되는 것이 아니라면 실력 좋은 후보라도 처음부터 모든 문제를 다 베스트 어프로치로 풀어가는 것은 사실상 불가능합니다. 당연히 중간에 생각하는 시간도 있어야 하죠. 이 때가 중요합니다. 혼자 머릿속으로만 가만히 생각하고 있으면 꽝입니다. 내가 왜 지금 struggle 하고 있는지를 인터뷰에게 알려주는 것이 중요합니다. Challenge 를 어떻게 극복하냐를 보는 것이 중요하고 어려운 algorithm 문제를 내는 것이 대부분 그런 이유입니다. 실제로 일할때도 벽에 부딪힐때가 있을텐데 최소한 왜 부딪혔는지를 아는 사람은 괜찮습니다. 그런 경우를 위해 팀이라는 것이 존재하니깐요. 그런데 최악의 경우는 왜 부딪혔는지도 모를 경우입니다.
4. 요즘 System Design 문제의 비중이 점점 커졌습니다. 요즘 핫한 micro service, distributed system, database partitioning, shared caching, CDN, failover, fault tolerance, multi DC/AZ, API gateway, security, streaming message, micro-batch 등으로 왠만한 web system 이나 data ingestion/ETL system 하나 정도는 디자인할 수 있는 정도는 겸비하셔야 합니다.
5. HashMap, LinkedList, Stack, DFS/BFS, Sorting, BST 같은 1차원적인 문제가 나왔다. 그러면 안타깝지만 이건 그냥 작정하고 이 사람이 코딩 완벽하게 다 하느냐 보겠다는 겁니다. 실제로 그런 문제들은 공부해서라도 숙지해 놓으셔야 합니다. 다른건 몰라도 HashMap과 DFS 는 실제 일하면서도 많이 쓰이는 데이터 스트럭쳐기 때문에 별 생각 없이도 코딩하실 줄 알아야 합니다. 그런 와중에도 1 - 3 번 팁을 잊으시면 안됩니다.
저런걸 다 하는 사람이 있을까 하지만 수십명 중에 1명은 꼭 있습니다. 그리고 FAANG 같은 회사들은 수백통의 이력서가 한 그룹에 들어오고 인터뷰가 생활화 되어 있기 때문에 수십명 중에 한명 뽑힐때까지 느긋하게 기다린다고 생각하시면 되겠습니다. 대부분 봤을때 완전 반대하는 사람이 있지 않는 한 온사이트 패널 6~7 명중 5명 정도가 OK 이고 나머지가 So So 만 하면 합격입니다.
3번에 대한 질문이 있습니다. 사실, 저도 적극적으로 제가 struggle하고 있는 부분에 대해서 설명을 하려는 성격입니다. 인터뷰라는 것은, 자기 자신의 장점을 maximize하고 negative한 부분을 최소한 minimize해서 candidate가 어떻게해서 회사에 기여를 할 것인가에 대해서 증명하는 과정이라고 알고 있습니다. 하지만, 알고리즘을 푸는 과정에서 마침 제 알고리즘이 edge case에 부딪쳐서 완벽하지 않다는 것을 알아챘을때, 어떠한 문제가 있는지에 대해서 적극적으로 표현을 하자니, 제가 좀 negative하게 보이고 힌트를 얻으려고 하는 것 같아서 어떻게 반응을 보여주어야 할지 난감합니다. 특히 technical interview 한창 하는 과정에서, 어떻게하면 negative하게 안보이고, struggle하는 부분이 있어서 도움 요청할때의 팁을 공유해도 되겠습니까?
다른건 모르갰고, 무조건 자바로만 해야 한다는건 반대입니다.
전 매일 자바로만 개발하는데요, 인터뷰 위해서 파이썬 공부했습니다. 자바 배웠던 시간의 1/10도 투자 안했지만 인터뷰 보는데 지장 없었구요, 가장 큰 장점은 시간 절약입니다. 자바로 20줄 나올걸 파이썬으로 10줄도 안나오면 벌써 시간 절반은 줄인겁니다.
이걸로 프로젝트하라 하면 아직 한참 모자르지만, 인터뷰는 무조건 파이썬으로 합니다. leetcode에서 연습하세요. 생각보다 빨리 배우실 수 있으실 거예요.
코딩인터뷰나 tech company hiring에 대해선 1도 모르는 사람입니다..다만 대기업 인터뷰어로 경험은 좀 있는데요, 아직 테크니컬 인터뷰 할 짬은 아니고 또 엔트리레벨이나 인턴 인터뷰를 하다보니 behavioral 인터뷰에 좀더 포커스가 맞춰져있습니다. Evan님 글과 댓글들을 쭈욱 읽어봤는데요, 말투가 뭔가 좀 다른분들보단 aggressive/demanding 하다거나 다르다는 생각이 계속 들어요... 처음엔 혹시 2세이신가?? 했지만 비자랑 언어문제 얘기 읽으니 그건 아니신것 같고... 단순히 인터넷 글이라서, 또는 조바심이나 답답한 마음이 글 분위기에 반영이 되지 않았나 하는 생각도 들지만 혹시나 오프라인에서 영어대화시에도 비슷한 느낌이 아닐까 싶어서 조심스래 댓글 답니다. 사람 말투가지고 이러네 저러네 하고 싶진 않지만 그래도 인터뷰에 도움이 되지 않을까 싶어서요. 제가 하고 싶은 말은 위에 다른 몇몇분들이 말씀해 주셨듯 인터뷰에서는 이사람이 내가 같이 일하고 싶은 사람인가? 이게 참 중요한것 같습니다. 물론 테크니컬 인터뷰 완전 bomb하고 인터뷰어랑 케미 좋았다고 붙는건 아니지만 다른 사람이랑 비슷비슷하거나 좀 떨어져도 뒤집을수 있거든요. 또는 테크니컬 인터뷰 아주 ace해도 뭔가 소셜 스킬에 문제가 많다거나 하면 떨어지기도 합니다. 테크회사들은 좀 다를것 같기는 하지만요.
제가 초반에 했던 인터뷰들은 이사람이 likable한지 파악하는게 다였구요, 어떤 사람은 테크니컬 지식은 좀 부족하지만(인턴이라 뭐..)프렌들리하고 맘에 들어서 추천, 어떤 사람은 테크니컬한데 arrogant한것 같아서 그점을 말하면서 비추천. (이점은 어떤 사람은 자신감으로 봐서 좋게 볼수도 있을것 같은데 저는 싫어하는 성격). 링딘으로 한국계 jok seeker분들께 네트워킹/멘토링 메세지가 오는데 어떤분들은 정말 도와드리고 싶은 마음이 들어서 제 시간 할애하서 도와드리게 되고 어떤분들 메세지는 읽고 답변하고 싶지도 않는 경우가 있습니다.
제가 드리고 싶은 말은 테크니컬 인터뷰 만큼이나 behavioral aspect도 한번 evaluate 해보심이 어떨까싶다는거에요. 성격은 바꿀순 없지만 어느정도는 fake는 가능하기도 하니까요. 저는 말수 적고 음침하고 페씨미스틱한 스타일인데 인터뷰 할때는 말 많고 긍정적이고 밝고 명랑한 사람으로 돌변하거든요-_-;; 노력으로...
와 신입이라 말 꺼내기 조심스러웠는데 저도 사실 딱 이 생각 했어요~ aggressive/demanding. 실제 대화는 어떻게 하시는지 몰라도 아는 사람이 이렇게 글을 보내면 처음 답변은 어찌 해 줄 수 있다 해도 피드백 보면 좀 부담스럽다란 느낌이 들것 같아요^^
정말 일리가 있는 말씀이신 것 같습니다. Behavioral 부분을 정말 개선하려고 노력을 해왔고 끊임없는 피드백과 개선이 중요한 포인트 중 하나라고 생각합니다. 질문을 할때 조금 직설적이고 aggressive한 부분이 있다고는 들어왔습니다. 제 말의 tone 부분에서는 제가 들어봐도 그닥 likable 하지는 않는 것 같습니다. 저도 interviewee로써, 나름 수 많은 인터뷰어들을 접하고 속으로 평가를 하는 것 처럼, tone이라던가, 정말 respectful한 인터뷰어도 있는 것 처럼 그렇지 않고, aggressive하고 stubborn한 엔지니어링 인터뷰어도 있어요. 이것을 과연 짧은 시간 안에 개선을 할 수 있는 부분인가 궁금합니다. 이러한 부분은 짧은 시간 내에 수 많은 behavioral mock interview로 개선이 가능한 부분이라고 생각하십니까?
저도 잘은 모르지만 인생 선배로서 조언 드리자면, 늘 부족하고 겸손한 마음가짐이 우선인 것 같아요. 아무리 인터뷰에서 잘 한다고 해봐야 나보다 훨씬 더 잘난 사람들앞에서 굼뱅이 주름잡는거라서요. 내가 뭘 잘하는지를 보여주는 것도 중요하지만 내가 부족한 부분을 알고 끊임없이 고치려는 그런 자세가 중요하다고 봅니다. 근데 이게 그냥 연습한다고 되는 것 같지는 않고요. 글쎄요. 자기 성찰이라고 해야할까요? 그리고 그런 마음을 갖는게 중요한 것 같아요. Evan님이 열심히 하는 모습은 너무 좋은데요. 자꾸 글에서 "그렇게 하라면 뭘 연습하면 되나요?"라고 직설적으로 말씀하시니 보는 입장에서는 being something보다 showing something에 무게를 두는 것 같아 살짝 안타까워요. 그리고 다른 한가지는 여기 게시판에서 다른 분이 댓글로 말씀을 해주시면 Evan님께서 다시 어떤 본인의 프레임을 잡으시고 시작하시는 것 같아요. 실제 인터뷰에서도 같은 상황이 자주 발생되잖아요. 질문에 대한 답을 본인 주관을 이야기 하는 것도 중요하지만 늘 어느정도의 여지를 줘야 할 것 같아요. 자기 주관이 확실한건 참 좋지만 반대로 아집처럼 보이면 인터뷰어 입장에서는 이 사람은 사고를 바꾸기가 쉽지 않겠구나라고 생각할 여지도 있을 것 같아요.
다른 방법으로 생각해보니, 겸손 + 사고의 유연성에 대해서 강조를 하시는 것 같습니다. 저 자신도 구체적이고 detail함을 추구하다보니까, 저도 모르게 유연한 사고로 자신의 프레임을 잡아나가기 보다는 세세한 답변들로써 개선을 해나가면서, showing something에 무게를 두는 것 같습니다.
일단 tech company 인터뷰가 behavioral이랑 코딩으로 나뉘는지 저는 모르겠지만 굳이 behavioral interview 연습을 하셔야한다고 생각들지는 않습니다. behavioral interview라면 뭐 힘든일 극복하는법, 팀원이랑 문제 생겼을때 어케 해결하는지...등등 묻는건데 이런 질문에 대한 ideal한 답은 사실 인터뷰 많이 보다보면 감이 오기도 하고 준비를 할수도 있구요... 제가 말씀드린 behavioral aspect는 코딩 인터뷰던 behavioral interview던 런치인터뷰이던 상대와 커뮤니케이션할때의 말하는 방법이나 태도등을 개선하면 도움이 되지 않을지...였습니다.
"짧은 시간내에 수많은 mock interview" 보단 honest한 feedback을 줄수 있는 사람과의 인터뷰가 엄청 중요하다고 생각합니다. 사실 이런점에 대해선 피드백 주기가 상대 입장에서 엄청 어렵습니다. 아마 reject받았을때 회사에서 떨어진 이유 피드백 주더라도 이런건 말 안해줄거고 잘 모르는 사람이나 애매하게 가까운 사람이 mock 인터뷰 해줄경우 상대가 디펜시브하게 나오거나 퍼스널 하게 받아드릴까봐 말해주기 힘들것 같습니다. 저도 그래서 첫 댓글 남길때 고민을 좀 했구요... 사람에 따라 단점을 좀 고치거나 인터뷰때만 fake(저처럼)하는게 가능하기도 할텐데 이건 정말 케바케겠죠? likable 하지 않은사람이 짧은시간 노력으로 쉽게 likable이 될수 있다면 얼마나 좋을까요 ㅎㅎ
Honest한 피드백 같은 경우 지도교수한테 받았다는 얘기도 들어봤고 (굳이 mock 인터뷰를 안하더라도 평소 observe한거에서 얘기 가능...) 저같은 경우 학교에서 고용해준 professional career coach가 이것저것 지적해줬습니다 (목소리 톤, 자신감 관련, 단어 사용등등). 아무래도 일반인이 아니고 프로니까 피드백을 주는것에 있어서 거침없었던것 같아요. 아는 사람이 해주는경우 personal 하게 받아들이지 않겠다고 약속하고 뭔가 지적 들었을때 defensive하게 나오거나 excuse 만들지 않으면 가능하기도 한것 같습니다. 제가 작년부터 매니져한테 critical feedback 받아내서 하나하나 개선하려고 노력하고 있는거랑 비슷해요. 워낙 싫은 소리 하는거 싫어하시고 좋은말만 해주는 착한 매니져라 제가 발전이 없더라구요..
여담이지만, 정말 개발자분들이 많으시네요. 모임 가지면 재밌을듯 싶습니다.
댓글 [59]