이전에 포스팅했듯이 여전히 직장을 찾는 상태입니다.
그 와중에 우연히 싱가폴 주재 회사와 컨택을 하게 되었는데 이력서를 보고는 프로그래밍 퀴즈를 보내 오더군요. ACM이나 구글 코드 잼 스타일의 '특수상황을 기발하게 수학적으로 해결'해야 하는 그런 문제는 아니었습니다.
첫번째 문제는 string rotation 함수를 짜는 거였죠. ("abcd", 1)로 호출하면 "dabc"로 리턴되는 뭐 그런 거요.
제약사항이 몇 가지 있었는데 인자로 넘겨주는 문자열에 직접 operation해야 하고, dynamic allocation을 쓰면 안되고, 표준 함수를 쓰면 안되고, 루프를 최대한 적게 써야 하는... 뭐 그런 조건들이었습니다. 좀 생각해보면 malloc 쓰지 않고 문자열 길이와 상관없이 O(n)으로 가능하죠.
그렇게 첫번째 문제를 풀어 보내고 며칠 있다가 두번째 퀴즈를 받았습니다 -_-;;;
첫번째는 소위 걸러내기용이고 두번째가 좀 더 진지한 테스트라고 하더군요.
그래서인지 두번째는 문제도 두 개였는데, 하나는 strtok와 비슷하면서도 좀 더 고차원적인 기능을 하는 str_split함수를 만드는 거였고, 다른 하나는 '범용성 있는' hash table 모듈을 만드는 거였습니다.
첫번째와 차이가 있다면 단순한 기능 구현 뿐만 아니라 여러 가지 feature를 생각해서 추가 구현해보라는 식의 멘트가 있었다는 건데요. 예를 들면 wchar_t에 대한 고려 같은 거죠.
근데 이번에는... 좀 상황이 달라졌습니다. 싱가폴 집값이 비싼 탓에 그 쪽의 대우가 나쁘지 않다 하더라도 갈 맘이 좀 줄어든 거지요 -_-;
게다가 마냥 저 문제 풀이에만 매달려 있는 것도 힘들었고요. 두번째 문제는 정말 제대로 짜려면 두 가지 모두 며칠씩은 매달려야 할 거 같아서 기능만 돌아갈 정도로, 하루이틀만에 상당히 rough하게 짜서 보냈습니다.
그런데 이번에는 답장이 영 다르게 왔더군요. 제 코드를 상당히 세세하게 지적하면서요 -_-;;
영어로 왔었는데 간단하게 요약하면,
- 전역변수를 써서 thread unsafe하다
- ~~ 이런 상황에 버그가 있다
- (작동에는 문제가 없지만) 모 표준 함수에 대한 헤더파일이 없다.
- 해시 테이블에 메모리 릭이 있다.
- 해시 테이블에 공간이 모자라면 bucket을 2배수로 재할당 하도록 짰던데 다른 방법은 없을지?
- add_key()에서 ~~ 상황이 고려되지 않았다.
뭐 이런 식이었습니다 -_-;
그리고 말미에는 '위의 사항들을 수정해서 다시 보내주었으면 한다. 그럴 경우 우리는 연봉 $xxx 정도를 제시하겠다. 우리는 작은 회사라 현재 니가 있는 회사만큼 좋은 대우는 해 주기는 힘들다' 뭐 이런 말들이 있더군요. 조건은 나쁘지 않았습니다, 어쨌든...
근데 사실 쇼킹했습니다. 저렇게까지 답변이 올 줄은 몰랐거든요 ㅡㅡ; 물론 의욕 상실해서 건성건성 코딩을 했다는 핑계는 있었지만 솔직히 아직 제가 한참 멀었다는 얘기죠.
메일에도 '이번 퀴즈는 단순히 요구사항을 만족하도록 기능을 구현했는가를 보려던게 아니다'라는 말이 있긴 합니다. 재사용성과 디자인 및 사용 편의성에 중점을 둔 것이었다더군요.
초보 개발자일 때는 사실 되냐 안되냐, 아냐 모르냐에만 치중합니다. 그럴 수 밖에 없기도 하구요 -_-;
중간단계에 접어들면서 아는 것을 활용해 '어떻게' 만드느냐에 눈을 뜨기 시작합니다. 그리고 시간이 지나면 자신이 만든 것에 대해
'보증'할 수 있는 능력을 키워나가는데 여기에는 버그라든가 메모리 릭을 최대한 적게 유지하는 방어적인 프로그래밍의 틀을
잡아나갑니다.
문제는 저 '방어적 프로그래밍'의 틀이 초보일 때부터 잡혀 가야 하는데 그게 안된다는 거죠. 저의 사례만 봐도 그렇지 않나요? -_-;;
방어적인 프로그래밍이란 것도 그 범위가 참 넓죠. 습관이 되어 늘 신경쓰면서 프로그래밍할 수 있을 정도로 훈련을 하는 것이
중요하지 않나 싶습니다. 특히 자신의 코드를 다양하게, 최대한 넓은 커버리지를 테스트할 수 있는 테스트 케이스가 일단은 중요한
듯 합니다. 그런 말도 있죠? 개발자가 자기 프로그램을 테스트하면 잘 돌아가는 방향으로만 테스트한다는...-_-
그 외에도 자료구조나 로직, 알고리즘, 아키텍처, API 디자인이나 UI 디자인도 고민해야 하고, 위에서처럼 thread-safe라든가 국제화에 대한(utf-8지원이라든가) 고려도 필요할 수 있고... 뭐 이리 많아 ㅡㅡ;
결국 따지고 보면 개발이 쉬운게 아니에요...;; 어떤 프레임워크나 툴이나 특이한 언어를 다룰 줄 안다거나 하는 걸로 뻐기기에는 프로그래밍의 세계는 너무나 깊은 거죠.
결론은... 프로그래밍은 대충 하면 안된다는 겁니다 -_-
그리고 덧붙여... 우리 나라에서 저렇게 사람을 뽑는 회사를 저는 아직 보지를 못했는데 우리 나라 회사들도 사람 좀 제대로
뽑았으면 하네요. 우리나라 대부분의 회사들은(제가 접해 본 많은 회사들은) 개발자를 뽑는 건지 필요한 장비를 구하는건지 헷갈릴
때가 많습니다. 실력 테스트는 거의 없고 스펙에 맞으면 대충 몇 가지 물어보고 뽑죠 -_-;
회사들이 좋은 개발자를 신경 써서 잘 뽑는 문화가 퍼진다면 개발자들도 자신을 갈고 닦는 것에 좀 더 신경을 쓰게 되지 않을까 하는 생각이 드네요.
이올린에 북마크하기
