@SoftyChoco Blog

이력서의 상세 내용을 적을 때 개발처럼 생각하면 좋다.개발자가 흔히 반복되는 문제를 해결하기 위해 디자인 패턴을 사용하는 것처럼, 이력서에도 패턴이 존재한다.흔히 이야기하는 STAR 기법은 "어려웠던 일을 있는 그대로 전달하기 위한" 목적으로써 사용하는데, 해당 기법은 "문제 수준이 높은 과제"에서만 잘 먹힌다는 점이다.특히나 주니어 같은 경우에는 문제의 수준이 높은 경우가 많이 발생하지 않고, 실패가 많을 수도 있다. 그럼 어떻게 고민해보면 좋을까?디자인 패턴에 대해서도 많은 개발자들이 하는 말이 "디자인 패턴에 코드를 맞추지 말고, 코드를 효율적으로 짜다보면 자연스럽게 디자인 패턴과 맞춰진다" 라고들 한다. 마찬가지로 이력서도 "효율적"으로 작성하면 된다.어떤 이력서가 효율적일까? 이력서의 목적은 "..

저는 멘토링도 익명으로 진행합니다. 흔히 멘토의 배경만 보고 '저 사람 말이 맞을꺼야' 라는 생각을 하는 분들이 꽤나 많기 때문에, 그런 '편한 사고'를 막기 위해, 제가 적는 내용을 의심하고, 직접 생각하게끔 하기 위해 그렇게 진행합니다.그러다보니, 제 멘토링은 일반적인 멘토링보다 시간이 오래걸릴 수 밖에 없습니다. 멘티의 경험담을 듣고, 어떤 부분이 좋은지/나쁜지를 고민하고, 왜 제가 그렇게 생각하는지를 논리적으로 설명하는데, 이 과정에서 '멘티가 이해할 때까지' 설명해야하기 때문이죠.그런데 이 과정에서, 간혹 유난히 시간이 많이 걸리는 케이스들이 있습니다. 이미 마음에 철벽을 많이 쳐버리신 분들이에요.'하지만 다른 사람은 이렇게 생각할꺼야' 라는 자기 비판을 가지고 있어서, 제가 이야기하는 내용이 ..

실패한 경험을 숨기지 말자. 흔히 이력서에 "자신의 성과"만을 입력하고자 하는 사람들이 있다. 물론 충분히 연차가 있고, 그만한 실력이 있다면 그래도 괜찮다. 이미 여러 문제해결을 통해 실패를 했을 것이고, 그게 쌓였을 것이라고 보기 때문이다. 하지만, 저연차일수록 실패한 경험을 숨기는게 마냥 좋은게 아니다. 주로 저연차에게 원하는 것은 "성장속도"인데, 여기서 말하는 성장은 하드스킬의 영역만이 아니다. 실패에서도 배울 수 있는 사람인지, 실패해도 다시 일어날 수 있는 사람인지도 중요하다. 그렇다면 이런 실패한 사례를 어떻게 어필할 수 있을까? 과거로 돌아가 과거를 바꿀 수 없기 때문에, "만약 내가 다시 그 상황을 겪는다면"으로 생각하면 된다. 그리고 우리는 그것을 회고라고 부른다. 블로그에 회고를 해..

개발자라면 많은 트래픽을 받아보고 싶은 분들이 많을텐데요,정작 신입 이력서에서 요구하는 대규모 트래픽 경험을 도대체 어디서 얻을 수 있는지는 알기가 어렵습니다.기업에서 신입에게 어느정도의 선을 요구할지, 좀 더 명확하게 차근차근 알려드리겠습니다.당연하게도, 가장 이상적인건 직접 경험하는 것당연히 대규모 트래픽을 직접 경험해보았다면 가장 이상적이겠지만,이 글을 보시는 분들은 이런 대답을 원한게 아닐 것이라는 것쯤은 알고있습니다.그렇다면, 왜 이게 가장 이상적일지 생각해보신적이 있을까요?깊게 생각해보지는 않고 "단순히 동일한 경험이니까." 정도로 치부할게 아니라,대규모 트래픽을 경험해봤다는 것의 실제 의미는 시스템 운영 중에 트래픽으로 인한 부하가 될만한 지점(병목지점)을 인지하고 개선하는 것입니다.당연히 ..

여러군데에 이력서를 넣고, 합격률을 확인하는건 대부분 의미가 없습니다. 흔히 개발자적인 생각에서 이력서를 고쳐가며, 이전 이력서는 합격률이 8%, 변경 이후 이력서는 합격률이 15%...와 같은 형태로 체크를 하시는 분이 있습니다. 하지만, 이게 너무나도 의미가 없다는 것을 알고 계신가요? 가장 큰 오류는 '회사의 성격', '채용 담당자'가 모두 다르다는데 있습니다. 어느 회사는 내 이력서에서 내 성실한 태도를 마음에 들어할 수도 있고, 어느 회사는 내 이력서에서 협업 능력을 마음에 들어할 수 있으며, 또 다른 회사는 내 이력서를 마음에 들어하지 않을 수 있다는 것이죠. 말하자면, 이력서와 회사 간의 합격률은 매번 다른 변수에서 실행되는 테스트 케이스입니다. 이런 테스트 케이스가 유효할리 없겠죠? 그렇다..

아직은 '바이브 코딩은 완성되지 않았다'라는 말들을 하지만, 저는 이미 충분한 역할을 하고 있다고 생각합니다. 직접 활용해본 결과, 앞으로의 프로덕트 팀의 구조는 이렇게 변하지 않을까? 라는 생각에 글을 한번 적어봅니다.현재의 바이브 코딩의 장점은 "빠른 생산성"이지만, 그에 대한 문제점으로는 "믿을 수 없는 안정성"에 있습니다. AI가 생성하는 결과물이 우리의 기대를 벗어나거나, 눈에 보이지 않는 오류를 포함하기 때문인데요. 이러한 문제는 단순히 더 좋은 AI를 기다릴 것이 아니라, 이에 맞춰 조직의 구조를 새롭게 변화시켜야 할 때라고 생각합니다.생산성과 안정성의 딜레마AI는 우리에게 명확한 기회와 위기를 동시에 제시했습니다.기회는 바로 '압도적인 생산성'입니다.아이디어 구상부터 실제 코드 생성까지의 ..

해당 이력서의 경우에는 취업 준비생의 이력서입니다. 기술스택은 모두 부트캠프에서 3달간 배운 것 밖에 없어서 다른 사람들의 이력서에 비해 부족한 부분이 너무 많았어요. 대신 노가다나 승선을 1년씩 진행했던 경험을 살려 이력서로 녹여내었습니다. 해당 이력서로 변경 전 500개의 기업에서 불합격 통보를 받았지만, 변경 후 일주일도 안되어 "서류 - 과제 - 면접"에서 과제 전형을 패스하고 바로 면접으로 진행되었습니다. 자신만의 경험이 없는 잘못된 이력서: https://softychoco.tistory.com/14

회사에 겨우 입사했는데 업무 배정이 안되거나 일을 주지 않고, 선임이 없다면 어떠실 것 같나요? 경력이 있으시다면 어느정도 알아서 할 수 있을지 모르겠지만, 신입이라면 이것 만큼 스트레스 받는 일이 없을 것 같습니다. 가만히 있는데 물경력이 되어가는 느낌이고, 다른데 이직도 못할 것 같고... 이번 사연자 분은 이런 문제를 겪고 계신 분입니다. 이 분의 경우 전임자가 망쳐놓은 프로젝트를 외주를 통해 개발하고 있고, 정작 본인은 제대로 된 업무가 없는 상태이시더라구요. 저는 이런 경우라면 남는 시간동안 공부를 하면서 이직 준비를 할 것 같습니다. 이런 문제는 다른 회사에서도 퇴직 사유로 이해해줄만한 부분이기 때문에 최대한 공부를 해서 이직 시에 "회사에서 업무를 제대로 부여받지 못해서 이직을 했다"라고 이..

개인적인 이유나, 이력을 위해 사이드 프로젝트를 시작해보셨던 적이 있나요?"이건 정말 잘 만들어봐야지!"라는 생각에 의욕이 넘치게 시작했지만, 어느 순간 흥미가 떨어지고 진행이 멈춰버린 경험이 있는 분들이 많으실겁니다.왜 이런 일이 생기는지 생각해보셨나요?오늘은 그 이유를 이야기해드리려고 합니다.마감 기한이 없어서학교의 과제나, 회사의 프로젝트는 마감 기한이 존재합니다.그 기한 안에 결과물을 내야하니, 어떻게든 시간에 맞춰 "현재 내가 아는 만큼의 지식"으로 해결하려고 노력합니다.하지만 사이드 프로젝트는 중요도가 상대적으로 떨어지다보니, 마감 기한이 없거나 너무 느슨한 경우가 많습니다.이런 경우에는 우선순위에 대한 고민을 하지 않고, 우선순위가 낮은 것에도 오랜 시간을 쏟는 경우가 많습니다.마감 기한을 ..

이런 생각을 해보자. 어제까지는 막노동을 하던 사람이, 오늘 갑자기 기막힌 사업을 구상해서 성공할 가능성은 얼마나 될까? 아마 대부분은 불가능에 가깝다고 여길 것이다.왜 그럴까?단지 그 사람이 막노동을 하는 사람이라서가 아니다. 우리는 생략된 배경까지도 생각하여 판단한다. 막노동을 하는 사람은 먹고살기 힘들 것이고, 하루하루 일하는게 삶일테니까.물론, 100% 모든 사람이 그런 것은 아니다. 그럼 그들간의 차이는 어디에서 발생하는걸까? 우물 안 개구리이러한 상황은 분명 막노동을 하는 사람만의 이야기가 아니다.대부분의 사람들은 자신이 맡은 '역할'의 관점을 잘 벗어나지 못한다. 마치 우물 안 개구리처럼, 자신이 보고있는 하늘이 전부라 믿는 것처럼. 그 역할이 주는 안정감과 익숙함에 안주하면서, 다른 세상이..