이번 주말 동안엔 코테, 면접, 지원서 작성 이렇게 세 가지 취준 세트가 있었다.
토요일에 코테를 보고, 일요일에 면접을 보고, 12시까지 마감인 지원서를 서둘러 작성해 제출했다,,
그 과정에서 인성면접과 기술면접에 대비해 예상 질문을 정리해보았다.
문항 선별은 지금까지 봐온 여러 번의 면접에 기반해, 정말 내 경험에 기반해 작성했다.
추가로, 여기 있는 질문들 외에 각자 본인의 자소서에 대해 예상 질문을 몇 개 정돈 적어보는 것도 추천한다.
사실 면접은 예상 질문 다 뽑아서 답변 다 적어보고 달달달 읽어보면서 조금씩 외워가는 게 정도다.
인성 면접 예상 질문 정리
인성 질문은 공통적으로 문항이 정해져 있다. 여기 써있는 문항들 다 답변 정리해두면 된다.
필수 질문 (90% 확률로 나오는 질문들)
•
자기 소개 (& 지원 동기)
•
날 뽑아야 하는 이유 (& 지원 동기)
•
목표 (꼭 얻어가고 싶은 것)
•
해당 직무를 선택한 이유
•
궁금한 점
•
마지막으로 하고 싶은 말
선택 질문 (50% 확률로 나오는 질문들)
•
만들고 싶은 서비스 (개발 동아리 면접용, 회사라면 패스)
•
성격 장단점
•
갈등 해결 경험
•
팀에서 본인의 역할은? (협업 경험) → 협업에서 중시하는 가치와 함께 말하면 좋음
기타 질문 (거의 안나오는 질문들)
여기 질문들은 사실 디테일한 질문들이라 안 나올 확률이 높지만 미리 준비해두면 변형된 다른 디테일한 질문에 멋지게 답할 확률이 높아진답니다. 시간이 없다면 여긴 패스해주세요!
•
개발자가 되고 싶은 이유?
•
동료 중 한 명이 탈주하면 어떻게 할 것인지?
•
시간 내에 출시를 못하게 되는 상황이 오면 어떻게 할 것인지?
•
최근 열심히 몰두했던 일
•
최근 스트레스 받았던 일
•
본인을 동물로 표현하자면?
•
본인을 색깔로 표현하자면?
기술 면접 대비 예상 질문 정리 (자바, 스프링, 백엔드)
기술 면접은 사실 나를 위해서 답변을 현재 내 머릿속에 있는 것들로 작성했으니, 좀 더 디테일하고 정확한 답변을 원한다면 질문을 토대로 답변은 따로 구글링해보고 본인만의 답변을 적어보길 바란다.
기본적인 질문들
•
Spring
◦
패러다임 : AOP, 함수형, 객체지향
▪
AOP → 공통 기능 모듈화해(공통 로직) 핵심 로직과 분리 (예외처리 method따로 분리)
▪
Lambda → 익명 함수를 만들어 코드를 더 간결하고 가독성 좋게 작성하게 해줌
•
(parameter1, parameter2, ...) -> { 코드 }
▪
Stream → 컬렉션과 배열 처리 간단하게 해줌
코드
▪
객체지향 4가지 → 추상화, 캡슐화, 상속, 다형성
◦
디자인 패턴
▪
싱글턴 패턴 → 인스턴스 하나만 만들고 그것만 사용 (private 생성자)
▪
MVC
◦
SOLID
▪
SRP(단일책임원칙), OCP(개방폐쇄원칙), LSP, ISP(인터페이스분리원칙), DIP
◦
DI → 의존성 주입 → 필드 주입, 생성자 주입, 수정자주입 @Autowired
◦
JPA 등장배경 → 객체지향을 관계형 DB와 매핑
•
JWT 토큰 기반 인증 서버 → AccessToken과 RefreshToken
•
인증/인가 차이 → 인증은 로그인/로그아웃 같은거, 인가는 페이지 들어오는 권한
•
DB 4계층 → 인스턴스, 데이터베이스, 스키마, 테이블
•
DDD → 도메인 주도 개발 (entity, service, repository 중심)
•
TDD → 테스트 주도 개발 : 테스트 케이스 작성하고 이를 통과하는 코드 작성
•
Docker 배포 과정 → build한 이미지를 docker hub에 push, ssh 접속해서 docker hub에서 이미지 pull 받아와서 컨테이너로 띄우기. docker-compose사용하면 설정 더 쉽게 가능.
자소서 관련 질문들
•
CICD 과정
◦
CI : 빌드. gitignore했던 파일들 넣어줘야함, develop브랜치에 push되면 실행되게 설정 가능
◦
CD : 배포. ssh 연결하고 그 안에서 배포 했던 과정 그대로 넣어줘야 함 ex) docker
•
http와 https 차이점, https 배포 과정
◦
secure 붙음. ssl 인증서 발급.
◦
도메인을 얻어 AWS Route 53을 이용해 최종적으로 도메인과 EC2를 연결
•
cors 에러란?
◦
웹 브라우저는 보안상의 이유로 다른 도메인 간의 자원 요청을 제한하는데, 이 때문에 서로 다른 도메인의 웹 애플리케이션 간의 API 호출 등이 제한되어 발생하는 에러
•
Redis 어디에 썼는지
◦
로그아웃 시 블랙리스트 토큰 관리에 씀.
◦
자주 업데이트 되는 데이터라 인메모리 db라 접근 빠른 redis에 적합.
◦
짧은 유효기간으로 저장가능한 양 많지 않은 redis에 적합
•
메모리 누수
◦
크롬 노드 디버거 사용함. 스냅샷 찍어서 부하 있는지 없는지 살펴봄. 중복되는 객체 같은거.
•
DB 설계 과정
◦
ERD → 스키마
•
Http 상태코드
◦
401은 인증 오류(아이디, 토큰 재발급), 403은 권한 없음, 404는 리소스 없음, 409는 중복 체크 충돌
•
Builder 패턴이란
◦
객체 생성 과정을 캡슐화하여 객체 생성 과정을 단순화하고 가독성을 높이는 디자인 패턴
•
DTO 조회 방식
◦
DTO 변환 방식 → JPA에서 Entity를 조회해오고서 이를 컨트롤러나 서비스단으로 전달해 DTO로 변환하는 방식 (조회한 데이터 재사용성이 좋음_good)
◦
DTO 직접 조회 방식 → JPA에서 DTO를 직접 조회해옴 (쿼리 더 적게날리는데 의미x)
[여기부터 아래 두 문항은 ChatGPT 답변 참고했다]
•
MVC 방식에서의 DTO 생성 위치
◦
DTO는 데이터 전송을 위한 용도로 사용되는 객체입니다. 이러한 이유로 DTO와 같은 객체는 주로 서비스 레이어 또는 컨트롤러(Controller)와 같은 레이어에 위치시키는 것이 좋습니다.
◦
컨트롤러(Controller)는 클라이언트에서 전달된 요청(Request) 데이터를 처리하고, 응답(Response) 데이터를 생성하는 역할을 담당합니다. 따라서, 컨트롤러에서는 클라이언트의 요청에 대한 응답(Response) 데이터를 생성하기 위해, DTO 객체를 이용하는 것이 일반적입니다.
◦
서비스(Service) 레이어는 주로 비즈니스 로직을 처리하는 역할을 담당합니다. 따라서, 서비스(Service) 레이어에서 DTO 객체를 생성하고, 응답(Response) 데이터를 생성하는 것은 비추천되는 방법입니다. 이러한 로직은 컨트롤러(Controller)에서 처리하는 것이 더욱 적절합니다. 하지만, 특정한 경우에는 서비스에서 Response DTO를 생성하는 것이 더 편리한 경우도 있습니다. 예를 들어, 비즈니스 로직에서 여러 개의 데이터를 조합해서 반환하는 경우 등입니다. 따라서, Response DTO를 생성하는 위치는 상황에 따라 다르며, 개발자의 판단에 따라 선택하는 것이 좋습니다.
◦
결론은, SRP(단일책임-객체는 하나의 책임만 져야 함)원칙을 어길 위험을 아예 방지하기 위해선 Response Dto 생성을 컨트롤러에서 하는 게 맞기에 기본적으론 컨트롤러에서 하겠습니다! 다만 여러 데이터를 조합해서 반환하는 경우엔 예외적으로 서비스에서 하는 거로 할게요! Response DTO의 Validation, JSON 변환 등을 Service Layer에서 처리하면 SRP 원칙을 위반할 가능성이 있다고 합니다. 그런 부분 조심하면 될 거 같아요!
•
MVC
1.
Domain:
도메인은 비즈니스 로직에 대한 개념적 모델을 나타내며, 엔티티 클래스로 구현됩니다. 예를 들어, 사용자, 주문, 상품, 카테고리 등의 객체가 이에 해당합니다. 도메인 클래스는 데이터의 유효성 검사, 비즈니스 규칙의 적용 등과 같은 비즈니스 로직을 처리합니다.
2.
Repository:
리포지토리는 데이터베이스와의 상호 작용을 추상화하는 인터페이스입니다. 데이터베이스의 CRUD(Create, Read, Update, Delete) 작업을 처리하고 도메인 객체와의 상호 변환도 수행합니다. JPA, Hibernate, MyBatis 등의 ORM(Object-Relational Mapping) 프레임워크를 사용하여 구현할 수 있습니다.
3.
Service:
서비스는 비즈니스 로직의 구현체입니다. 도메인 객체를 사용하여 데이터를 처리하고, 필요한 경우 리포지토리를 호출하여 데이터베이스와의 상호 작용을 수행합니다. 또한 트랜잭션 관리 등의 역할도 수행합니다.
4.
Controller:
컨트롤러는 HTTP 요청을 처리하고, 적절한 응답을 반환합니다. 클라이언트로부터 전달받은 데이터를 검증하고, 서비스를 호출하여 비즈니스 로직을 처리한 후 결과를 반환합니다. 뷰(View)를 렌더링하거나 JSON, XML 등의 데이터 형식으로 반환할 수 있습니다.
하루 정리
TIL 작성하기
우테캠 코테 (망함 ㅎ)
1시 30분 DDD 면접
지원서 작성