개발새발 블로그

이번에 이직 면접을 보면서 정리한 기술면접 질문리스트입니다.

구글링 시 나오는 신입 개발자 질문리스트를 참조한 게 많은 도움이 되었습니다.

답은 찬찬히 채워 넣는걸로 😂

본인 경력: 2년 (2022)

지원 포지션: 백엔드/풀스택

면접 시간: 30분~3시간 (평균 40분 내외)

JAVA

1. Java 컴파일 과정
2. Static의 의미, 장단점
3. OOP (객체지향 프로그래밍)의 개념
4. OOP의 4가지 특징 (추상화/캡슐화/상속/다형성) 💎💎💎
   - 오버로딩, 오버라이딩 질문이 가장 많았음
5. OOD (객체지향 설계)의 5원칙 SOLID
6. Java 8버전의 특징
7. 접근 제어자 4가지 종류
8. GC(가비지 컬랙션) 설명

SPRING

1. Spring의 특징 💎💎
2. Spring의 구동원리
3. DispatcherServlet의 역할
4. IOC(제어의 역전) 설명, 장단점
5. DI(의존성 주입) 설명, 장단점
6. AOP(관점지향 프로그래밍) 설명, 장단점 💎💎💎
7. Spring과 Spring boot의 차이점
8. Spring에서 사용해 본 어노테이션은?
9. Spring Cloud 설명
10. Spring Security 설명
11. Spring MVC 패턴 설명

DATABASE

1. 트랜잭션의 의미
2. 트랜잭션의 4가지 특성 ACID
3. Index 설명
4. NoSql과 RDB의 차이점

NETWORK

1. 브라우저에 URL을 입력했을 때 서버로 전달되는 과정
2. HTTP와 HTTPS 프로토콜 차이점

ETC

1. REST API Method의 특징 💎💎💎
2. API 설계 해보세요. (손코딩)
3. 쿠키와 세션의 차이점
4. 웹서버와 WAS의 차이점
5. Git과 SVN의 차이점
6. 프레임워크와 라이브러리의 차이점
7. 온프레미스 서버를 클라우드로 이전 시 진행 과정
8. Rolling, Blue Green, Canary 배포 전략
9. Java 외에 써 본 언어가 있나요?

1. Overview > Contribution settings > Private contributions 활성화

2. 자신이 기여한 리포지토리에 스타를 찍는다.

비공개 조직 탈퇴 후 로그인 상태에서 확인해보면 기록이 잘 뜬다.

깃허브 포럼글의 일부인데 풀리퀘나 이슈도 들어가기는 하지만 별 찍어두는게 안전해보인다.

모두 미리 해둬서 소중한 잔디를 유지하자

A commit will only count as a contribution if one of the following is true:

• You are a collaborator on the repository or are a member of the organization that owns the repository.
• You have forked the repository.
• You have opened a pull request or issue in the repository.
• You have starred the repository.

We recommend starring any repositories you contribute to. That way, your commits to those repositories will remain in your contributions graph even if you leave the organization that owns the repository or delete your fork of the repository. Learn more about stars 116.

• 참고글

Keep Github commit graph when leaving an organization

https://github.com/isaacs/github/issues/1138

https://github.community/t/getting-all-your-commits-in-your-contributions-graph/10186

• Spring boot + Thymeleaf + IntelliJ
• 개발 툴에서 실행시 정상 작동하나 jar로 실행시 index 페이지만 진입되고 다른 페이지는 뷰단을 못찾음
• application.yml에는 Thymeleaf 설정하지 않음
• view path: /member/custom-login

template might not exist or might not be accessible by any of the configured Template Resolvers

18:46:38.954 [http-nio-8080-exec-10] ERROR org.thymeleaf.TemplateEngine - [THYMELEAF][http-nio-8080-exec-10] Exception processing template "/member/custom-login": Error resolving template [/member/custom-login], template might not e
xist or might not be accessible by any of the configured Template Resolvers
org.thymeleaf.exceptions.TemplateInputException: Error resolving template [/member/custom-login], template might not exist or might not be accessible by any of the configured Template Resolvers
        at org.thymeleaf.engine.TemplateManager.resolveTemplate(TemplateManager.java:869) ~[thymeleaf-3.0.15.RELEASE.jar!/:3.0.15.RELEASE]
        at org.thymeleaf.engine.TemplateManager.parseAndProcess(TemplateManager.java:607) ~[thymeleaf-3.0.15.RELEASE.jar!/:3.0.15.RELEASE]

spring:
  thymeleaf:
    prefix: classpath:/templates/

spring.thymeleaf:prefix: classpath:/templates/ 옵션을 추가하였으나 효과가 없었음 

경로에 슬래시(/)가 중복으로 들어가면 에러가 발생 한다고 한다.

리턴 패스를 "/member/custom-login"에서 "member/custom-login"로 변경하자 정상 작동하였다.

spring.thymeleaf:prefix: classpath:/templates <- 여기서 슬래시를 지워도 작동 되지만

해당 옵션 디폴트 값이 classpath:/templates/라서 패스에서 슬래시를 빼는 쪽으로 가기로 했다.

## 참고글

https://bigphu.tistory.com/94

https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.templating.spring.thymeleaf.enabled

골드는 금방 찍을 줄 알았는데 생각보다 오래 걸렸다.

처음에는 리트코드에서 자바로 문제를 풀었다.
그런데 PS도 초심자인데 영어문제라 이해하는데 한세월이 걸렸다 ㅋㅋ

백준+파이썬으로 바꿨는데 지금이면 리트코드도 할만하지 않을까?

파이썬을 사용하면서 자바 개발자인데 파이썬으로 풀어도 되나,

새로운 언어라 어렵지 않을까 했는데 바꾸기 잘한 선택이었다.
내장 라이브러리도 좋다보니 실버까진 쭉쭉 풀렸다. 
여기까진 알고리즘 공부보단 파이썬 문법에 익숙해지는 과정이라고 본다.

실버 2부터 시간초과 지옥에 빠졌다. 

문제 밑에 보면 힌트로 알고리즘 분류가 있다.
바로 문제풀이를 하지 않고 알고리즘을 검색해서 어떤 유형인지 찾아보고 풀었다.
그러다보면 이 문제는 무슨 알고리즘 쓰는구나 감이 온다.
최근에 알고리즘 책도 사서 틈틈이 읽고 있다.올해 안에 플레 후기를 올렸으면 좋겠다.

테스트 코드를 실행하니 @DisplayName의 한글 인코딩이 깨진다.

설정 > 에디터 > 파일 인코딩

에기서 인코딩 부분을 전부 UTF-8로 변경.

프로퍼티 파일 부분에서 명확한 Native에서 ASCll로의 변환 체크

{intelliJ}/bin/idea64.exe.vmoptions 파일에

-Dfile.encoding=UTF-8 < 항목 추가

도움말 > 사용자 지정 VM 옵션 편집

-Dfile.encoding=UTF-8 < 항목 추가

유닛 테스트 결과 DisplayName이 한글로 정상적으로 노출됨.

오늘 읽은 범위

• 9장: 단위테스트

책에서 기억하고 싶은 내용을 써보세요.

• TDD법칙

1. 테스트 코드를 먼저 작성하고 실제 코드를 작성한다.

2. 컴파일은 통과하면서 실행이 실패하는 정도로 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 만큼만 실제 코드를 작성한다.

• 테스트 케이스가 있으면 안심하고 설계를 개선할 수 있다. 가독성을 생각하여 실제 코드 못지 않게 깨끗하게 짜야 한다.
• FIRST 규칙

1. FAST

  테스트는 빨라야한다

2. INDEPENDENT

  각 테스트는 서로 의존하면 안되며 순서에 상관없이 실행 가능해야 한다.

3. REPEATABLE

  테스트는 어떤 환경에서도 반복 가능해야한다,

4. SELF-VAILDATING

  테스트는 성공/실패 두가지로 결과를 내야한다.

5. TIMELY

  테스트는 실제 코드를 작성하기 직전에 구현한다. 테스트 코드를 나중에 작성하게 되면 테스트를 포기 할 수 있다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• 현재 환경에서는 테스트 주도 개발을 하지않아 테스트 코드를 많이 작성해보지 않았다. 이번 챕터를 통해서 테스트 코드를 어떻게 작성할지 가닥을 잡았다.

오늘 읽은 범위

• 7장. 오류처리

책에서 기억하고 싶은 내용을 써보세요.

• 오류 코드보다 예외를 사용하라.

오류 코드를 사용하면 함수를 호출하면 바로 오류를 체크해야한다.

그래서 try~catch문을 이용하여 예외를 던지도록 처리하는 것이 낫다.

• try~catch~finally문 부터 작성하라

try블록에서 코드를 실행하면 어떤 시점이든 에러 발생시 catch문으로 넘어갈 수 있다.

catch 블록은 프로그램 상태를 일관성 있게 유지해야한다. 그래서 try~catch~finally 문을 먼저 작성하고 시작하면 좋다.

• null을 반환, 전달하지 마라

null을 반환하는 경우에는 일일히 null 확인이 필요하다. 애초에 null을 넘기는 것을 금지하면 합리적이다.

Java의 경우 Optional 같은 Wrapper 클래스를 사용하거나 List의 경우 빈 리스트를 반환하는 방식으로 nullPointerException을 막을 수 있다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• try~catch 문을 사용하고 있긴하지만 오류코드와 함께 사용하고 있어 코드가 깨끗하지 않고 혼돈을 야기한 것 같다.
• 개발시 null 체크를 꼼꼼하게 하도록 신경을 썼는데, 처음부터 null을 못넘기게 금지하면 된다는 점이 센세이션했다.

오늘 읽은 범위

• 6장 객체와 자료구조

책에서 기억하고 싶은 내용을 써보세요.

• 자료구조

별다른 동작 없이 자료를 노출한다,

새로운 자료구조를 추가하기 어렵다.

기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다

• 객체

동작을 공개하고 자료를 숨긴다

새로운 함수를 추가하기 어렵다.

기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

• 기차 충돌

//전
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

//후
Option opts =ctxt.getOpthons();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

위와 같이 함수를 줄줄히 호출하는 코드를 기차충돌이라고 부른다.

각 함수를 끊어서 선언하는 방식으로 변경하면 좋다.

• 구조체 감추기

//전
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

//변경 1 -해당 방법도 노출되는 부분이 많다...
final String outputDir = ctxt.getAbsolutePathOfScratchDirectoryOption();

// outputDir를 쓰이는 코드를 보니 파일을 생성하기 위해서였군! 
String outFiel = outputDir + "/" + classNm.replace('.','/') +".class";
FileOutputStream fout =new FileOutputStream(outFile);
BufferdOutputStream bos = new BufferdOutputStream(fout);

//변경 2 - ctxt 객체에서 해결하도록 변경
BufferdOutputStream bos = ctxt.createScratchFileStream(classNm);

내부 구조를 감출 수 있도록 코드를 변경한다.

변경 2 같은 경우 해당 코드의 히스토리까지 파악해야 하므로 연습이 많이 필요할 것 같다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

짧은 분량인데 어려워서 여러 번 읽었다. 일단 많이 쓰는 기차 구조부터 피해보자.

절차적인 코드, 객체지향적인 코드는 각자 적합한 상황이 있으므로 최적의 조건을 선택하자.

오늘 TIL 3줄 요약

• 불필요한 주석은 달지 말자.
• 주석을 남길 때는 오해가 없도록 명확하게 전달되게 작성한다.
• 주석보다는 코드 자체로 의도가 전달 되도록 하자.

TIL (Today I Learned) 날짜

• 2022-04-29

오늘 읽은 범위

• 4장. 주석

책에서 기억하고 싶은 내용을 써보세요.

• 주석은 언제나 실패를 의미한다. 주석 없이 코드로 의도를 표현하도록 노력해야한다. (p.68)
• 코드에 주석을 추가하는 이유는 보통 코드품질이 나쁘기 때문이다. (p.69)

• 좋은 주석
  • 결과를 경고하는 주석 - 실행시간이 긴 테스트 케이스 등을 경고하는 용으로 사용가능. (p.73)
  • TODO주석 - 앞으로 할일을 TODO 주석으로 남겨보자. IDE에서 TODO 주석을 추적하는 기능이 있다. (p.75)
• 나쁜 주석
  • 의무적으로 다는 주석 - 너무 당연한 정보를 제공하거나, 쓸모 없는 내용
  • 오해할 여지가 있는 주석 - 명확하게 전달되도록 적자.
  • 사용하지 않는 코드 주석처리, 코드 수정내용 주석으로 남기기 - 버전관리에 남아있으니 안심하고 지우자.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 좋은 주석 파트에서 나온 TODO은 한번도 사용한 적이 없는데 써봐야겠다.
• 나쁜 주석 파트를 보면서 불필요한 주석을 많이 단 것 같다. 주석이 중요하다고 말만 들었지 어떤 식으로 써야하는지 몰랐는데 도움이 되었다. 남기기 위한 주석을 작성한 경험도 있고, 갓 취직 했을 때는 한동안 API 위에 꼭 author를 남기며 뿌듯해 했던 기억이 난다 ㅎㅎ..
• 이번 파트를 보면서 좋았던 점은 그나마! 잘하고 있던 점도 있었기 때문이다. 나는 코드를 쪼개서 변수 선언하는 것을 좋아하는데, 길고 멋있는 코드를 짜는 지인이 내 코드가 쉽다고 비웃은 적이 있기 때문이다. 역시 가독성이 짱짱
  주석 파트이지만 주석 없이 코드로 의도를 표현하는 법을 배워서 많은 도움이 되었다.

#코딩 #개발자 #노마드북클럽 #노개북 #클린코드 #CleanCode

오늘 TIL 3줄 요약

• 함수는 한 가지만 잘 수행해야 한다.
• 길이가 짧고 서술적인 이름을 가지도록 한다.
• 읽는 사람을 생각하며 작성하자.

TIL (Today I Learned) 날짜

2022-04-27

오늘 읽은 범위

3장. 함수

책에서 기억하고 싶은 내용을 써보세요.

• 작게 만들어라! (p.42)
  • 함수는 작을 수록 좋다.
  • 중첩 구조가 생길 만큼 함수가스 커져서는 안된다.
• 한 가지만 해라! (p.44)
  • 함수는 한 가지만 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.
  • 함수에서 의미 있는 이름으로 다른 함수를 추출 할 수 있다면 여러 작업을 하는 셈이다.
• Switch문 (p.46)
  • Switch 문은 분기가 여러개이므로 한 가지 작업만 하게 작성하기 어렵다.
  • 예시는 다형성을 이용하여 해결하는데, Switch문을 추상 팩토리로 이동시키고 파생 클래스의 인스턴트를 생성하는 것으로 중복을 피한다.
• 서술적인 이름을 사용해라! (p.49)
  • 짧고 어려운 이름보다 길고 서술적인 이름이 좋다.
  • 함수 기능을 가장 잘 표현하는 이름을 선택한다.
• 함수 인수 (p.50)
  • 인수 개수는 0개가 가장 좋다. 3개 이상은 피하자.
  • 인수가 많아지면 가독성이 떨어지고 테스트도 어렵다.
  • 인구 개수가 3개 이상이면 클래스 선언을 고려해보자.
• 부수 효과를 일으키지 마라! (p.54)
  • 함수명으로 예측되지 않는 작업을 하지말자.
  • 예) checkPassWord(password) -> 해당 함수에서 세션 수정하기.
• 오류 코드보다 예외를 사용하라! (p.57)
  • 오류코드를 이용시 조건문을 보통 사용하게 되어 중첩 코드를 야기하고, 오류 코드 반환시 즉시 처리해야 하는 문제가 생긴다.
  • 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리 가능하다.
  • try~catch 블록은 정상 동작과 오류 처리 동작을 섞는다. 각 블록을 별도 함수로 선언하면 좋다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 함수 부분 예시를 보면서 하지말라는 것은 다 하고 있었구나.. 뼈를 맞은 기분이었다. 주로 만지는 것이 레거시다 보니 몇백줄짜리 함수가 너무도 익숙하다. 특히 부수 효과를 일으키지 마라 ! 파트에서 아찔함을 느꼈다. 이런 문제로 유지보수를 하는 경우가 얼마나 많은가.. 책을 읽으면서 단호한 사수에게 코드 리뷰를 받는 것 같았다. 책의 내용을 한 번에 적용하기는 쉽지 않겠지만, 여러 번 읽으면서 체화되도록 노력해야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 추상화 파트에서 이해가 안되어서 내일 찾아보려고 함.

#코딩 #개발자 #노마드북클럽 #노개북 #클린코드 #CleanCode