서론
삼성전자 Samsung Research는 정말 가고싶은 기업중 하나였고, 그만큼 대학원 졸업시즌부터 취업하고 나서까지 계속해서 시도하고 노력해왔었다. 물론 취업 직후라 거의 준비를 못해 간 경우들도 존재하긴 했지만, 나름 준비를 열심히 한 것들 위주로 정리해 보겠다. 한때 첫 번째 시험은 네이버 블로그에 게재했었는데 그 이후 업데이트된 내용을 보충하여 이렇게 후기글로 작성한다.
이 글의 취지는 서류 결과 발표 일정 및 코딩테스트 일정을 공유하고 시험장에 들어가기 전에 알면 좋은 사항들 그리고 느낀점에 대해서 포스팅 해보고자 한다. (삼성전자 코딩테스트를 붙어본적이 없어 어떻게 공부하라 라고는 말은 못하겠다)
삼성전자 지원 및 코딩테스트 이력
(첫 번째 try : DX- 삼성 리서치) 대학원 취준기간중
일정 | 이벤트 |
2021-09-17 | 서류 제출 |
2021-10-13 | 서류 결과 발표 |
2021.10.24(일) 09:00 ~ 12:30 (시험 시간) 3시간 | 코딩 테스트 시험 |
(두 번째 try DX- 삼성 리서치: 2022년 상반기 취직 직후 시험 준비도 못했었고 기록이 남아 있지 않다)
(세 번째 try : DX- 삼성 리서치)
일정 | 이벤트 |
2022.09.06 ~ 2022.09.14 (지원 기간) | 서류 제출 |
2022.10.05 | 서류 결과 발표 |
2022.10.16(일) 08:30 ~ 13:00 (시험 시간 이때부터 4시간 ) | 코딩 테스트 시험 |
(네 번째 try : DS- 혁신센터)
일정 | 이벤트 |
2023.09.11 ~ 2023.09.18 (지원 기간) | 서류 제출 |
2023.10.06 | 서류 결과 발표 |
2023.10.15(일) 14:30 ~ 19:00 (시험 시간) 4시간 | 코딩 테스트 시험 |
(다섯 번째 try: DX- 디바이스플랫폼센터)
일정 | 이벤트 |
2024.03.16 | 서류 제출 |
2024.04.05 | 서류 결과 발표 |
2024.04.14(일) (시험 시간) 4시간 | 코딩 테스트 시험 |
후기 공통 부분
시험 장소: DX부문 - 삼성전자 인재개발원 / DS부문 - DS 동탄에듀센터
위치(지도): 삼성전자 인재개발원/DS에듀센터 동탄 지도 순입니다.
좌석 : 상당히 넓은 자리에 1인 1석으로 되어 있었다.
컴퓨터 : 각자 노트북과 키보드 (또는 Desktop), A4용지 2장이 비치되어있었다
사용 가능한 언어 : C++, Python, Java
라이브러리 제한 사항 :
Python의 경우 일부 Library가 제한되어 있다. sys / sys.stdin.readline()는 확실히 사용 못하고 itertools도 사용 못했던걸로 기억한다. itertools는 아리까리 함. Python외의 언어들은 특별한 제한은 없었다.
1. 첫 번째 Try 후기 (석사 과정중)
첫 번째 후기의 교훈 : 제출 형식을 잘 맞추자
준비하면서의 심정
당시 석사 졸업을 준비하면서 취업준비하는 입장이다보니 알고리즘 공부를 남은 11일동안 했어야 했고 바로 백준에 들어가서 기출문제들을 보면서 계획을 세웠다. 평소 연구실에서 심층강화학습/시뮬레이션 관련 코드를 짜기는 하지만 알고리즘 코딩은 완전 다른 이야기였다.
이번 기회를 놓치고 싶지 않은 마음과 동시에 백준에 있는 삼성 기출문제 약 50문제를 보면서 착잡한 마음이 들었는데, 그래도 이 상황에서 할 수 있는 일들은 해야겠다 싶어 계획을 짜서 한 문제씩 격파해 나가기 시작했다. 목표는 시험장 들어가서 2문제중 1문제만 완벽하게 풀고 나온다.
준비 과정
참고로 나는 기계공학을 학부때 전공 했으며 알고리즘 수업은 대학원에 와서 들었다. 가까스로 BFS, DFS, 자료 구조 등 개념만 알고 있었던 나는 한 문제 한 문제를 푸는데 시간이 오래 걸렸고 (최대 2일) 이 속도로는 절대 기출을 다 볼 수 없을 거라는 생각에 전략을 변경했다. 최근 기출 10개정도만 문제의 본질을 이해하고 유형을 알아갈수 있도록 했다. 덕분에 21611번- 마법사 상어와 블리자드 이 문제 시간초과난것만 빼면최근 상어 관련문제는 다 풀었다.
알고리즘 시험에 익숙해지는 가장 빠른 길은 내가 구현할 거를 생각해보고 다른 사람 코드를 이해하는 방법인듯 하다. 그리고 왜라는 질문을 계속 던져가며 그 구현은 왜 이렇게하면 편한지 특징들을 파악해나갔다. (내 사고의 흐름에 맞추는 과정) 이렇게 익숙해질때까지 사고 시뮬레이션을 반복했다.
덕분에 처음에 2일걸리던게 점점 이해가 빨라지고 문제를 푸는 속도도 점점 빨라지는걸 느꼈다. 그래도 1문제 구현하는데 족히 2시간은 걸렸다. 주변 얘기를 들어보니 2솔을 위해서 쉬운문제는 1시간에서 1시간 10분컷을 하고 나머지 시간을 어려운문제에 투자해야 한다고 들었지만 목표가 애시당초 1문제를 완벽하게 풀고 나오자였기때문에 큰 욕심을 내지는 않았다. 이렇게 준비를 나름 끝맞췄다
시험장에서
시험장에 들어서면 수험표검사를 하고 검사실을 찾아간다. 자리에 앉고 조금 기다리면 오리엔테이션 시간이 다가오는데 심장이 떨리기 시작한다. 오리엔 테이션이 끝나고 시험이 시작되자, 바로 타자소리가 들리기 시작했다. 심장은 터질것 같았지만 내 페이스를 지키고자, 차분히 A4용지에 문제를 파악하고 생각했던 알고리즘을 Pseudo-code로 적어나가기 시작했다.
당시 풀었던 1번째 문제 - https://www.acmicpc.net/problem/23288
주사위를 굴리는걸 구현해야하는데 이 부분이 생각보다 헷갈려서 나머지 부분부터 구현방법을 생각하고 적었다 (나머지는 BFS, 조건문만 이용하면 바로 구현 가능). 시간은 20분정도가 지나고 다른 사람들은 이미 타자를 불같이 치고 있었고 점점 마음은 초조해져 갔다. (내심 빠르게 풀고 혹시나 2번째문제를 풀 수 있지 않을까 하는 욕심때문에?) 결국 주사위를 구현해냈고 시간은 2시간 10분 ~ 15분정도 걸렸다 (디버깅 포함).
생각보다 시간은 걸렸지만 Sample test case (10개)도 읽어들여서 print했을때 모두 맞췄다. 그래서 아 됐다! 이제 서버에 제출하자! 해서 제출했는데, 그런데... '테스트 케이스와 맞는것이 없습니다' 자꾸 이런 메세지가 떴다.
진짜 멘탈이 실시간으로 나갔다. 아니... 10개를 다 맞췄는데 테스트 케이스랑 하나도 안맞을리는 없잖아.. 라는 생각과 함께 남은 시간으로 어떻게든 제출이 되겠지 생각을하고 출력을 계속 바꿔봤다. 참고로 삼성에서는 Test case 갯수도 입력으로 받는다.
T = int(input())
for _ in range(1, T+1):
################################
자네의 코드를 입력하게나
################################
print("# %d" %score)
그래서 이거 그대로 이용해서 작성한 코드를 넣어서 모든 Test case를 T=10개를 출력했다. 출력은 # 33 # 61 # .. 이렇게 잘 나왔었고 답도 맞았는데, 뭐가 문제인지 계속 헤매고 멘탈은 가출하고.. 도대체 나한테 왜 이러는데 라는 생각만 들었다. 끝나기 2~3분전 예시 출력부분에 하나를 발견했다.
# 1 33
# 2 61
# 3 361
...
지금 내가 바로 위에 빨간색으로 칠해 놓은 녀석들을 발견했다. 바로 Test case numbering이다. 솔직히 이때까지만해도 설마 저것때문에 안읽히는건가? 라는 생각을하면서 저 부분을 대수롭게 생각하지 않았다. 결국 3분이라는 짧은시간동안 저부분 고치지 못하고 냈다. 시험이 끝난 직후에도 저 부분이 문제라는 인식을 하지 못하고 있었다. 한심할 뿐이다.
다음날 복기를 하고 백준에 문제가 올라왔길래 백준 조건에 맞춰서 코드를 올렸다. 코드는 Python으로 작성한 코드이며 시험장에서 시험봤던걸 그날 복기해 놓은 코드다.
[주사위 굴리기2 - Die rolling]
주사위 구현 방법
매번 -현재 바닥면 숫자 중심으로 [상, 하, 좌, 우] 숫자를 update시켜 나갔다.
- 주사위가 위 아래로 굴러가면 좌우는 그대로 유지된다. (아래로 굴러가면 현재 바닥면의 숫자가 위로 가고 아랫면 숫자는 7-위로 간 숫자가 된다. 위로 굴러가면 그 반대로 하면 됨)
- 주사위가 좌우로 굴러가면 상 하는 그대로 유지된다. (좌로 굴러가면 현재 바닥면의 숫자가 오른쪽으로 가고 왼쪽 숫자는 7-오른쪽로 간 숫자가 된다. 우로 굴러가면 그 반대로 하면 됨)
from collections import deque
#T = int(input()) #Data set nums (삼성시험때는 있었는데 백준에서는 없어서 주석처리함)
N, M, K = list(map(int, input().split())) #행 렬
board = [list(map(int, input().strip().split())) for _ in range(N)]
#상하좌우
dy = [-1,1,0,0]
dx = [0,0,-1,1]
def BFS(board,y,x):
visit = [[False]*M for _ in range(N)]
Q = deque()
ref_value = board[y][x]
count=0
if visit[y][x] ==False:
Q.append([y,x])
visit[y][x] = True
count=1
while len(Q) != 0:
y,x = Q.popleft()
for _ in range(4):
ny = y + dy[_]
nx = x + dx[_]
#예외조건
if -1<nx<=M-1 and -1<ny<=N-1 and board[ny][nx] == ref_value and visit[ny][nx] == False:
Q.append([ny,nx])
count+=1
visit[ny][nx] = True
return ref_value, count
def die_move(cur_die, dir, un_fold):
if dir==0: die_num = un_fold[0]; un_fold[1]=cur_die; un_fold[0]=7-cur_die #위로 굴러가면 현재 있는게 아래로 기준이 됨#up
if dir==1: die_num = un_fold[1]; un_fold[0]=cur_die; un_fold[1]=7-cur_die #down
if dir==2: die_num = un_fold[2]; un_fold[3]=cur_die; un_fold[2]=7-cur_die #left
if dir==3: die_num = un_fold[3]; un_fold[2]=cur_die; un_fold[3]=7-cur_die #right
return die_num, un_fold
cur_die = 6
dir =3
un_fold = [2,5,4,3] #상하좌우 #initial 6기준
yo=0; xo=0
score = 0
for order in range(K):
#print("check point",dir,dy[dir],dx[dir])
ny = yo + dy[dir]
nx = xo + dx[dir]
#벽에 튕기는거 예외 케이스
if nx<0: nx=1; dir=3
if nx>M-1: nx=M-2;dir=2
if ny>N-1: ny=N-2; dir=0
if ny<0: ny=1; dir=1
cur_die, un_fold = die_move(cur_die, dir, un_fold) #주사위 이동
board_num = board[ny][nx]
ref_value, count = BFS(board,ny, nx) #BFS
score += ref_value*count
if cur_die < board_num: #좌
if dir==0: dir = 2; pass
elif dir==1: dir = 3; pass
elif dir==2: dir = 1; pass
elif dir==3: dir = 0;
if cur_die > board_num: #우
if dir==0: dir = 3; pass
elif dir==1: dir = 2; pass
elif dir==2: dir = 0; pass
elif dir==3: dir = 1;
if cur_die == board_num:
dir = dir
yo =ny; xo=nx
print(score)
결과적으로 맞았고 내가 짠 알고리즘은 문제가 없다는걸 알았다. 백준 삼성문제집에는 Test case numbering 이 따로 존재하지 않아 제대로 인지하지 못했었던 것이다. 이때 심경은 진짜 제대로 풀어놓고 죽쒀서 개 준 느낌이랄까... 다른 사람한테는 쉬웠을지 모르겠지만 나에게는 나름 노력의 산물이다보니 이 한문제가 너무나도 큰 아쉬움으로 남았다. (비공식 1솔)
결론: {# Test Case Numbering Answer} 테스트 케이스 숫자 출력을 빼먹지 말자. 백준에서는 Test Case를 내가 따로 넣는게 아니라 내 알고리즘으로 직접 채점해주다보니 저 부분을 빼먹기가 쉽다.
3. 세 번째 Try 후기 (이번 시험부터 시험시간 4시간) - 재직중
세 번째 Try 교훈: 기간이 짧으면 언어를 함부로 바꾸지 말자, 한 번에 다 구현하고 디버깅 할 생각하지 말자
이번부터 삼성리서치가 아닌 혁신센터와 같은 IT와 관련된 곧으로 지원하기 시작했다. 어떻게 보면 내가 재직하면서 IT에 많이 익숙해지고 자신감이 생겼다고 볼 수도 있겠다. 이번 시험 기출부터는 백준에 문제 복기가 안되어 있다. 따라서 아래 코드트리 사이트에서 연습 할 수 있다.
또한 1번 문제는 그대로 빡구현 문제 2번 문제는 API구현 문제로 바뀌었다. (2번 문제는 자료구조를 물어보는 경향이 강해졌다. Linked List를 물어본다던지, Priority Queue를 물어본다던지)
준비하면서의 심정
직장에서 Python이 아닌 Java로 웹 개발을 하게 되면서 자연스럽게 Java로 코딩 테스트를 잘 보고 싶다는 생각이 들었다 이를 위해 프로그래머스와 백준에서 Java로 문제 풀이를 연습하기 시작했다. 아마도 업무에서 Java 개발자로서 좀 더 전문성을 갖추고 싶은 마음이 컸던 것 같다.
준비 과정 (9월 중순 ~10월 한달)
정적 타입 언어에 익숙하지 않았던 나는 Java를 코딩 테스트 수준까지 끌어올리는 데 시간이 꽤 걸렸다. Java 자체를 공부하면서 실무에는 많은 도움이 되었지, 코딩 테스트에서는 여전히 자주 막혔다. Python에서 쓰던 습관 때문에 Java에서 언패킹과 같은 말도 안 되는 문법을 자연스럽게 시도했던 적도 있었다. 한 달 반 정도 연습한 끝에 Java로 코딩 테스트를 푸는 데 어느 정도 익숙해졌지만, 여전히 삼성 알고리즘 문제는 더 많은 시간이 걸렸고 코드 줄 수도 Python보다 1.5배 이상 길었다. 그렇게 8~10문제 정도를 Java로 풀어보고 시험장에 들어갔다.
이 시기 준비 과정에서 BFS, DFS, 브루트 포스, 백트래킹 등 다양한 빡구현 유형의 문제들을 접하며 나름대로 실력을 쌓을수 있었던 거 같긴하다.
* 퇴근후에 매일 같이 코딩테스트 연습 프로그래밍 언어 공부를 했었다. 실무에서 도움이 많이 되긴 했지만 시험은 익숙한 언어로 보는걸 추천한다.
시험장에서
이번 전략은 문제를 대충 이해하고 나서 푸는 과정에서 자주 갈아엎었던 경험을 바탕으로, 완벽하게 알고리즘 설계를 끝내고 나서 구현을 시작하자는 것이었다. 해당 문제는 아래 링크에 걸어두었다.
그렇게 약 1시간 동안 알고리즘 설계를 마친 후, 중간 확인 없이 알고리즘 전체를 한 번에 구현하고 디버깅을 시작했다. 하지만 이런 방식은 미친 짓이었다. 정말 고수라면 한 번에 구현해서 맞출 수 있겠지만, 나는 그런 수준이 아니었다 (착각이었을까). 설계를 완벽하게 했다고 생각했지만, 여전히 허점과 실수가 많았다. 결국, 중간에 막히고 헤매다가 손을 놓아버리게 되었고, 이전 시험보다 1시간이 더 주어진 상황에서도 제대로 구현하지 못한 채 멍하니 있다가 시험장을 나왔다. 정말 허무하기만 하다. 이번 시험을 통해 중간중간 메소드마다 테스트 케이스로 확인하면서 구현하는 것이 올바른 접근이라는 것을 깨달았다.
해당 문제 이후 다시 풀어서 github에 올려 놓았다. (BattleField.java)
https://github.com/taehyuklee/Algorithm/tree/main/Algorithm-Samsung/JavaVersion
결론: 굳이 코딩테스트에 익숙한 언어를 바꾸지 말고, 한 번에 다 구현후 디버깅 하지말자.
4. 네 번째 Try 후기 - 재직중
네 번째 Try 교훈: 뭘까...??
이쯤되면 삼성전자 알고리즘 시험하고 나랑 맞지 않는듯 해 보인다. (SK(주) C&C로 중고신입 이직이후 5번째 시험보긴 함. 마지막 미련이랄까..)
준비하면서의 심정 (8월 말 ~10월 한달)
경력이 쌓이기 전에 중고 신입으로 (2년차 전) 이직하고 싶은 마음이 절실했다. 특히 원래부터 가고 싶었던 삼성전자가 계속 눈앞에 아른거렸고, Java로 솔루션 개발도 하고 코딩테스트 꽤나 봤겠다. 마지막 도전이라 생각하고 모든 것을 걸기로 했다. 퇴근 후, 심지어 휴가까지 내면서 코테연습에 집중했다.
막바지 일주일 동안은 컨디션을 관리하며 오전 시험 시간에 맞춰 바이오 리듬을 조정했다. 매일 퇴근 후 저녁을 먹고 나서 밤 8시부터 12시(자정)까지, 주어진 4시간 안에 시험 문제 두 개를 푸는 연습을 반복했다. 덕분에 삼성전자가 선호하는 구현 문제들(나선형 좌표, 주기적 경계 조건, 막혔을 때 반대 방향으로 전환하는 방식 등)을 보면 바로 구현할 수 있을 정도의 실력이 되었다. 그만큼 절실했기에...
시험장에서
실전식으로 문제를 꽤나 풀었기때문에 어느정도 자신감이 올라가 있는 상태였다. 문제를 열심히 풀었다. 어떻게든 구현해서 테스트 케이스를 모두 맞추는 데 집중했다 (Hidden Case는 크게 신경 쓰지 않았다 A형이기때문에). 당시 첫 구현 문제는 아래 링크로 걸어 두었다.
미친소 문제였다(당시 루돌프의 반란 문제)
이때 시험장에서 체감상 문제를 읽어 내리고 읽어내려도 끊이질 않았다. 해가 갈수록 단순히 코드 구현 능력뿐만 아니라 문제를 정확히 이해하는 능력도 점점 더 중요해지는 것 같았다. 해당 문제에서 핵심 포인트였던 넉백 효과, 사람이 밀리면 연쇄적으로 다음 사람이 밀리는 시뮬레이션을 재귀 함수로 훌륭하게 구현했다. 그런데 가장 단순한 부분에서 실수가 나왔다. 문제에서 요구한 최단 거리(L1 Norm)를 굳이 필요 없는 BFS로 구현하는 바람에 오류가 발생하기 시작한 것이다.
어려운 부분은 잘 구현했으면서도 쉬운 부분에서 실수가 생긴 것이다. 1시간 30분을 남기고 모든 구현이 끝났음에도 불구하고 10개의 테스트 케이스 중 6~7번째부터 계속 틀리기 시작했다. 이미 머리가 지쳐 있었고 디버깅이 쉽지 않았지만, 1시간 30분이 남아 있었기에 꾸역꾸역 계속 시도했다. 결국 마지막까지 디버깅에 실패했고, 그대로 제출할 수밖에 없었다.
해당 문제 이후 다시 풀어서 github에 올려 놓았다(2024-루돌프 소싸움 최종본.java)
https://github.com/taehyuklee/Algorithm/tree/main/Algorithm-Samsung/2024-The%20first%20Half-Samsung
결론: 연습부족이라고 하기에 삼성전자의 알고리즘 시험문제가 나랑 이제 잘 안맞는다는 생각이 든다.
5번째 시험은 SK로 이직후 팀배치 받는 등 정신없이 지나가서 후기를 남길게 없어 일정만 공유하도록 한다.
맺음말
삼성전자의 기나긴 여정은 여기서 종지부를 찍었다. 앞으로 삼성전자와의 인연이 닿을지는 모르겠지만, 우선 계속해서 내 서류를 붙여준 인사팀에 무한한 감사함을 느낀다. 이제 기회가 된다면 경력 이직으로 도전해보도록 하겠다.
그리고 삼성전자 코딩테스트에서 자주 나오는 구현 방법론들을 정리하여 포스팅한 글을 공유합니다.
삼성전자 코딩테스트 보시는 분들 화이팅입니다! 이 글이 조금이라도 도움이 되기를 바랍니다.
'후기 > 취준-이직 후기' 카테고리의 다른 글
삼성전자 코딩테스트(코테) 구현 모듈 (공유) (0) | 2024.10.08 |
---|---|
[신입 공채] SK C&C - 코테 및 면접 (최종 합격) 후기 (0) | 2024.05.15 |
[신입 공채] 현대자동차 (카클라우드 직무) - 코테 및 면접 (1차 면탈) 후기 (0) | 2024.05.12 |
[신입 공채] LG 전자 - 코테 및 면접 (최종 탈락) 후기 (2) | 2024.05.10 |
[신입 공채] kt ds - 기업 코테 및 면접 (최종 합격) 후기 (0) | 2024.05.09 |