[우테코] 레벨1 인터뷰

---

목차

1. 서론

2. 레벨 로그

3. 질문 준비하기

4. 피드백

---

 

 

---

🙂 서론

 

레벨 로그에 대한 후기를 작성할까 말까 하다가...

피드백 받았던걸 기록해두면 좋을 것 같아서 뒷북으로 작성해본다.

 

우아한테크코스에서는 새로운 레벨이 시작할 때마다 레벨 인터뷰를 진행한다.

이전 레벨에서 자신이 학습한 내용들에 대해 리마인드도 하고 현재 학습 상태에 대한 인지가 된다.

간만에 면접 준비(?)를 하려니까 덜덜 떨렸다. 긴장 MAX😖...

 

진행 과정은 아래와 같다.

1. 방학 기간에 각자 레벨 로그를 준비한다.
2. 다른 사람의 레벨 로그를 읽고 이를 바탕으로 질문을 미리 준비해둔다.
3. 인터뷰 당일에 질문하는 사람 / 답변하는 사람 / 관찰자 역할을 번갈아가며 진행한다.
   (관찰자: 말하기 역량에 대해 피드백 함)
4. 인터뷰를 진행한다.
5. 인터뷰를 마치면 서로에게 피드백을 해준다.

 

---

📚 레벨 로그

제출한 레벨 로그를 바탕으로 좀 더 디테일하게 풀어냈다.

 

전략 패턴

• : 유사한 행위들을 캡슐화해 인터페이스로 정의하는 일
• 다른 전략을 사용하고 싶을 때 로직을 수정하는 게 아니라 전략을 바꿔 끼우면 된다.

 

MVC 패턴

• model과 view를 분리하는 것은 view의 변경 사항이 model에 영향을 주지 않기 위함이다.
• view에서 사용하기 위해 toString을 재정의하지 마라. toString은 디버깅을 편리하게 하기 위해 재정의하는 것이다. view를 사용하기 위해 재정의하면 view의 변경이 있을 때마다 도메인을 변경하는 상황이 온다.
• 값에 대한 검증이 모두 도메인의 역할은 아니다. 예를 들어 로또 숫자를 저장한다는 클래스가 존재한다고 하자. 값이 a, b, c같은 문자가 올지 숫자가 오는지에 대한 검증과 숫자가 0에서 45 사이의 숫자인지에 대한 검증은 다르다.

 

Stream

• stream을 사용하는 것이 항상 좋은 것은 아니다.
• stream은 디버깅이 불편하고 성능이 더 떨어질 수 있다.
• 때에 따라 가독성이 더 떨어지기도 한다.
• stream을 사용함으로써 얻는 이득이 명백한 경우에만 사용하는 것이 좋다.

 

final

• 재할당 금지
• != 불변

 

접근제어자

• 모든 메서드가 static이면 생성자의 private화를 고려하라.
• 테스트를 위해 상수/메서드를 public화 하는 것은 부적절하다. 접근제어자는 항상 최소화하는 것이 캡슐화와 정보은닉에 좋다.
• 최소화된 접근 제어자는 변경에 의한 영향을 최소화할 수 있다.

 

getter

• getter의 제한 목적은 ‘객체에 메시지를 보내 자신의 상태에 대한 로직은 스스로 처리할 수 있도록 하기’ 위함이다.

 

테스트

• 하나의 테스트 메서드에서는 하나의 assert만 사용하자.
• 테스트에서 @DisplayName을 사용하자. @SuppressWarning을 통해 오류 무시가 가능하지만 오류를 무시하는 행위가 적절한 행동인지 생각할 필요가 있다.
• 테스트 코드는 메서드 사용법의 레퍼런스가 된다.

 

함수형 인터페이스

• : 1개의 추상 메서드를 가진 인터페이스
• @FunctionalInterface 어노테이션 사용 (없어도 동작은 하지만 함수형 인터페이스 조건에 부합되는지 검사해준다)
• Predicate: argument를 받아 boolean 값을 반환하는 함수형 인터페이스

 

정적 팩토리 메서드

• 인스턴스를 재사용할 때
• 의미 있는 이름의 객체 생성 메서드가 필요할 때
• 생성자를 private로 막고 정적 팩토리 메서드만 사용하는 경우 인스턴스 생성에 혼란이 올 수 있다. 이 경우 정적 팩토리 메서드의 네이밍 컨벤션을 준수하면 어느 정도 방지할 수 있다.

 

Enum

• : 열거체를 정의할 수 있는 클래스
• Enum을 key로 저장하는 경우 EnumMap의 사용을 고려하라.
  • null을 포함해 enum외의 값이 key가 되는 것을 막아준다.
  • 해시맵보다 빠르다. 둘 다 시간복잡도가 O(1)이지만 해시맵에서 발생하는 해시 충돌 문제가 없다.
    (+해시 충돌: 해시 테이블에는 해시함수와 어떤 연산을 거쳐서 나온 값을 인덱스 삼아 데이터를 저장한다. 이 때 연산에 의해 다른 값인데 같은 인덱스에 저장하려는 현상이 발생할 수 있다.)

 

Abstract Class vs Interface

	Abstract Class	Interface
상속 가능 개수	단일 상속 만	다중 구현 가능
하위에 영향	O	X
계층 구조	O	X

 

instanceof

• 캡슐화가 깨지기 쉽다.
• 이를 사용하는 이유는 보통 클래스에 따라 다른 로직을 실행하기 위해서이다.
  메서드를 직접 정의하는 방식으로도 충분히 로직을 짤 수 있다.

 

Exception

	Checked Exception	Unchecked Exception
예외 처리 코드	필수 (예측 가능하지만 예방하기 힘든 예외는 반드시 처리할 필요가 있다.)	선택
RuntimeException 상속	X	O
확인 단계	컴파일	런타임

• 예외를 처리하는 방법
  • 복구: DB에서 기본키 중복으로 인해 insert실패한 경우 입력받은 값에 난수를 더해 다시 insert 시도
  • 회피: exception 발생한 경우 throw를 하여 메서드를 호출한 쪽에서 처리하도록
  • 전환: 더 정확한 정보를 가진 Unchecked Exception으로 전환하여 throw

 

try-with-resources

• try-finally보다는 try-with-resources를 사용하자.
• try에서 선언한 객체가 AutoCloseable 인터페이스를 구현했다면 close() 메서드가 자동으로 호출된다.
• Java 9부터는 외부에서 할당해서 사용할 수 있다. (가독성 ↑)

 

JDBC

• : DB 관련 작업을 도와주는 Java API
• 개발자는 JDBC에서 제공하는 인터페이스를 사용한다. 이를 구현하는 구현체는 각 DB 회사에서 만들어 JDBC 드라이버를 제공해준다.
  • Connection을 통해 DB를 연결
  • Statement를 통해 SQL 저장
  • ResultSet을 통해 SQL 결과 저장

 

---

🐱‍👓 질문 준비하기

 

가능한 진짜 면접처럼 꼬리 질문으로 준비하려고 했다.

예제로 준비했던 질문 한두가지만 적어본다.

 

1. 테스트 메서드는 한글로 작성할 수 있다.
   • 테스트 메서드명은 어떻게 작성하시는 편이신가요?
   • 👉 한글로도 작성하는 경우 노란 전구로 경고가 떠요. 어떻게 해결하시나요?
   • 👉 @DisplayName와 @SupressWarnings의 차이점은 무엇인가요?
2. equals와 hashCode는 함께 정의해야 한다.
   
   • equals와 hashCode를 함께 정의해야 하는 이유가 뭔가요?
   • 👉 (HashMap, HashSet등의 답변이 나온다면) HashMap이나 HashSet에서 사용되지 않는다면 둘을 재정의할 필요가 없는걸까요?
   • 👉 equals와 hashCode를 함께 재정의했던 경험과 재정의한 이유에 대해서 설명 부탁드립니다.

 

---

😘 피드백

 

우리조 짱~~~ 감사합니다❤

 

😥 말하기에서 아쉬웠던 점

• 불필요한 추임새
• 목소리 톤 조절
• 숨 쉬면서 말하기 (ㅋㅋ)

 

너무 긴장해서 ㅋㅋㅋㅋㅋ ㅠㅠㅠㅠㅠㅠㅠ😂😂😂

목소리 너무 하이톤 올라가서 계속 목 아파했고 까먹기 전에 말한다고 말을 다다다다 내뱉는 자각은 있긴 했는데..

불필요한 추임새는 나도 몰랐던거라 듣자마자 아!!!!!!1 했다 ㅋㅋㅋ

 

 

😎 (주관적) 팁

• 애매모호한 이론적 지식을 설명하기 힘들다면 개인의 경험담을 가져와 설명하는게 편할 때도 있다.
• 원하는 방향으로 질문을 이끌어가기 위해 답변에 떡밥 던지기
• 예제 등을 말하다 답변이 길어질 것 같다면 두괄식으로 말하기
  (결론 -> 예제1 ->  예제2 -> ....)
• 안된다고 딱 잘라 말하기보다는 자신의 경험 상으로는 이랬다 식으로 서술하는게 더 자연스럽게 느껴질 수 있다.