최근에 면접을 하나 더 봤는데요. 그때 받았던 질문들을 정리해보겠습니다.
일반 면접과 마찬가지로 처음에는 본인 소개 및 회사에 대해 어느정도 아는지 물어보셨다.
본인이 관심이 있다면 당연히 대답할 수 있어야 한다. 본격적으로 질문을 적어보도록 하겠다.
1. DRM
Digital Rights Management의 약자로서, 디지털 콘텐츠의 사용 권한을 관리하는 기술이다.
저작권 보호를 통해 콘텐츠 제작자의 권리를 보호하고, 콘텐츠의 불법 복제 및 배포를 어렵게 만들어 산업의 성장을 지원한다.
일반적으로 외부 서비스나 소트프웨어를 통해 구현된다고 한다.
2. 슬라이딩 윈도우
이 부분이 확실하진 않은데 들었던 것 같아 정리한다.
배열이나 리스트의 일정 범위의 요소를 연속적으로 이동시키면서 문제를 해결하는 방법이다. 최대값, 최소값, 합계 등을 빠르게 계산할 때 유용하다.
윈도우 설정 -> 윈도우 이동 -> 연산 수행 -> 최적의 결과 도출이 기본적인 순서이다.
3. 최근 공부한 내용
블로그에 포스팅된 내용을 설명하려고 했으나 긴장되서 자세히 말하지는 못했던 것 같다.
4. 프로젝트 시작한 계기
마음에 맞는 사람들끼리 시작했다.. 라는 내용으로 설명드렸다.
5. 프로젝트 시 생각나는 내용
3개의 파트를 맡아 진행했었는데 그 중 정렬 파트에 대해 간략하게 설명드렸다. TimSort를 사용한다고 했는데 이 부분에 대해 추가 질문을 하셨다.
Sort 알고리즘 2개가 합쳐진 알고리즘이라고 했다.
6. 본인은 리더인지 팔로워인지
나는 지금 당장은 경험이 부족해서 팔로워라고 생각하고 후에는 리더를 해볼 것이다라는 느낌으로 말했다.
7. 리더가 되면 어떻게 이끌 것인가
모두가 성장할 수 있는 환경을 만들고, 아는 부분에 대해선 공유하게끔 할 것이다.. 라고 했다.
8. 본인의 장단점(강점, 약점)
새로운 것을 좋아하고 배움에 있어서 겸손하다고 말씀드렸다. 약점은 인정받고자 하는 욕구라고 했다.
9. 해당 약점을 약점이라고 생각하는 이유
아직은 그런 적이 없지만 극단적으로 생각해보면 인정을 받기 위해 수단과 방법을 가리지 않을 수도 있겠다 라는 생각에 그렇게 말씀드렸다.
이를 방지하기 위해 관련된 사례들을 파악하고 주변인에게 도움을 구하겠다 라고 했다.
10. TCP, UDP 차이점
인터넷 상에서 데이터를 전송하기 위해 사용되는 두 가지 주요 프로토콜이다.
TCP
3-way handshake를 사용하며 데이터의 오류를 검사하고 오류 없이 데이터를 전송한다. 이메일, 웹 페이지 로딩, 파일 전송 등에 사용한다.
UDP
3-way handshake 같은 연결을 사전에 설정하지 않는다. 또한, 손실이 발생해도 재전송을 요청하지 않는다. 실시간 스트리밍, 온라인 게임 등에 사용한다.
11. REST API 원칙
Representational State Transfer의 약자로, 웹 표준을 활용하여 시스템 간의 상호 운용성을 제공하는 방법이다.
자원(Resource)의 표현(Representation)에 의한 상태 전달을 의미하며, 웹의 기본적인 기술과 프로토콜을 사용한다.
이를 정의하기 위해 몇가지 핵심 원칙을 따라야 한다.
1. 명사를 사용하라
항상 리소스(객체)가 어느 범주에 해당하는지 확인하고, 그 범주에 맞는 네이밍 컨벤션을 일관되게 사용해야 한다.
무조건 동사를 쓰지 말라는 것은 아니다.
2. 일관성이 핵심이다
가독성과 지속성을 극대화 하기 위해 '/' 나 '-'를 사용한다.
또한, 소문자를 사용하고, 파일 확장자를 사용하지 않는다.
마지막 문자로만 사용하지 말자.
3. CRUD 함수명을 사용하지 마라
URI는 어떤 동작이 수행되는 지를 가르키는 것이 아니라, 리소스를 가르킨다.
리소스에 대한 작업은 HTTP Method를 이용한다.
4. 필터를 위해 쿼리 파라미터를 사용해라
리소스에 대한 정렬, 필터링, 페이징은 신규 API를 생성하지 않고 쿼리 파라미터를 활용한다.
12. 왜 동사를 사용하면 안될까요?
다양한 이유가 있지만 동사를 사용하면 같은 리소스에 대한 동작도 이름이 매우 달라진다.
반면에, 명사를 사용하면 api를 규칙적이고 깔끔하게 관리할 수 있다.
GET /getUsers ---> GET /users
POST /createNewUser ---> POST /users
GET /getUserById/12 ---> GET /users/12또한, 프로퍼티를 표현하기에 적합하다.
GET /getAccountsOfUserByUserId/123
---> GET /users/123/accounts13. HTTP 상태코드
HTTP 요청에 대한 상태를 나타내는 코드이다.
- 1xx(정보): 요청을 받았으며 프로세스를 계속 진행
- 2xx(성공): 요청을 성공적으로 받았으며 인식했고 수용했음
- 200 OK -> 요청이 성공적으로 실행됨
- 201 Created -> 요청이 성공적이며 그 결과 새로우 리소스가 생성됨
- 3xx(리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요함
- 4xx(클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
- 400 Bad Request: 잘못된 문법으로 인해 서버가 요청을 거절함
- 403 Forbidden: 클라이언트가 콘텐츠에 접근할 권한이 없음
- 5xx(서버 오류): 서버의 오류 혹은 프록시 서버나 게이트웨이 같은 서버의 보조 구성 요소에 문제가 생겼음
14. 과제 피드백
감사하게도 꼼꼼하게 코드 리뷰를 해주셨는데 자료를 못찾아서 기억에 의존해 글쓰는 점 양해 바랍니다.
1. 왜 좋아요 모델을 따로 만들었는가
팀프로젝트 당시에 따로 빼서 정의했기에 이번에도 유사하게 만들었다고 했다.
이에 대해 부가적인 설명을 하자면 다음과 같다.
좋아요 모델을 따로 만드는 경우
- 장점
- 확장성
- 관계성 명확
- 데이터 정규화
- 단점
- 조회 성능
- 복잡성 증가
댓글 모델 내부에 정의하는 경우
- 장점
- 성능
- 간단한 설계
- 단점
- 확장성 부족
- 데이터 중복
2. 좋아요를 취소하면 댓글이 삭제되는 문제
답변을 제대로 못했는데 면접관님이 시간 부족했으니 이해한다..? 라는 느낌으로 넘어가 주셨다.
추가로 적어보자면 다음과 같다.
댓글 모델 자체에는 영향을 주지 않고, 좋아요만 취소된다.
3. 댓글 신고 필터링이 의미가 없음
이 당시에는 답변을 하지 못했다.
content 필드를 Serializer 필드에 추가하고 get_content 메서드에서 댓글 작성자인 경우, 댓글 내용을 직접 반환해야 한다.
4. 댓글 신고 카운트 상승을 1씩 더하게 구현한 이유
단순하게 생각하여 누르면 1씩 증가하게 구현했다. 그렇지만 여기에는 문제가 존재한다.
동시성 문제
여러 사용자가 동시에 같은 댓글에 대해 신고를 할 경우, 카운트가 1만 증가하는 문제가 발생할 수 있다.
이를 해결하기 위해 트랜잭션, F() 표현식으로 처리할수도 있다.
5. 권한 설정이 안되어 있음
시간 부족으로 빠뜨렸다고 했다.
댓글 수정 부분에 권한을 추가해야 한다.
추가로, 시간이 부족하셨냐.. 라고 물어보셨는데 그에 대해서 솔직하게 부족했다고 말씀드렸다. 그러나 점심 시간을 좀 줄여서 진행했으면 완성했을 것이라고 했다.
15. 전공에서 무얼 배우는가
회로, 프로그래밍, 역학 등 다양하게 배운다고 했다.
16. 웹개발을 하게된 이유
예전 수업때 로봇 비전이라는 수업을 듣고 ML 엔지니어를 꿈꾸게 되었다. 이를 위해 파이썬이라는 언어를 배워야 했고 그 과정에서 재미를 느껴 졸업 후 파이썬, 장고 부트캠프를 들으며 웹개발의 꿈을 키웠다 라고 했다.
17. 추후 목표
유사한 길을 걷는 분들께 알고 있는 지식을 나눠주고 싶고 피드백을 바탕으로 성장하고 싶다고 했다.
18. 궁금한 점
해당 기업에만 존재하는 평어 문화라던지, AI 관련 궁금증, 다양한 기술스택에 대한 질문을 했다.
마지막으로, 객관적인 수준을 파악하게 된 좋은 면접이었다..라는 느낌으로 말씀드렸다.
실무자분들께 피드백을 받을 수 있는 좋은 경험이었다.
