인터뷰 담당자가 응시자에게 Stack Exchange 사용자 이름을 요청하는 것이 적절합니까? [닫은]


126

소프트웨어 면접에서 (또는 인터뷰 전 심사 질문으로) Stack Exchange 사용자 이름을 요청한 경우 적절하다고 생각하십니까?

제게는 매우 합리적인 요청 인 것으로 보이며 매우 유익한 요청 인 것 같습니다. 5 분 내에 후보에 대해 더 많은 정보를 얻을 수 있다고 확신합니다. 30 분 인터뷰. 그러나 그러한 질문은 나쁜 형태일까요? "너무 개인적인"입니까?

( GitHub 또는 기타 공개 / 온라인 코드 공유 포럼과 마찬가지로 )


36
그들이 요청하면 회사 / 관리자 / 직업에 대해 많은 정보가 있다고 생각합니다.
JeffO


25
제 경우에는, 이력서가 있으면 물어볼 필요가 없습니다.
Keith Thompson

45
사용자가 다른 SE 사이트에서 활동중인 경우 SO 계정이 훨씬 더 많은 개인 정보에 연결될 수 있다는 점이 조금 문제가 있습니다. 종교 사이트 또는 육아와 같은 콘텐츠는 사용자가 실제로 공유하고 싶지 않은 개인 정보를 고용주에게 제공 할 수 있습니다. 그리고 고용주는 잠재적으로 사용자가 SE에서 사용자 ID와 대화 한 모든 내용을 검색 할 수 있음을 잊어서는 안됩니다.
미친 과학자

18
글쎄, 나는 SO를 사용하여 모든 바보 같은 질문을 했으므로 고용주에게 바보처럼 보이지 않습니다. 역화!
채드 해리슨

답변:


105

단답 : 물론입니다.

조금 더 긴 답변 :
직장에서 우리는 정기적으로 후보자의 스택 오버플로 / 스택 교환 사용자 이름을 요청합니다. Stack Exchange 커뮤니티에 공헌하면 누군가가 자신의 기술을 가지고있는 곳이 훨씬 더 명확 해집니다.

GitHub 계정 을 요청하고 GitHub 계정이 없는 후보자 수락을 거부하는 다른 사람들을 알고 있습니다 *.

우리의 경우, 우리는 하지 않습니다 그들이 경우에 고려의 후보를 제거 하지 않는 계정을 가지고있다.

궁극적으로, 그것은 회사의 요구와 후보자의 기술 사이의 일치를 식별하려고 할 때 인터뷰 퍼즐의 한 조각 일뿐입니다. 그것은 만들거나 깨는 요인이 아닙니다. 인터뷰 중 인상을 확인하는 데 도움이됩니다.

* 분명히, 나는 그 접근법을 용납하지 않으며, 그것이 그 팀이 다른 자격을 갖춘 후보자를 놓치게한다고 생각합니다. 좀 더 극단적 인 입장에 대해 들었고 스택 오버플로 계정 이름을 요청하는 것이 비교적 온화하다는 것을 보여주었습니다.


주석을 기반으로 한 추가 규정 자 :

  1. 메타 스택 오버플로 및 메타 유형 게시물 은 보지 않습니다 . 메타는 다르기 때문에 이해합니다. 또한 이러한 유형의 게시물 뒤에있는 내용을 놓치기 쉽습니다. IMO는 후보를 평가할 때 신호보다 잡음에 더 가깝습니다.

  2. 마찬가지로 의견 및 검토 활동도 고려되지 않습니다. 상황이 결여되어 있으며 후보자의 업무 수행 능력과 의미있는 상관 관계가 없습니다.

  3. 인터뷰에서 응시자의 성과와 참여한 Q & A 수준 사이에 확실한 상관 관계가 있음을 발견했습니다. 그들의 스택 오버플로 / 스택 교환 계정은 인터뷰 과정에서 제출 된 코드 샘플과 동등한 지원 사실이됩니다.


인터뷰에서 의무적 인 xkcd 스트립 . 정교함 .


70
github 계정이 없기 때문에 후보를 거부하면 가혹한 것처럼 보입니다 (멍청한 읽기). Github는 소스 코드를 게시하는 데 사용할 수있는 유일한 서비스는 아니며 개인이 자신의 공개 버전 제어 서버를 가질 수 있다고 계산하지는 않습니다.
Arseni Mourzenko

5
@MainMa-동의했고, 나는 그것을 용인한다는 것을 암시하지 않기를 바랍니다. 다른 면접관이 알아야 할 일로 연결하면됩니다. 확실하지 않다면 내 답변을 편집하겠습니다.

13
Github 계정을 가진 대부분의 사람들은 몇 년 전에 코드를 작성했습니다. Google을 통해 찾은 담당자를 기준으로 후보를 판단하는 것은 불공평합니다.
Reactgular

2
나는 github를 사용하지 않는다. u는 개인 계정을 무료로 가질 수 없다. 비트 버킷을 선호한다. 그래서 나는 github을 요청 받았다. 당신은
장난 치지

23
누군가가 StackOverflow에 대해 들어 본 적이 없다면 아마도 기술적 문제에 대한 해결책을 찾기 위해 Google을 사용하지 않았을 것입니다.
Ken Liu

113

SO 사용자 이름이 무엇인지에 대해 빈칸을 물으십시오. 그것은 매우 직설적으로 들릴 것이고, 그런 질문은 조금 침략적이라고 생각할 것입니다. 문제를 해결할 때 어떤 온라인 리소스를 사용하는지 묻는 것이 훨씬 더 적합합니다. 그리고 경우에 그들은 그들이 StackOverflow의 사용자 인 것으로 대답, 다음, 당신이 그들에게 있다고 생각 하는 방법을 그들이 상호 작용. 그들이 활성 요청 - 어 / 답변 - 어 있음을 언급하는 경우, 다음 자신의 사용자 이름이 적합 할 것입니다 무엇을 요구.

면접관이 물어 보는 것은 괜찮다고 생각하지만, 후보자가 거절하면 거래를 중단해서는 안됩니다.

어떤 사람들 은 StackOverflow에 대한 질문 이없는 전문화 된 독점 도구를 사용합니다 (방금 확인했습니다). 어떤 사람들은 다른 사람들의 일반적인 질문에 대답 할 시간이 없습니다. 나는 언어 장벽 때문에 SO에 대해 묻거나 대답하지 않는 일부 개발자를 알고 있습니다.

StackExchange 생태계에 많이 참여하지 않는 훌륭한 개발자가 있습니다.


14
이것이 내가 부적절하다고 생각하는 이유입니다. 당신이 옳습니다 : 응시자가 답변을 거부 할 경우 거래를 중단해서는 안되지만, 실제로는 그렇지 않을 것이라고 말할 수 있습니까? 심리학은 이것이 사실 일 가능성이 없다고 말합니다. 비록 그것이 실제 행동이 아니더라도 이와 같은 정보는 여전히 어느 정도 귀하의 결정에 영향을 줄 것입니다. 여기서 계정을 가지고 있지 않은 사람들에게 공정하게하기 위해 유일하게이기는 것은 게임을하지 않는 것입니다. 우선 질문을하지 마십시오.
Spooniest

9
시점에 동의하십시오. 내 SO 프로필은 주로 내가 묻는 질문입니다. 가장 간단한 질문에 대답 할 수있는 분야에서 가장 빠른 타이피스트 (나가 아닌)에 속하거나 자유 시간에 보내고 싶은 것보다 더 많은 노력이 필요합니다. 커뮤니티에 대한 나의 주요 기여는 리뷰 대기열에 있습니다. 리뷰는 소수의 사용자에게만 보여지기 때문에 몇 분 안에 커뮤니티에 되돌릴 수 있으며 다른 사람이 훔치지 않도록 분당 80 또는 100 단어를 입력하지 않아도됩니다.
Dan Neely

3
정확하게 bog 표준 C # 및 Java 직원을 고용하는 경우 StackExchange / StackOverflow 사용자 ID에 대해 문의하십시오. 나는 무엇보다도 델파이 사람이고 StackOverflow의 델파이 섹션은 매우 활동적이지만 아마도 "광도"레벨의 델파이 사람의 90 %는 StackOverflow에 있지 않습니다. 모자 한 켤레에 StackOverflow 담당자 대신 "내가 들었거나 다운로드하거나 다운로드 할 수있는 것"을 허용합니다. 실제 언제라도 가짜 인터넷 포인트를 통한 코드.
Warren P

27
@WarrenP : "내가 들었거나 다운로드 할 수있는 것" 은 사내에서 사용되며 같은 건물에 앉아있는 주요 비즈니스 사용자를 넘어서는 제공되지 않는 소프트웨어를 개발하는 사람들에게는 어렵습니다. 거기에 내장 된 많은 소프트웨어는 실제로 외부 사용자에게 "배송"되지 않습니다.
FrustratedWithFormsDesigner

3
그들이 중요한 것을 구축했다는 것을 증명할 수없는 사람을 평가해야한다면 어쨌든 시도해 보 겠지만 좋은 징조는 아닙니다. 25 년 동안의 역사는 대부분 들어 본 적이없는 사내 비공개 소스였습니다. 그러나 나는 여전히 언어 하위 커뮤니티에서 사용되는 공유 라이브러리 등에 코드와 픽스를 제공합니다. 나는 내 분야에서 가장 훌륭한 사람들의 대부분을 찾습니다.
Warren P

68

이 의견이 특히 인기가있는 것 같지는 않지만이 정보를 요청하는 것은 괜찮다고 생각하지 않습니다.

스택 교환은 학습의 장소입니다. 나중에 "멍청한 질문"을하는 것으로 판단되는 것에 대해 걱정할 필요가 없습니다. 나는 프로그래밍뿐만 아니라 모든 종류의 주제에 대한 지식을 넓히기 위해 Stack Exchange에 왔습니다. 내가 스스로 문제를 해결하기 위해 어떤 노력을 기울 였다면, 그 주제에 관한 대부분의 전문가들이 답을 알고 있어야한다는 질문을 자각 할 필요는 없습니다.

또한 여러 계정을 유지하는 사용자, 질문 및 답변을 제공하는 사용자의 문제를 악화시킬 수 있습니다. 나는 이미 이것을 SE에서 여러 번 보았습니다. 질문이 적을수록 지식이 풍부 해 보이기 때문에 사용자가 그렇게 생각합니다.


2
회사는 자체 심사 기준을 마련해야한다는 데 동의합니다. 사용자가 SE 사용자 이름을 제공하도록 요청한 경우 인터뷰 담당자는 응시자에게 SE 사용자 이름을 제공해야합니다.
hanzolo

6
동의하다. 이전에 사용자 ID 제공을 거부했습니다. SE / SO를 사용할 때마다 미래의 직업 응용 프로그램에 대한 온라인 존재에 대해 생각해야한다면 내 업무에 해가되고 현재 고용주에게 장애가 될 것이라고 생각합니다.
jwg

3
면접관으로서 나는 자신의 "멍청한 질문들"에 관심이 없다 (나는 많은 질문을했다). 나는 그들의 멍청한 답변에 대해 조금 더 걱정할 것입니다. 그러나 주로 개발 과정이 어떻게 발전하고 있는지 알고 싶습니다. (물론, 응시자가 내 동기를 알 수있는 방법이 없으므로 우려가 유효합니다.)
kmote

7
그렇습니다. 완벽한 세상에서 면접관은 신중하게 진행 상황을 연구하고 대답을 설명 할 수있는 명확성을보고 있다고 생각합니다. 그러나 현실 세계에서 나는 그들에게 "그들이 대답을 알고 있어야한다고 생각했다"는 질문을보고 나서 건너 뛰는 것에 대해 걱정할 것입니다.
MikeS

2
@emory 이것은 사용자에게 고통입니다. 실용적인 '작업'쿼리의 일부로 광채를 내뿜을 수있을 때를 알지 못하기 때문에 제대로하기가 어렵습니다. SE와 rep 시스템을 덜 유용하게 만듭니다. 더 이상 실제 작업 헤드 스페이스를 보지 않고 여가 시간에 냉소적으로 만든 담당자를 보이므로 고용주의 이익을 무효화합니다. 마지막으로 Git에서 원격 브랜치를 삭제하는 방법과 같은 쉬운 질문에 적극적으로 대답하는 동기를 제공합니다.
jwg

26

후보자에게 자원하지 않은 정보를 요청하는 것은 부적절하다고 생각합니다 (범죄 배경과 같은 몇 가지 명백한 예외를 제외하고). 어떤 질문을 할 수 있습니다. 특정 사이트에 대한 참여가 인종, 연령, 성별 또는 차별이 금지 된 다른 카테고리와 상관 관계가있는 것으로 판명 될 경우 잠재적으로 소송을 제기 할 수 있습니다. 실제로 그러한 차별을 실제로 저지르고있을 수도 있습니다 (거의 확실하지 않음).

이 빠른 Google 검색 결과 에 따르면 소셜 미디어 검색은 고용주가 정보를 발견하는 것이 불법임을 묻고 잠재적으로 차별 소송에 노출 될 위험이 있습니다. 어떤 곳에서는 장애 나 임신에 관해 묻는 것이 합법적이지 않습니다. SO와 SE는 전문적인 사이트이기 때문에 차별이 문제의 목적이 아니라고 주장하는 것이 더 합리적입니다.

저는 개인적으로 "저희가 알고 싶은 전문 웹 사이트에 참여하고 있지만 이력서에 반영하지 않았습니까?" 그리고 나는 그들이 참여하고 있지 않은 다른 사람들이 경쟁하는 다른 후보자들이 자신의 답변에 도움을 줄 수 있다는 것 외에는 부정적인 것으로 간주하지 않을 것입니다.


9
인터뷰는 후보자에게 자원하지 않은 정보를 요청하는 것입니다. "저는 JavaScript에 대해 전혀 모르지만 콜백을 얻을 수 있도록 이력서를 올려 놓으십시오"라는 말은 거의 없지만, 작업에 필요할 때 알고 싶을 것입니다. 개인적으로, 나는 종종 후보자들에게 그들이 읽거나 참여하고 싶어하는 기술 또는 프로그래밍 관련 웹 사이트, 블로그 및 커뮤니티에 대해 질문합니다. 후보자가 최신 정보를 얻고 배우는 방법을 알아 내고, 나에게도 추천을받습니다. 또한 같은 이유로 선호하는 도구, 편집기, IDE에 대해서도 묻습니다.
Zach Lipton

1
당신은 차별에 대한 법적 / 불법적 근거가 뒤 바뀌 었다고 생각합니다. 두 변수의 상관 관계, 그 중 하나는 때 입니다 업무 성과의 유효한 예측, 당신은 그것에 대해 물어 사용할 수 있습니다. 명백한 예 : MIT 등록은 성적으로 중립적이지 않지만, 누군가 MIT를 졸업했는지는 기술 작업과 관련이 있는지 물어볼 수 있습니다. 마찬가지로, SE / SO 참여는 기술 문제를 의사 소통하고 기술 개발을 따라갈 수있는 능력을 나타내는 올바른 표시이므로, 이러한 범주 중 하나와 상관이 있어도 유효합니다 (성별)
MSalters

1
@psr 귀하의 반대 의견에 감사 드리며 잠재적 차별 문제에 대한 귀하의 의견은 주목할 가치가 있습니다. (다음 인터뷰 전에이 질문을 HR 부서에 제출하도록 촉구했습니다.) 그러나 개인적으로 저는 다른 의견 제시 자들과 동의합니다. 무작위로 이력서를 선택할 수도 있습니다.
kmote

25

SW 면접에서 (또는 인터뷰 전 심사 질문으로) Stack Exchange 사용자 이름을 요청한 경우 적절하다고 생각하십니까?

좋은 후보는 StackExchange 계정이 없습니다. 따라서 5 명에게만 현장 인터뷰를 제공 할 수 있고 100 명의 지원자를 기대할 수 있다면 이는 초기 후보를 더 잘 구별 할 수있는 더 좋은 방법을 제공하는 좋은 전략 일 수 있습니다.

그러나 염두에 두어야 할 당신이 할 후보자 제거 할 수 없습니다 당신이 그렇지 않으면 계정을 가지고 있지 훌륭한 후보가 될 사람의 위험을 기꺼이하지 않는 한 StackOverflow의 계정이 있어야합니다.

당신이 인터뷰 과정의 한 부분으로 이것을 사용하려면, 나는 것 강하게 github에와 StackExchange은 (포괄적이지) 모두 가능성이 있습니다 - 중 하나 옵션으로 추천합니다.

이것이 필수로 표시되지 않도록하십시오.


가능하면 인터뷰 대상자로서의 인터뷰에서 내 프로필을 자원 봉사하겠습니다. "재미있게 코딩하니?"에 관한 질문과 관련하여 자연스럽게 나타날 수 있습니다. 또는 "외부 학습을 위해 무엇을합니까?" 또는 그런 질문이 있습니다.

그러나 이것들 을 찾는 데 도움이됩니다 .


또한 StackExchange 계정에는 두 가지 스토리가 표시 될 수 있습니다. *

  • 의미있는 질문을 할 수있는 능력
  • 의미있는 답변을 제공하는 능력

프로필과 질문 / 응답 비율에 따라 둘 다 좋거나 나쁠 수 있습니다.

* 여기서 길을 너무 많이 보냈다는 것을 보여줄 수도 있습니다.


2
"인터뷰 프로세스의 일부로 이것을 사용하려면 github와 StackExchange가 널리 사용되지만 배타적이지 않은 옵션 중 하나로 권장합니다." 합법적 인 개발자 사이트 / 메일 링리스트 등에 참여하면 유용한 정보를 제공 할 수 있습니다.
Dan Neely

잠재적 인 직원들이 온라인에서 시간을 보내는 데 더 나쁜 곳을 생각할 수 있습니다. 그러나 당신이 말했듯이, 실제로 StackExchange에서 수행중인 작업에 달려 있습니다.
Michael Lai

"아, 그러나 정보가 필요하지 않습니다"라는 메시지가 표시되면 이미 의심스러운 것입니다. 그것은 단지 적합 후보없이 잎 제공하지 않는 사람 ... 거부하는 경우 "필요하지"가장 가능성
jwenting

13

예,하지만 사전 심사 질문으로 가장 가치 있다고 생각합니다. 사실, 처음 질문하는 경우, 면담 중에 정보에 의미있는 방식으로 행동 할 수 없습니다. 코드 샘플을 요청하기 위해 사무실에 올 때까지 기다리는 것과 같습니다. 사전 심사 질문의 또 다른 이점은 그들이 어떤 이유로 든 공유하고 싶지 않다고 결정하면 핫 시트에 있지 않고 결정을 내릴 수 있다는 것입니다.

일반적으로 훌륭한 / 허용 가능한 리소스라고 생각합니다. 그들에게 하나가 있다면, 특히 인터뷰 중에 자신 이 코드 샘플로 제공 한 답변을 찾을 수 있거나 그들이 작업하고있는 것과 관련된 몇 가지 질문에 답변 한 경우 훌륭한 대화 포인트 가 될 것입니다. 이것은 그들이 이전에 분명히 시간을 들여 놓은 특정 주제라는 추가 이점을 가지고 있으며 서면 답변을 개발했습니다. (그 답변이 잘 구성되지 않았거나 잘못 밝혀지면 매우 유용한 지표입니다).


11

나는 고용주가 그것을 요구하는 것이 합리적이라고 생각하지만, 그것이 메이크 앤 브레이크 규정 자라고 합리적이라고 생각하지 않습니다.

Joel은 고임금은 고임금 일자리를 얻는 것과 같지만 자신의 논리에 따라 고용 된 경우가 아니라면 정신적 기술을 습득하고 다량의 담당자를 확보 할 시간이 없을 수 있다고 언급합니다. 그래서 (당연히 그렇게하고) 스택 교환에 대한 시적 왁스 남자는 정말 모두 높은 취업의 지표의 인정 고용에서.


1
그러나 가장 점수높은 사용자 에게는 직업이 있으며 일반적으로 출퇴근 또는 점심 시간에 질문에 대해서만 답변합니다.
Brendan Long

직장 대신 사이트에서 많은 시간을 보낸다는 지표는 어떻습니까?
JeffO

@JeffO 나는 그것이 Joel이 만들고자하는 주장이라고 생각합니다. 작업 대신 스택 오버플로에 많은 시간을 소비하면 실직 상태 일 수 있습니다.
Ampt September

@BrendanLong 나는이 경우 Jon Skeet이 예외가 아니라고 생각합니다.
Ampt

1
@Ampt 내 요점은 "평판이 많은 사람"이 직업이없는 것에 대해 근거없는 가정을하고 있다는 것입니다.
Brendan Long

5

나는 항상 이것을한다.

온라인 평판 소스를 요청하는 IMHO는 이력서를 요청하는 것과 한 가지 중요한 차이점이 있습니다. 좋은 온라인 평판을 찾는 것은 좋은 이력서를 만드는 것보다 훨씬 어렵습니다.

Stack Exchange는 응시자의 의사 소통 기술에 대해 알아볼 수있는 좋은 장소입니다.

훌륭한 프로그래머 이상을 존중하는 것은 없습니다. 그러나 훌륭한 프로그래머이자 훌륭한 커뮤니케이터가 될 수 있다면 달성 할 수없는 것이 거의 없습니다. -제프 애트우드

GitHub는 (최소한 우리가 사용하는 기술 스택에 대해) 대부분의 유명한 프로젝트가 호스팅되는 곳이며, 후보자가 이러한 프로젝트 중 일부에 기여한 경우 자신의 작업 품질에 대해 많이 말합니다 (좋은 프로젝트는 문서가없는 풀 요청을 수락하지 않습니다) 및 / 또는 단위 테스트).


4

이것에 대해 유럽과 미국 사이에 문화적 차이가있을 수 있지만 여기에 대한 나의 관점이 있습니다 ...

직업을 신청할 때, 후보자로서 자신의 경험, 문제의 직업을 수행 할 수있는 능력 및 능력을 제시하고자합니다. 귀하는 고용주가 라고 말할 수있는 간단한 선택을하기 위해 귀하가 제시되는 방법을 적극적으로 결정하고 있습니다 . 이것이 우리의 새로운 직원 입니다.

고용주는 후보자 중 누가 업무를 수행 할 수 있는지 파악하고, 회사 문화에 정착 할 수있는 능력을 갖추고, 해결 하는 것보다 더 많은 문제를 일으키는 직원을 채용하지 않기를 희망 합니다.

따라서 채용 할 때 후보자에게 Stack Exchange 자격 증명이나 Facebook 사용자 이름, Twitter 계정 또는 Google ID를 요구하지 않습니다. 나는이 모든 것들을 사적인 개인적인 활동으로 생각하고, 그들이 행한 행동으로 인해 이루어지지 않는 한, 업무 관련 문제가 아니라는 후보들의 합리적인 기대를 존중할 것입니다.

응용 프로그램에서 CV가 Stack Exchange ID를 언급 한 경우, 졸업생에게 약간 긍정적 인 상업적 경험이있는 모든 사람들에게 기대되는 Stack Exchange를 사용한다는 점을 제외하고는 무시합니다.

인터뷰 과정은 후보자가 우리가 모집하는 작업을 수행 할 수 있음을 보여줄 수있는 기회를 제공하는 것입니다. 그들이 그것을 증명할 수 있고 합리적인 사회적 혼합처럼 보인다면 아마도 직업을 제공받을 것입니다.

만족스러운 참조가 적용되는 해당 작업이 제공된다는 점에서 Stack Exchange 계정이 참조처럼 사용되는 것을 볼 수 있었지만 여전히 이것이 공정하고 비 작업 생활에 대한 과도한 침입이 아니라고 확신하지는 못합니다.

인터뷰 프로세스의 일부로 Stack Exchange를 사용하고 공헌 할 것인지 물으면 대답은 '그렇지만'사용자 이름을 요구하면 '그에게 다시 연락해야합니다'라고 말할 것입니다. 그 이유는 다음과 같습니다. 저는 Stack Exchange에 기여한 적이 없었으며, 그 변경이 이루어질 때까지는 개인적으로 개인적인 삶의 일부입니다.


이제 프로필이 인터뷰 프로세스의 일부가 된 경우 Stack Exchange에 어떤 영향을 미치는지 고려하십시오.

사람들은 곧 인터뷰 초대를받는 데 중요한 요소가 되려면 아주 뛰어난 프로필을 가져야하며 나쁜 인터뷰를 만들지 않을 것임을 곧 알게 될 것입니다. 요컨대, 유일한 효과는 일자리를 얻지 못하게하는 것입니다.

따라서 이력서에 포함되는 사항에 대해주의를 기울이는 것처럼 Stack Exchange에서도 동일하게 수행됩니다. 의견이없고 매우 신중하게 생각한 답변 만 있으며 100 % 확실하지 않은 경우 게시하지 않습니다. 아래로 투표 한 답변을 남기시겠습니까? 아니면 질문이 잘못 되었습니까? 당연히 아니지.

스택 교환은 더 나쁠 것입니다.


1
"I have never been employed to contribute to Stack-Exchange, and until that changes, it's completely part of my private, personal life."당신은 강한 지적을합니다 (그리고 이것은 내 질문에서 레슬링했던 문제입니다). 따라서 다음과 같은 인터뷰 질문을 지나치게 방해하는 것으로 간주합니다. "SO / SE-Prog 프로필이 전문 지식과 커뮤니케이션 기술을 상당히 대표한다고 생각하십니까?"
kmote

4
나는 그 질문을 면접 전문가의 전문성에 상당히 빈약하게 반영한다고 생각한다. 내 대답은 '개인 프로필에있는 개발자 그룹 회의에서 내 프로필을 통해 내 캐릭터에 대한 좋은 아이디어를 얻을 수 있다는 것입니다. 때때로 나는 진지하고 때로는 덜 그렇고 때로는 옳고 때로는 틀리다. 그러나 무엇보다도 문제에 참여하고 논의하게되어 기쁘다.”
Michael Shaw

1
최고의 인터뷰 기술은 후보자가 제공되는 직무와 관련된 기술을 입증하고이를 바탕으로 채용 할 수있는 환경을 제공하는 것입니다. 일반적으로 업무 적으로 만족스럽지 않은 다른 기준에 따라 직원을 고용하는 회사를 발견했으며 스택 교환 프로필이이 범주에 속합니다.
Michael Shaw

4

인터뷰를하기 전에 스택 오버플로에 대한 응시자의 정보를 검색 할 것입니다. 결국 공개 정보이며, 보통 인터뷰 중에 새로운 것을 배우거나 문제가있는 문제를 해결하기 위해 어떤 종류의 자원을 사용하는지 묻습니다. 사람이 스택 오버플로를 언급하면 ​​보너스가 그들에게 포인트를 주지만 반드시 거래 차단기는 아닙니다.

내 질문의 대부분은 개방형이며 문제 해결 및 요구 사항에 대한 접근 방식을 중심으로 진행되며 온라인 문서를 읽음으로써 대답 할 수있는 질문이 아니므로 항상 배우고 탐구하는 사람들을 찾고 있습니다.

GitHub의 경우 오픈 소스 프로젝트에 참여하는지 물어보고 GitHub를 언급하면 ​​보너스도 고려합니다.


3

면접에서 스택 오버플로에 대해 묻지 않았습니다. 내가이 핸들을 10 년 이상 사용해 왔고,이 핸들을 가진 정치적으로 지향 된 포스트 중 일부는 트로츠키 주의자 부터 ayn randist 까지 다양하게 볼 수 있습니다 . 나의 정치는 그들의 선출직이 아니며 (선출직을 위해 출마하는 것 외에는 그렇지 않을 수도있다), 나는 그들에게이 손잡이를 말하지 않을 것이다. 또한이 닉네임 사용을 중단하고 다른 닉네임 사용을 늘리고 있습니다.

30 분의 인터뷰보다는 SE에 게시 된 질문과 답변을 보면 5 분 안에 응시자에 대해 더 많이 배울 수 있다고 확신합니다.

그렇습니다. 나는 오랫동안 노동력에 있었고, 나쁜 경험을했습니다. 누군가 나를 인터뷰하고 내 게시 기록을 확인하면 내가 그들에 대해 게시하는지 궁금 할 수 있습니다.

GitHub 계정 없이는 후보자 수락을 거부합니다

현재 고용주는 GPL 코드가 코드베이스에 영향을 미치는 것에 대해 겁에 질 때 오픈 소스 프로젝트에 기여하는 것을 금지 합니다.


MSO 및 메타 게시물은 IMO를 고려할 때 "탁상"입니다. 의견과 마찬가지로. 그들은 성격에 대한 아이디어를 제공하지만, 그 시점의 상황을 고려하지 않습니다. 우리 모두는 그 시절을 보냈기 때문에 우리는 그것에 대해 꽤 선했습니다. 그러나 주요 Q & A의 품질은 논리와 문제 해결 방법을 나타내는 지표입니다.

아무리 재능이 있어도 저 크나 프리 마돈나를 고용하지 않습니다. 나는 어렸을 때 좌파 이데올로기에 유혹을 받았으며, 내가 얼마나 순진했는지 믿을 수 없었습니다. 다행히도 " 완벽한 라틴 아메리카 바보에 대한 안내 "를 찾았 습니다.이 책은 저의 생명을 구했습니다.
Paulo Scardine
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.