신입 개발자 코딩 테스트 문제 (경력 개발자가 생각하는 신입 면접)

신입 개발자 코딩 테스트 문제 (경력 개발자가 생각하는 신입 면접)


신입 개발자 코딩 면접 채용


이 글은 지난 2013년에 제가 썼던 글의 댓글 모음입니다. 주옥같은 명문들이 많아 그냥 남겨두기엔 아까워 공유합니다.


어느 분이 회사에서 신입 개발자 코딩 테스트를 진행[링크]했는데 면접자들 수준이 한숨 나올 지경이라 답답했다고 글을 올리셨었죠. 그걸 트랙백 걸어 제가 다른 글을 썼었는데, 시간이 이렇게 지났음에도 주옥같은 명문 댓글의 가치는 떨어지지 않는군요.


어쨌든, 저는 신입 개발자 코딩 테스트는 반대하는 입장입니다. 짧은 시간 동안 회사에서 제작한 시험이 그 사람의 가치를 100% 파악하지 못한다고 생각합니다.


물론, 기본 상식은 있어야겠지만, 그런 건 면접 볼 때 질문 몇 개 던져보면 알 수 있습니다.

차라리, 단 하루에 벌어지는 코딩 테스트보단 일주일간 결과 제출 - 피드백 - 다시 제출 - 피드백을 반복하며 아는 거 모르는 거 죄다 끌어내는 테스트가 더 효율적이라고 봐요.

저도 실제로 그런 면접을 본 적이 있었는데, 제 실기 면접 역사상 가장 훌륭했다고 봅니다. 코드 설계, 구현, 주석, 문서 처리 등 다양한 문서를 제출해야 해서 되게 귀찮았지만, 그걸 통해서 제 수준이 노골적으로 드러났습니다. 물론, 회사에서도 노골적으로 제 수준을 알았겠죠.


하여간에, 당일치기 코딩 테스트는 아직도 부정적이라 보는데, 넌센스 퀴즈 못 풀었다고 인재가 아니라는 식의 시험은.... 저는 ... 이해하기 힘듭니다. 정말 좋은 사람 뽑으려면 하루가 아니라 3일, 5일 시간을 들이는 게 합리적이죠.


정규직 직원(신입 개발자 포함) 한 명 뽑아놓으면 일을 욕 나올 정도로 못해도 해고를 못 하는 우리나라 실정에 왜 면접 기간은 늘리지 않는 것인지 한편으론 이해가 되질 않습니다. 하려면 충분히 할 수 있는데도 안 하는 건, 아마 우리 사회가 많이 경험하지 못한 부분이라 그럴 겁니다.


향후엔 장기 테스트 면접이 점차 늘어나리라 생각하며, 예전 댓글 소개합니다. 서론이 너무 길었네요;;


신입 개발자 코딩 면접 문제


1. 말보단 포트폴리오


면접 시 가장 확실한 건 테스트를 하는 것 보단 지참한 포트폴리오를 가지고 얘기하는 게 훨~씬 더 도움이 되고, 보통 이렇게 진행되지 않던가요?


아무리 신입 개발자래도 졸업작품 정도는 있을 것이고(팀으로 했든 뭘 했든), 비전공자라도 자신이 제작한 프로그램 한두 개 정도는 들고 가야 말발이 먹히더라도 먹히는 게 이쪽 업계 관행인데 말이죠!


그렇게 해야 하는데 말발만 있는 사람을 골라내기 힘든 부분도 있습니다. 그래서 어떤 회사는 이력서 내용은 다 필요 없고 일단 인성이나 말투만 면접 때 보고 실제 업무 능력은 인턴 기간 동안 파악하려 하죠. (코딩 테스트 < 인턴 기간)


그래도 말로 풀어내는 구두 면접은 어차피 기억력 테스트인지라, 개인적으론 큰 효과가 없다고 생각을 합니다.


어쨌거나, 면접 시간은 최소 2시간 이상으로 잡는 게 바르다고 봐요. 고작, 시험 답안지나 구두 면접 정도로 그 사람을 판단하는 건 불가능하니, 굳이 테스트를 해야겠다면, 뭔가를 만들어 보라 시키고 옆에서 지켜보는 편이 낫겠습니다.


설령, 문제를 끝까지 풀어내지 못하더라도 옆에서 지켜보면 그 사람의 성향이나 성장 잠재력 정도는 알아볼 수 있을 테니깐요.

물론 지참한 포트폴리오를 가지고도 얘기를 합니다. 하지만 면접 시간이 한정되어 있을 때는 포트폴리오만 가지고 판별하기도 힘들죠.


실제로 프로젝트에 참여를 안 해 놓고 작업 진행 과정이나 내용만 숙지한 다음에 자기가 한 것처럼 얘기할 수도 있으니까요. 사실 테스트를 쳐 보면 저런 케이스를 빨리 확인할 수도 있기도 하고요.


2. 첫 번째 빡침. 신입 개발자가 포인터, 클래스 모를 수 있지!!


소스포지 들어가서 소스 다운받아가지고 소스 이해하고 수정할 정도의 실력만 있으면 돼. 그 이상을 구직자에게 요구하는 건 다 허세지.


코더에게는 불필요한 능력이야. 너희가 프로그래밍 아키텍처 설계할 능력도 없고 라이브러리도 그냥 외국 프로그래머들이 개발한 것 돈 주고 사서 쓰는 주제에 뭔 프로그래머 자부심은 그렇게 많어? 다 그냥 핑계지.


학원에서 단기 속성으로 3개월에 대충 문법만 띠고 온 애들 보면서 에휴 빙신들 그러면서 약 올리고 싶은데. 명분이랄지 무슨 핑계를 대야 하니까 그 핑계로 내미는 게 포인터고 클래스고 레알 한심하다.


포인터, 클래스가 중요하다 아니다를 떠나서, 이 개념 없이 어떻게 소스를 이해하고 수정할 수 있다는 것인지 이해가 되질 않네요.


소스 그 자체를 검색해서 찾았다 하더라도, 이것을 사용함으로써 생기는 문제들은 꽤 다양한 편인데, 이런 부분에 대한 에러처리는 어떤 것을 이해하고 사용하는지요? 사용자가 정상적인 방법으로만 사용한다고 가정하고 프로그램을 짜시는 건가요?


글쎄요, 저도 사용자인지라 프로그램들을 만지다 보면 엉뚱한 것들을 마구 넣어봅니다.


신입 개발자 코딩 시험 테스트[코딩 테스트] 하긴 해야하는데...


특히 int의 최대값 이상으로 넣다 보면 어떤 프로그램은 죽거나 뻗거나 엄한 값을 내놓거든요. 특히 C나 C++에서는 메모리를 직접 액세스하는 경우가 많으므로 이점은 주의해야죠. 그래서 포인터에 대한 개념을 이해하고 있어야 하는 것이 아닌지요? 신입 개발자, 경력 개발자 모두요.


메모리 문제는요. 자바 같은 경우 가비지 컬렉션이 되기 때문에 프로그래머가 직접 메모리까지 고려하는 건 이미 10년도 지난 예전 이슈입니다. 요즘엔 gcc 같은 경우에도 버퍼오버플로 때문에 생기는 보안 문제 때문에 컴파일러가 자체적으로 스택 오버플로까지 해줍니다.


자꾸만 포인터 가지고 메모리 엑세스니 뭐니 교과서에나 나오는 예제 가지고 호들갑들 떠는데 예제로 설명해드리면 그게 얼마나 한물간 이슈인가를 실감하실 수 있겠는데 제가 지금 시간이 없어서 일단 그 정도만 알려드릴게요. 검색해보세요.


얘네들 수준이 포인터 가지고 문자열 처리, 함수 매개변수 전달. 뭐 그런 초급 수준의 얘기들 하는 겁니다. 그 정도는 하루 이틀이면 그냥 띠어요.


그거 아니면 mfc에서 객체 포인터로 접근하는 거 뭐 그런 거 지금 얘기하고 있는 겁니다.

프로그래머가 메모리까지 고려하는 건 현재 진행형입니다. 가비지 컬렉터가 완벽하다고 생각하십니까?


아닐 텐데요 ... .. .


가비지 컬렉션하고 버퍼오퍼플로우는 좀 다른 개념이긴 한데 아무튼 (신입 개발자 포함) 프로그래머가 메모리까지 신경 쓸 필요 없습니다. 제 말을 믿으세요.


gcc 스택가드 써보시고 java에도 물론 탑재되어 있습니다. 이게 진짜 언제 이슈인지. 그리고 어느 언어가 좋다 나쁘다 이건 무의미한 거 아시죠?


필요에 따라 정당한 걸 골라 쓰시면 되는 겁니다.

한 가지 언어를 다룰 줄 알면 다른 언어 문법 습득하는 건 일도 아닙니다. 펄이나 파이썬 같은 스크립트 언어의 경우에는 한나절이면 충분합니다.


신입 개발자 코딩 테스트


"가비지 컬렉션하고 버퍼오퍼플로우는 좀 다른 개념이긴 한데 아무튼 프로그램머가 메모리까지 신경 쓸 필요 없습니다."


제가 얼마 전 메모리가 좔좔 새는 프로그램을 다뤄봤는데, 메모리 신경을 안 쓰는 프로그래머는 프로그래머로서 자격이 없다고 생각합니다.


그토록 가비지 컬렉터가 완벽하면 왜 소멸자는 문법에서 안 빼나요? 님의 말씀엔 모순이 있습니다.


2부로 이어집니다 [링크]


신입 개발자 코딩 테스트 문제 (경력 개발자가 생각하는 신입 면접)

댓글(0)

Designed by JB FACTORY