<1/16> 말아먹기 전문가

 취업 준비를 시작한 이래로, 오늘 세 번째 면접을 볼 수 있었다. 그리고 의심의 여지 없이 시원하게 말아먹었다. 긴장했다는 변명을 하기 민망할 정도로 너무 답변을 못했다. 일단은 오늘 면접을 돌아보면서 앞으로의 방향성을 다시 생각해보는 시간을 가져보자.

 

 첫 면접은 스타트업, 두 번째 면접은 대기업, 이번 면접은 다시 스타트업 회사였다. 첫 면접은 기술 관련 질문을 많이 물어보셨고, 두 번째 면접에서는 기술 관련 질문은 하나도 없었다. 이번 면접에서는 특이하게 코딩 테스트 코드를 어떻게 개선할 수 있을지를 물어보심에 더해 자료구조, 객체지향, 자바에 대한 기본적인 지식, 팀 프로젝트에서의 역할과 갈등 해결 방법 등에 대해 물어보셨다. 1시간 이상 면접을 진행했고 더 많은 이야기를 나눴던 것 같은데 긴장 상태로 진행하다보니 지금 당장 기억에 남는 것들을 두서없이 적어내릴 것 같다.

 

 면접관 분들은 분위기를 풀어주려고 굉장히 노력해주셨고, 내가 제대로 답변하지 못하는 부분에 있어서도 추가적으로 알려주시면서 면접을 이끌어주셨다. 또한 소중한 면접 기회를 제공해주신 분들이기에 감사한 마음이다. 나만 잘했으면 얼마나 좋았을까?

 

 일단은 기억에 남아있는 대로 주셨던 질문들을 복기해보자. 코딩 테스트 관련해서는 구체적으로 적지는 않겠지만, 코딩 테스트 코드를 가지고 중복된 코드를 제거하는 것이나 코드 린트를 사용하여 스타일을 맞추는 이유, SQL에서 COALESCE의 의미를 알고 있는지 등을 물어보셨다. 앞의 두 부분은 내 나름의 생각을 말씀 드렸다. SQL 관련해서는 제대로 답변을 못드렸는데, 코딩 테스트 당시에 어렴풋한 기억 속 데이터베이스 수업을 뒤지면서 풀었었고 그래서 명확하게 개념을 이해하고있는 상태가 아니었다. 면접을 준비하면서도 SQL에 대해서는 많이 준비를 하지 못했다. SQL을 직접 작성한지가 꽤 되었다보니 아무래도 부족할 수밖에 없었다. 프로그래머스에서 SQL문제를 좀 풀어보고 관련 CS공부도 시간을 좀 더 쪼개서 해야겠다.

 

 이후 첫 질문은 String, StringBuffer, StringBuilder의 차이를 알고 있느냐는 질문이었다. 코딩 테스트 문항 해결에서 왜 answer를 String 대신 StringBuilder로 사용해서 문자를 더했냐를 말씀하시면서 물어보셨는데, String에 다른 String을 더하면 계속해서 새로운 String 인스턴스가 생기기 때문에 시간적으로 손해를 볼 것이라고 답변드렸고, StringBuffer와 StringBuilder의 차이는 말씀드리지 못했다. String을 안 쓴 이유는 '시간'이 아니라 '메모리'적인 측면에서 답변을 드렸으면 더 좋았을 것 같지만 아무튼 큰 결에서는 맞게 말씀을 드린 것 같은데, StringBuffer와 StringBuilder의 차이를 아예 말씀드리지 못 한 점은 너무 아쉽다. 둘의 차이와 장단을 다시 공부하고 둘을 사용하는 상황들도 다시 공부해야겠다.

 

 다음으로 원시타입과 참조타입의 차이를 물어보셨는데, 이걸 왜 제대로 답변드리지 못했는지 아직도 이해가 안된다. 참조타입은 null을 허용한다고 말씀드렸다. 그럼 왜 null이 되는데? 아니 참조타입은 말 그대로 '참조'를 하니까... 원시 타입은 메모리에 원시적으로 값 자체를 써버리고 참조타입은 참조할 주소를 쓰니까... 아니 이름에 다 나와있는데 이걸 왜 답변 드릴 때는 생각을 못했는지 원... 이런 기본적인 부분에 대해 잘 알고있다고 생각해서 오히려 공부를 소홀히한 점이 발목을 잡았다.

 

 리스트와 셋, 맵의 차이에 대해서도 물어보셨다. 리스트와 해시 자료구조의 차이는 놀랍게도 처음 자료구조를 공부할 때 정말 열심히 봤던 부분이었다. 왜 셋과 맵의 키는 중복이 허용되지 않는지, 왜 해시 자료구조는 contains()의 시간복잡도가 상수시간인지 등을 이해하는데 있어 해시 테이블과 메모리 참조 주소 저장 방법 등을 같이 이해하는 시간이 분명히 있었는데... 이걸 말로 표현하려니 정리가 잘 안됐고, 면접관님께서 그냥 언제 사용하는지 정도로 말씀해주셔도 된다고 해주셨음에도 횡설수설했다. 자료구조도 다시 봐야겠다.

 

 ArrayList와 LinkedList의 차이에 대해 물어보셨다. 이건 그나마 답변 드려야 할 부분은 답변을 드린 것 같다. ArrayList는 그냥 배열형태로 저장하는거라 중간에 값이 들어가면 그만큼 나머지 영역에 대한 복사가 일어나고 그래서 O(N)만큼의 비용이 발생하지만, LinkedList는 Node에 저장된 다음 참조 주소 값만 바꾸면 되기 때문에 O(1)이다. 그러나 맨 뒤에 원소를 추가하는 상황이나 검색에 있어서는 둘이 큰 차이가 없다 정도로 답변을 드렸다.

 

 SOLID원칙에 대한 질문도 있었다. 각 원칙의 이름과 의미에 대해서는 설명을 드렸는데, 좀 더 예시와 왜 이런 원칙이 있는지를 같이 말씀드렸으면 좋았겠다싶다. 각 원칙이 왜 중요하게 강조되는지는 사실 코드의 유지보수성을 높이고, 변화와 확장에 유연하게 대처 가능한 코드를 작성하기 위함이라는 하나의 목적으로 향한다고 생각하는데, 이런 생각을 좀 더 조리있게 정리해서 설명을 드렸으면 좋았을 것 같다.

 

 객체지향적 사고가 뭐라고 생각하는지도 질문 주셨다. 내 답변은 아마 '객체와 객체가 아닌 것을 적절히 구분해, 객체 간 소통이 잘 되는 애플리케이션을 만들 수 있는 사고방식'이라고 말씀드렸던 것 같다. 당연히 횡설수설했다. 사실 이 부분에 대해서는 '어떻게 해야겠다'는 방향성을 잡기가 좀 어려운데, 계속 공부하다 보면 뭔가 천천히 머릿 속에 개념이 잡힐 것 같다.

 

 이력서에 작성해놨던 에러 처리나 디자인 패턴에 대해서는 어떻게 사용했었는지를  물어보셨다. 에러 처리의 경우 로그를 적용하게 된 과정을 말씀드렸고 이를 통해 오류 발생 원인을 파악할 수 있게되어 그나마 좀 상황이 나아졌으며, 모니터링 관련해서 공부해보고 싶다고 답변 드렸다. 디자인 패턴은 적어놨던 내용 중 내가 제대로 이해하고 해당 디자인 패턴을 사용했나? 하는 의문이 드는 부분이 있어 그 부분을 수정해야겠다고 말씀드렸다.

 

 좋은 테스트코드란 무엇이라고 생각하는지에 대한 질문도 받았다. 나는 코드를 봤을 때 이 사람이 뭘 테스트 하고 싶은지가 드러나는 코드가 좋은 테스트코드 같다고 말씀드렸다. 이에 더해 좋은 테스트 코드는 사실 좋은 비즈니스 로직 코드와 연계되어있으며, TDD프로젝트를 진행하면서 테스트 코드를 작성하기 어려웠던 경우 비즈니스 로직을 잘못 처리하고 있는 것은 아닌가 고민하고 수정했던 경험을 말씀드렸다.

 

 이 외에도 더 많은 질문들이 있었던 것 같은데 지금 생각나는 것들이 이것밖에 없다. 내일까지는 계속 혼자 복기해볼 예정이니 만일 더 생각이 난다면 작성해보도록 하겠다. 뭐 아무튼 세 번째 면접을 시원하게 말아먹고 나니, 우매함의 봉우리의 끝에 내가 있구나 싶다. 아무것도 모르면서 좀 안다고 생각하는... 다시 마음을 다잡고 공부해야 할 시기다. 뭐가 됐든 면접 경험을 쌓을 수 있었다는 것은 중요하다. 자책은 오늘까지만 하고 내일부터는 다시 정진하자.