일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- reactive
- Spring Batch
- 공유기 서버
- 웹앱
- Spring Framework
- 서버운영
- 웹 스터디
- reactor core
- 웹 커리큘럼
- reactor
- ipTIME
- spring reactive
- Today
- Total
Hello World
어려운 기술 면접을 변명함 본문
존경하는 최범균님께서 얼마 전에 “면접이 이리 어려워서야“라는 글을 쓰셨습니다. 범균님은 몇몇 회사에서 SW 개발자를 뽑으면서 지나치게 높고 폭넓은 수준의 역량을 요구하는 것 같다면서 그런 사람을 뽑고 싶은 마음은 이해하지만 그런 사람이 세상이 몇이나 되겠냐며 현실에 맞춘 기준이 필요하지 않냐고 제안하십니다.
글을 읽으면서 이 비판(나쁜 의미가 아닌)에 일부 동의하면서도 제가 비판 대상의 일부임을 솔직히 인정하지 않을 수 없었습니다. 그래서 약간의 변명이 필요하다는 생각이 들었습니다. 사실 저는 이렇게 다른 사람의 주장을 논박하면서 토론하는 것을 좋아합니다. 이런 일을 단순히 즐기는 면도 있지만 이런 토론을 통해서 주제가 더욱 풍성하고 명확해진다고 생각하기 때문입니다.
먼저 코딩 시험에 대한 제 개인적인 의견은, 해당 코딩 문제를 풀어야만 통과하는 엄격한 시험이라면 전 낮은 수준의 문제를 내도록 해야 한다는 의견입니다. 높은 역량을 가진 기술자를 뽑기 위한 수단이라기보다는 기준 이하의 기술자를 걸러내기 위한 수단이란 뜻입니다.
범균님이 말한 알고리듬 수준의 코딩 시험이 어떤 것을 말하는지 불분명하지만 알고리듬 경진 대회에 나오는 어려운 문제를 꼭 풀어야 한다고 요청하거나 대학 시절에 공부하기는 했지만 일하면서 거의 접할 일이 없는 정렬이나 탐색 알고리듬을 풀어 보라는 식은 해당 직무가 그런 역량을 필요료하는 것이 아닌 이상 지나친 것일 수도 있습니다. 범균님께서 말씀하신 대로 일반 애플리케이션 개발자에게는 그런 알고리듬 능력보다는 모델링 능력과 데이터 가공 능력이 실제 업무에 더 필요하기 때문입니다.
하지만 어떤 코딩 시험은 꼭 풀어야만 통과한다는 기준보다는 특정 문제를 줬을 때 그 문제를 분석하고 해결해 나가는 과정을 관찰하면서 그 사람의 수준을 알아보려는 의도로 진행되는 경우도 많습니다. 질문이 모호할 때 다시 물어본다거나, 바로 세부 구현으로 넘어가지 않고 여러가지 개념적인 흐름을 탐색한다거나, 여러 가지 가설을 세우고 검증한다거나 하는 모습을 보면서 어떤 역량을 가진 사람인지 알아 보는 것이지요. 좋은 면접관이라면 적당히 도움도 주고 도전도 하면서 그 시간을 이끌 것입니다.
이런 차이는 대면 면접에서도 적용되는데 구현 기술이나 방법론이나 최신 기술 경향이나 과거 경험들에 대해서 여러 가지 질문들이 나올 수 있는데 이 모든 것에 하나라도 올바로 대답하지 못한다고 떨어뜨리는 회사는 아마 없을 것입니다. 완급을 조절하면서 어떤 수준의 사람인지 알아보려는 것일 뿐이죠.
예를 들어, (잘 하지는 않고 중요하다고 생각하지도 않지만) SOLID 원칙이나 몇몇 디자인 패턴에 대해서 질문할 경우가 있습니다. 요즘은 워낙 많은 사람이 SOLID에 대해서 알고 있어서 용어를 모르는 사람은 거의 없습니다. 대부분 다섯 가지 원칙이 무엇이고 어떤 뜻인지도 잘 얘기합니다. 하지만 교과서적인 정의를 줄줄이 읊는 사람과 한 번이라도 고민해 보고 자신의 말로 개념을 말하는 사람은 분명히 다릅니다. 제가 아는 몇 사람은 SOLID 중 몇가지 원칙 밖에 기억하지 못했지만 그 의미를 서투른 말로 떠듬떠듬 설명하는 과정에서 자신이 좋은 SW를 개발하는 데 고민하는 사람이라는 사실을 무의식중에 우리에게 알려 주었고 우리는 그분들에게 같이 일하자고 제안했었습니다. 물론 지금도 훌륭하게 기여하고 있습니다.
그럼 왜 이런 면접이 문제로 거론되는 걸까요?
몇몇 면접관들은 완장 효과 때문인지 권위적인 자세로 면접을 진행하면서 면접 대상자가 인격적으로 모욕을 느끼게 합니다. 마치 심문하듯 면접을 진행하면서 자신도 넘지 못할 수준을 요구합니다. 때로는 상대의 역량을 알아내려고 하기보다는 자신의 전문 분야에 편중된 질문을 하면서 공정하게 면접을 진행하지 않습니다. 면접이 아니라 면접관의 자기 자랑으로 흐르기도 합니다. 어떤 면접 대상자는 자신이 검증 대상이 된다는 사실 자체를 못 받아들이는 사람도 있는데, 권위적인 면접관과 이 자존감 낮은 면접자가 만나면 지옥이 펼쳐집니다. 불행한 일이지만 실제로 일어나는 상황이고 이런 안 좋은 경험이 면접이 지나치게 어렵다는 식으로 알려지는 경우가 있습니다.
개발자 면접은 일종의 협상입니다. 아무리 뛰어난 사람이라도 해당 시점에 필요한 적임자가 아닐 수도 있고 거꾸로 당장 일 할 수 없는 사람이라도 성장 가능성만 있으면 뽑을 수 있는 상황일 수도 있습니다. 면접 결과가 자신을 객관적으로 평가한 결과라고 생각하지 않는 게 좋습니다. 같은 사람과 다음번에 또 면접을 보게 되면 다른 결과가 나올 수도 있습니다. 당시 상황과 필요에 따라 평가의 기준은 달라지게 마련입니다. 면접 결과가 안 좋으면 그냥 상황이 안 맞았다고 생각하시는 것이 좋습니다.
면접은 객관적이지도 않지만 절대 평가도 아닌데, 어떤 때는 내가 부족하지만, 같이 면접을 봤던 사람들에 비해 상대적으로 낫다고 판단되어 채용이 될 수도 있고 어떤 때는 충분한 자격이 있지만 더 적합한 사람에 밀려 탈락할 수도 있습니다.
물론 이런 변명에도 불구하고, 면접이 지나치게 엄격하다는 소문은 도전하는 사람들의 의지를 꺾을 수 있어서 회사 입장에서는 면접에서 탈락하는 사람들이 면접 기준이 너무 높아서 탈락했다고 오해하지 않도록 사후 관리를 잘 할 필요가 있습니다. 실제로 그런 소문 때문에 구인에 어려움을 겪는 회사가 있기도 하고요.
몇몇 회사는 채용에서 탈락한 기록을 관리하면서 한번 떨어졌던 사람은 가능하면 면접 후보에서 제외하는 경우도 있는데 정말 바보 같은 짓입니다.
글이 생각보다 길어졌는데, 제가 하고 싶은 말은 하나뿐입니다. 도전했는데 떨어졌다면 자신을 다시 돌아보고 심기일전하는 계기로 삼는 것은 좋지만 절대로 포기하지 마시고 다시 도전하십시오. 절대적이지도 객관적이지도 않고 일관성도 없고 때로는 미친놈일 수도 있는 누군가의 평가에 너무 큰 의미를 부여할 필요는 없습니다.
그리고 사실 SW 개발자는 실력으로 공정하게 평가 받는 환경을 늘 추구합니다. 더 나아가 좋은 개발 실력이 사업의 성패에 큰 영향을 주는 사회를 간절히 원합니다. 그래서 기술을 무시한 의사 결정이나 기술자를 부품 취급하는 관행이 없어지고 기술이 세상을 더 나은 세상으로 만드는데 쓰일 수 있기를 바랍니다. 그런 관점에서 어떤 회사인가가 높은 수준의 개발자를 찾고 그들을 대우해준다는 소식이 들린다면 이는 좋은 소식이기도 합니다.
출처: http://blog.fupfin.com/?p=137
'News & Tips > 참고자료' 카테고리의 다른 글
sublime text3 마스터링 코스 (0) | 2016.01.26 |
---|---|
[펌]G메일 받은편지함 정리하는 팁 9가지 (0) | 2016.01.24 |
web으로 영화관 좌석 미리보기 구현 (0) | 2016.01.18 |
[펌]텔레그램으로 토렌트 검색하고 다운받는 시스템 구축 (0) | 2016.01.15 |
git ignore file 생성 (0) | 2016.01.14 |