요즘 채용시장에서 드는 감정이 있다. 내가 실력이나 경험이 부족해서 탈락하는 게 아니라, 채용이라는 구조 자체가 비논리적이고 일방적이기 때문에 거부감이 든다는 점이다. 진짜 실력자는 채용 전형 하나만 봐도 그 회사가 어떤 마인드를 갖고 있는지 파악한다. 그리고 그런 사람일수록 조용히 사라진다. 아무 말 없이. 이 글은 내가 직접 겪은 “절대 이렇게 채용하지 말아야 할 사례”들을 모아 반면교사로 남기는 기록이다. 단순한 하소연이 아니라, 더 나은 채용 문화를 위한 제안이다. 내가 내가 언젠간 창업을 하거나, 임원진 또는 팀 리더가 되어 면접관이 된다면, 적어도 아래는 하지 않을 것이다. 단, 이 글에서 말하는 대상은 묻지 마 지원, 직무 적합성에 어긋난 지원자를 제외하고, 성의 있게 서류를 작성을 한 인재..

이 글은 사이드프로젝트를 주제로 다루고 있지만,사실 실전 프로젝트에서도 똑같이 적용됩니다.이름만 사이드일 뿐, 구조와 책임이 없다면어떤 프로젝트든 실패로 이어지는 건 순식간입니다. 사이드프로젝트는 이제 단순한 개인 실험을 넘어,사업 아이디어 검증, 초기 시장 반응 테스트, 비용 절감형 개발 전략으로까지 활용되고 있습니다. 특히 요즘은 외주를 맡기기보다, 내부 인력이나 프리랜서 개발자와 함께기획과 와이어프레임 정도만 갖춘 상태에서 직접 사이드프로젝트를 실행하는예비사업자, 기획자, 소규모 업체들이 많습니다. 그런데 실제 현장에서 보면, 기획 없이 바로 개발부터 들어가거나,도메인 흐름·차트 플로우·역할 정의 같은 핵심 설계가 빠진 상태로 시작하는 경우도 적지 않습니다.심지어 사이드프로젝트를 핑계 삼아, 기획조..

이것은 내가 잡플래닛의 대한 리뷰를 보고 회사를 평가를 했을 때의 결과들의 대해 작성해보고자 한다. 사실 잡플래닛도 100% 신뢰성이 있다고는 말할 수 없다. 나는 사실 좋은 글은 잘 보진 않고 평가가 나쁜 글 위주로 보고 판단하는 편이다. 물론 나쁜 글이라고 해도 100% 믿지 않으며 면접은 보고 잡플래닛 나쁜 리뷰와 면접 결과와 일치성이 보인다면 거르는 편이고 이전에 나빴지만 현재는 나아진 것으로 보이는 것이라면 수긍이라도 해볼 것이다. 면접을 보고나서 잡플래닛 리뷰가 쓴 것 감정적으로 작성했는지, 침착하게 있는 사실 그대로 적은 경우도 있는지 어느정도 알 수 있는 수단으로 생각하기 때문에 면접 때 지원자에게 대하는 태도로 보고 재평가 할지 입사하지 말아야 하는 업체인지 판단하고 최종 합격 시 역시 ..

이번 포스팅에서는 묻지 마 지원의 대해 다뤄보고자 한다. 대체 묻지 마 지원은 무엇인가? 회사 입장에서는 지원자가 아무런 생각 없이 막 지원한 티가 느껴지는 경우를 말하는 것이다. 묻지 마 지원을 판단하는 기준은 무엇일까? 1. 이력서 상 지원하고자 하는 직무가 전혀 맞지 않는 경우. 2. 단체 문자처럼 이력서를 회사에 보내는 경우 3. 회사명 기입이 잘 못 됐을 경우. 4. 이력서 내용이 너무 성의 없을 경우. 이런 대표적인 리스트로 뽑았다. 여기서 경력 미달로 인한 묻지 마 지원은 넣지 않았다. 경력이 부족해도 이에 준하는 역량을 보유할 수도 있기 때문이다. 자세한 것은 N년차, 혹은 이에 준하는 역량을 뜻하는 문장이란? 포스팅 참조하길 바란다. 따라서 묻지 마 지원 대상 서류가 되지 않으려면 어떻게..

이번 포스팅에서는 본인이 쌓은 연차보다 높은 채용공고가 올라와져 있을 때 지원 자격이 되는지의 대해 한번 다뤄보고자 한다. 지난 포스팅에서 늘 강조해 왔던 내용 중 하나인 개발은 경력이 아닌 실력이 중요하다는 말을 계속해 왔다. 이 말인즉슨 저연차가 퍼포먼스를 잘 내는 개발자인 반면 고연차가 퍼포먼스를 내지 못하는 사람도 존재하기 마련이다. 따라서 본인이 1-2년 차 경력을 보유하고 있다고 한다면 4-5년 차를 뽑는 공고에도 충분히 지원할 수 있고 서류 통과 후 최종적으로 합류가 가능할 수도 있다는 점의 대해 아주 가능성이 없지 않다. 내가 생각하는 경력이라고 한다면 프로젝트 경험도가 많고 개발의 대한 배경지식이 깊고 넓음을 측정하는 부분에 불과하며 경력을 쌓는 동안 본인이 무슨 일을 했는지 혹은 개발에..

이 것은 나의 기준으로 작성한 것이며 개발자라면 코드를 짤 때 올바른 습관을 가지면서 짜는 것이 가장 중요하다고 생각한다. 같은 결과 값이 나올 때 누가 짜느냐의 따라 다르지만 코딩 내용만 보고도 이 사람은 개발을 해본 사람이다. 이 사람은 개발을 해본 사람이 아니다. 이 사람은 개발 숙련도가 높을 것 같다. 등 판별할 수 있는 근거가 있기 마련이다. 이전 포스팅에서 클린 코드의 법칙의 대해 업로드 해 보았다. 보통 정보처리기사 문제 범위 중 하나이며 면접 시 소프트스킬 검증 할 때 클린 코드가 무엇이며 클린 코드를 구성할 때 사용 원칙 등 한 번쯤 질문받았을 것이며 코드 리뷰 역시 잘 짠 코드인지 왜 그렇게 짰는지도 검증 작업도 진행될 것이다. 필자는 개발을 진행할 때에는 쓸 때 없이 긴 코드를 사용하..