삼성전자 SW 역량테스트 B형 후기 2 (첫번째 테스트)
Study 카테고리의 다른 글
이전 글에 이어지는 삼성전자 SW 알고리즘 역량테스트 B형 취득 후기입니다. 이번 글에서는 2번의 시험 중 첫번째 시험을 치르면서 느낀 점을 정리해보았습니다.
삼성전자 SW 알고리즘 역량강화 특강에 참가하여 2번의 B형 테스트를 치를 수 있는 기회를 얻었습니다. 현재 코로나로 인해 상시 테스트가 계속 미뤄지고있는 것으로 알고 있는데, 정말 좋은 기회를 얻었습니다.
B형 테스트
이번 테스트는 최초로 비대면으로 진행되었다고 합니다. VDI (가상 데스크탑) 을 이용하여 대면 시험과 거의 동일한 환경에서 테스트가 진행되었습니다.
인터넷 접속은 불가능하고 VDI에 설치된 IDE (Visual Studio, Pycharm, Eclipse) 만을 이용할 수 있습니다. 대면시험과 동일한 환경에 화상 감독으로만 변경되었다고 생각하시면 됩니다.
앞으로 테스트가 어떤 형태로 진행될 지는 모르겠지만 비대면 시험도 괜찮다고 느꼈습니다. 본인이 익숙한 장소에서 익숙한 장비(모니터, 키보드) 로 시험을 치를 수 있고, 직접 왔다갔다하는 번거로움이 없어서 좋았습니다!
8월 21일 첫시험
첫 시험은 사실 별로 긴장을 하지 않고 봤습니다. 실전문제 몇문제를 풀어본 상태였고 한번의 기회가 더 있었기에 가벼운 마음으로 임했습니다. 심지어 필기할 펜과 종이도 준비하지 않았습니다. (메모장 앱을 사용하였습니다.)
다소 자만하여 시험에 임했고, 결과적으로는 제대로 당했습니다…
시험 문제를 봤을 때 첫 느낌은 “너무 쉬운데…?’ 였습니다. 그러나 제약사항을 보고 B형 시험이 테스트하고 싶어하는 것이 무엇인지 깨달았습니다. A형에서는 볼 수 없는 엄청난 사이즈의 제약사항 (1억, 10억…) 을 보았고 어떻게 풀어야할 지 생각해 보았습니다.
문제 자체는 언젠가 한번쯤 접했을 법한 심플한 문제였습니다. 그러나 사이즈 제약이 커서 효율적으로 동작시키는 것이 관건인 문제였습니다.
배열을 사용하는 것은 당연히 불가능하고, 저는 세개의 링크드 리스트를 만들어 서로 연관시키는 방식으로 알고리즘을 설계했습니다. 배드 케이스에서는 시간초과가 날 수 있으나 더 효율적인 방식은 존재하지 않는다고 판단하였습니다.
설계한 대로 구현하던 도중, 링크드리스트를 3개 대신 2개만 이용하여 풀면 코드가 더 간결해질 것이라고 생각했습니다. 2개로 푸나 3개로 푸나 배드케이스는 같아서 시간복잡도에서 손해를 보지 않을 것이라고 생각했습니다. (이게 큰 실수였습니다.)
그래서 구현 도중 설계를 바꾸었고 그대로 구현을 끝마쳤습니다. 테스트 결과 애매한 시간이 나왔고, 테스트 케이스를 하나씩 체크해보며 어디에서 시간이 많이 소모되는지 확이하였습니다.
25개의 테스트 케이스 중에서 단 하나의 케이스만 과도하게 시간이 오래 걸리는 것을 확인했습니다. 해당 테스트 케이스를 분석해보았고, 처음 설계했던 대로 3개의 링크드 리스트로 구현했어야 했음을 깨달았습니다.
그러나 코드의 큰 틀을 바꾸기엔 이미 시간이 너무 지나버렸고, 결국 그대로 제출할 수밖에 없었습니다.
운이 정말 좋지 않는 이상 통과할 수 없을 것이라고 생각했고, 역시나 이번 테스트에서는 통과하지 못했습니다.
느낀점
첫 시험을 치르면서 느낀점이 많았습니다.
자만하지 말자
처음 보는 시험을 너무 쉽게 생각했던 것 같습니다. 다음 시험은 제대로 준비하고 진지하게 임해야겠다고 생각했습니다.
배드 케이스 & 엣지 케이스
제가 처음에 설계했던 알고리즘과 중간에 바꾼 알고리즘의 배드 케이스 시간복잡도는 같았습니다. 그러나 실제로 배드 케이스는 아주 특수한 저격성 시나리오에서만 발생하게 됩니다. 일반적으로 그런 시나리오는 주어지지 않는다고 봅니다.
일반적인 시나리오에서는 바꾼 구조가 살짝 비효율적이나 시간복잡도는 같았습니다. 둘 다 충분히 통과할 수 있을 만한 시간복잡도를 가집니다.
그러나 문제는 엣지 케이스에서 발생했습니다. 처음 설계했던 구조에서는 엣지 케이스에서도 일반적인 케이스와 비슷한 시간 복잡도를 가졌습니다. 그러나 두번째 구조에서는 엣지 케이스의 경우에 배드 케이스와 동일한 시간복잡도를 가졌습니다.
가능한 시나리오를 생각해보고 여러가지 형태의 테스트 케이스에 대해서 생각해 보아야합니다. 이때, 일부러 저격하지 않는 이상 발생하지 않는 시나리오는 배제하여도 무방합니다.
구현 도중 설계를 바꿀 경우
만약 제가 중간에 설계를 바꾸지 않았다면 테스트를 통과할 수 있었을 것입니다. 그러나 구현 도중 설계를 바꿔야하는 상황은 빈번하게 발생합니다.
설계한 대로 100% 구현할 수 있는 상황은 거의 없습니다. 따라서 구현 도중 설계를 바꿔야할 상황이 오면 다시 설계 단계로 돌아가 신중히 생각해보는 과정을 거쳐야합니다.
제가 설계를 바꿔야겠다고 생각하고 잠시 구현을 멈추고 다시 설계하면서 여러 케이스에 대해 신중히 고민했다면 이번과 같은 실수는 발생하지 않았을 것입니다.
급하게 코드를 작성하지 않고 신중히 생각하면서 문제를 풀어나가는 자세가 필요합니다.
8월 27일 두번째 시험
첫번째 시험에서 많은 것을 느끼고 두번째 시험은 제대로 준비하고 제대로 치렀습니다.
이에 대한 내용은 다음 글로 남기겠습니다.
댓글남기기