@SoftyChoco Blog

대기업 출신과 중소기업 출신들이 섞여있는 회사에서 근무를 해본 경험이 있습니다. 거기서 동료들과 일하며 흥미로운 점을 발견했습니다. 어디 출신이냐에 따라 눈에 띄는 '마인드셋'의 차이가 존재한다는 것이었죠. 네카라쿠배부터, 아마존, 구글 출신까지. 대기업 출신의 동료들은 새로운 아이디어나 어려운 문제에 대해 '어떻게 하면 할 수 있을까?'를 먼저 고민하는 경향이 있었습니다. 실패에 대한 두려움보다는 도전에 대해 긍정적인 편이였어요. 반면, 중소기업 환경에서 올라온 동료들과 과거의 저는 새로운 시도 앞에서 "그게 되겠어?", "해봤자 안 될 텐데"와 같은 냉소적인 반응을 먼저 보이곤 했습니다. 처음에는 그저 개개인의 차이라고 생각했지만, 각자의 이야기를 들어보고 과거를 회고해보면서 깨달았습니다. 이건 개인..

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

대부분의 사람들은 어떤 일을 진행할 때, 무슨 일이 벌어질지부터 걱정합니다.그러나, 말도 안되는 것 같지만 현업에서는 문제를 일단 '만드는' 것이 가장 중요하다는 것, 알고 계신가요?물론 여기서 '문제를 만든다'는 것은 단순히 오류나 버그를 일부러 일으키는 것을 이야기 하는게 아니라,정확히는 해결해야 할 가장 중요한 문제 하나에 집중하는 것이죠.그리고 해결해야 할 문제가 선정되면, 이후에 나타나는 다른 문제들은 그저 발생하는대로 차근차근 해결해 나가면 됩니다.'분석 마비'가 발생하는 순간자주 있을만한 예시를 들어 설명해보겠습니다.새로운 기술 스택도 익힐 겸, 아이디어가 떠올라서 사이드 프로젝트를 시작하려던 경험은 다들 한 번쯤 있으실겁니다.제 경우에는 처음에는 '간단한 기능 하나만 구현해보자'라는 생각으..

작년은 "사람"에 대해 좀 더 알아가보는 한 해였다.갑작스러운 구조조정으로 인해 팀장을 해보기도 하고, 여러 사람들에게 멘토링을 진행해보기도 했다.사람들과 많이 이야기하다보니 인생에서 어느 방향으로 가야할지 길을 찾지 못하는 사람들이 많았고, 그 때마다 "50살 쯤에는 뭘 하고 있을지 생각해보고 거기에 맞게 플랜을 세워보세요." 라는 말을 자주 했었다.물론 여전히 이 말은 맞다고 생각한다.만약, "내가 50살에 해외여행을 다니면서 일을 하고싶은 사람" 이라면?해외에서의 의사소통을 위해 언어를 배운다.위치에는 영향받지 않는 일자리를 얻거나 수익구조를 만든다. 대략적으로 이런 것들을 준비해야 할 것이고, 이런 것들을 준비해나가다 보면 목표에 도달할 수 있을테니까.우선은 당장 할 수 있는 영어 공부를 시작했다..

해당 이력서는 펌웨어 관련 개발을 하셨던 분의 개선 전 이력서입니다. 자기소개를 보면 좋은 내용들이 있긴 하지만, 이력서 내에 좋은 내용들에 대한 사실을 뒷받침해줄 근거가 부족합니다. 기술스택은 무난하지만, 펌웨어 개발자에서 갑자기 백엔드 개발자로 전향하게 된 이유나, 프로젝트에 적힌 내용이 기술스택밖에 없다는 점. 또한 이력서 자체에 본인의 색깔이 확연하게 드러나지 않아서 낮은 점수를 받을법한 이력서라고 생각됩니다. 펌웨어 개발자를 하다가 백엔드 개발자를 하게 된 이유가 공부할 수 있는 범위와 자료의 한계, 즉 본인이 더 많이 배울 수 있는 환경을 찾기 위함을 충분히 어필하고, 펌웨어 개발자로써 지냈던 경력들을 활용하여 본인의 경험을 살려내면, 많은 장점이 나올 것이라고 생각됩니다. 그런 장점들을 자기..