2018년 하반기 'ㅈ' 기업 개발자 면접 후기

2018년 하반기 'ㅈ' 기업 개발자 면접

2018년 하반기 11월에 실시된 'ㅈ' 기업 개발자 면접 후기입니다

인터뷰 내용은 회사의 자산이므로 회사 이름은 생략하겠습니다. 'ㅈ' 기업은 웹 서비스 개발자 직무를 준비하는 분이시라면 충분히 짐작할 수 있는 기업입니다. 연봉 3500 정도, 워라벨과 개발자 본인 성장에 있어서 좋은 기업입니다. 개인적으로 회사가 궁금하시다면 비밀 댓글을 남겨주세요. 'ㅈ'기업의 채용 프로세스는 다음과 같습니다.

1. 서류
2. 알고리즘
3. 실무진 면접
4. 임원 면접

개인적으로 서류에 대해서는 솔직한 내용이 최고인 것 같습니다. 저 같은 경우 제 자신을 꾸미지 않고 솔직하게 작성하였고 통과하였답니다.

알고리즘 시험

알고리즘 시험은 5시간 동안 총 4문제 코딜리티 사이트에서 진행되었습니다. 개인적으로 어렵다는 평판과 달리 문제의 난이도는 굉장히 쉬운 편에 속했었습니다. 2시간만에 다 풀고 종료했었으니까요. 시험 문제 역시 회사 자산이므로 제가 함부로 공개할 수 없음을 이해주셨으면 좋겠습니다. 개인적으로는 완전 탐색 방법으로 알고리즘을 풀어보고 그것에 대해 DP, 그래프 등 알고리즘을 최적화 시키는 방법이 1가지라도 몸에 익히신 분이라면 충분히 쉽게 풀 수 있을 듯 합니다. 또한 코딜리티는 프로그래머스 사이트와 달리 테스트 셋 결과만 나타내므로 최대한 많은 테스트 셋을 추가하시는게 지원자한테 유리한 것 같습니다.

실무진 면접

4문제를 다 풀었고 어느정도 다 맞으거 같다는 자신감이 있었기에 붙을 줄 알았지만, 붙었다는 메일을 받고 정말 기뻤습니다. 그리고 1 주일간 면접 준비를 하게 되었습니다. 우선 제가 준비한 면접 준비는 다음과 같습니다.

1. 1분 자기소개
2. 코딩 시험 4문제 코드 리뷰 준비
3. 자소서에 썼던 프로젝트 질문 준비
4. 회사 서비스에 대한 평가
5. 최근 읽은 서적에 대한 간단한 내용 준비

여러 검색을 통해서 위의 5개 정도는 반드시 나온다고 해서 딱 준비해갔습니다. 그리고 면접 당일!! 그 내용을 공유합니다.

실무진 면접은 3:3 면접이었다!

시간에 맞춰 도착하니까 인사 담당자분께서 면접 방 안내를 해주셨고 이미 저 말고 2명의 지원자가 도착해 있더군요. 알고보니까 모두 11번가에서 개최한 '도시락 토크' 참가자였다라는 놀라운 사실이... 그래서 저희끼리 대화하며 약간의 긴장을 풀 수 있었습니다. 약간의 시간이 지난 후, 실무진 면접관 3분께서 방에 들어오셨습니다. 검색 서비스 개발팀 팀장님, 부팀장님, 그리고 직책상 더 높으신 분이었는데 너무 긴장해서 직책은 잘 못들었습니다. 편의상 대장님(?)이라고 하겠습니다. 간단한 인사 후, 약 2시간 가량의 실무진 면접이 바로 시작되었습니다.

일단 처음은 자기소개부터!

어떤 면접이든, 자기 소개부터 시작했습니다. 저를 포함한 지원자 모두가 1~3분 이내에 자기소개를 준비해서 빠르게 넘어갔습니다. 실은 공대생 특징 중 하나가 말을 진짜 못하는 것인데 3명다 말을 잘하더라구요. 뭐 다들 저처럼 매일 매일 연습을 했겠죠?? 한명이라도 실수해서 더듬거리거나 떨었다면 더 긴장이 풀렸을텐데,(못난놈 심보) 전부 다 잘하니까 더 긴장되었습니다. 개인적으로.

공통 질문! 프로그래밍, 자바, 스프링의 기본을 묻는다.

질문은 3명을 앉혀놓고 왼쪽에서 오른쪽 혹은 오른쪽에서 왼쪽으로 순서대로 한 질문에 대해 답변하는 것이었습니다. 개인적으로 아쉬웠던 것이 저는 가운데 앉아서 대부분 앞에서 기본적인 답변을 해버리니까 할 말이 없더라구요 ㅠㅠ 망했어.. 아무튼 간략적으로 질문과 답변에 대해 공유하고자 합니다.

Q1. 자바 8의 람다는 무엇인가요?

개인 답변

자바 람다는 자바에서 함수형 프로그래밍을 지원하기 위한 기능 중 하나입니다. 자바에서는 기본적으로 함수는 일급 시민이 아니기 떄문에, 자바 8이전에 특정 메소드를 파라미터로 넘기려면, 인터페이스 형태로 넘겨야 가능합니다. 이 부분을 간단히 하기 위해 무명 인터페이스로 만들어서 넘길 수 있지요. 이 부분의 표현을 간소화시켜 만든 표현할 수 있게 만든것이 람다입니다.

무슨 말이냐면 예를 들어, 덧셈이라는 함수를 자바에서 코드로 넘기려면 다음과 같은 일을 해야 합니다.

interface Addable{
    int add(int a, int b);
}

public class Test {
    public int addFunc(int a, int b, Addable addable){
        return addable.add(a, b);
    }
    public static void main(String[] args) {
        int a = 5, b= 10;
        Test t = new Test();

        System.out.println(t.addFunc(a, b, new Addable() {
            @Override
            public int add(int a, int b) {
                return a + b;
            }
        }));
    }
}

꽤나 복잡하지요? 이 부분은 자바 8에서 다음과 같이 작성할 수 있습니다.

@FunctionalInterface
interface Addable{
    int add(int a, int b);
}

public class Test {
    public int addFunc(int a, int b, Addable addable){
        return addable.add(a, b);
    }
    public static void main(String[] args) {
        int a = 5, b= 10;
        Test t = new Test();

        System.out.println(t.addFunc(a, b, (i1, i2) -> i1 + i2));
    }
}

훨씬 간단하지요? 이렇게 무명 인터페이스로 코드 조각을 보낼 때 훨씬 더 간단하게 보낼 수 있는 것이 람다입니다. 컴파일 시에 이 람다 조각들은 무명 인터페이스로 컴파일 된답니다. 언어 덕후인 저는 이 부분에 대해서 잘 대답했답니다 하하.

Q2. 자바 8의 FunctionalInterface 애노테이션은 무엇인가요?

개인 답변

FunctionalInterface 애노테이션은 이 애노테이션이 붙은 인터페이스에 대해서 강제적으로 단일 메소드만 가지게 해주는 애노테이션입니다. 만약 이 애노테이션이 붙은 인터페이스가 자바 8에 추가된 default 메소드를 제외하고 2개 이상의 메소드가 존재한다면 컴파일 시에 에러가 나게 됩니다.

무슨 말이냐면, 위의 Addable 인터페이스를 다시 봅시다.

@FunctionalInterface
interface Addable{
    int add(int a, int b);
}

이 상황에서 default 메소드를 제외한 다른 메소드가 추가된다면 컴파일 에러가 뜨게 됩니다. 왜냐하면 자바8 이상의 컴파일러에서 앞서 말했듯이 람다를 컴파일 할 때 무명 인터페이스로 변환됩니다. 이 떄 무명 인터페이스의 부모인 인터페이스, 여기서는 Addable 같은 인터페이스가 만약 1개가 아닌 2개 이상의 메소드를 지니고 있으면 어떤 메소드에 관한 것인지 컴파일러가 추론하지 못하기 때문입니다. 이 부분 역시 잘 설명했습니다.

Q3. 스프링의 DI 패턴에 대해서 설명해주세요

개인 답변

스프링 DI 패턴을 지원하기 위해서 @Autowired라는 애노테이션을 통해 빈으로 등록한 클래스들을 주입할 수 있습니다. 또한 빈에 해당하는 자바 클래스를 만드는 방식은 xml로 설정하는 방식, 자바 코드 방식이 있는 걸로 알고 있습니다.(이미 전 지원자분께서 잘 설명해 주셨습니다...)

모범 답안

위의 개인 답변은 개인적으로 틀린 답변으로 생각합니다. 이처럼 틀린 답안, 답변에 대해서 모자란 개인 답안에 대해서는 이처럼 모범 답안을 남깁니다.

DI는 쉽게 말해서 각 컴포넌트 간 의존성 관계를 소스코드 내부가 아닌 외부 설정파일 등으로 설정하여 그 의존성을 끊는 것에 목적이 있습니다. 또한 스프링에서 DI 방식에는 다음의 3가지 방식 있습니다.

1. 생성자 주입 방식
2. 필드 주입 방식
3. 세터 주입 방식

또한 현재 스프링 버전에서는 빈으로 설정된 각 컴포넌트를 @Autowired로 쉽게 불러올 수 있습니다.

Q4. 스프링 JPA에 대해서 설명해주세요, ORM, 하이버네이트 JPA 관계를 말씀해주세요

개인 답변

이전 지원자와 생각이 같습니다. 덧붙여 설명하자면 JPA를 사용하면 DB의 데이터를 긁어올 때 자체적으로 캐싱을 지원하기 때문에, 성능이 더 좋은 것으로 알고 있습니다. 개인적으로 JPA를 프로젝트에서 적용해본 경험이 있는데, 직접 DB 연동을 위해 Repository를 작성하는 것보다 손쉽게 DB를 연동시킬 수 있어서 좋았던 기억이 있습니다.

일단, 저와 이전 지원자가 기본적인 답변을 했고 그 이상의 답변이 나오지 않았습니다. 면접관님께서 질문한 의도는 ORM, 하이버네이트, JPA 관계에 대해서 알려달라 하셨습니다. 따라서, 이 질문에 대한 모번 답안은 다음이 될 것 같습니다.

모범 답안

ORM은 Object Realtion Mapping으로 관계형 데이터 베이스의 엔티티와 자바 클래스를 매핑시키는 기술을 뜻합니다. 자바의 ORM 기술 구현체로써 Hibernate, OpenJPA 등이 있고 이를 위한 표준 인터페이스가 바로 JPA입니다.

Q5. 스프링 프레임워크와 비교해서 스프링 부트에 대해서 설명해주세요

개인 답변

개인적으로 스프링 프레임워크는 사용해본 적이 없고 스프링 부트만 사용해보았기 때문에 둘을 잘 비교하긴 어렵지만 제가 알기로는 스프링 프레임워크에서 의존성 관리, 빈 설정 등 어려운 작업들을 손쉽게 해주는 것이 스프링 부트라고 알고 있습니다. 말씀드린 것처럼 스프링 부트로 프로젝트를 진행했을 때 파이썬의 장고 자바스크립트의 Express 처럼 손 쉽게 개발할 수 있었습니다. 다만, 스프링 프레임워크에 대해 전반적인 지식이 없으니 프로젝트에서 원하는 기능을 커스토마이징할 때 힘든 감이 있었습니다.

Q6. 링크드리스트와 해쉬맵에 대해서 설명해주세요(저한테만 질문하셨습니다.)

개인 답변

고정 길이 배열은 메모리에 올라올 때 한 번에 그 길이만큼 올라가는데 반면 링크드리스트는 흩어져서 메모리에 올라갈 수 있습니다. 옜날 메모리가 턱 없이 부족했을 때 많은 데이터를 효율적으로 저장하기 위해서 만들어진 자료구조체로 알고 있습니다. 해쉬맵은 어떤 키에 대해서 값을 저장하는 자료구조체인데 해쉬 함수라는 것을 통해서 키-값을 저장합니다. 이떄 해쉬 함수는 출력 값이 제한되어 있기 때문에, 해쉬충돌이 일어나는데 이를 해결하기 위한 제일 쉬운 방법은 각 해쉬 배열에 링크드 리스트를 연결한 체이닝 방식이 있습니다.

Q7. Key가 256 고정 길이, 어떤 문서가 무수히 많은 데이터가 존재할 때 key에 대해서 정렬하기 위해선 어떻게 해야 합니까?

개인 답변

잘 모르겠습니다.

모범 답안

이 문제의 답안은 여러가지가 있을 수 있습니다. 개인적으로 면접 본 후 집에 가면서 생각해봤는데, key에 대해서 정렬이 필요하려면 일단 sorted 해쉬 맵을 만들고, 체이닝 방식으로 해쉬 충돌을 해결하게끔 만들면 될 것 같습니다. 이때 링크드 리스트를 우선순위 큐나 삽입 정렬 링크드 리스트로 구현하면, 정렬된 key들을 손쉽게 얻을 수 있을 것입니다.

Q8. TDD는 무엇이고 이것에 대해서 어떻게 생각하나요?

개인 프로젝트라면 상관없지만 팀 프로젝트라면 TDD는 꼭 필요하다고 생각합니다. 왜냐하면 잘 작성된 테스트가 있어야 자신을 포함한 다른 팀원에서 어떤 문제가 생겼을 때 대응하기 쉽기 때문입니다. (이미 전 지원자가 개념을 잘 설명해주었습니다.)

모범 답안

TDD란 테스트 주도 개발의 약자로써 말 그대로 테스트가 주도하는 개발 방법론입니다. TDD가 제대로 적용된 코드라면, 보다 객체 지향적이고 보다 효율적인 코드 작성을 할 수 있습니다. 다만, 잘 작성된 테스트 코드를 짤 수 있기 위해선 어느 정도 훈련이 필요합니다. 더불어 TDD는 다음의 주기를 갖고 있습니다.

1. 테스트 코드 작성
2. 테스트 실패
3. 성공을 위한 최소한의 코드 작성
4. 리팩토링

Q9. OOP 원칙에 대해서 알려주세요

개인 답변

OOP원칙으로 SOLID가 있습니다. 각각은 지금 생각나지 않습니다만, 한 가지 S, 이것은 단일 책임의 원칙입니다. 어떤 클래스가 있으면 그 클래스는 한 가지 기능만을 담당해야 한다는 법칙입니다. 예를 들어 은행 계좌 프로그램에서 입금/출금에 대해서 입금하는 기능을 단일 책임 원칙에 따르면 메소드로 나뉠것이 아니라 담당하는 클래스, 출금하는 기능을 담당하는 클래스로 나뉘어야 한다는 것입니다.

모범 답안

답변 할 때 SOLID는 다음정도로만 말씀하시면 될 것 같습니다.

• SRP(Single Responsibility Principle) : 단일 책임 원칙, 저의 개인 답변과 같습니다.
• OCP(Open Clos Princile) : 개방 폐쇄의 원칙, 클래스는 확장에는 열려있고, 변경에는 닫혀 있어야 한다는 원칙입니다.
• LSP(Liskov Substitution Principle) : 리스코프 치환의 원칙, 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다라는 원칙입니다. 쉽게 설명하면 부모가 동작하는 기능은 자식도 동일하게 동작해야 한다는 것입니다.
• ISP(Interface Segregation Principle) : 인터페이스 분리의 원칙, 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙입니다. 바꿔 말하면, 하나의 큰 인터페이스보다는 여러개의 작은 인터페이스를 구현하는 것이 낫다라고도 할 수 있습니다.
• DIP(Dependency Inversion Principle) : 의존 관계 역전의 원칙입니다. 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의 역전입니다. 쉽게 말하면 코드에서는 인터페이스에서 구현하는 클래스로 그 의존 관계가 흐르지만 실행시에는 역전된다 정도로 생각하시면 되겠습니다.

Q10. 자주 쓰는 디자인 패턴이 있거나 알고 있는 디자인 패턴에 대해서 알려주세요.

개인 답변

잘 모르겠습니다.(이미 앞선 지원자 분이 팩토리랑 빌더 패터에 대해서 설명하였습니다.)

모범 답안

당시 머리가 하얘져서 생각 안났지만 개인적으로 잘 아는 옵저버 패턴에 대해서 이야기 했어야 했습니다.ㅠㅠ 천추의 한... 옵저버 패턴이란 데이터 push 방식으로 데이터를 발행하는 Publsher에 대해서 데이터 변동을 감지하는 Subscriber를 두는 방식입니다. 데이터가 변동되는 것을 Publisher가 Subscriber로 데이터를 밀어주는 것이지요. 이를 구현한 것은 RxJava, 현재 스프링 5에 추가된 Webflux의 핵심 라이브러리인 Reactors가 있습니다.

Q11. 자바스크립트에서 클로저란 무엇인가요?

개인 답변

자바스크립트에서 클로저는 함수형 프로그래밍 할 때 내부 함수에서 쓰이지만 외부 함수에 정의된 변수를 가리킵니다.

모범 답안

클로저는 독립적인 (자유) 변수를 가리키는 함수입니다.

예를 들어서

function getClosure() {
  var text = 'variable 1';
  return function() {
    return text;
  };
}

var closure = getClosure();
console.log(closure()); // 'variable 1'

여기서 클로저는 getClosure()라는 함수입니다. 그러나 closure는 getClosure() 안에 정의된, text를 가리키고 있지요. 이런 것을 클로저라고 합니다.

Q12. MySQL DB 엔진에 2가지가 있는데, 이에 대해서 알려주세요.

개인 답변

잘 모르겠습니다. (세 지원자 모두 이 질문에 뚝배기가 깨졌습니다.)

모범 답안

MySQL DB 엔진에는 InnoDB, MyISAM이 대표적으로 쓰입니다. MyISAM은 이전에 나왔던 엔진인 ISAM(Indexed Sequential Access Method)의 단점을 보완한 엔진으로 비-트랜잭션 세이프 테이블을 관리합니다. 장점으로는 데이터 모델 디자인이 단순하여 전첵적인 속도는 InnoDB 엔진보다 빠르답니다. InnoDB는 MyISAM에서 지원하지 않는 트랜잭션을 지원합니다. 커밋과 롤백, 장애 복구, 외래키 등 다양한 기능을 지원하고 mysql을 설치하면 기본적으로 이 엔진을 사용합니다. 속도는 앞서 설명한 MyISAM보다는 떨어지지만 안정성이 굉장히 높기 때문에 많이 사용됩니다.

Q13. NO-SQL이란 무엇인가요?

개인 답변

NO-SQL이란 Not Only SQL의 약자로써 기존 SQL에 비해서 특정 기능에 대해서 더 나은 기능을 제공합니다. 보통 json형태의 도큐먼트 형식으로 데이터를 저장하고 확장성이 좋기 떄문에 비정형 데이터를 다루는데 좋습니다. DB로는 대표적으로 Mongo DB가 있습니다.

모범 답안

도큐먼트 형식이 아니라 관계형 데이터베이스와 다른 방식이라고 해주셔야 합니다. MongoDB가 도큐먼트 형식이고 저장하는 방식에는 여러 종류가 있습니다. Redis에는 Key-Value 스토어 형식으로 저장한답니다.

Q14. Redis와 MongoDB의 차이점을 알려주세요.

개인 답변

둘 다 NO-SQL DB인데 Redis는 인메모리DB이고 MongoDB는 MySQL처럼 서버-클라이언트를 설치해서 사용하는 데이터베이스이다.

모범 답안

더 자세한 차이는 MongoDB는 도큐먼트 형식으로 데이터 값을 저장하고, Redis는 Key-Value 스토어로 값을 저장한다는 것을 말씀해주시면 좋을 것 같습니다.

Q15. 당신의 방식 A가 있다. 근데 팀장은 특정 이유 없이 B를 하라 한다. 타협점은 없다. 이 상황에서 어떻게 할 것인지 말씀해 보세요.

개인 답변

시간이 있다면, 팀장에게 자신이 생각한 방식의 이유를 말씀드리고 팀장이 생각한 이유에 대해서 듣고 타협점이 없으니까 일단 B 작업을 수행합니다. 그 작업에 대해서 시간적 여유가 남는다면 A 방식도 구현해보고 둘의 성능을 비교할 것 같습니다. 만약 A가 좋다면 설득의 좋은 도구가 될 것이고 B가 좋다면 두 방식 다 알게 되기 때문에 저에게는 해로울 것이 없을거라고 생각합니다. 그러나 그럴 시간조차 없다면, B를 선택하고 차후에는 어떻게 해야할지 모르겠습니다.

Q16. 지원자 모두 백엔드 개발자를 원하는 것 같은데 저희 팀은 프론트엔드 개발도 합니다. 본인이 프론트엔드로 배정 받았을 때 어떨 것 같습니다.

개인 답변

저는 개발 자체가 재미있기 때문에 프론트엔드/백엔드 어떤 개발이라도 상관없을 것 같습니다. 다만 개인적으로는 백엔드 개발을 더 맡고 싶습니다.

개인 질문! 자소서 위주로!!

Q1. MSA에서 통신 방식이 무엇이 있을까요?

개인 답변

개인적으로 서버간 통신 시 http 기반 rest 통신으로 알고 있습니다.

Q2. 다른 방식이 있을까요?

개인 답변

그 외에는 잘 모르겠습니다만, 다른 방식이 있다면 TCP/IP 통신이 있을 것 같습니다. (여기에 대해서는 잘 모르겠습니다. 인터넷에 쳐도 잘 모르겠네요...)

Q3. MSA에서 통신할 때 성능과 안정성 2가지 이슈가 있는데 한 가지 이슈로 솔루션을 해결해야 합니다. 어떤 것을 선택할거에요?

개인 답변

서비스에 따라 다를 것 같습니다. 검색 서비스라 가정하면 저 같은 경우 성능이 조금 늦더라도 정보의 질이 더 우선이라고 생각하기 떄문에 안정성을 선택할 것 같습니다.

Q4. 본인이 자소서에 쓴 것은 성능을 더 선택할 것처럼 생각해서 물어본건데 다르게 대답하시네요?

개인 답변

(당황;;) 제가 자소서에 그렇게 쓴 것은 이런 이슈가 있는 것으로 아는데 회사에서는 MSA를 어떻게 바라보고 있는지 궁금해서 쓴 질문입니다.

Q4. 프로젝트에서 멀티 스레딩을 이용해 보셨는데 어떻게 동기화 같은 방식을 해결하셨나요?

이 질문은 공통적으로 물어봤던 질문입니다만, 프로젝트 성향이 강해서 개인 질문으로 분류하였습니다.

개인 답변

저는 synchronized 키워드 사용도 있지만, 제가 알기로는 자바에서 멀티스레딩에 안전한 자료구조체로 Vector가 있는 것을 알고 있습니다. 그래서 그 자료구조체를 사용해서 손쉽게 데이터 동기화를 할 수 있었습니다.

Q5. 프로젝트에서 통신 규약을 만들었다는데, 어떤 것을 만들었나요? 그리고 왜 그렇게 했나요?

개인 답변

헤더에 사용자번호와, 주차장 번호, 메세지 정보, 그리고 8자리의 주차장을 표현하는 비트를 담아서 시스템에서 통신되는 메세지 규약을 만들었습니다. 저희가 졸업 작품을 만들었을 때 최대한 외부 기술을 배제하고 대학 생활 내에서 배운 이론들을 토대로해서 프로젝트를 완성하자고 팀원들끼리 의견을 모았고 그래서 다른 플랫폼 간 통신을 위해서 시스템을 위한 통신 규약을 만들었습니다.

Q6. 그렇게 했을 때 어떤 문제점이 있었나요?

개인 답변

개인적으로 생각했을 때 건방져 보일 수 있는 답변이지만, 각 플랫폼에서 메세지 규약을 정해놓고 통신했을 때 별다른 문제점 없이 통신할 수 있었습니다.

Q7. 본인이 생각했을 때 그 규약이 실제로 쓸 수 있을까요?

개인 답변

실제로는 그런 규약을 사용할 수 없을 것 같습니다. 저희 시스템만을 자체적인 통신 규약이었기에, 외부 사용자가 이해하기도, 사용하기도 어렵다고 생각합니다. 설계적으로 생각했을 때 실패한 설계라고 개인적으로 생각하고 있습니다.

Q8. Vue, React를 사용하셨다고 썼는데 본인의 자바스크립트 수준이 어느정도라고 생각하시나요?

개인 답변

저는 바닐라 자바스크립트 기본적인 코드 작성이 가능합니다만, 백엔드 개발을 위주로 공부했기 때문에 뛰어나지는 않습니다. 다만, React, Vue를 이용하면 간단한 화면 작성, To-Do list는 만들 수 있습니다.

Q9. 리액트에서 라이프 사이클에 대해서 아는대로 알려주세요.

개인 답변

제가 redux 같은 상태 관리 라이브러리를 사용하기 때문에 세세한 라이프 사이클에 대해서는 잘 알지 못합니다. 상태관리 라이브러리를 사용하지 않는다면 componentDidMount에서 ,API 호출이나 이런 것들이 작성되는 것으로 알고 있습니다.

모범 답안

위의 답변은 완전히 틀린 답변입니다. 다음 정도만 말했다면, 어땠을까하는 아쉬움에 적어봅니다.

리액트 라이프 사이클은 다음과 같습니다.

1. Mount
   1. constructor
   2. componentWillMount //API 호출은 여기에서입니다.
   3. render
   4. componentDidMount
2. Update
   1. componentWillReceiveProps //props 변화가 일어날 때만 1번이 실행됩니다. state만 변화할 경우 2번만 실행됩니다.
   2. shouldComponentUpdate
   3. componentWillUpdate
   4. reder
   5. componentDidUpdate
3. UnMount
   1. componentWillUnMount

추가적으로 뷰의 라이프 사이클은 다음과 같습니다.

1. Create
   1. created
   2. beforeCreate
   3. created
2. Mount
   1. beforeMount
   2. mounted
3. Update
   1. beforeUpdate
   2. updated
4. Destroy
   1. beforeDestroy
   2. destroyed

마지막으로 회사와 지원자에 대한 공통 질문!

마지막으로는 회사에 대해서 지원자가 어떻게 생각하고 있는지랑 인터넷에서 검색했던 것처럼 읽은 서적을 묻는 등의 질문이 주를 이루었습니다. 이 답변은 회사랑 밀접한 관계가 있는 질문만 공유하겠습니다. 다음은 마지막 내용에 대한 질문입니다.

Q1. 회사에서 어떤 직무를 하고 싶어서 지원했나요?

Q2. 회사에 대해 질문하고 싶은것 있으세요?

Q3. 회사의 서비스 써봤나요?

Q4. 주력 언어는 무엇인가요?

개인 답변

개인적으로 알고리즘을 표현할 때는 파이썬, 백엔드 개발할 때는 자바, 자바스크립트, 프론트엔드 개발 떄에는 자바스크립트를 사용합니다.

Q5. 최근에 읽은 서적에 대해 알려주세요.

개인 답변

최근 읽은 서적으로는 "리액트를 다루는 기술", "Do it Vue.js"가 있고 현재 읽고 있는 서적으로 "Programming Rust"가 있습니다.

후기

개인적으로는 코딩 시험을 뚫어서 실무진 면접까지 올라가서 좋았습니다. 그리고 면접관님들도 지원자들을 최대한 알아보려는 노력이 질문 곳곳에 묻어 있는게 느껴져서 정말 감사했습니다. 한 가지 아쉬웠던 점은 코딩 테스트에 대한 질문은 일체 없었습니다. 아무래도 난이도가 워낙 쉬워서 질문하지 않았던 것 같습니다. 열심히 준비했는데 정말 아쉽더라구요. 결과는 아쉽게도 탈락이었습니다. 다만 좋은 경험을 했고 그 경험을 하게 해준 회사와 면접관에 대해서 감사 인사를 표하고 싶습니다.