라이브 코딩 면접 회고

1. 블로그를 시작하고 나를 찾는 회사 많아졌다~

 도쿄 이드콘에서 얻은 인사이트를 기반으로 새로운 프로젝트를 열심히 만들던 중에 갑작스러운 면접 제의 메일을 받았습니다. 네? 저 서류 올려놓은 데도 없고 넣은 적도 없는데요?? 블로그를 보고 연락을 주셨더라고요. 마침 면접에 들어가기 전에 면접관님께서 블로그 이야기로 먼저 운을 띄워 주셔서 제 블로그의 어떤 부분이 인상 깊으셨는지 한 번 물어봤습니다. 코드의 동작을 상세하게 풀어서 작성한 점과 이해하기 쉬운 표현을 사용한 점을 짚어주셨습니다. 확실하게 제가 의도한 부분들을 짚어주셔서 정말 감개무량했습니다.

 

 블로그를 시작한 가장 큰 동기는 제 자신을 위한 레퍼런스를 만드는 데에 있었습니다. 뭔가를 했다는 것은 기억이 나는데 상세한 내용이 기억 안 날 때, 깃허브에 올려놓은 코드뭉치를 뒤적거리는 것보다 블로그에 올려놓은 것들 다시 정독해 보는 게 굉장히 도움이 되었습니다. 이해하기 쉬운 표현을 사용한 것도 작성된 글을 제가 다시 볼 때 금방 이해하기 위해서였습니다. 코드의 동작을 상세하게 풀어서 작성한 것도 같은 맥락입니다. 모든 것이 제 자신을 위한 행위였어요.

 

 다만 실질적으로 스마트 컨트랙트의 동작을 풀이해 주는 자료가 거의 없다는 것이 조금 불만이기는 합니다. 이더리움 표준이나 DeFi 컨트랙트를 검색해 보면 대부분 EIP, ERC 문서를 요약해 놓은 글뿐이고 해당 표준 또는 인터페이스를 기반으로 구현된 스마트 컨트랙트가 어떻게 동작하는지는 거의 다루지 않더군요. 동작 과정이 궁금하다면 구현체 코드와 거기에 달린 주석, 테스트 코드를 보고 직접 돌려보는 방법 밖에 없습니다. 그러면 결국 Alice도 Bob도 piatoss도 삽질을 해서 코드를 일일이 분석해봐야 합니다. 이것은 어찌 보면 사회적으로, 블록체인 생태계에 있어서도 자원의 낭비가 아닌가.. 저는 그렇게 생각을 합니다. 그렇다면 친절한 누군가가 자기 시간을 조금 희생해서 자신의 삽질 과정을 문서로 남겨놓는다면, 그걸 참고해서 다른 이들은 삽질 횟수를 조금은 덜어낼 수 있지 않을까요? 그리고 이것이 시간 빌게이츠인 제가 할 수 있는 최선의 선한 영향력 행사라는 것...

 

 이런 맥락에서 최근 Patrick Collins라는 분을 존경하게 되었습니다. 유튜브에서 스마트 컨트랙트 관련 강의를 하시다가 작년에 아예 Updraft라는 교육 플랫폼을 만드셨더라고요. 강의는 모두 무료이고, 저도 많은 도움을 받았습니다. 블록체인 태그가 들어가면 프리미엄 붙어서 강의 가격이 기본으로 $300가 넘어가던데, 이런 식으로 무료로 푼다는 게 정말 대단하고 저도 이 분처럼 더 많은 개발자들을 블록체인 생태계로 온보딩하는 데 도움이 되고 싶다는 생각을 했습니다. 그런 생각으로 계속해서 블로그를 운영해 나갈 계획입니다.

 

2. 라이브 코딩

 라이브 코딩을 처음으로 경험해 봤습니다. 도대체 어떻게 살아왔길래 뭐든지 처음인 거냐 싶겠지만, 뭐 그렇게 됐습니다. 문제가 공개되기 전에는 높은 확률로 알고리즘 문제 풀이라고 예상하고 있었습니다. 면접 시간이 한 시간으로 잡혀서 이 시간 안에 뭔가를 구현하기에는 애매할 거라고 생각을 했습니다. 그런데 아니나 다를까, 기능 구현 문제였습니다. 문제는 2개로 30분간 구현 시간이 주어졌는데, React Hooks에 대한 기본 개념을 이해하고 활용할 줄 아는지에 대한 문제였습니다.

 

 문제는 제가 해커톤에 제출할 dApp 구현을 위한 최소한의 프런트엔드 지식만 갖추고 있다는 것. 그런데 왜 프런트엔드를 지원했는가? 면접 제의받고 기업 미션이 마음에 들어서 승낙했는데, 막상 구인중인 포지션을 보니까 조금 애매하더라고요. 프런트엔드랑 백엔드가 있고, 백엔드는 Nest.js를 사용할 줄 아는 것이 자격요건인데 이게 충족이 안 돼서 우선 프런트엔드로 지원을 했습니다. 꼼꼼하게 살펴보지 않은 제 잘못도 있는데 일이 이렇게 될 줄은...

 

 그래도 다행히 첫 번째 문제는 어렵지 않아서 잘 구현을 했는데, 두 번째 문제에서 막히고 말았습니다. 평소에 useState랑 useEffect만 주야장천 사용했던 것이 문제였을까, 다른 React Hooks를 활용해서 문제를 풀어야 하는데 이게 생각이 안 나다 보니까 결국 면접관님께 힌트를 받아서 겨우 문제를 해결할 수 있었습니다. 그 과정에서 '아, 이거 사용해 봤는데 정확한 개념은 모르겠습니다.'라는 희대의 망언을 해버리고 지울 수 없는 흑역사를 만들어버린 나. 크아아악!

 

3. 글쓰기와 말하기의 간극

 면접 시간은 1시간인데 라이브 코딩을 30분에 끝냈다는 것은, 남은 30분 동안 무언가가 남아있다는 것을 의미하죠. 남은 30분은 제출한 서류에 기반한 면접 질문을 받았습니다. 본디 라이브 코딩 결과를 기반으로 왜 이렇게 코드를 짰고 변수명은 왜 이렇게 했고 이런 것들에 대한 질문이 들어올 거라 예상했는데, 어떻게 내 예상은 항상 빗나가는 것인지... 선선한 가을이 되면 이력서 넣어봐야지 하고 마음 놓고 있다가 갑자기 잡힌 면접 일정으로 급하게 서류 다듬다가 라이브코딩만 하는 줄 알고 마음 놓고 있다가 면접 준비 많이 못했는데!! 우와아악!

 

 그렇게 면접을 보고 다시금 느낀 것입니다만, 글쓰기와 말하기의 간극을 좁히는 것이 너무나도 어려운 것 같습니다. 제 블로그를 보시고  '오, 이 사람 글 좀 재밌게 쓰는데?'하고 호기심에 저한테 말 걸어봤다가 절망적인 말주변머리에 기겁하고 손절하시는 것은 아닌가, 참 마음이 무겁습니다.

 

 제 자신에 대한 변호를 조금 해보자면, 제가 무언가를 머릿속에서 인출하는 데 걸리는 시간이 상당히 걸립니다. 이것은 제 조심스러운 성격으로부터 기인된 것으로 보입니다. 다른 사람한테 상처주기 싫고 분쟁거리 만들고 싶지 않은 성격 탓에 머릿속으로 필터링을 수차례 거치고 선별된 표현을 사용하다 보니, 주변에서 반응이 느리다는 평가를 많이 받았습니다. 블로그 글을 쓸 때도 비슷하게 필터링을 반복해서 적용하면서 글을 쓰다 보면 평균적으로 하나의 게시글을 마무리하는 데 2~3일 정도가 걸립니다. 그런데 글은 그럴 수 있잖아요. 느려도 괜찮습니다.

 

 그런데 말하는 것은 반응이 바로바로 나와주길, 티키타카가 되는 것을 사람들이 원하지 않습니까? 면접이라는 상황은 그런 식으로 바로 응답이 나와야 하다 보니, 머리에서는 필터링을 거치는 것보다 입이 먼저 반응해서 나불나불 거리다 보면 저도 무슨 말을 하는지 당최 이해가 안 되는 경우가 종종 발생합니다. 훈련이 필요하다고 생각하는데... 어떤 방식이 좋을까요? 저는 5~10분 정도 짧은 강의 동영상을 녹화해서 유튜브에 올려볼까 생각 중입니다. 블로그 1년 했으니까 이제 유튜브 1년 해보고, 1년 뒤에도 일자리를 찾지 못하면 머리밀고 중이되어 블록체인에 팔만대장경을 새겨 넣겠습니다. 이젠 정말 윤회 뿐이야.