기술면접시 뭘 물어보는것이 좋을까요..

copy 함수를 만들어보라고 해보세요.

짧고 굵은 코딩이 될 것 같네요.

그런건 너무 쉬운거같은데
좀더 원론적인것을 묻는게좋을것같네요
코딩같은거야 들어와서 1주일이면 다 습득하거나 레퍼런스를 참고할수 있는
부분입니다.

개념이 없는넘이었군요 :oops:

이런....^^;;;;;; 죄송합니다~~~~~

필요한 것을 어떻게 구현하느냐 보다는 필요한 것을 어떻게 알아내느냐 더 중요하다고 생각합니다.
인터넷 조금만 뒤지면 샘플코드가 천지지요.. 알고리즘만 잘 생성해내면 코딩이야 뭐 금방 하지 않겠습니까? 기반지식이 얼마나 있는지 알아낼수 있는 문제가 좋다고 봅니다..

file system 구성이 어떻게 되어있냐?
scheduling방식에는 어떤것이 있으며 linux에선 어떤 방식을 사용하고 있냐?
thread와 process의 차이는 무엇인가

file system 하나만 질문하시죠?
이것만 해도 30분 정도는 답변할 내용은 충분합니다.
전 경력 10년차인데요.
요즘 새로온 직원들 보면 file system이 뭔지 전혀 모르더군요.
다른 것은 가르쳐 주기 쉽지만 file system 만큼은 안되더군요.

구글아저씨가 모르는 문제를 내주세요~

Data Structure 강의시간에 교수님에게 질문했던게 떠오르는군요. 마침 교수님이 void에 설명하셔서 나름대로 애들에게 도움이 돼라고 질문을 했었죠.

"교수님!!~ 혹시 void나 void*가 특별하게 쓰이지 않나요?~"

교수님왈!~ "아니!! void가 void지. 특별하게 뭐있어!!"

그 교수님이 일명 방교수님이라고 부르는데...그 교수님땜시 그 수업에서 엄청 쪽먹고, 그 다음부터는 절대 질문을 하지 않았다는 전설이...

저라면 두가지를 보겠습니다.

싸가지(의욕) + 얼마나 보았는가?

첫째, 참으로 어려운 부분입니다. 같이 생활해봐도 참으로 알기 어렵습니다. ^^;

둘째, 얼마나 다양하고 많은 책을 읽었는지...혹시 OS공룡책, 커파일공룡책, 레드북씨리즈, ACM, 황희융교수, 이석호교수 외 SNU패밀리, 김치하교수, 이재규씨, mano, navathe, korth...
컴퓨터 사이언스에 관심이 있다면 한번쯤은 듣어봤을 법한 이름들입니다.

이름안다고 전부 아는건 아니지만, 어느정도 알고 있다는건 그래도 관심이 있으니까! 찾아보고 지속적으로 관심이 있다는거니까요. 첫번째와 약간은 일맥상통합니다. ^^;

어느분야의 누굴뽑느냐에따라 상당히 다르겠죠..

그사람의 해온일의 검증차원에서 물어보시는게 적당할것 같군요.

새로운일이나 혹은 문제 혹은 개념용어등은 일시적으로 생각이 안나거나
대답을 못할수도 있습니다.
천재들도 건망증이 심하거나 순간적이고 적흥적인 말에대해 잘대응하지 못하기도 합니다.

또한 void 포인터 머이런것에대한 견해의 차이도 있겠죠..
제가생각하는 void 와 님 혹은 옆사람에게 말해보라고하면
같은대답을 한는사람이 과연 몇이나될까요..

- 알고리즘은 실제 프로그래밍에서 매우 중요하므로 다음과 같은 문제도 낼 수 있습니다.

유클리드의 "호제법"에 따라
최대 공약수를 구하는 함수를 작성하시오.
이 함수를 개량하여 최소 공배수도 구할 수 있게
하여 보시오.

GCD를 호제법에 의해 구한 후
LCM = 수1 * 수2 / GCD 했다면
다음 문제로...

- 라이브러리의 활용도

어떤 수를 나누어 (정수 나누기 정수)
몫과 나머지를 출력하는 프로그램을
작성하라고 해 보십시오.
표준 함수 중에는 분명히
구조체를 이용하여 quot과 rem
(각각 몫과 나머지)를 반환하는
함수가 있습니다.

- 알고리즘 + 라이브러리

피타고라스의 정리에 따라
직각삼각형의 빗변을 구하는 함수를
만들라고 하십시오.

x1, y1, x2, y2를 받아서

return sqrt(pow(x2 - x1, 2) + pow(y2 - y2, 2));

혹은

return sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1));

라고 했다면, 표준 라이브러리를 잘 활용하고
알고리즘을 잘 아는군요.

피타고라스의 정리 문제를 내실 경우에는
후자에 점수를 더 많이 주세요.

실행 속도상 후자가 더 빠르답니다.

- 몫과 나머지

아까 표준 라이브러리 문제의 정답입니다.

C언어 : <stdlib.h>
C++ : <cstdlib>

에 보면

div_t div ( int numer, int denom );

몫과 나머지 구조체는

typedef struct {
int quot;
int rem;
} div_t;

RedHat Linux라면 rpm에 대해서 물어보세요

'프로그래밍 이란 무엇이라 생각 하는가?'

저는 저를 아는지 물어봅니다. :) 뭐 모른다는 이유만으로 떨어뜨린 적은 없었던 것 같은데...(분야가 다를수도 있으니)

아주구체적인 내용을 물어보라는분들이 많은데..
그럴꺼 같으면 차라리 해놓은걸 보여달라고하세요..

아무리 말해도 그건 말뿐이 더되나요..
그정도 잘하면 분명뭘해도 했을테니..

뭐 무엇무엇이 어떻게 생겼고 어디서 나왔으며 이렇게 사용하고 아주예민한부분이 있으며 주저리주저리.. 800타이상되는 타속으로 날코딩을 해내려가면서
일부기능을 직접 보여주는사람 있었습니다.
결론은 그럼 당신이 직접 만들어보시오.... 그사람 개발기간을 6배나까먹고도 못했습니다.

개발이면 개발, SE 면 SE, NE 면 NE 지원하는 분야에 따라 다르므로

어느 특정 질문을 하기보단

자신이 자신있는 분야에 대해서 서술 or 설명(부담스럽나?)하라고 하는게 나을듯 해보이는데요

그 얘기를 들어보면, 이 사람 수준이 어느정도 되는지, 그걸 바탕으로 질문을 할 수도 있다고 생각합니다.

PS. 질문을 무지막지하게 하는 압박면접은 싫어요 -.- :oops:

면접 그 짧은 시간내에 그 사람의 기술적인 평가를 몇 문제 가지고 하는 건 사실 힘들거라 생각이 되어 집니다. 세세한 코딩이라든지 그런 것 보다는 해당 업무 분야에 대한 그 사람의 가지고 있는 기술적인 마인드 ( ? ) 부분에 대해서 물어 보시는 건 어떨까요 ?
예를 들면 앞으로 해야 할 일이 그동안 하던 것과는 생소한 것일 때 어떻게 그 문제를 해결할 지에 대한..그 막연한 일을 구체적을 설명 하시고 해결 법을 물어 본다든지, 앞으로 새로운 기술들이 많이 나오는데 어떻게 그런 기술들을 현실적으로 습득을 할 지에 대한 것이라든지...

기초적인 코딩이나 내용들은 안물어 보는게 나을듯 하네요.

차라리 그사람이 하게될 업무에 대하여 어떻게 해결하는지 패턴을 묻는 편이 낫죠.

특히 경력자 들에게 기초적인 내용 코딩해보라고 하고 물어보고 그러면 짜증날듯..

정말 이런 말이 딱이지 싶습니다.

그 사람을 왜 뽑고자 하는 지를 잘 판단하신 후 그 이유에 합당한 사람인지를 판단할만한 내용을 물어보는 것이 맞겠죠. 간단히 신입과 경력의 경우마 하더라도 신입은 앞으로의 가능성을 보고 경력이면 역량을 보겠죠..
이렇게 조금씩 영역을 줄여가다 보면 그 사람에게 요구되는 면이 구체적으로 나올 것이고 그것을 파악할 수 있는 문제도 더 확실히 보이겠죠.

하지만 역시 사람 뽑는 문제가 힘든 문제라는 건 변함이 없겠군요.

지난번에 비슷한 주제가 나와서 한번 글을 올렸었는데요.
제가 96년 처음 취업할 때 당했던(?) 방법입니다.

C 시험문제를 10~20 개 정도 초급, 중급, 고급을 적당한 비율로 내세요.
아주 어려운것도 포함하고요.
K&R을 던져주면서 오픈북으로....

응시자도 별 거부감이 없고, 다면적(?) 평가가 가능해서 좋은 방법이라 생각했었습니다.

면접이 아니라 시험이군요..

이번 글 읽고...
어떻게든 울 회사에 버텨야 겠다고 결심했습니다..
면접보기가 두려워요~~~^.^

저도 얼마전에 경력자에대해 면접시험관 비스무레한 것을
할 기회가 있었는데, 다음 세가지 질문을 했습니다.

1. 자신이 책임지고 설계 및 코딩한 모듈 하나를 말하시오
2. 위 모듈에 대해 설계 다이어그램을 화이트보드에 그리고
설명하시오 (최대 30분안에).
3. 제작한 제품이 실제 판매되고, 1년 이상 유지 보수 해본
경험이 있는지, 그때 얻은 교훈은 어떤것들이 있는지..