:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
17/10/18 06:34
대학생때 직접 겪은 일입니다.
인턴 구하는 중이였고 면접을 봤는데 제가 써보지 않은 언어로 간단한 코딩을 시키더라구요. 그리고 약 500페이지짜리 레퍼런스북을 주면서 보면서 해도 된다길래 책에서 찾고 있었는데 1분정도지나니깐 "넌 빨리 못배우네? 난 너한테 딱히 궁금한게 없는데 질문있음?" 이라고 묻길래 엄청나게 당황했었습니다...
17/10/18 12:46
알죠. 당장 제가 일하는 회사도 가짜 오프닝 만들어 둔적도 있는데요. 그래도 학교하고 연계해서 하는거라 이런 케이스는 거의 없습니다.
학교시스템 + 외부에서 받는데 TO가 다 차서 학교시스템에 올린걸 취소하는 경우도 있고, 여러명 인터뷰봤는데 마음에 드는 사람이 없어서 다 거절하는 경우도 있지만, 대놓고 학생들 20명정도 불러다가 저 짓하는 경우는 잘 없어서요. 같은 반에서만 약 15명정도가 면접보러갔다가 같은 소리 듣고 왔는데 3~4명정도부터는 확신했었고요. 그래서 뒷쪽에 인터뷰 보러간애들은 다 대충대충 하고 왔고 아예 가지않았던 애들도 있고요. 학교 시스템 통해서 면접이 잡힌건데 이게 학생들한테 상당히 불리한 시스템이라... 무슨 이유던간에 회사에서 컴플레인하면 학생은 레터까지 써서 공식적으로 사과까지 해야하는데 회사에서는 시작 하루전에 캔슬해도 아무런 제재를 받지않아서 학생들이 불편해하고요.
17/10/18 02:57
제가 있는 회사는 링크드 리스트 정도야 당연히 기본이고, 최소한 트리는 정도는 술술 써나갈 줄 알아야 하더군요. 실무 칠판 코딩 면접 4번 봤는데 1번은 디큐, 2번은 트리 관련이었네요. 예외 케이스도 설명해가면서 예외처리를 하면 좋지만, 어짜피 칠판에다가 설명하면서 대충 코딩하니까 컴파일이 되는지 안 되는지는 아무도 모르고, include, import 이런거 안 써도 뭐라 안 하죠. 그냥 대충 봤을 때 어느 정도 실행 가능하겠다는 수준은 되어야 하는 것 같습니다.
참고로 하나 첨언하자면, 구글 전화 면접으로 온라인 코딩 문제 다 잘 풀었는데 결과는 탈락이라서 의아했는데, 인사담당자가 이유를 알려주더군요. "슈도코드를 써서 탈락"이라고요. 그 뒤로는 어디든 가능하면 그냥 최대한 FM문법으로 합니다 크크
17/10/18 04:51
일단 저라면 그런 문제는 안내겠지만, 낸다고 해도 의사코드로 진행할겁니다.
실무자 입장에서 알고리즘은 알면 좋긴 한데, 그것만 잘하시는 분들도 있다보니 골치가 좀.. 저라면 디자인 패턴이라던지 oop, functional이나 주로 사용하는 프레임워크같이 실무에 좀 더 밀접한 질문들과 함께 코딩테스트로 실무분야의 작은 단위를 직접 설계하고 코딩하게 하는 문제를 냅니다. 예를 들면 앱개발자에게는 기본적인 기능들이나 작은 기능을 갖춘 앱을 만들게 하는거죠. 이걸로 코딩 스타일이나 프레임워크 이해도, 라이브러리(패키지) 관리 능력이 있는지를 파악합니다.
17/10/18 05:30
해외에 살고 있고 여태까지 인터뷰중에 syntax까지 정확하게 요구하는 회사는 없었어요. 사실 정확히 코드 쓰라고하면 시간낭비죠.. 그냥 알고리듬이랑 정확하게 설명만 하면 pseudo code로도 충분했었습니다.
17/10/18 05:50
답변해주신 분들 감사합니다. 주로 수도 코드 정도로 짠다고 생각하면 되는군요. 옆동네에 근무하는 사람으로서 궁금했었어요.
17/10/18 09:28
탑 SW 엔지니어들도 면접 볼때는 시간내서 다시 공부한다고 하더라고요. 링크드 리스트는 기본이고 트리, 스택 등등요. 어느회사 면접에서는 커맨드라인 계산기를 즉석에서 짜서 컴파일해서 샐행결과를 보여줘야 했다고 하더군요. 그러니깐 (1+2)*3 + 4/9 뭐이런거를 커맨드라인으로 입력하면 계산 결과를 알려주는.. 일단 스트링 입력 처리, 입력 파싱, 연산자 순서 (곱셈을 먼저 덧셈을 나중에), 그리고 괄호인식 까지....
17/10/18 09:35
컴파일해서 오류 안난다 -> 해당 언어를 최근에 공부하고 있다 or 사용하고 있다 라는 뜻 정도라서 이건 패스하고
링크드 리스트를 즉석에서 설명하면서 짜는것은 인턴레벨의 면접에서도 해야 합니다.
17/10/18 05:26
1차 온라인 화상인터뷰중에 stack 코드 만들어보라고 했더니.. 잠시생각하더만 구글검색에서 가장 위에 나오는 코드를 연기하면서 배끼고 있더군요 껄껄껄.. 얼마나 재밌던지..
17/10/18 05:34
좀 오래전에 페북 면접 봤는데, 파이썬 자바 유창함이라고 썼다가 피봤습니다. 일단 너무 오랜만에 해서 컴파일 에러가 발생했습니다. 그리고
코딩이 맞는 방향이라도 왜 그렇게 생각했는지 설명이 안됩니다. 진심으로 인터뷰 보는 중에 무아지경에 빠져서 본능이 절 그리로 이끌었습니다가 제 생각이지만 그렇게 말 할 수는 없었습니다. 두번째로 정말 장기적인 플랜이 있긴 한데, 그걸 영어로 설명할 자신이 없었습니다. 물론 제가 코딩을 하는 궁극적인 이유도 모르지만, 본능적으로 이걸 지금 단순히 컴파일만 가능하게끔 다 처리하면 장기적으로 연산속도가 너무 느려질거 같았습니다. 그밖에도 여러가지 이유때문에 그렇게 했지만 생각을 영어로 표현이 정말 안되더군요. 그 와중에 손가락은 계속 자판을 두드리는 모습과 의자에 앉아서 뱃살을 보는 제 눈을 보면서, 저는 멀티태스킹이 되는 사람임을 느꼈습니다. 마지막으로 인터뷰어가 저보고 엄청 머라고 했습니다. 너 이렇게 하면 안된다고. 그래서 저는 저의 미래를 직감하고 뱃살을 만지면서 오케이 다음부터는 잘할께라고 하면서 그냥 계속 오케이 했습니다. 못알아듣는 말이 절반인데도 불구하고 결과는 일단 2차 면접까지는 다 통과했습니다. 3차 인터뷰에서 나이든 아저씨가 정말 잘 들리는 영어로 용어를 계속 섞어 쓰길래 너처럼 말하면 안된다고 미국식 조크를 날렸다가 떨어졌습니다. 그냥 하던대로 뱃살을 잡으면서 오케이라고 할 걸 그랬습니다. 본문에 날짜별로 압축하는건 제가 있던 거의 모든 랩 다 그랬습니다. 일단 지도교수님이 의지가 없습니다. 굳이 잘 돌아가는 시스템을 새로 바꿀 이유를 못찾을 뿐더러, 그걸 바꾸는 노력과 시간에 제 연구에 더 집중하는게 나았습니다. 드랍박스로 전부 쉐어!
17/10/18 09:24
- 그래서 연습이 필요합니다.
- vcs 안 쓰는 건 자기 선택이긴 한데, 저희 부서원들은 전부 공감할 수 없어서... 솔직히 여전히 이해는 안 가긴 합니다. 돈 조금 내면 private으로 쓸 수 있고, 아니면 내부 서버에 gitlab같은 거 설치할 수도 있거든요. 그리고 vcs는 잘 돌아갈 때가 아니라 잘 돌아가지 않을 때를 위한 거기도 하구요.
17/10/18 09:20
석사 박사의 경우 논문 내용이 자신의 연구 주제이고, 그 연구 방향이 저희 부서의 업무와 어느 정도 유사해야 관련이 있기 때문이죠.
관련 지식이 어느 정도 있는지, 연구는 얼마나 심화해서 했는지, 어느 정도 하면 막힐텐데, 그걸 어떻게 해결했는지 등을 물어봅니다.
17/10/18 09:17
실무에서 뛴지 20년 조금 안되는 프로그래머입니다.
프로그래머로서 자신있긴 한데 저런 인터뷰는 통과할지 잘 모르겠네요. 언어만 해도 다양하게 사용해서 어떨 때는 C++ 어떨 때는 Python 어떨 때는 Java, Node-js 등등 또 언어에서도 여러가지 라이브러리를 활용해서 하다보니 다른 언어 쓸 때면 문법조차 잠시잠깐 헷갈릴 때도 많은데 말입니다. 필요할 때면 검색해서 자신의 부족한 기억을 보조하는 경우가 많으니 저런 인터뷰 나오면 당황하고 탈락할 것 같습니다.
17/10/18 09:29
사실 랩실 수준에선 zip으로 버전관리 많이 하고 틀린방식이라고 생각하진 않습니다.
1. 협업 없음 2. 추가 유지/보수 필요 없음 3. 소스코드 관련 문서 작성 필요 없음 4. 서버 관리에 필요한 인력 부족 5. 소규모 s/w 개발(통상 1만 라인 이하) 물론 제 전공이 임베디드 s/w라 다를 수 있다고 생각은 합니다만, 정말 svn, git 등으로 버전관리를 한다고 해서 생산성이 올라갈지는 의문이 듭니다.
17/10/18 09:42
svn, git으로 버전관리 하면 안하는것보다 당연히 좋습니다. zip으로 버전관리 하는것에 비해 단점이 단 하나라도 있을까? 싶은데요..
면접에서 git말고 zip을 날짜별로 관리하는것 때문에 탈락하는건 사용하는 도구가 후져서 탈락하는게 아닙니다. 개발자로서 현재 상황 에서 개선 가능한 요소들을 생각하고 적용하는 고민이 없었다는 것이니까요. git으로 전환하는게 큰 비용이 드는것도 아니고요. 랩실 수준에서 협업 없고, 서스테이닝 필요없고, 문서작성 필요없는 환경에서 일했다고 하더라도 그런 환경에서 일한 기억은 그대로 랩실에 두고 취직해야 할것 같습니다. 왜냐면 헙업 없고, 문서작성 필요가 없더라도 내가 작성한 코드를 반년 이후에 본다면 잘 기억이 안날수도 있으니까요.
17/10/18 10:59
현업과 개발환경이 달라 어떤 점이 개선 가능한지가 의문이였는데, 스스로 고찰을 해봐야겠네요.
git으로의 전환이 큰 비용은 아니지만, 작은 비용도 처리가 어렵습니다. 연구비로 처리가 안되서요... ㅠㅠㅠ
17/10/18 09:48
그렇게 생각하셔도 어쩔 수 없지만, 이제는 분야에 관계없이, 1인 개발의 경우라도, git을 쓰는게 사실상 표준입니다. 5가지 이유를 쓰셨는데,
1. 방금 썼지만 협업과는 관계가 없습니다 2. 추가 유지/보수가 필요없다는 것과 관계없이 개발중에는 계속 소스에 변경이 발생하기 때문에 필요합니다 3. vcs는 문서와는 별개입니다. 같이 하는게 편하기 때문에 많이들 쓸 뿐입니다. 4. github이나 bitbucket을 사용하시면 서버 관리야 당연히 github이나 atlassian이 합니다. 보안이 필요해서 공개할 수 없으면 private repo를 쓰면 되구요 5. vcs의 사용은 소프트웨어의 규모와 역시 별개입니다. vcs의 효용성은 저 같은 평범한 사람이 이야기하는 게 아니라 많은 대가들이 주장하는 바입니다.
17/10/18 11:08
사실상 표준이고, 대가들이 좋다고 한다는 너무 일반적인 이유라 생각합니다.
물론 이 두가지 이유로 vcs를 사용해야 한다는건 약간은 납득할 수 있습니다만.. 전 조금 더 실질적인 이득이 궁금했는데, 직접 활용해보고 판단을 해야겠군요. 아 그리고.. 보안은 당연히 필요하고, private repo 사용시 들어가는 비용(매우 작지만..)이 연구비로 처리가 힘들어 사용하기가 어렵네요.
17/10/18 11:13
네 생각은 다를 수 있지만, 사실상 표준이라는 하나만으로도 쓸 이유는 충분합니다. 업무 효율성, 관리 측면, 협업, 개인 경력 관리... 어떤 이유를 들어도, 현재 사용하는 거에 익숙해서 바꾸지 않고 싶다는 점만 제외하면 vcs와 압축파일 관리는 vcs의 손을 들 수 밖에 없습니다.
그리고 위에 냐옹이님이 쓰셨지만 개인별 계정으로 하시면 사실상 무료로 사용 가능합니다.
17/10/18 10:00
추가 유지/보수 필요 없음은. 활용성이나 재사용성은 고려하지 않는 기초적 수준만 했다는거고
필드 나가서는 당연히 협업/유지보수/재활용성 은 무조건 필요한데 형상관리에 전혀관심이 없다는 것도 문제죠. 최근 오픈소스건 라이러리배포던 git을 필두로 형상관리를 통해서인데 그쪽에 관심이 없다는건 좀 뒤쳐졌다는 인상을 줄수있고요. 십대 일 수준의 경재율 이라면 충분한 탈락사유죠
17/10/18 10:03
혼자서 코드를 짜더라도 날짜별 코드 백업이나 코드 롤백, 추가했던 기능들에 대한 코멘트(커밋메시지) 등등 버전관리가 유용한 경우가 많습니다.
개발중에 삽질하다가 이렇게 하는게 아닌가보다 하고 롤백하려고 해도 백업을 미리 해둔게 아니라면 어렵죠.
17/10/18 10:05
4번은 저도 동의합니다. 글쓴이의 댓글 중 "gitlab 설치해서 운영할수도 있지 않느냐"에 대해서도 살짝 갸우뚱 하긴 합니다. 그런 프로그램 설치에 익숙하다면 모를까 불편하다면 나중에 굉장히 귀찮아 집니다.
그런데 본문의 박사님의 프로젝트가 CS 전공자의 프로젝트라면 버전 관리는 필수라고 생각합니다. 그외 전공에서도 하는일을 버전 관리하면 좋긴한데 익숙하지 않은 분들이 git배우고 하는 걸 주판 튕겨보면 사실 손해가 더 커서 권장하진 않습니다. 자바초코칩님께서 말씀하신 내용 중에 4번을 제외한 나머지 항목에 해당된다 하더라도 버전 관리는 꼭 필요하다고 생각합니다. 1 -> 한달 뒤에는 한달 전의 본인과 협업 해야 합니다. (기억이 안남.....) 2 -> 음.. 좀 애매한데 저같은 경우는 쪼가리 코드라고 하더라도 gist에 올려서 변경 사항을 추적하는 편입니다. 이득도 많구요. 3 -> 소스 자체가 문서고 문서변경에 대한 추적은 필요 합니다. 5 -> 2번에 대한 응답으로 갈음하겠습니다. 저라면 그건 틀린데요!! 가 아니라 음~ 한번 써보시면 좋을텐데요 이득 많음 히응히읗 하면서 권유할듯욥.
17/10/18 10:14
구글 면접 한번 도전해봤는데 2진수 그레이 코드로 변환하라길래 초등학교때 배운거라 자신있게
이렇게 하면 됩니다. 이랬는데 그렇게 하시면 안됩니다. 그래서 ?????????????????????? 상태 빠져서 어버버하다가 탈락했던 기억나네요ㅠㅠ 차라리 아예 모르는거면 생각해봤을텐데 당연히 변환공식 알아서 그대로 구현했는데 다른 방법을 원하시더라고요.
17/10/18 10:25
저도 회사에서 일하고 있는데 글 읽고 엄청 자극되네요... 과연 내가 면접을 본다면 통과할 수 있을까?
게으름에 빠져있던 저를 일깨워주는 좋은 글이었습니다. 다만 아래에 있는 박사분 사례에서 버전관리 시스템에 대해서는 한가지 의문점이 있는데요 탈락의 사유가 git 을 써본적이 없어서인가? 하는 생각이 들었습니다. 저는 이런건 연구실 그리고 학교라는 환경의 특성이 아닌가 생각하고, 오히려 git 같은 vcs 사용법은 실무에서 제아무리 길어봤자 몇주에서 한달정도만 배우고 사용해보면 금방 와 이거 진짜 편하네 하면서 익숙하게 사용할텐데 하는 생각이거든요. 코딩 인터뷰도 문제없이 통과하고, 문제 해결능력도 검증된 분이라면 오히려 그쪽에 가중치를 두는게 맞지 않을까 하는 생각인데 뭐 회사마다 가중치를 두는 부분은 달랐겠지요. 그거보다 자기가 쓴 논문내용을 설명 못했다는 부분이 훨씬 납득이 안갔습니다. 제 기준에서는 자기 논문이 기억이 안난다는건 자기가 애지중지 키운 자식에 대해 아 그사람 잘 몰라요 하는 수준이라고 생각하거든요. 이건 잊어버렸다기보다는 논문 과정에서 뭔가 부정함이 있었지 않았을까 싶네요. 논문은 누가 대신 써줬다던가
17/10/18 10:28
조금 더 정확히 말씀드리면 vcs를 안 쓸 수는 있는데,
vcs를 알고 있고, 다른 데서 사용한 적도 있었지만, zip으로 날짜별로 묶어 네트워크 디렉토리에 올리는 방식이 아무 문제도 없고, 바꿀 필요가 없다는 식으로 말씀을 하셔서 만장일치 탈락으로 결정했습니다.
17/10/18 10:38
그렇군요... 사실 보다 솔직한 제 생각은 (저도 가끔 면접보는데 들어가는 입장에서) 저는 vcs 의 활용유무로 탈락을 결정하지는 않았을 것 같다는 생각입니다.
vcs 가 중요하지 않다기보다는 너무 기본이라...? 어차피 면접 보면 다들 제각각 오만가지 버전관리하는 방식을 사용하셨고(본문 사례와 같은 v1, v2 방식 아카이빙 포함..), 어차피 입사하면 커밋메시지 쓰는것 하나부터해서 회사에서 요구하는 버전관리 시스템에 대한 교육기간이 반드시 필요한데 설령 안써봤더라도 그때 배우면 충분하지 하는 생각이거든요. 물론 판단 기준이 vcs 를 써봤냐 안써봤냐가 중요한게 아니라 뭔가 회사가 제시하는 방식에 대해 손쉽게 납득하지않고 독고다이식 내가 맞다라는 방식을 고수하며 트러블을 일으킬것 같다는 쎄한 느낌이 들어서 탈락시키셨다면 그 쪽으로는 결정에 공감이 갑니다.
17/10/18 11:06
그리고 제가 위에서도 짧게 썼지만, 그분 지원 동기중 하나가 동료들과 스터디도 하면서 새로운 걸 공부하고 공유하는 분위기를 만들고 싶은데, 그게 아니어서 아쉽다고 하셨었거든요. 새로운 걸 공부하길 원하지만, vcs는 사용하지 않고 그냥 하던대로 하고 싶다는 점은 모순이라고 판단했습니다.
17/10/18 10:30
궁금한게 알고리즘 구현을 하라고 한다면 무슨 언어로 시험을 보게되나요?
대학 졸업하고 공무원 준비하려다 실패하고 요즘 다시 국비로 자바 웹프로그래밍 과정 배우고 있는대 이것만 듣고있다간 취직 힘들겠다 싶은대 추가로 독학할만한게 뭐가 있나 궁금하내요. 안드로이드, php쪽이 그나마 익숙하고 지금은 jQuery, jsp배우는 과정이거든요.
17/10/18 10:33
조금 규모가 있는 회사에선 이런저런 언어를 쓰니까 주로 자신있는걸로 하라고하는데
작은회사에선 회사에서 주로 쓰는 언어로 하길 원하는곳도 잇구요
17/10/18 10:37
어떤 언어든지 자유롭게 자기가 만들고자 하는 로직을 만들어낼 수만 있다면 상관없죠.
솔직히 어느 정도 언어에 익숙해지고 나면, 다른 언어 배우는 건 syntax만 익히면 되니까... 요즘 나오는 함수지향형 언어들의 경우는 개념이 좀 달라서 어려울 순 있어도, 일반적으로 많이 쓰는 언어들은 사실 거기서 거기입니다. C/C++. C#, 자바, 자바스크립트, php... 등등은 사실상 한 뿌리에서 나왔다고 봐도 무방하고요.
17/10/18 11:08
제 경우는 자기가 가장 편한 언어를 선택하라고 말씀드리는데, (다행히 ^^;) 제가 모르는 걸 하는 분은 없으셨습니다. 압도적으로 python이 많고 그 다음에 c++, c, java였습니다.
17/10/18 10:33
zip으로 묶어서 네트워크 디렉토리에 올리는게 버전관리 하나만을 생각한다면, 문제가 없다고 생각할 수도 있겠지만...
그럼 diff는? branch는??? 을 생각하니까 갸우뚱하네요;; 하긴... 저희 회사 사장님도 VCS를 쓰시긴 하지만, 오로지 체크인, 체크아웃 외에는 아예 쓰는 일이 없...
17/10/18 11:17
늦은 나이에 이제 C#과 자바 배우기 시작 한지 4개월 정도인데 이런거 보고 있으면 겁이 덜컥 나네요 ㅠㅠ 과연 내가 해낼 수 있을지...
17/10/18 11:40
신입이라면 신입에게 걸맞는 질문을 할겁니다. 그렇게 까지 겁내실 것 없을 거에요.
선배로써(?) 약간의 조언을 드리자면, 언어 책도 좋지만, 프로그래밍 개념서, 이론서 등을 많이 보시는 게 도움이 많이 될 겁니다. 예를 들면, Code Complete, 생각하는 프로그래밍... 같은 책이죠. The Art of Programming 이 이 분야 최강이지만, 분량이 워낙(...)
17/10/18 12:18
조언 감사드립니다! 프로그래밍 개념서라는게 따로 존재 하는 줄 몰랐네요 :D 그렇챦아도 새로 코드 짤 때마다 어떤 순서와 구성으로 해야 하는게 좋은지 번번히 고민 하던차에 많이 도움이 될 것 같습니다.
17/10/18 12:22
도움이 됐다니 다행이네요. 저것 말고도 좋은 책들이 많으니, 인터넷 서점 등에서 서평이 좋은 책을 골라서 찾아 보시는 것도 좋을거에요.
서평들 중에서 "실무에 하나도 도움이 안된다."는 무시하시고요. 보통 그런 서평 쓰는 사람들은 풋사과들입니다(...)
17/10/18 12:41
현직에 있음에도 불구하고 프로그래밍과 코딩을 구별 안하는, 더러는 못 하는 사람들이 너무 많아요. 그런 사람들이 쓰는 서평이겠죠 크크크
17/10/18 11:40
글 잘 읽었습니다. 저런거 없이 입사해 다행이군요 ㅠㅠ
비전공자 현업자라 자료구조, OS 등의 부분에서 약점을 가지고 있는데 독학용 교재나 mooc 등에 추천해주실만한 강의가 있나요? 덤으로 데이터 분석일을 하고 있어서 장차 선형대수나 확률, 통계쪽에도 발을 들여야 할 것 같은데 혹시 추천해주실만한게 있다면 추천 부탁드립니다.
17/10/18 12:14
엄청나게 다양하지만, Khan academy나 coursera에서 자기 수준에 맞는 수업 들으면 좋을 거라고 생각합니다.
선형대수 확률 통계는 저도 알못이라 ㅜㅜ 혹시 python하시면 laff를 찾아보시면 좋겠네요.
17/10/18 12:23
이런 글 볼때마다 과연 내가 다른 회사에 경력으로 입사할 수 있을까 하는 자괴감이 드네요 흑흑
저는 프로그래밍이란 결국 자동화의 산물이라고 봐서, 입출력, 조건분기, 반복을 기반으로 시작해서 더 다양한 일을 동시에 시키고 싶으니 쓰레드, 물리적으로 다른데 있는 데이터 쓰고싶으니 네트워크 등등.. 이 추가되는 거라고 생각하거든요. 그래서 다른 언어를 보게되면 무조건 입출력, 반복, 조건분기 세가지 문법만 보고 나머지는 필요할 때 (갓구글님!) 찾아서 쓰는데.. 링크드리스트 정도야 당연히 쉽게 구현이 가능하지만 트리쪽은 조건에 따라서 좀 까다로운 부분도 있는지라 어버버 할것도 같고 무섭네요. 이런걸 술술 해야 취직이 쉬운 세상이라니 도태되는것 같고 참.. ㅠㅠ
17/10/18 12:39
저희 회사 같은 경우는 쥬니어 레벨 개발자는 거의 코딩만 보고 뽑는 편인데요. 그나마도 자료구조를 구현하라, 복잡한 알고리즘을 구현하라 이런 문제는 잘
안 내고 (면접자의 지식에 너무 좌지우지되는 성향이 짙어서) 실무에서도 가끔 접하게 되는 복잡도의 문제 정도로만 나옵니다. 다만 푸는 과정, 접근 방법, 문제를 대한 태도 등을 많이 보죠. 실제로 문제는 잘 푸는데도 떨어지는 분들 꽤 됩니다. 일정 이상 채용 프로세스가 잡힌 회사에서 중요한건 문제 그 자체가 아니라 면접관과의 커뮤니케이션이에요.
17/10/18 12:50
예전에, 임의의 자연수 n보다 작은 2의 승수 중 최대값을 구하는 함수를 만들라는 문제를 냈더니,
[Math.logs2(n)] 을 써서 낸 답변자를 보고 경악했던 기억이... (게다가 타입캐스팅도 안했어!!)
17/10/18 14:11
저도 비슷한 생각입니다. 면접에서 보고자 하는 것이 면접시 낸 문제를 풀고 못 풀고가 중요한 게 아닌 것 같다는 생각이 드네요. 결국 회사는 상품을 팔아야 하는 거고, 그걸 할 수 있는 사람인지를 판별하는 게 면접의 목적이 되어야 할 것 같습니다.
17/10/18 12:51
전에 다녔던 소규모 회사가 생각나네요.
대표한테 버전관리 하자고 했더니 그걸왜해 하시며, 무조건 작업전에는 서버에 올라간거 다운받아서 하라고 하시고. 타이밍 안맞아서 남이 작업한거 덮어씌었더니 욕먹고... 그래 지금까지 안쓸수는 있다고쳐도.. 회사발전이나 작업효율을 위해서 도입하자고 하면 고민은 해볼수있는건데...오로지 돈돈 크크
17/10/18 23:17
제가 다니는 회사는 아직도 clearcase 씁니다.... 요즘 git으로 migrate 중인것 같기는 한데...
작은 회사도 아니고 엄청 큰 회산데.. ㅠㅠ
17/10/18 18:16
음 그런데 괴담식으로 프로그래밍 안풀려서 치킨집에서 고민하는데 치킨집 사장이 가볍게 풀어주고 갔다는 이런 이야기가 실제로 가능한가요?
최종트리가 정말 치킨집인지 궁금합니다!
17/10/18 18:26
그런 경우도 있고, 아닌 경우도 있는 거지요...
그러고 보니, 이 바닥 떠난 선배님들 중에 연락 되는 분들은... 어디보자... 택시 운전사, 컴퓨터 학원 강사, 핸드폰 가게 사장, 보험 설계사... 등등이 되셨군요;;
17/10/18 20:45
말씀하신 면접 통과한다고 하면...
우리나라에서는 학부 졸업 신입 지원자 기준으로 거의 탑 수준 아닌가요...? 우리나라 상위권 대학 컴공 학부 졸업생만 되도 저정도 수준이 될런지요...
17/10/18 23:23
인터넷에 찾아보시면 "넥슨 입사시험 문제" 또는 "넥슨 코딩테스트" 라는게 돌아다닙니다.
한번 보시면 알겠지만, 컴공 학부 4년을 "충실히" 이수했다면, 풀지 못할 문제가 아닙니다. 글쓴 분이 어떤 회사를 다니시는지 모르겠지만, 아마도 넥슨 코딩테스트 이상의 난이도는 아닐 거라고 봅니다. 대부분의 경우, 해당 문제를 해결하기 위해 어떤 식으로 접근했는지, 코드를 얼마나 직관적이고 효율적으로 만들었는지를 보는 것이지, 말도 안되게 어려운 문제를 내 놓고 해결하라는 식은 아닐 겁니다. 예를 들어서, 네트웍 연결 안 된 컴퓨터 한 대 던져주고, 레퍼런스 없이 다익스트라 알고리즘을 구현해라... 뭐 이딴 건 안 한다는 거죠;;;
17/10/19 01:22
면접 문제 자체가 다 기본적으로 학부 때 배우는 내용입니다. 사실 학부 때 배운 내용을 다 알기만 해도 정말 쉽게 볼 수 없는 수준이기도 합니다만...
그리고 면접 통과하는 분들의 학력이 이른바 좋은 학교 쪽에 치우쳐 있지 않습니다. 제가 글에서 언급한 안 좋은 경우도 학력도 좋고 수상 경력도 좋았었죠.
17/10/18 23:21
신입으로 들어올때는 보통 3~5년차쯤 이직하는게 연봉 뻥튀기에 제일 좋다며? 하면서 들어왔는데..
정작 연차가 조금 쌓이고 나니 인터뷰가 무서워서 못옮기겠어요... 허허 대학 졸업하고 인터뷰 준비할때가 "인터뷰 실력"에 있어서는 지금까지 중 제일 빠릿했던 것 같아요.
17/10/19 15:38
vcs 사용에 대한 논란이 많네요. 제가 채용에 관여한다면, vcs를 사용해보지 않은 사람은 굉장히 높은 확률로 뽑지 않을꺼 같군요.
심지어 git은 사용해보지 않고 svn만 사용해봤다고 하더라도 큰 감점요인으로 생각합니다. 1. 버전 관리 시스템이 필요 없을 정도의 소프트웨어 개발만 경험해본것으로 보임 2. 학부 프로젝트 수준의 소프트웨어를 개발하더라도, 버전 관리의 필요성이 느껴질텐데.. 문제 해결을 위한 학습 의지가 낮아 보임 3. git을 사용해보지 않았다는건, 오픈소스에 관심이 없는것은 물론이고 접해본 코드가 굉장히 한정적일것으로 예상됨 4. MD 파일 작성은 물론, 문서화는 제대로 해봤을까라는 의문이 듬 어떤 경우라도 소프트웨어 개발을 한다면 VCS 사용은 기본이라고 보구요. git 에 능숙함을 보여주는 지원자라면 일단 긍정적으로 볼것 같습니다.
|