요새 면접을 좀 봤다.

파란창, 한국원송이, 소설닷컴의 과제 ...

파란창 🦋

과정은
서류 -> 코딩테스트 -> 면접 이었다.

면접까지 가봤다... ( 나름 여기에도 만족한다. 코테를 처음 뚫어봤기 때문이다. )

면접에서 코딩테스트의 풀이과정을 설명하는 시간이 있었다.( 기술면접 물론 포함 )

코딩테스트 ♨️

오금을 지릴정도로 어려운 문제는 나오지 않았다.

아... 진짜... 문제는 자주 접해보는게 중요한거같다. 이제야 떠오른 풀이때문에 아쉽긴 하다...

내 풀이엔 input값을 내가 이해하기 편하게 바꾸는 과정이 있었다.

면접관님이 input을 변형하지 않고 푸는 방법이 있을까요? 라고 질문하셨다.

30초만 시간을 달라하고 고민을 해봤더니 input을 변형하는 과정 없이도 가능했다.

남에게 설명하니 쓸데없는 코드들도 보였다.

아 그리고 회사 다니면서 코딩테스트 공부는 아주 희미해져갔다...

백수시절 준비했던 뽀록으로 겨우 합격했는데...

이 버프도 언제 끝날지 모른다..

기회는 새와 같아서 준비된 사람만 잡을 수 있다는데 자주는 못하더라도 꾸준히 잡고 있어야 한다고 생각했다.

여기서 얻은 교훈은

• input 그대로 사용하는 풀이도 생각해볼것( 코드가 간결해질 수 있다. )
• 남한테 설명해보듯 풀어보는것도 좋은 방법.
• 코테공부... 버리지마...

한국원송이 🐒

기초 공부를 제대로 해야된다… 사용사례 등을 궁금해 했다.

써봤지만 🧠빼고 써본것들이라 제대로 대답을 못했다.

제대로 알고 쓰자고.

어떤 개발자 분이 그래도 이런 기술이 있다고 인지하고 있다는게 중요하다고 했다.

당시엔 그게 무슨말인지 몰랐었는데 면접을 보고, 단순한 '~이게 뭐에요?'같은 질문이 아닌, '~상황이 있는데 그땐 어떻게 사용할 예정?'이런 질문을 받을때 중요하다고 느꼈다.

소설닷컴의 과제 🐔

내가 오만했다.

과제전형은 조건만 맞추면 된다고 생각하고 정말 '충족'만 시키게끔만 했다.

근데 떨어졌다.

궁금해서 피드백 요청메일을 보내봤다.

할 수 있는 기술을 보여준 과제였다면 더 좋았을것 이란 내용을 받았다.

하긴 생각해보면 내가 할 수 있는것을 사전에 보여줄 수 있는 통로는 과제밖에 없었다. 회사는 그걸 보고 판단하는거고.

회사의 핀트를 맞추지 못했다.

튜토리얼 마냥 단순한 구성이었다.

같은 곡이라도 연주자의 레벨에 따라 다르게 들리는 법이다... 계속 쉽게만 치려고 했었나보다. 같은 과제 명세서(?)라도 보여줄 수 있는게 다른 법인거같다.

공작새 처럼 보여줘야겠다.

변수의 접근제어자를 명식으로 사용필요, 일관성 필요 등등 아직 부족한게 많다.

🐸 진짜 주저리..

오늘은 코드 한 줄 덕분에 뿌듯해진 날이었다.

유지보수를 하면서 항상 염두해 두고 있는 부분은 다른 개발자가 왔을때도 알아볼 수 있느냐이다.

어떤 이슈 작업은 꼬리에 꼬리를 물어서 (너무 많이 봐서) 이해가 된 부분이 있다.

그 부분을 다른 사람이 봤을 때, 가능한 내가 고친 부분은 한번에 알아볼 수 있게끔 바꾸는게 지향점인데! 오늘 그 고민을 하며 작업을 했다.

똑같은 코드이지만 위치가 달랐는데, 더 적절한 위치를 찾아보는 고민을 했다.

한줄이지만 뿌듯한 경험이었다. 좋은 습관을 잘 들여보자..

문서도 써보도록 해보자.