[면접후기 , 면접 질문 정리] Front-end 면접 후기(Job Interview)

2023. 1. 3. 23:59Web Programming(웹 개발)/Job Meeting(면접 후기 및 면접 질문)

여러분 제가 오늘은 1일  2포스팅을 하게 되었네요!

새벽에 코딩테스트를 본 그 기업에 면접을 방금 전에 끝내고 왔는데요

탈탈 털리고 왔습니다...

물론 제가 면접에 대해 파고들어서 준비를 깊게 하지는 않았지만, 예상 질문 리스트나 기술적인 질문에 대한 부분(구글링을 통해 열심히 찾아보았습니다)들을 새벽 6시 넘어서까지 정리하고 잤는데...(참고로 7시 30분에 일어났습니다;;) 

 

느낀점과 제가 향후 더 발전해나가야하는 점 등을 정리해보려고요

우선 이 글을 읽으시는 여러분들이 가장 궁금해하실 면접 방식과 면접에서 나왔던 질문들을 적어보려고 해요!

사실 아까 집에 오면서 면접에서 여쭤보셨던 기술 질문들 그리고 중요하다고 따로 설명해주셨던 말씀들을 다시금 곱씹어보면서 왔거든요

그래서 아주 기억이 생생합니다 제가 다 기억해서 여기 써보겠습니다

 

면접 방식

- 2대 1로 진행(면접자 1명, 면접관 2명)

- 1명은 포트폴리오 위주로 질문/1명은 기술 관련 질문(개발 언어 및 개발 방법론, 알고리즘, CS적인 지식들)

 

기술 관련 질문(제가 했던 답도 적어볼게요)

1. 상속이 무엇인가요? 자바에서는 다중 상속이 가능한가요?

- 부모 클래스의 메소드를 하위 클래스가 그대로 이어받아 사용할 수 있는 것을 말합니다.

- 자바에서 다중 상속은 가능합니다!(나란 인간 틀린 답 당당하게 대답했다...;; 긴장해서 멀티스레드라고 잘못 들은 바람에 가능하다고 자신있게 얘기해버림ㅋㅋ)

자바에서 상속이란 부모 클래스에서 정의된 필드와 메소드를 자식 클래스가 물려받는 것을 말한다.

특징
1. 자바에서는 다중 상속을 지원하지 않는다. 따라서 extends 뒤에는 단 하나의 부모 클래스만 올 수 있다.
2. 자바에서는 상속의 횟수에 제한을 두지 않는다.
3. C++의 경우에는 최상위 클래스가 없지만 자바에서 최상위 클래스는 Object클래스이다.  Object 클래스만이 유일하게 super class를 가지지 않으며 자바의 모든 클래스들은 Object 클래스의 자손이라고 볼 수 있다.

 

2. 오버로딩과 오버라이딩 차이를 설명하세요.

- 오버로딩은 부모 클래스의 메소드를 자식 클래스가 그대로 차용하는 것을 말합니다. 오버라이딩은 부모클래스의 메소드를 자식 클래스가 재정의해서 사용하는 것을 의미합니다. 

1. 오버로딩(Overloading)
- 메소드의 이름이 같지만, 시그니처(파라미터수, 타입)에는 다른 메소드를 중복으로 선언하는 것을 의미한다.
- 파라미터 개수가 같을 경우, 데이터 타입이 달라야 한다.
- 리턴값만 다른 오버로딩을 작성할 수 없다. 


2. 오버라이딩(Overriding)
- 상위 클래스의 메서드를 하위 클래스가 재정의 하는 것이다.
- 메소드의 이름과 파라미터의 갯수나 타입도 동일해야 하며, 주로 상위 클래스의 동작을 상속받은 하위 클래스에서 변경하기 위해 사용된다.
- 메소드의 리턴형이 같아야 한다. 

<오버로딩(Overloading)은 기존에 없던 새로운 메서드를 정의하는 것이고,오버라이딩(Overriding)은 상속 받은 메서드의 내용만 변경 하는 것이다.>

 

3. CPU의 클럭은 어떤 기능을 하느냐 주파수인 기가 헤르츠로 측정을 하는데 왜 그렇게 하느냐(컴퓨터 구조 재미있게 수강했다고 하니 여쭈신 질문)

- 탐색 속도와 관련있는 것으로 알고 있습니다. 주파수로 측정하는 이유는 잘 모르겠습니다(잘 모르면 모른다고 대답하라고 하셔서 모른다고 대답했습니다)

PC의 “두뇌”인 CPU의 성능은 프로그램 로드 속도와 프로그램이 얼마나 원활하게 실행될 수 있는지에 큰 영향을 미친다.
프로세서 성능을 측정하는 방법은 몇 가지가 있는데, 클럭 속도(또는 "주파수")는 가장 중요한 부분 중의 하나이다.
CPU가 장착되는 메인보드(Main Board)에는 작은 수정(Crystal)이 탑재되어 있는데, 그 수정이 CPU에 클럭 신호(clock tick)를 보낸다.
Clock은 CPU나 GPU 등의 연산 속도를 표현할 때 사용된다.

보통 ‘동작 속도’ 혹은 ‘클럭 속도’라고 말한다.
초당 클럭신호가 많을수록 더 많은 데이터를 처리할 수 있다.

Digital Signal은 0과 1을 출력하며, 전기적 신호를 발생시킵니다.
1초에 0과 1을 한 번 번갈아 갈 때  1Hz로 표시한다.
1초에 1000번의 전기적 신호를 발생시킨다면 1kHz가 되고, 100만 번이면 1MHz(메가헤르츠), 10억 번이면 1GHz(기가헤르츠)가 된다.
최신 CPU들은 3~4GHz의 연산 속도를 가지고 출시되고 있고, 이것은 초당 30~40억 회의 연산을 수행한다는 것을 의미한다.

오버클럭(Overclocking)
일반적으로 CPU의 최대 클럭 속도는 출고될 때 고정되어 나오지만, 일부 제품은 사용자가 임의로 클럭 수를 높일 수 있는 기능을 제공하기도 하기도 하는데 이것이 오버클럭이다. 

 

4. 일반적인 32비트 컴퓨터에서 명령어 처리 과정이 어떻게 되는지 설명해주실 수 있나요?

- 명령어를 저장하고 처리하는 명령어 레지스터가 있고, 주소 값을 처리하는 주소 레지스터 그리고 그들을 연결하는 각각의 버스(bus)들이 있습니다.

▶ 호출사이클(Fetch)
- 레지스터 PC에 저장되어 있는 값에 해당하는 주기억장치로 가서 데이터를 복사해서 레지스터 PC에 저장한다.

해석사이클
- 레지스터 IR로 가져온 기계어 비트열을 해석한다
- 연산자의 유형에 따라 피연산자 필드를 적절히 나눈다

실행사이클
- 레지스터 IR의 비트열에 해당하는 신호를 연산장치에 제공하고, 범용 레지스터나 주기억장치에 보내서 기계어 명령어를 수행한다.

 

5. 그리디 알고리즘이 무엇인지 설명하고 그것의 대표적인 알고리즘을 말해주세요

- 요건 배운지 오래되서 생각이 도저히 안 나더라고요 그래서 설명을 못했네요 ㅜ 

그리디 알고리즘(Greedy algorithm)
- 탐욕 알고리즘 또는 욕심쟁이 알고리즘이라고도 한다.
- 미래를 생각하지 않고 각 단계에서 가장 최선의 선택을 하는 기법
- 동적 프로그래밍 사용 시 지나치게 많은 일을 한다는 것에서 착안하여 고안된 알고리즘
- 동적 프로그래밍을 대체하는 것은 아니고 같이 쓰이며 서로 보완하는 개념입니다.

그리디 알고리즘을 사용해서 해결할 수 있는 대표적인 문제 
- 분할 가능 배낭 문제
- 프림 알고리즘
- 다익스트라 알고리즘

▣ 알아두어야 할 사항
- 일반적인 상황에서 그리디 알고리즘이 항상 최적 해를 보장할 수 없을 때가 많다.
- 코딩 테스트에서의 대부분의 그리디 문제는 탐욕법으로 얻은 해가 최적의 해가 되는 상황에서, 이를 추론할 수 있어야 풀리도록 출제된다.

 

6. 어떤 디자인패턴이 좋다고 생각하며 본인이 쓴 디자인패턴이 있는지 말해주세요 그리고 그걸 왜 썼는지 설명해주세요 

- MVC 패턴을 이용하여 개발을 많이 해왔고, 아무래도 범용적으로 가장 많이 사용하는 디자인 패턴이라고 생각합니다. 뿐만 아니라 코드가 Model, View, Controller로 한눈에 어떤 역할을 하는 코드가 있는지 파악하기 편해서 코드 관리나 협업할 때도 용이하여 사용하였습니다. 

 

참고 사이트

https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS8616098823 

 

[Design pattern] 많이 쓰는 14가지 핵심 GoF 디자인 패턴의 종류

디자인 패턴을 활용하면 단지 코드만 ‘재사용’하는 것이 아니라, 더 큰 그림을 그리기 위한 디자인도 재사용할 수 있습니다. 우리가 일상적으로 접하는 문제 중 상당수는 다른 많은 이들이 접

www.hanbit.co.kr

-> 여기에 되게 잘 나와있네용!

 

7. MySQL과 MongoDB를 써보셨다고 DB에 자신있다고 하셨는데, RDBMS와 NoSQL의 차이점을 설명해주세요

- 차이점은 잘 모르겠고, 제가 써보고 느낀 바로는 MySQL 같은 경우는 구조적으로 쿼리문을 통해 다 작성을 해서 DB 스키마 설계를 하고  데이터 작업을 해야한다는 것입니다. 그에 비해 MongoDB는 DB를 생성할 때 스키마를 먼저 정의하지 않아도 Collection으로 바로 만들어서 데이터를 집어넣을 수 있기 때문에 초보자도 쉽게 사용할 수 있는 간결한 DB라는 생각이 들었습니다. 

1. RDBMS
- R은(Relational)의 약자로 RDBMS는 관계형 데이터베이스 관리 시스템을 의미한다.
- RDBMS는 RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스이다. 
- 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다는 게 RDBMS의 가장 큰 특징

→ 어떤 시스템에 사용하는 것이 좋을까?
- 데이터 구조가 명확하며 변경될 여지가 없고 명확한 스키마가 중요한 경우
- 중복된 데이터가 없어(데이터 무결성 확보) 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 잦은 변경이 없는 시스템에 적합

2. NoSQL
- Not Only SQL의 약자로 RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미한다. 
- NoSQL에서는 RDBMS와는 달리 테이블 간 관계를 정의하지 않는다.
- 데이터 테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않아 일반적으로 테이블 간 Join도 불가능
- 대표적으로 Document Database인 MongoDB와 Redis, Riak, Amazon Dynamo DB

어떤 시스템에 사용하는 것이 좋을까?
- 정확한 데이터 구조를 파악할 수 없고, 변경/확장이 될 수 있는 데이터가 많은 경우
- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경될 시에는 모든 컬렉션에서 수정을 해야한다.
- Update가 많이 이루어지지 않는 시스템
- Database를 Scale-Out를 해야 되는 시스템에 적합(아주 많은 양의 데이터를 저장해야 하는 경우)

 

8. 스택과 큐가 있는데 각각을 설명하고, 그것이 각각 컴퓨터에서 어디 작업에 쓰이는지 설명해주세요 

- 스택은 LIFO, 말 그래도 쌓인다는 의미로 LIFO(Last In, First Out)의 구조를 가지며 메모리 할당에 쓰입니다. 큐는 스케쥴링에 많이 쓰이고 FIFO(First In, First Out) 구조를 가집니다. 그리고 선형적입니다. 

Stack
- 같은 구조와 크기의 자료를 정해진 방향으로만 쌓을 수 있다.
- top으로 정한 곳을 통해서만 접근할 수 있다.
- top에는 가장 위에 있는 자료는 가장 최근에 들어온 자료를 가리키고 있으며, 삽입되는 새 자료는 top이 가리키는 자료의 위에 쌓이게 된다.
- Stack에서 자료를 삭제할 때도 top을 통해서만 가능하다.
- Stack에서 top을 통해 삽입하는 연산을 'push' , top을 통한 삭제하는 연산을 'pop'이라고 한다.
- 후입선출(LIFO, Last-In-First-Out) 구조

▶ 예시
- 웹 브라우저 방문기록 (뒤로 가기) : 가장 나중에 열린 페이지부터 다시 보여준다.
- 역순 문자열 만들기 : 가장 나중에 입력된 문자부터 출력한다.
- 실행 취소 (undo) : 가장 나중에 실행된 것부터 실행을 취소한다.
- 후위 표기법 계산수식의 괄호 검사 (연산자 우선순위 표현을 위한 괄호 검사)


Queue
- 큐는 한쪽 끝에서 삽입 작업이, 다른 쪽 끝에서 삭제 작업이 양쪽으로 이루어진다.
- 삭제 연산만 수행되는 곳을 프론트(front), 삽입 연산만 이루어지는 곳을 리어(rear)로 정하여
각각의 연산 작업만 수행된다.
- 이때, 큐의 리어에서 이루어지는 삽입연산을 인큐(enQueue)라고 한다
- 프론트에서 이루어지는 삭제연산을 디큐(dnQueue)라고 한다.
- 선입선출(FIFO(First In, First Out) 구조


예시
- 우선 순위가 같은 작업 예약 (프린터의 인쇄 대기열)
- 은행 업무 콜 센터 고객 대기시간
- 프로세스 관리
- 너비 우선 탐색(BFS, Breadth-First Search) 구현
- 캐시(Cache) 구현

 

9. 웹과 앱의 차이가 무엇이냐?

- 제가 느끼기에는 웹이 좀더 까다롭다고 느꼈습니다. 웹의 경우 통신적인 부분이 중요하기 때문에 DB 연동이라던지 API적인 부분 등신경쓸 부분이 많았던 느낌이었습니다. 제가 그 전에 만들어보았던 앱은 좀더 뭉터기로 한번에 만드는 느낌이었다면 웹은 좀더 세분화해서? 프론트와 백을 명확히 구분해두고 만들어야하는 느낌이라 까다롭게 느껴졌던 것 같습니다. 

차이점
웹(WEB)
단말기와 서버에서 정보를 검색하고, 수동적으로 정보를 제공받는다.

어플(APP)의 경우 프로그래머의 의도에 따라 단말의 OS 정보를 포합하여 기기정보(맥정보), 시간정보, 위치정보, 전화번호, 은행거래정보 등 단말기의 모든 부분을 조종할 수 있고, 정보를 변경할 수 있는 능동적인 프로그램이라는 점에 차이가 있다.
 
Web으로 제작할지 APP로 제작할지의 판단 기준
스마트폰내의 정보나 서버의 정보를 이용해야 하는가? - > APP!
단지 정보를 제공하고 보여주며 제공된 기능만 사용할 것인가 -> WEB

 

 

10. 왜 채팅서비스는 Restful API가 아닌 웹소켓으로 개발했는가? (웹소켓의 기능을 알고있는지 묻는 질문)

- 통신에 좀더 용이하기 때문이라고 알고 있습니다(사실 잘 기억이 안 나서 두루뭉실하게 말함ㅋㅋ)

등장 배경
웹소켓이 나오기 전에는 모두 클라이언트의 요청이 없다면, 서버로부터 응답을 받을 수 없는 구조였다.
통상적인 Http 통신은 Client가 요청을 보내는 경우에만 Server가 응답을 하는 단방향 통신
웹소켓은 이러한 문제를 해결하는 방안이 되었음!!!

웹소켓이란?
- 두 프로그램 간의 메시지 교환을 위한 통신 방법 중 하나
- 웹소켓에서는 서버와 브라우저 사이에 양방향 소통이 가능
- 브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있게 해줌(웹페이지를 ‘새로고침’하거나 다른 주소로 이동할 때 덧붙인 부가 정보를 통해서만 새로운 데이터를 제공하는 웹서비스 환경의 한계를 본질적으로 해결)
 
웹에서도 채팅이나 게임, 실시간 주식차트와 같은 실시간이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현할 수 있게 됨
가상화폐 분산화 기술의 핵심도 WebSocket으로 구현할 수 있음.

문제점
1. 프로그램 구현에 보다 많은 복잡성을 초래한다.
- 웹 소켓은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 비정상적으로 연결이 끊어졌을때 적절하게 대응해야 한다. 이는 기존의 HTTP 사용시와 비교했을 때 코딩의 복잡성을 가중시키는 요인이 될 수 있다.
2. 서버와 클라이언트 간의 Socket 연결을 유지하는 것 자체가 비용이 듦
- 특히나 트래픽 양이 많은 서버같은 경우에는 CPU에 큰 부담이 될 수 있다.
3. 오래된 버전의 웹 브라우저에서는 지원하지 않는다. (물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있다.)

대표적인 사용 사례
WebSocket 프로토콜은 실시간 데이터 업데이트와 클라이언트에 메시지를 보내는 기능이 필요할 때 이상적

1. 페이스북과 같은 SNS APP
2. LOL 같은 멀티플레이어 Game
3. 위치 기반 APP
4. 증권 거래 정보 사이트 및 APP
5. 화상 채팅 APP
6. 구글 Doc 같이 여러 명이 동시 접속해서 수정할 수 있는 Tool

 

반대로 질문하고 싶은 거 해달라고 말씀하셔서 직접 한가지 질문도 던졌습니다!

내가 한 질문
- 개발자를 뽑으실 때 중요하게 생각하시는 역량이나 기준이 있나요?

면접관님들의 답
1. 기초부터 착실히 다져놓았는가, 초등학교 수학을 잘 모르면 중고등학교 수학을 따라갈 수 없듯이 결국 기초를 잘 다져놓아야 뭐든 응용할 수 있다.(여담으로 아카데미 2-3개월 다닌 친구들한테 기존에 배운 거 시키면 잘하지만 새로운 거 해보라고 하면 아예 못한다고 하셨다. 기초의 중요성 강조)
2. 끝까지 문제를 해결하는 끈기와 열정을 본다.
3. 개발을 할 때 본인이 했던 개발 툴이나 방식 등을 왜 썼고, 그 코드를 왜 그렇게 설계하였는가를 한번이라도 생각해본 개발자를 뽑는다. 결국 어찌어찌 했다가 관건이 아니라 안됐어도 그 사고과정 안에서 내가 어떤 생각을 했고, 어떤 접근법을 제시하였으며 왜 그런 툴과 언어(or 라이브러리, 디자인패턴, )를 썼는가를 설명할 줄 알아야한다. 
4. 내가 짠 코드가 어떤 케이스가 입력되더라도 항상 100%의 정확도를 보장하는가? 그렇게 되기 힘들기 때문에 자기가 짠 코드를 하나하나 뜯어서 이게 왜 이렇게 해결되는 것인지 그리고 그것을 해결할 수 있는 다른 방법이 존재하진 않는지 한번 더 짚고 넘어가야 한다. 

그리고 여러가지 스택을 할 줄 아는 것보다 한 가지라도 제대로 할 줄 아는 것이 중요하다는 말씀도 해주셨어요 

취준생 분들이 이력서에 여러가지 언어나 기술을 다뤄봤다고 많이들 쓰는데 한가지도 제대로 하기 힘들다고, 여러가지 얕게 아는 것보다 하나라도 깊게 파고들라고 하셨습니다!

 

면접을 통해 제 능력이나 제 스스로를 어필한 것보다 배워가는 게 더 많았던 시간이었던 것 같습니다. 

아침부터 일어나서 다녀오느라 힘들긴 했지만, 그래도 면접관님들을 통해 좋은 말씀도 듣고 스스로 깨달았던 게 좀 있었네요 이제 코테 준비도 열심히 하고 잊고 살았던 전공 지식도 다시 공부를 좀 해봐야겠어요 


이제부터 내가 할 것

1. 개발을 할 때 꼭 왜 이 언어를 썼고, 이런 방법론을 쓰려하는지 생각해보고 이유를 적어보기

2. 중간중간 꼭 내가 성취한 결과물들과 코딩본들을 리마인드 할 수 있는 시간을 가지고 내가 이 프로젝트를 통해 무엇을 배웠는지 어떤 사고를 했는지 정리해보기

3. 말 뿐이 아니라 진짜로 하는 사람이 되기

4. "꾸준히 열심히 잘하는 것"이 아니라 그저 "꾸준히 하는 것"에만 집중하기!(나는 너무 잘하려고 부담을 많이 가져서 중간에 지치는 게 있는 것 같다는 생각이 들었다 꾸준히 하면 남들이 결국 열심히 했다고 평가해주니까 꾸준히 잘하려고 너무 스스로를 꾸짖지 말고 천천히 성실히 해나간다는 생각으로!)

5. 평소 논리적으로 항상 이유와 원인을 말하는 연습하기

 

 

댓글과 공감은 포스팅에 힘이 됩니다! 

빠쇼~