[회고] 라이브 코딩 면접 후기

신선했던 면접 경험

---

최근 좋은 기회로 라이브 코딩 면접을 보게 되었습니다. 이제까지 코딩 테스트, 기술 면접, 과제 제출 방식은 경험해 봤으나, 라이브 코딩은 처음 접하는 방식이었습니다. 알고 보니 면접관이 보는 앞에서 코드를 직접 작성하며, 문제를 해결하는 테스트였습니다. 이러한 유형은 주로 소통 역량, 문제 해결 방법과 여러모로 회사와 핏이 맞는지 확인하는 목적이 크다고 합니다. (실제로 면접을 진행한 회사도 그러했습니다.) 저는 협업과 코드리뷰를 많이 해봤기 때문에 커뮤니케이션에 자신도 있었고, 평소 하던 대로 하면 되겠다고 생각하여 긴장을 덜하게 되었습니다.

라이브 코딩 주제는 '369 게임 만들기'였습니다. 알고리즘 구현일 거라 생각했지만, 주제 자체는 예상보다는 어렵지 않았습니다. 더 나아가 단계별로 문제를 해결하는 과정이 주어졌습니다.

• 1단계 : 주어진 요구사항에 맞게 369 게임 구현
• 2단계 : 오답률에 따른 게임 종료 및 사용자 등 몇 가지 심화 기능과 클래스 추가
• 3단계 : 지역별 다른 규칙의 369 게임을 위해 추상화 및 다형성 적용
• 4단계 : 다양한 지역 동시 게임 진행을 위한 동시성 적용

각 단계를 보면 객체지향 개념과 구현 역량을 필요로 합니다. 저는 이러한 문제 내용도 그렇고, 위 과정이 굉장히 흥미로웠습니다. 일반 코딩 테스트는 어느 정도 정해진 알고리즘과, 자료구조만 잘 활용하면 해결할 수 있습니다. 그렇다 보니 항상 '실제 구현 역량과 얼마나 연관이 있을까?' 하는 의문이 들었습니다. 해당 기업에서 주어진 문제는 기본적인 개념을 필요로 하면서 면접과정 동안 저의 문제 해결 방식을 체크하기 너무 좋다고 생각했습니다. 모든 라이브 코딩 면접이 그렇지는 않겠지만, 해당 기업의 문제는 굉장히 인상이 깊었습니다. 

 

쉽지 않았던 과정

---

 

부담을 최대한 내려놓고, 저의 방식대로 최선을 다 하였습니다. 요구사항에서 생긴 의문에 대해 질문도 던져보고, 의사코드를 작성하여 저의 문제 풀이 계획을 설명했습니다. 풀이를 하면서도 클린 코드도 잊지 않고, 세세하게 작성해 나아갔습니다.

하지만 한 가지 놓쳤던 점. 1시간이란 면접 시간을 잊고 있었습니다. 자기소개와 기타 시간을 제외하면 약 45분에 가까웠습니다. 시험 초반 커뮤니케이션에 너무 집중했던 나머지, 4단계 문제 중 2단계에서 면접 시간이 끝났습니다.

여기서 객관적으로 판단하자면, 저의 입장에서만 좋은 커뮤니케이션이었지 면접관 입장에서는 어땠을지 확신할 수 없습니다. 또 다른 한 가지는 '사용자의 오답률에 따라 게임 종료' 요구사항을 구현하는 부분에서 막혔습니다. (아마 이러한 부분에서 면접관 분에게 질문하면서 문제를 해결했으면 좋았겠지만, 마음이 급해지다보니 머릿속으로만 해결 방법을 고민하게 되었습니다.) 정말 아쉬웠습니다. 인상 깊었던 문제로 회사에 대해 더욱 관심도 생겼고, 회사에서 추구하는 핏이나 기술이 저와 100% 일치했기 때문입니다.

면접이 끝나고 아쉬운 마음에 스스로 재풀이를 해보았습니다. 여유를 갖고 풀어보니 1시간만에 모든 문제를 쉽게 해결할 수 있었습니다. 부담없이 저의 방식으로 최선을 다 하였다고 언급했지만, 지금 생각해보면 '잘보여야 한다'는 생각으로 가득했던 것 같습니다. 당시 '검색'도 자유였는데, 제 스스로가 검색을 부정행위라고 생각하였습니다. (검색을 잘하는 것도 개발자의 역량인데..)

 

문제 풀이 오답

---

 

문제 풀이 중 일부만 작성하였습니다.

1) 멘탈을 흔들었던 '오답률 구현'

요구사항
- 각 플레이어는 독립확율로 매 순서마다 오답율에 의거하여 답을 얘기/ 오답을 얘기하는 경우 게임 종료
- 오답 CASE) 박수쳐야할 때 숫자를 얘기한다거나, 잘못된 숫자를 얘기하는 경우
- 사용자(Player)는 오답율을 갖는다.

먼저 저는 오답율(errorRate)을 double 타입으로 지정했습니다. 가령 오답율이 0.1%와 같이 소수점일 수도 있기 때문입니다. 

그리고 369 게임을 진행할 때, correctAnswer() 메서드로 사용자가 정답을 말하는지, 오답을 말하는지 체크했습니다. 이때 Math.random() 메서드를 사용했는데요. 이 메서드는 default로 0부터 1.0 사이의 난수를 반환합니다. 따라서 저는 101을 곱하였고, 이로인해 0부터 100까지의 값을 반환하도록 만들었습니다. 만약 사용자의 오답율이 40%로 라고 가정하했을 때, '난수가 0부터 40 사이의 값이 나온다면 오답이다'라고 판정하여 이에 대한 boolean 값을 전달했습니다. 

게임에서 어떠한 방식의 오답이라도, 오답일 경우 결국 게임종료이기 때문에 확률에 따른 오답/정답 여부만 체크했습니다.

간단한 방법입니다. 하지만 면접을 볼 당시에는 random()을 활용할 생각은 했지만, 오답율을 어떻게 적용할지 떠오르지 않았습니다. 🥲

 

2) 지역별 다른 게임 규칙 적용하기 [추상화, 다형성 적용]

기본 369 게임 요구사항
- number 에 3,6,9가 포함되면 "clap", 아니면 입력받은 숫자를 String으로 리턴
지역별 다른 규칙의 369 게임
- 서울지역에서는 박수를 한번만 치지만, 부산 지역에서는 3,6,9가 나온숫자만큼 박수를 쳐야한다.
- 부산 do369(33) => "clapclap", 서울 do369(33) => "clap"

먼저 저는 369 게임의 클래스에서, 규칙에 따른 do369()에 abstract를 적용하여 추상 메소드로 만들었습니다. 

이를 상속하는 서울 369 게임 클래스입니다. 정규식 패턴을 활용해서 입력받은 숫자에 3,6,9 중 하나라도 포함되면 clap을 반환하게 구현하였습니다.

부산 369게임 클래스입니다. 문자로 변환한 입력받은 수에서 3,6,9 포함하는 수 만큼 clap을 append하고, 이를 반환합니다.

인스턴스 t1은 서울의 규칙을 따른 결과를 출력하고, t2는 부산의 규칙을 따른 결과를 출력합니다.

 

3) 동시성 적용

요구사항
- 서울지역, 부산지역, … 여러 지역에서 다른 룰로 게임이 동시에 진행될수 있도록 한다.

결과 예시

이 문제를 풀기 위해 369게임 부모 클래스에 Thread를 상속했습니다. 이로써 새로운 지역의 클래스를 만들어도 Thread가 적용됩니다. 그리고 각 게임들은 다른 쓰레드에 할당됩니다.

결과 예시를 보면 모든 게임이 진행된 뒤, 마지막에 '모든 게임의 박수 횟수: n'를 출력해야 합니다. thread를 적용하면서 이 부분이 조금 난제였습니다. 횟수를 출력하는 명령어를 아무리 마지막에 적어도 main 쓰레드로 인해서 가장 첫번째로 실행되어 횟수를 측정할 수가 없었습니다.

그래서 저는 먼저 횟수를 측정하는 인스턴스를 하나로 고정하였습니다. 그리고 t1과 t2가 이 인스턴스를 공유하도록 하였습니다. 마지막으로 Thread의 join() 메서드를 활용하여 횟수를 출력하는 메서드가 t1,t2 쓰레드가 종료될 때까지 기다리게 하였습니다.

 

코드링크

---

https://github.com/Si-Hyeak-KANG/threeSixNineGame_solve

GitHub - Si-Hyeak-KANG/threeSixNineGame_solve: 라이브 코딩 면접에서 진행했던 문제로, 시간을 갖고 재풀이