기업입장에서는 모든 사람을 데리고 면접할 이유가 없으니까요.

코테로 필터링 하고 면접 보는 거 보다 시간적,비용적으로 그리고 좋은인재를 채용 할 수 있는

방법이 있으면야 기업들도 그 방법을 고르겠죠.

다 좋은데 1개월짜리 테스트시 급여는 제공되나요? 

업체의 요구사항을 구현하는 것은 좋은 말로는 코딩 테스트이지만 구직자 입장에선 일이 됩니다.

만약 무급으로 시행된다면 문제의 소지가 있다고 봅니다.

많이 공감가지만 역시 시간이 많이들어서가 아닐까 합니다. 무당이나 관상가 불러놓고 직원을 채용하는 곳도 있었던 것처럼 짧은 시간안에 많은 사람을 걸러내야해서 그런거같네요.

멋지다!!!

좋은 말, 좋은 생각 잘보고 갑니다~

오랜 시간... 끝까지 좋은 말, 좋은 생각 간직하며 살아가길 바랍니다~

좋은 하루 되세요~

질문글이 꼼꼼하고 수준이 높습니다 

ㅎ 코딩테스트 보다 어떤 현실이슈를 윗글처럼 예외케이스

까지 언급하면서 디펜시브 하게 글을 쓸수 있다 하는

테크니컬 글쓰기 능력검증을 하는게 더 나을듯 합니다 

알고리즘을 몰라도 개발은 할 수 있습니다.

예를 들어 1부터 100까지의 합을 구하는 문제를 푸는 방법은 다양하죠.

for 문을 돌려서 1부터 100까지 더할 수도 있을테고

가우스 공식을 사용하여 풀수도 있습니다.

알고리즘이란 단어의 뜻에도 있듯이 어떠한 문제를 해결하기 위한 방법입니다.

이런 방법들을 공부 해보고 익히고 있는 것과 모르고 있는 것에는

경력이 쌓이고 개발을 오래 할수록 많은 차이가 납니다.

예를 들어 코드의 가독성 및 유지보수등에도 차이가 나게 되겠죠.

저의 짧은 개발경력에서 느낀건

프레임워크를 써봤는지 부터 프레임워크의 활용, 오픈소스의 활용, 에러핸들링 경험, 더나아가 실전개발에 쓰이는 기술(AWS 등)보다는 컴퓨터공학의 이론을 잘 알고 활용하는게 더 중요하다고 생각되네요.

맞는 말을 하신 부분도 있는데

그냥 제가 경험해본 봐로는 고려 못하신 점이 있으신 거 같아서 항목별로 

답글을 달아봅니다.

Chapter 1 알고리즘? 중요할까?..

-> 경력직의 경우와 신입의 경우는 나눠서 봐야된다고 봅니다. 

신입한테는 의미가 있고

경력한테는 의미가 조금 적긴 하겠죠.

다만 현재 한국 구인시장의 알고리즘 코테의 경우에는 대부분 신입에게 포커싱이 맞춰져있다고 봅니다.

그래서 유효하다고 봅니다.

Chapter 2 기업

-> 말씀하신 대기업은 소위 말하는 기존 대기업일 경우 일거고

이 경우 채용의 공정성과 과학적 채용에 대한 이슈가 구직자들이 느끼는거보다 큽니다.

KT나 정선카지노의 경우를 봅시다...

외부의 청탁을 피하기 위해서라도 반드시 필요한 필터링입니다. 

그리고 그거정도 통과 못할 사람이면 사실 필요없어요.

경험있는사람 그냥 외주 쓰면됩니다.

총 비용 관점에서 보면 채용보다 외주가 쌉니다...

Chapter 3 채용방식의 다양화좀..

-> 다양화할 경우 지표로 공정하지 못합니다.

보통 팀단위에서 인사권이있고 자율권이 있을 경우 해당 팀에 맞는 사람을 뽑아야하기 때문에 팀별로 다양화 할 수는 있겠지만

그룹차원의 인사팀에서 대량으로 뽑아서 분배해줘야하는 대기업인사 시스템에서는

채용인원 능력의 균일성이라는게 생각보다 중요한 이슈라서요.(공정성문제도 있고)

Chapter4 지금 실무자들은?..

-> 사다리걷어차기 이슈라고 보시나본데 실제 공채 도입이전에

내부 직원을 대상으로 몇년에 걸쳐서 테스트하고 인사 KPI지표로 관리하면서 시험수준을 정비했습니다.

실제로 통과 못한 직원들을 정리해고하는 용도로 많이 써먹었구요.

반대로 불편한 사실을 말씀드리자면요

나이를 떠나서 학벌 좋은사람들이 훨씬더 시험 잘 통과했던 것으로 기억나네요.

Chapter5

-> 저는 이게 세대 간 사다리 걷어차기로 번지지 말았으면합니다.

저도 지나친 시험 만능주의에 회의감을 느끼고 있긴합니다...

다만 완전 필요없다! 이러는건 

필요한 이유도 있을거고 기존에 채용과정이 얼마나 더 불공정했는데

점점 나아지고 있는 과정인지에 대한 몰이해라고 생각합니다.

다양한 채용 케이스를 선택했으면 좋겠다고 하는데

선택할 수 있어요

그런 알고리즘 테스트 안보는데 가면되잖아요?

반대로 꼭 그런 채용과정을 거쳐야만하는 대기업에 목맬 이유는 없다고 봅니다.

소위말하는 네카라배나 투자를 받은 스타트업 등에서는 좀 다른방식으로도 보는데도 많아요.

정리

1. 코테, 진짜 실무개발과 접목이 될까? 알고리즘을 대체할 좋은 오픈소스, 메소드도 많은데..

-> 그 실무 능력을 어떻게 검증할지가 생각보다 힘이듭니다...특히 대량 채용의 그룹통합 인사시스템에서는...심지어 한번뽑으면 해고도 쉽지않아서 써보고 자른다는 불가능합니다....

실제 인사제도 개편하는데 의사결정을 옆에서 지켜보면 최선이 아니고 차악을 선택한거에 가깝습니다.

대안이 없어요 생각보다.

2. 알고리즘 지식을 무조건 부정할 순 없다. 코드를 비효율적으로 짜게되면 SQL N+1, 서버자원(CPU, RAM 등) 낭비가 심하다.

-> 저도 기본적인 레벨에 알고리즘은 필요하다고봅니다. 너무 시험적으료 교조화는 안되었으면...

3. 코테를 떨어지면 면접관 얼굴도 못보는게 억울하다.

-> 면접관 시급을 생각해보면 생각보다 비쌉니다....(최소 하루에 한명 사용하는 비용이 30이상이고 3명인데 그 돈 생각하면....)

그리고 그렇게 거르고 걸러도 일주일 내내 30분단위로 면접만 보기도 해요.

4. 지원자 평가에 있어 공채든 수시채용이든 코딩테스트 하나만 선택지가 아닌 과제형 혹은 Github 포폴 평가도 있었으면 좋겠다..

-> 그럼 각 전형별로 어느 시험이 쉬웠다 편파적이다에 대한 공정성 이슈를 어떻게 피해나가고

정치권의 압박에 의한 특별 채용같은 예외 채용케이스가 계속 생길 수도 있다는 거에 대해서 어떻게 피해나갈 수 있을 것인지 대안이 부재합니다. 

본문에서 제시된 과제형 테스트의 경우 기간이 1달이지만 그 과제 내용이 무려 1달을 Full로 해서 진행하는 테스트가 아닌 것으로 알고있습니다. 과제가 마감 기간이 있고 그 마감 기간안에만 신청해서 과제를 제출하면 되었던 것으로 기억하네요..

좋은 글 감사합니다.

하루 4시간 공부시 알고리즘 한시간 그외는 포플 세시간 개발

 이정도 비율이 이상적이죠.  디자인패턴등 위에서 언급한 요령등 기본기 ,  경험구축은 일하면서 습득하죠

알고리즘은 회사일로 익히기 힘듬

근본적으로

대기업 위주의 채용 시장과 실패한 중소기업 육성정책으로

다들 대기업에 목매는 구직 시장 상황이 문제라고 봅니다.

음.. 한번 기업 채용하는 입장에서 서술해보겠습니다.

보통 신입공채 열어서 개발인력 20명을 채용한다고 했을때,

저희 회사 최종 지원률이 거진 100:1, 즉 2000명도 지원했습니다.

(대기업이다보니, 다소 경쟁률이 높은편입니다, 대학생/중고신입/타 직종자 등 무수합니다)

이제 2000명을 알고리즘코딩테스트 없이,

기술면접과 깃허브 블로그등을 꼼꼼히 살펴보려고 합니다. 

기술면접인데 최소 30분은 해야하고, 면접관 2명은 들어가야겠죠? (2:1 면접)

그러면,

2000명 X 0.5시간 X 면접관 2명  = 2000이 나오고

또 기술면접인데 인사팀이 보면 안되고 현업에 있는 개발자가 해야겠죠?

그러면 회사 내 면접관으로 들어갈 시니어 개발자급 20명을 착출합니다.

2000 / 20명 = 1인당 100시간이고,

(하루 종일 면접으로 풀타임으로 가정했을때) 하루에 일 근무시간이 8시간이니,

100/8 = 12.5

즉 시니어급 개발자 20명이, 한번 공채에 1인당 12.5일을 면접만 봐야하는군요. 

거기다 공채는 보통 상반기/하반기 나누어져있으니,

무려 시니어급 개발자 20명이 (본인 프로젝트 업무는 전혀 손도 못댄체, 코드 한줄 못짠채로) 

1년에 한달을 면접만 봐야하네요. 이는 기업에서 엄청난 손실이죠.

사실 채용자체도

기업에서는 엄청난 리소스를 투자하는 겁니다.

그래도 면접을 진행했을때, 합/불을 떠나 과정 자체가 의미있는 토론이 되었으면 좋겠지만,

실상 면접에 가면, 상당히 채용조건에 비해 수준미달인 저급 지원자들도 많습니다.

그런 지원자들까지 면접 진행하게 되면

기업이나 면접관 입장에서나 엄청난 시간/비용 낭비이기 때문에,

최소한의 어느정도 이해도가 있는 지원자들만 면접을 보기 위해서인데,

문제는 대한민국 취업난에 따라, 소프트웨어 직군도 마찬가지로

수요에 비해 지원자가 너무 많으니

자연스럽게 알고리즘도 난이도도 불필요하게 지나치게 높아지게 되는게 아닐까 싶네요.

pub68 

사실 근본적인 문제는 알고리즘 테스트가 아니고

그냥 구직난이죠.....

 만년코더

맞습니다. 꼭 소프트웨어 전형에 코딩테스트 말고,

모든 직종에서 대기업 공채에서 보는 인적성 테스트도 같은 맥락이죠.

아마 기업쪽에서도 인/적성이란 실제 업무 퍼포먼스랑 연관짓기 어렵다는거 알겁니다.

그런데 공채 한번 열면 200대 1, 이렇게 기본 경쟁률에 몇만명 씩 지원하는데,

어느정도 명백한 객관적 평가로 점수를 매겨서 차별화해서 합/불을 나눠야하는데

이 지원자들 몇만명을 언제 다 PT발표 들어보고, 과제줘보고 피드백주고 할까요.

다들 소중한 의견 감사합니다.

착하게살면운으로돌아온다 pub68 

두분이 일단 공통되는 부분이 있어서 의견을 내보자면.. 확실히 기업에서는 1명만 면접을 보는게 아닌 몇십, 많으면 몇백명을 보는게 현실이다보니 최대한 편리한 방법으로 인사채용 프로세스를 선택한다는건 예상했지만.. 역시 이게 어쩔수없는 현실일까요..ㅠ

sum = 0
for i in range(1, 101):
  sum += i

i = 100
sum = (i*(i+1))/2

제 생각에는 알고리즘 테스트라고 해야 옳은데, 코딩 테스트라고 기업들이 말하고선 알고리즘을 테스트하는게 문제가 되는게 아닌가 싶습니다.

Chapter 1 알고리즘? 중요할까?..

1) 최단시간에 짜낸 코드가 클린코드일까?

2) 지금은 정답이 주어져있어서 그렇지 나중에 동일한 시간+정답을 모르는 상황에서 코딩하라 하면 제대로 해낼까?

3) 코딩에는 많은 테스트가 필요한데, 테스트가 아닌 실제 개발에서 테스트를 제대로 해낼 수 있을까?

 알고리즘 테스트는 문제를 시간단위 메모리단위 얼마나 효율적으로 해결하는지에 초점을 가지고 있습니다.

메모리나 시간 단위에 대한 제한은 있어도, 코드를 사람이 직접 검토한다면 고려대상이 될 수는 있겠지만 클린 코드나 재사용성 모듈화 등등을 고려해서 코드를 얼마나 잘 짜냐가 관건은 아닙니다.

그리고 채용을 위한 시험이기 때문에 시간을 짧게 주는 것이지 실제 개발에서도 테스트를 무슨 2시간만에 해내라고하던가 그렇진 않잖아요?

기업이 주어진 시간내에 문제를 다 풀라고 하는 기업 본적 없습니다. 그냥 최소한의 기준과 등수 등으로 하곘죠

Chapter 2 기업

프레임워크 활용, 오픈소스 활용, 어떤 프로젝트 경험이 있었는지 이런 것들로 경쟁을 한다면 오히려 불공정한 레이스가 더 되지 않을까 싶습니다.

중고신입으로 다른 기업에서 보통 최대 2년 경력인 사람들까지 대기업 공채 신입을 지원할수 있는데 그러면 그 사람들이 실무에서 경험 한 것이 훨씬 유리한 포지션이 됩니다.

만년코더

이렇게 장문의 피드백을 남겨주시게 되서 정말 감사합니다.

저도 기업의 입장을 어느정도 이해하고 쓰긴 했으나, 이런 심적인 부분까지는 생각치도 못하고 글을 쓰게 됐습니다.

Chapter 1 알고리즘? 중요할까?..

⇒ 요즘 보니까 경력직(수시채용)에 있어서도 지원공고를 보면 과제테스트 혹은 포토폴리오, 혹은 아예 과제전형 없이 면접으로 이어지는 부분도 있어가지고 이부분에 기대를 하고 있는 1인입니다.

Chapter 2 기업

⇒ 저는 채용에 있어 내부추천 등을 통해 지원을 받더라도, 과제, 면접 전형은 꼭 거치자는 의미로 쓴 글이었습니다. 실제로 블라인드 커뮤니티 내부에서도 보면 대기업 사내추천으로 면접기회를 잡았을지라도 면접 혹은 과제테스트는 꼭 보게 되어있고, 여기서 떨어지면 일반 지원자처럼 아웃인 케이스도 많이보였습니다.

Chapter 3 채용방식의 다양화좀..

⇒ 이건 생각도 못했네요.. 저는 보통 대기업 인사 프로세스에 있어 인사팀 뿐만 아니라 필드 개발자들도 참여를 해서 검증을 하는건줄 알았어요.. (그리고 주도권 또한 필드 개발자들에게 있는줄..)

* 수시채용 기준 카카오가 개발자들이 코드를 보고 서류 합/불 결정을 한다는 얘기가 있더라구요.

Chapter4 지금 실무자들은?..

Chapter5

정리

알고리즘 몰라요.. 코테 해본적없습니다..

다만 우리나라 실무 현실은 예외처리가 너무 많아서 최적화 알고리즘 하고 싶어도 예외처리하려면

적용하기 쉽지 않은 경우도 다반사입니다. 제 경험상으로 보자면 알고리즘보다는

해당 업무에 대한 프로세스 이해도를 높여야 코딩이 가능합니다.

알고리즘 암만 해도 업무 프로세스 이해 못하면 알고리즘 적용 자체가 안되요..

YepBt

저는 여전히 알고리즘 테스트 = 코딩테스트 라고 생각합니다.

1) 메모리나 시간 단위에 대한 제한은 있어도, 코드를 사람이 직접 검토한다면 고려대상이 될 수는 있겠지만 클린 코드나 재사용성 모듈화 등등을 고려해서 코드를 얼마나 잘 짜냐가 관건은 아닙니다.

⇒ 모든 기업이 그런건 아니겠지만, 요즘 많은 기업들이 '단순히 잘 돌아가는가?' 를 떠나서 '코드를 효율적으로 잘 짰는가?' 도 평가하는곳이 점점 생겨나고 있습니다. (최근 Python을 쓰는 모 기업 코딩테스트도 '파이썬틱하게 짜라' 라고 아예 명시되어 있었습니다.)

2) 그리고 채용을 위한 시험이기 때문에 시간을 짧게 주는 것이지 실제 개발에서도 테스트를 무슨 2시간만에 해내라고하던가 그렇진 않잖아요?

⇒ 실제 개발에서는 시간제약이 없긴 하나, 오히려 코드 설계에 있어서 생각이 많은 사람에게 코딩테스트를 보라하면.. 처음부터 오히려 그게 불리하지 않을까 싶네요 (채용 후 장기적으로 봤을땐 기대할 수도 있겠지만)

3) 기업이 주어진 시간내에 문제를 다 풀라고 하는 기업 본적 없습니다. 그냥 최소한의 기준과 등수 등으로 하곘죠

⇒ IT 대기업 중 하나는 주어진 제시간안에 모든 문제를 못풀면(모든 테스트케이스 통과 포함) 코딩테스트 불합격인걸로 압니다.

저도 이를 간접적으로 경험해봤습니다.

4) 프레임워크 활용, 오픈소스 활용, 어떤 프로젝트 경험이 있었는지 이런 것들로 경쟁을 한다면 오히려 불공정한 레이스가 더 되지 않을까 싶습니다.

⇒ 저는 그래서 최대한 모두에게 자신의 실력을 표출할 수 있으면서도 신입/중고신입 불균형 없이 모두에게 공정할 수 있도록 코딩테스트 하나의 선택지만 있는게 아닌, 포토폴리오/과제형 테스트 까지 총 3개 중 하나를 골라서 시험을 치르게 했으면 좋겠다는 의견이었습니다.

감사합니다 :)

13년째이짓

저 또한 포폴만으로 기업에 지원을 하면 약 절반이상 가량 서류합은 됐었습니다. 제 경험 상 '실무지식(AWS, 도커 등)'을 강조하며 기업에 서류를 넣으면 절반은 먹고가는것 같았습니다. 

제 생각은 한번 적어보도록 하겠습니다.

Chapter 1 알고리즘? 중요할까?..

1) 알고리즘과 실전개발은 전혀다른 영역이다. 

2) 알고리즘보단 프레임워크를 써봤는지 부터 프레임워크의 활용, 오픈소스의 활용, 에러핸들링 경험, 더나아가 실전개발에 쓰이는 기술(AWS 등)이 더 가치있다고 생각합니다.

위의 두개의 말 맞는 말인것 같습니다.

하지만 소수의 인력을 뽑기위해서는 변별을 해야합니다.

기존 몇년전에는 코딩테스트 대신에 인적성을 많이 쳤습니다. 아직까지도 인적성 및 ncs를 치는곳이 있구요,

하지만 인적성 잘하는 사람이 개발을 못하는 사람은 봤어도, 알고리즘을 잘하는사람이 개발을 못하는 사람은 아직까진 본적이 없는 것 같습니다.

Chapter 2 기업

하지만 현실은 기업에서는 '일단 코딩테스트부터 보고 시작하자' 입니다. 아무리 오픈소스, 프레임워크를 잘 쓰며 개발을 할 줄 안다 해도, 코테에서 떨어지면 면접도 못본 채 아웃입니다.

현재 대한민국에서 코딩테스트가 심각하게 어려워서 통과는 못하는 기업은 없는 것 같습니다?

--> 보통 5문제를 내면 3문제에서 2문제만 풀어도 면접을 볼수 있을텐데요?

아닌 기업이 있다면 대략적으로 댓글 부탁드립니다.

Chapter 3 채용방식의 다양화좀..

기업은 다양한 방식으로 지원자를 채용했으면 좋겠습니다.. 최근에는 프로그래머스에서 일부 회사들이 코딩테스트 전형이 아닌 과제형 방식으로 신입공채를 열기 시작했습니다.

'기간은 약 1달 줄테니, 우리가 주는 기획서를 참고해서 이런 주제의 프로젝트를 만들어와라.' 라는 방식의 채용방식이었는데, 개인적으로 저는 과제형 채용방식이 낫다는 이유는 다음 이유를 꼽았습니다.

1) 기간이 아주 넉넉하다.

2) 지원자가 가진 기술지식을 확실히 볼 수 있다.

3) 운이 좋다면 과제의 피드백도 얻어낼 수 있다. (이를 통해 지원자는 어디부분의 실력이 부족한지 알 수 있다.)

채용방식 다양화는 회사가 크면 클수록 힘듭니다.

위와 같이 한달의 과제를 줘서 검토를 하게된다면 ? 

과제를 채점해야하는사람이 필요하게 됩니다.. 자기 업무는 업무대로 하면서 해야합니다..

그리고 알고리즘 잘하면서 개발 잘하는 분 많습니다.

Chapter4 지금 실무자들은?..

(욕먹을 각오로 글 씁니다.)

케이스 바이 케이스라 생략,,

정리

경력직은 코딩테스트가 좀 그럴수 있으나, 신입직을 뽑을 시에는 현재로썬 코딩테스트가 가장 공평하다고 생각합니다.

ex)  인적성 -> 결국 학벌 좋은사람이 더 높은 점수를 상대적으로 잘봄. 왜냐하면 인적성 자체가 국어 수학적 사고 방식을 요구하기에 고등학생때 공부 열심히 한사람이 대채적으로 유리함

     코딩테스트 -> 대부분 대학교 들어와서 처음 접하기에 인적성보다는 공평한것 같음

므흐므흐 

대댓글이긴한데요 ㅋㅋㅋ

요즘 보니까 경력직(수시채용)에 있어서도 지원공고를 보면 과제테스트 혹은 포토폴리오, 혹은 아예 과제전형 없이 면접으로 이어지는 부분도 있어가지고 이부분에 기대를 하고 있는 1인입니다.

-> 실제로 신입 채용을 제외하고

경력직은 과제형으로 진행하는데가 많이 생겼죠.

이건 신입의 경우에는 키워서 쓸 사람이고

경력직은 용병으로 즉시전력감이고 TO가 확정적으로 정해져있는 경우가 많아서 그렇습니다.

당연히 경력직은 코테의 필요성이 의문시 되고 있고 기업도 알고 있다고 봅니다.

Chapter 2 기업

⇒ 저는 채용에 있어 내부추천 등을 통해 지원을 받더라도, 과제, 면접 전형은 꼭 거치자는 의미로 쓴 글이었습니다. 실제로 블라인드 커뮤니티 내부에서도 보면 대기업 사내추천으로 면접기회를 잡았을지라도 면접 혹은 과제테스트는 꼭 보게 되어있고, 여기서 떨어지면 일반 지원자처럼 아웃인 케이스도 많이보였습니다.

-> 실제로 내부추천자의 경우에는 경력자 뽑을때의 인사 프로세스 정도로 진행하고 있습니다.

저도 추천 몇번 해봤는데 될놈될이고...그냥 서류 합격이 쉽게 되는 정도 수준인듯....

Chapter 3 채용방식의 다양화좀..

⇒ 이건 생각도 못했네요.. 저는 보통 대기업 인사 프로세스에 있어 인사팀 뿐만 아니라 필드 개발자들도 참여를 해서 검증을 하는건줄 알았어요.. (그리고 주도권 또한 필드 개발자들에게 있는줄..)

* 수시채용 기준 카카오가 개발자들이 코드를 보고 서류 합/불 결정을 한다는 얘기가 있더라구요.
-> 전통적인 대기업과 인터넷 기반의 유니콘 기업의 인사채용 방식은 다를 수 밖에 없습니다

전자는 대량생산 방식이고 후자는 팀단위 자율성을 보장하는 방식입니다. 

인사도 팀장이하구요....

대기업에서 개발자가 채용에 관여할 수 있는 부분은 점수를 메기는 정도 입니다.

HR에서 결정합니다.

Chapter4 지금 실무자들은?..

-> 제가 코테 도입할 때 초창기에 있었는데요. 우선 KPI로 삼하서 일정 등급이하면 직무 전환으로 다 내보냈구요(콜센터에 발령내는 등) 나이드신 분 쫓아내는 용도로 많이 사용했습니다.

그리고 약간 오해가 있는게 IT직군만 해당하는 부분이라서 실제로 IT 계열사라고해도 IT직군이 아닌 분들이 꽤 많습니다. 

Chapter5

정리

사실 지금의 코딩테스트가 탄생한 또 하나의 중요한 이유는

효율성 때문이죠.

구직자를 하나하나 면접 보는데 드는 시간적인 비용이 크니까

면접 대상자 수를 줄여 비용을 줄이기 위함이죠.

기간을 길게 못주는 이유는 이 사람이 직접 푼건지 아니면 대리로 푼건지 알 길이 없어지니까 그런거 같구요.

코테를 저도 싫어하는 사람에 속하지만, 

의문?까지는 들지않네요.

제 생각에 코테는 뽑기의 최대치를 올리는 방법이라고 생각합니다. 완전 자본주의적인 회사의 입장이 나타나는 채용 절차 중 한가지죠.

저도 신입공채를 통해 입사해서 실무에서 일하고 있지만, 같은 동기라도 실력차이가 있는 것은 팩트입니다.

여기서부터는 화딱지나지만 철저하게 회사입장입니다.

(기존의 코테는 실무자를 회사에서 내보내기위한 방법으로도 사용되었다고합니다만 그것을 제외하고 신입을 거르는 용도로만 언급하겠습니다.)

어차피 신입의 실력을 완전히 믿고 일을 맡기는 회사는 드물겁니다.

(전 거의 없다고 생각합니다 98%는?)

그렇게 면접에서 거르고 걸러도 막상 시키면 어정쩡한 신입도 분명히 있으니까요.

그러니까 '신입 == 가르쳐야한다'가 머리속에 일단은 있는거죠.

(안가르치고 일잘하는 분들 많습니다. 경력직, 프리 등등 필요하면 그분들과 진행하죠.)

가르칠 얘들중에 어차피 실무능력을 믿을 순 없으니

(어지간한 포트폴리오가 아닌 이상 신입들 포트폴리오보고 괜찮다고 생각할만한 인사 재량의 각 장님들은 드물겁니다.)

뭐라도 잘하는 신입을 뽑고싶은 것이고 그렇게 추가된게 각종 테스트 또는 과제죠. 

그중에서 코테는 효율성이 높습니다. 회사의 자원을 최소로 사용할 수 있거든요.

따라서 코테는 회사에서 어차피 실무는 믿음이 안가니 그 중에서 1가지라도 잘하는 애를 데려다가

키우자라는 마인드를 가진 회사 중역들이 만든 절차(요즘은 중소, 스타트업도 코테를 하는 경우가

있긴합니다만 제 경험상 거긴 코테 점수좀 떨어져도 포폴이나 면접에서 좋은 인상을 남기면

합격했습니다.)입니다.

여기까지가 회사입장이고,

구직을 희망하는 우리는 어떻게하냐 ? (완전 현실적으로)

1. 가고자하는 회사가 확실하다! 포기가 안된다!

= 코테고 뭐고 준비하셔야합니다. 회사의 채용방식이 바뀌길 기다릴게 아니라면 (특별한 채용방식이 생겨나지않는 이상 왠만한 우량기업들은 코테채용이 계속 있을 것 같습니다.)

2. 아니꼽다! 코테는 안된다!

= 코테없는데 가야합니다. 답이 없어요.

3. 신입은 드문일인데 인맥이 작용 될 가능성도 있겠지요...? 본적이 없기때문에 가능성은 좀 드물다 생각합니다.

분명한 것은 수요보다 공급이 많은 이시점에서 

왜 이런걸로(개인이 생각하기에 쓸데없다는 절차) 거르냐 ! 이거 쓸모없지않냐! 이런 생각보단 

빡치고 열받아도 일단 희망하는 회사에 들어갑시다! (싫어하는 코테라도 준비해서..!) 라는 게 

본인한테 좋을 것이고, 좋음을 알기 때문입니다.

제가 이렇게 댓글 남긴 이유는 사실

Chapter4 지금 실무자들은?..

하지만 신입에게 이런 어려운 코딩테스트를 현직 실무자분들께 풀어보라하면.. 개인적으로 합격률이 얼마나 나오는지 궁금합니다.

이 부분 때문인데요! 

과연 현재 실무자들이 구직을 희망하시는 분들 처럼 각잡고 시간투자해서 공부하면

그 합격률이 안나올까요..?

의도는 왜 말도안되는 난이도로 코테를 내냐! 라고 느껴지긴합니다만

실무자가 코테를 못한다는 전제가 보이는 것 같아 안타깝습니다.

이미 그 코테를 통과해서 일하고 계시는 실무자님도 존재 하십니다.

본인이 생각하시는 것보다 실무에는 숨은 실력자분들이 많으십니다!

제가 생각한 의도가 아닐 수 있고 제가 글을 읽고 느끼고 관련된 정보를 공유하고자

꼰대같이 적은 글이기 때문에 현재 제가 생각한 그 마음이 전달이 될진 모르겠지만

잘 준비해서 좋은 직장에 채용 되시길 기원합니다. 화이팅하십쇼!

@므흐므흐 저는 정규할 생각이 없어서 ㅎㅎ 정규직하면 업무외에 회사일도 해야하고;; 급여도 지금보다 박봉이라 생활하기 힘들것 같아요;;

현플 

애초에 시험 최초로 만들때 

모르모트를 현직자가 했다는 걸 

몰라서 할 수 있는 이야기라고 생각합니다...............

사실 신입 코테 수준이

회사마다 케바케이긴하지만

합격기준으로 봤을 때

유명 대기업 IT 직군의 경우에는 

성적으로 치면 중간값이하에요....

프레임워크의 활용, 오픈소스의 활용, 에러핸들링 경험, 더나아가 실전개발에 쓰이는 기술(AWS 등)

이런것들이야 말로 시간주고 공부하라 그러면 못하는 사람이 없는 분야죠;;

만년코더

결국.. 진짜 운칠기삼이네요.. 흑

HJOW

아무래도 예상했지만.. 구직자에게 있어선 잔인한 제도 같습니다 ㅠ

현플

진짜 구직자 마인드에 있어선 너무 격하게 공감됩니다..

저 또한 목표를 하는 회사들이 있어서 그런지 (혹은 최소컷) 그 아래를 바라보기란 쉽지가 않고, '코테는 아니꼽다!' 라는 마인드가 격하게 있는 것 같아요..ㅋ

그리고 제가 Chapter 4 의견을 낸 이유는, 물론 코테를 출제 하는 분들 또한 알고리즘을 잘 하시는 실무자분들이겠으나, 잘하는 사람보다 못하는 사람이 많다는 현실을 어느정도 들었기 때문입니다..ㅠ

13년째이짓

제가 정규직을 고집하는 이유가 안정적인 삶을 꿈꿔서 그런듯 하네요 ㅋㅋ

파이썬초보..

코딩테스트는 기존에 머리를 (빠르게) 굴려오셨던 분들이라면 어렵지 않으면서도 제로베이스에서 쉽게 접근이 가능하다고 생각합니다.

하지만 프로젝트(실무)/포토폴리오 같은 경우는 일단 다양한 상황을 예상하며 개발을 해야하다보니 결코 단시간 적으로 쉽게 개발할 수 있는게 아니라고 생각합니다.

1) 1인/사이드프로젝트로 시작할 경우 서비스 기획부터 생각을 해야합니다.

2) 프레임워크가 추구하는 패턴의 이해(MVC, MTV 등), 객체지향 프로그램(OOP)의 이해, 개발 성격에 따라서 다양한 개발론을 알아야할 필요도 있습니다.

이를테면 Resful API 설계론, 토큰인증(JWT), 라우터 설계, DB 테이블 설계, Controller 설계론 등등.. 또 에러가 발생하면 에러에 대한 대처능력도 큰 경험이라고 여깁니다. (때론 구글링을 백날 해도 안나오는 에러도 있어서 꽤 골때린적도 있습니다.)

4) 라이브 서비스가 유지된 채 최신 코드가 배포가 되어야 하다보니 CI/CD 배포론에 대해서도 알아야 합니다. (더 나아가서는 도커/쿠버네틱스 등도 고민해야겠고요.)

5) 코드를 배포할 땐 신중히 해야하는만큼, 테스트 검증도 필요합니다 : TDD

6) 대용량 트래픽도 버텨내야 하니 c10k Problem 등에 대한 문제도 고민해야겠고, 그 대안으로 Nginx 사용법도 익혀둬야겠죠?

7) 요즘 프레임워크들은 '코드의 재사용성(DRY)' 을 강조하다보니 확장성, 재사용성 등을 고려하며 개발을 해야합니다.

8) 먼 미래에 후임 개발자가 와서 코드를 물려받아 유지보수를 함을 염두해서도 효율적인 코드설계가 되어있어야 합니다.

9) 보안이슈도 있습니다 : SQL Injection, robots.txt 설정, 환경변수 설정, Nginx 설정(IP Black List 등)

저 또한 위의 경험의 흐름대로 사이드프로젝트 개발을 하고있고, 위 사례와 같이 다양한 상황에 대응해야 하는 포폴/실전개발이야 말로 오히려 더 시간이 걸리면서도 지원자의 잠재력을 판단할 수 있는 경험이 아닐까 싶습니다.

다들 소중한 의견 감사합니다.

노박사 

안녕하세요, 장문의 피드백을 주셔서 감사합니다.

하지만 인적성 잘하는 사람이 개발을 못하는 사람은 봤어도, 알고리즘을 잘하는사람이 개발을 못하는 사람은 아직까진 본적이 없는 것 같습니다.

⇒ 제 주변에도 이런 친구 한명을 보고있는데.. 확실이 남다르다는걸 저도 느꼈습니다.

현재 대한민국에서 코딩테스트가 심각하게 어려워서 통과는 못하는 기업은 없는 것 같습니다?

⇒ 어렵다는게 사실 어찌보면 상대적이긴 한데.. 저는 그래프/트리 응용이 나오는 순간 어려움을 느끼는 것 같습니다.. 그리고 카카오 공채 문제만 봐도.. 상당히 어렵다는걸 저는 느꼈습니다. (이전에 경력직 문제를 본적이 있는데 앞서 말했다싶이 난이도가 너무 달랐습니다.)

사실 구직자 입장말거 구인하는 기업 입장에서 생각해보면 면접,포트폴리오만 보는거보다 훨씬 효율적이죠

가능성도 높구요

어차피 면접은 한번 볼꺼 실력 검증하기엔 훨 좋죠

포트폴리오나 과제전형은 직접 확인해야 하니까요

우리나라에서 수능을 보는 이유와 비슷하지 않을까요.

수능공부가 살아가는데 큰 도움이 되지 않음에도 불구하고 수능에 매달리는 이유는 변별력 때문입니다.

좋은 대학은 한정되어 있고 지원자는 많으니...

코딩테스트도 마찬가지인것 같습니다.

좋은 직장(네이버,카카오 등)은 한정되어 있고 구직자는 몰리니 변별력을 갖추기 위해 코딩테스트를 도입하는 것이라 생각합니다

@므흐므흐 프리경력은 이제 8년차인데 8년 동안 공실 2주 있었습니다.. 요즘은 정규직도 연봉 많이 오른거 같긴한데 그래도 금액이..

코딩 테스트 = 알고리즘 테스트는 동의할 수가 없네요. 코딩 테스트의 도구로써 알고리즘을 많이 사용하는 것은 맞지만 모든 테스트가 알고리즘만 보지 않습니다.

특히, 코딩 테스트에서 보고자 하는 건 알고리즘을 풀 수 있는 능력만이 아닙니다. 일부 입과라고 해야할까요, 한 차례 필터를 하기 위한 알고리즘 테스트의 경우라면 모를까, 면접에서 코딩 테스트를 할 경우 대다수가 면접관이 참여하고 면접관과 의사소통을 하며 문제(이 문제가 복잡한 알고리즘 문제가 아닌 경우도 있고요)를 풀어나갑니다.

이때, 면접관이 관심 있어 하는 건 사실 얼마나 빨리 풀어서 답을 떠억 내는 것보다, 이 사람이 어떻게 문제를 접근하고 해결 방안을 제시하며 이걸 구현할 수 있는지를 보는 겁니다. 설사 막히는 부분이 있거나 문제를 제대로 풀지 못하더라도 이럴 경우에 어떻게 대응을 하는지 관심을 가지고 지켜봅니다.

시간이 부족하거나, 아이디어가 떠오르지 않아 단순무식하게 우선 해결하거나 완성하지도 못하더라, 이에 대한 충분한 설명과 함께 단순무식 말고 다른 해결 방안의 가능성을 제시한다면 충분히 합격선을 받을 수 있습니다.

프레임워크의 활용, 오픈 소스의 활용 등은 경력직에게는 확실히 필요하겠죠. 하지만 회사마다 사용하는 기술이 다른데다가, 특히 신입들에게 있어서 그런 기술 활용은 눈여겨 볼 만한 포인트도 아니고(개인적으로 그런 회사는 걸러졌으면 좋겠습니다.), 경력직에게 있어서도 개발할 때 어떻게 의사소통하며 문제를 해결해나가는지를 더 중요시 여기기 때문에 코딩 인터뷰를 하는 거라고 생각합니다.

인턴쉽이 아닌 이상 회사가 가용한 짧은 시간 안에 같이 일할 개발자를 판단하기에 코딩 인터뷰만큼 유효한 게 뭐가 있을까 싶네요.

실무 vs 알고리즘 종교전쟁 또 시작인가요.

알고리즘은 PC 하드웨어가 느리던 시절이나 퍼포먼스가 중시되는 게임개발 같은데서는 필요할 거 같고요.

현대시대의 웹개발에서는 크게 쓸모가 있을거 같지는 않네요. 웹개발 분야를 뽑는다면요.

실제 10년이 넘게 업계 에 있었지만, 알고리즘이 대단하다. 라고 느낀 경우나 개발자는 없었고요. 해당

코드도 없었네요. 그대신 말잘한다. 친화력 좋다. 지식이 방대하다. 꼼꼼하다. 리더십 좋다. 이런식으로

부각되는 사람이 일잘하고 잘풀리는 경우는 많이 봤습니다. 그래서 입사 테스트에서 코딩 테스트(특히

알고리즘 테스트)는 크게 중요하지 않다고 봅니다.

그리고 수능과 비교하는 댓글도 있던데, 수능은 대학에서 공부할 자격이 되는지를 테스트하는

시험이기 때문에 학습하는 능력을 테스트하는건 당연한거지요. 당연히 대학에서 배울때는 기초 지식

도 선행되어야 하기 때문에 그것도 있고요. 근데 실제 업무에서 알고리즘 관련 그렇게 많이 쓰지도 않

는데, 그걸로 당락을 결정하는 것은 수능의 경우와는 다르다고 봅니다. 회사에서 입사 테스트를

할려면 실무와 관계가 많은 걸로 해야죠.

HeuJung, 고내기

1. 좋은 기업은 한정되어있다.

2. 하지만 사람들은 좋은 기업쪽에 지원을 많이 한다.
3. 기업 인사담당자들은 많은 지원자들 중, 최대한 밥값을 하는 지원자를 선발해야 한다.

4. 하지만 많은 지원자들의 서류를 일일이 다 볼 시간은 없다.

5. 가장 최단 시간으로서 판별할 수 있는 방법은 '코딩테스트이다'

6. (필자 입장) 코테 말고 포폴 검사, 과제형 테스트도 추가해주면 안돼나??

현 상황이 위와같다곤 하지만, 구직자 입장에선 뭔가 억울해서 한번 하소연해봤습니다..ㅠ

초무쿤

저 말고 다른사람들도 코테 vs 실무를 외치는거면 그만큼 논란이 많은게 아닐까요?

TSTMAN

직접 실무자분 입장도 듣고싶었는데.. 좋은 피드백 감사합니다.

글을 쓰고 2-3일동안 잠수 탄 사이에 어느덧 Best 글에 올랐고, 많은 댓글들이 작성되었네요..

다들 감사합니다.

술술

좋은 의견 감사합니다.

사실 술술님 의견대로 '최소한의 CS지식을 보는 테스트'로서 코딩테스트가 들여졌으면 좋겠지만.. 현실은 아닙니다. 신입공채 기준 '면접' 이라는 티켓을 따기위한 과정인 코딩테스트에서는 무슨 합격률이 20~30%를 웃도는 문제를 들고와서 '이거 풀어보세요' 라고 하는게 오늘날의 현실입니다.

프레임워크의 활용, 오픈 소스의 활용 등은 경력직에게는 확실히 필요하겠죠. 하지만 회사마다 사용하는 기술이 다른데다가, 특히 신입들에게 있어서 그런 기술 활용은 눈여겨 볼 만한 포인트도 아니고(개인적으로 그런 회사는 걸러졌으면 좋겠습니다.)
⇒ 솔직히 요즘 신입들도 보면 프레임워크를 어느정도 사용할 줄 아는 사람이 점점 보입니다. 이제는 실무지식 쪽으로도 능력을 키우는 신입이 늘어나는 만큼, 이에 맞추어 새로운 평가 혹은 시험(과제형 등)이 생겨야하지않을까 싶습니다. 코테로만 사람을 판단하는게 과연 옳은지도 싶습니다. (알고리즘이랑 실무랑은 전혀다른 영역인데 이를 코테만으로 판단하기에는..)

경력직에게 있어서도 개발할 때 어떻게 의사소통하며 문제를 해결해나가는지를 더 중요시 여기기 때문에 코딩 인터뷰를 하는 거라고 생각합니다.

⇒ 저는 개발에 있어서 하나의 조별과제 라고 생각하는만큼, 이 '의사소통 문제해결' 에 대해선 확실히 공감이 갑니다. 그리고 코딩 인터뷰에 있어서도 단순히 머리 똑똑한지 보는 합격률이 20~30%를 웃도는 문제를 주는게아닌, 진짜 서로 협력해나가면서 문제를 풀어나갈 수 있는 코딩문제가 던져졌으면 좋겠습니다.

피드백 주셔서 감사합니다.

저는 알고리즘이 실무 능력에 비례한다고 생각하진 않습니다만.

회사 입장에서 코테를 보는 이유가

능력있는 개발자를 뽑는게 아닌

적어도 오면 안되는 사람을 걸러낸다라면  

저는 어느정도 공감은 되네요..

저도 코딩 테스트에 긍정적인 편은 아니지만, 솔직히 알고리즘 코딩 테스트로 좋은 사람을 걸러내는 경우보다 걸러야 될 사람을 거르는 순기능이 많다고 생각합니다.

그렇기 때문에 기업측에서도 출제한 문제에 대해서 엄격하게 평가하진 않는 것 같구요.

제 개인적인 생각으로 예를 들자면, 대다수의 자료구조가 이미 구현되어 있지만 굳이 자료구조를 구현해보라는 등의 테스트가 있는 것에 대해 있는걸 가져다 쓰면 되는데 왜 구현하냐고 말할 수 있겠지만 그 알고리즘에 대한 이해도가 없다면 현재 상황에 맞는 자료구조를 가져다가 사용했는지 또는 어떤 자료구조를 가져다가 사용해야하는지를 정확하게 판단할 수 가 없지 않을까요? 또는 기존에 구현된 것을 사용하지 않고 최적화가 필요해서 직접 구현해야 하는경우(별로 없을까요..?)가 있을 것 같습니다.

사실 저희 회사에서도 같은 기능을 구현할 때 온갖 알고리즘 기법 동원해서 짠 코드랑 기본적인 문법만 써서 쉽게 짠 코드 홈페이지 뜨는 속도 비교해보면 둘 다 크게 체감은 안되더라고요... 

웹개발이라 그런가... 아니면 컴퓨터 속도가 빨라지면서 그런가...

구직하는 입장이시니, 어렵사리 코딩 인터뷰를 보시면서 느끼셨을 생각이 충분히 이해합니다. 실무에서 써먹지도 않고 문제를 내는 사람조차 풀 수 있는지 모를만큼 괴랄한 난이도의 문제들이 이해가 가지 않으실 겁니다.

실제로 경력직의 경우에도 대기업?이라고 해야하나요, 네카라 같은 곳으로 이직할 때 그렇게 코딩 인터뷰를 봅니다. 이직할 때 따로 알고리즘을 공부하고 들어가야할 판이고, 인터뷰 보면서도 '경력자 데리고 뭔 이런 문제를 내냐'고 생각이 들기도 하고, 말씀하신 프레임워크를 활용하는 과제가 꽤나 유효할 거라고 생각합니다.

하지만 신입의 경우에는 다르다고 생각합니다. 회사가 당장 써먹을 인재로서 신입을 원하지 않는 이상, 프레임워크 활용 능력을 보는 건 넌센스입니다. 대기업 이야기를 하자면, 신입이 들어온 후 어떤 팀으로 배치될지 모르고, 심지어 그 팀이 어떤 언어, 어떤 프레임워크를 사용할지도 모르니까요. 가장 많이 쓰이는 스프링 프레임워크조차 용법이 다릅니다. 이 때문에 따로 신입 교육 과정을 거치고, 신입 프로젝트 같은 걸 수행하기도 하죠.

(똑같은 이야기가 경력직에도 적용됩니다만, 경력직의 경우에 TO가 보통 정해져 있어서 어떤 일을 할지 명확한 편입니다.)

결국, 이런 코딩 인터뷰를 보면 그네들이 원하는 인재상이란게 프레임워크를 활용할 줄 아는 사람이 아니란 게 명확한 거라고 생각합니다. 고층적인(이라고 쓰고 ㅈㄹ맞은) 문제가 주어졌을 때 이를 풀고 구현할 수 있는 사람을 원하다는 거고, 이조차도 말씀하신 것처럼 실무에 비적합할 수 있으니 최근에는 아예 인턴쉽까지 거쳐 사람을 뽑겠다로 이어지는 거죠.

구직자 입장에서야 불합리해보이지만 회사에서 개발자를 뽑는데 이만큼 효과적인게 어디있을까 싶습니다. 

신입이라는분이 항공권 예약매칭 어려운건 어떻게 아시는지 넘나 신기하네요 ㅋ. 전 실무해보기전까지 상상도 못햇엇는뎅. 많은분들 말씀하시듯 기업에서 코테를 선호하는 이유는 비용 딱 하나죠. 유행은 금방 금방 변하리라 봅니다.

봄꾸,  세퉁

통역사 입장에서 보면 실전통역 vs 토익 인 느낌도 없지않아 있는 듯 해요..

개발쪽에서도 코테 잘하는 사람이 개발을 잘하는 것은 아니나, 개발을 못하는사람은 코테를 못한다라는건 그래도 많이 잡아내는게 있어서 세퉁님 말대로 '개발 못하는 사람'을 걸러내는 용도로서 코테가 쓰이는 것 같습니다.

하지만 이게.. 진짜 너무 토익처럼 입시화가 되어가고 있다는것도 서럽습니다..

초무쿤

이 짤은 예전부터 많이 웃프게 돌던 짤인데 이 짤로 표현하고싶으신게 무엇인가요?

* 참고로 개발은 '여러 Exception 상황을 대비해서 개발이 이루어지는 사항'을 감안하면 지금 주제에 있어선 오히려 이 짤의 예시가 적절히자 않은 것 같다고 생각합니다.

확실히, 이미 만들어진 전문적인 알고리즘 지식이 담겨진 오픈소스라 할지라도, 이 오픈소스에 대한 이해도가 떨어지면 효율적인 사용이 어려울 수 있다는건 부정할 수 없는 사실입니다. 더군다나 오픈소스를 개조해야할 경우라면 더더욱 알고리즘의 이해가 필요하고요..

OR 오픈소스를 못쓴다면 직접 개발해야 하는 부분에대해서도 정말 공감이 많이갑니다..

이 부분에 대해서는 저도 부정을 할 수 없겠네요..

요즘은 컴퓨터 하드웨어 성능 및 인터넷 회선속도도 좋아지고 있고, 다양한 오픈소스가 나와서 그러지 않을까 싶네요 :)

하지만.. 만약 초당 N만 건의 요청이 들어온다면..ㅎㄷㄷ

술술

코딩인터뷰는 일단 팀마다 케바케인 것 같지만 코테 때 치뤄진 코드를 기반으로 코딩인터뷰가 치뤄지는 얘기는 많이 들었습니다. (코드리뷰, 코테 때 비효율적으로 짠 코드를 최적화 해라 등)

하지만 그와 반면, 다른 팀에서는 오히려 CS지식, 실무지식(도커 등)을 물어보는 팀도 있고, 저도 실제로 네카라배 경력직 면접에서 이를 위주로 물어봤습니다.

그리고 저는 프레임워크 활용능력에 대해서는 부정할순 없다고 생각하는게, 당장 경력직/신입 코테 난이도만 봐도 엄청난 차이가 난다는게 보입니다.

구직자 입장으로선.. 진짜 어찌보면 이런 입사전형이 불합리하지만.. 그래도 한이라도 풀어보고 싶고, 다양한 분들의 의견도 들어보고 싶어서 이렇게 글을 쓰게 되었습니다.

그리고 코테 외에도 효율적인 방법으로서의 대안책은 아까 말했다싶이 n일간의 넉넉한 시간+기획서를 주면서 과제를 시켜보거나, 포토폴리오를 보는방법도 있지않을까 싶습니다.

이전에 과제형 입사시험을 봤을 때, 기획 내용 중, '필터링 검색'이 있었는데 이거 구현하는데 정말 생각할게 많고(SQL 최적화, 다양한 검색조건 연관화 등), 빡샜더라고요..

이거하면서 바로 먼저 생각난게 '항공사 예약매칭' 시스템이었습니다.. 흑

결국 많은분들이 코테에 대해 아무리 좋다고 해도 결국은 그 좋은 이유가 비용, 짧은 시간 때문인 것 같네요..

또 몇일 간 잠수탄 사이에 많은 의견들이 쓰여졌네요!

정말 감사합니다.

저는 신입부터 3년차까지는 코딩 문제 하나 던지는 편입니다.

1 ~ 10만까지의 합을 구하라.

등차수열만 생각해내도 다행이라는 생각으로 던지는 질문입니다.

이거 손놓고 나가는 신입도 많고

3년차에 loop 10만번 돌리는 사람도 많더군요.

-- 추가 --

10만번 돌리는 코드 만든 사람에게

혹시 이거 loop 수를 줄일 수 있겠냐고 물어보면 

5에 4는 또 못합니다...;

_UnKnowN_

만약 코딩테스트를 보게된다면 진짜 _UnKnowN_ 님이 언급하신 사례급, 아니 이 사례보다 더 이상 급을 보는것('더 이상 급'이라고 말하자니 뭔가 좀 애매모호하긴 하네요... 일단은 '더 이상 급' 이라고 말하겠습니다!)은 개인적으로는 대환영입니다. (제가 비판하고 싶었던건 기본기를 보겠다고 전체 합격률 20~30%가 웃도는 코딩테스트를 입사시험에서 시킨다는부분을 비판하고 싶었습니다.)

애초에 알고리즘이라는게 '효율적으로 일을 시키자' 라는 목적으로 탄생한 바가 있는만큼...