brunch

You can make anything
by writing

- C.S.Lewis -

by Soohan Ahn Feb 20. 2019

코딩인터뷰 Q&A

Kodeveloper 190214

 2019/02/14 에 저희 회사 Freakout에서 진행된 Kodeveloper 스터디에서 코딩인터뷰에 관해서 발표를 하게 되었습니다. 발표자료는 여기에 공유해 두었습니다.


행사관련 포스팅: https://kodeveloper.com/%EA%B3%A0%EA%B5%B0%EB%B6%84%ED%88%AC%EA%B8%B0/2019/struggle-29/

발표자료: https://www.slideshare.net/SoohanAhn/failing-the-coding-interview


이 인터뷰들에 대한 경험은 추후에 더 자세히 쓰도록 하겠습니다.

이번 포스팅에서는 발표자료에 나와있지 않은, 이 발표 후에 받은 질문들을 정리해서 올려보도록 하겠습니다.


Q1. 코딩테스트 연습툴을 여러가지 썼는데 이유는?

A1.  

 한줄요약: 인터뷰 성격에 따라 플랫폼을 다르게 사용했습니다.


 발표때도 설명을 한 부분이지만, Online coding assesment와 Phone screening / Onsite interview에서 해결해야되는 문제는 조금 성격이 다르다고 느꼈습니다. Online coding assesment 같은 경우는 ACM ICPC, Google Codejam, Facebook Hackercup 등의 대회와 조금 더 비슷한 문제들이 많이 나오기 때문에 이에 대한 준비를 위해서는 Codeforces, Atcoder 등의 플랫폼을 활용하였습니다. 실제 기업에서 진행될 Online assesment의 플랫폼을 사전에 알고 접하는 경우에는 그 플랫폼을 테스트 해보기 위해서 그 플랫폼에서 연습을 해보기도 했습니다.

 그리고 Phone screening부터는 대회에서 나올만한 문제보다는 조금 더 기본기에 기반한 문제라고 생각했습니다. 더 짧은 제한 시간내에 풀어야하는 문제가 보통이기에 문제도 좀 더 직설적이라고 생각했습니다. 그래서 이 단계부터는 Leetcode를 적극적으로 활용했습니다.


Q2. 시스템 디자인 인터뷰 준비는 어찌하는가?

A2.

https://github.com/donnemartin/system-design-primer 를 우선 보았습니다. 그 이후에는 각 문제별로 더 많은 솔루션을 봤습니다. 사실, 알고리즘 문제에 비하여 나올 수 있는 문제가 한정적이기 때문에 그런 자주 나올 수 있는 문제들 위주로 많이 봤습니다.

 그리고 Pramp에서 모의 인터뷰를 하면서, 제가 상대를 인터뷰할때 제가 오히려 잘 모르고 궁금했던 부분들을 질문으로 활용하면서 상대의 답변으로 공부를 하기도 했습니다.


Q3. 한 문제를 푸는데 보통 얼마나 시간을 투자하셨습니까?

A3.

 처음에 공부를 위해서 문제를 풀 때는 솔루션이 15분~20분내에 나오지 않으면, 바로 솔루션을 보고 코딩에 들어갔습니다. 그 이상 시간을 들여서 계속 생각을 해보고 풀면 좋겠지만, 직장생활+육아로 인해 제가 들일 수 있는 시간은 한정되어있기 때문에 생각이 안 날 경우네는 그렇게 긴 시간을 투자하지는 않았습니다.

 다만, 그런 방식으로 공부를 하다보니 머리에 남는게 많지 않았습니다. 그래서 보완책으로 생각한 것이, 솔루션을 보고 푼 문제는 반드시! 관련 문제를 솔루션 없이 푸는 과정을 거쳤습니다. 그 다음 문제도 안 풀리면 솔루션을 또 보고, 세번째 관련 문제를 또 보고.. 그런 방식으로 진행하였고, 조금 더 좋은 효과를 볼 수 있었습니다.

 그 이후에 실제 상황을 생각하며 문제를 풀 때는, 30분내로는 무조건 푼다고 생각하고 풀었습니다. 실제 인터뷰에서는 어려운 문제라면 60분에 한문제면 충분하지만, Leetcode 기준으로 Medium이하의 문제는 30분 내에 풀고 Follow-up 문제까지 받아야 합격권이기에 그런 상황을 가정하고 준비하였습니다.


Q3. Space complexity 계산에서 recursive하게 구현할 시 발생하는 call stack은 포함해야하는가?

A3.

보통은 포함을 안해도 된다고 생각합니다. 포함을 시키지 않은 space complexity로 우선 답변을 하고, recursive하게 구현할 시에 call stack에 따른 비용은 ~~하게 발생할 수 있다 라는 정도로 답변을 하면 괜찮을 것 같습니다.


Q4. 현재 DevOps engineer 포지션에서 일한지 일년정도 된 주니어입니다. 현재 업무와 좀 다른 포지션으로 지원해도 불이익이 없을까요? DevOps 경력이 Software engineer로 지원하는데 있어서 불이익은 없을까요?

A4.

 어려운 질문인데, Job description 에 따라 다를 것 같습니다. Google을 비롯하여 많은 기업들이 'Software engineer'라는 타이틀로 개발자를 모집하고 인터뷰를 진행하는데, 이런 경우에는 보통 General한 엔지니어를 뽑고자 하는 목적이 강하기 때문에 이런 경우는 지원하는데 자체에 큰 불이익은 없고, 인터뷰에서 좋은 결과를 얻으면 괜찮을 것 같습니다.

 다만, 연봉 협상시에는 경력 인정여부에 따라 영향이 있을 수는 있습니다.


A4-1. 기타 다른분들 의견

 주니어 레벨이면 빠른 단계에서 직종 전환을 가져가는게 좋을 것 같습니다. 특정 분야의 경력이 길어지면 나중에는 옮기기 어려울 가능성이 큽니다.


Q5. 인터뷰 준비를 하는데, 특정 프레임워크를 공부하는 것과, 자료규조&알고리즘 쪽을 공부하는 것 중에서 어느 쪽이 더 좋을까요?

A5.

 알고리즘&자료구조를 포함한 전반적인 Computer science와 관련된 기초를 공부하는 것을 강력히 추천드립니다.

 특정 프레임워크에 뛰어난 사람 VS Computer science관련 기초가 튼튼한 사람.

 이 중에서 많은 회사들은 후자를 선호할 가능성이 큽니다. 정말 일이 급한 스타트업 같은 경우에는 전자를 원하는 회사도 있을 수 있습니다. 하지만 많은 회사들은 자신들이 사용하는 프레임워크 및 테크 스텍은 기초가 뛰어난 사람에게는 가르치면 그만이다 라고 생각하는 것 같습니다.

 그리고 후자를 중시하고 공부하는 편이 갈 수 있는 회사 및 포지션도 더 많기 때문에 실제 구직에도 더 유리하리라 생각합니다.



작가의 이전글 中途採用、FreakOut Inc.

매거진 선택

키워드 선택 0 / 3 0
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari
;