이직 준비 방향에 대한 조언을 구하고 싶습니다.

안녕하세요 질문 감사드립니다사실 성공적인 이직을 위해서는 두가지 모두 병행해야한다고 생각합니다그치만 현실적으로 불가능하다면 1번에 무게를 두시는 게 좋을 것 같습니다외부링크는 서류 합격탈락에 엄청 큰 영향이 있지는 않습니다 부가 정보 역할입니다현재 이력을 잘 풀어내는게 더 중요할 것 같습니다!

개발과 연관없는 경력 기입 여부

안녕하세요 질문 감사드립니다이전 회사가 현재 재직 중인 곳 이전이라면 굳이 이력을 길게 적을 필요 없을 것 같습니다결국 어필할 부분이 있냐 없냐 인데 다른 직군이였어도 어필 할 부분이 있다면 적을 수 있겠지만 질문하신 배경을 유추해보면 특별히 어필할 부분이 없으셔서 고민하시는 것 같아서 만약 그렇다면 간소화 해서 적는게 나아보입니다

다양한 관점의 코드 경험을 위해 개선하지 않은 코드

안녕하세요 질문 감사드립니다!두 부분 모두 레거시 x AI에서 개선을 진행하는 부분입니다!레거시 x AI 강의는 AI를 활용하며 고민하면서 한 기준을 정하면서 기본편 코드를 개선 및 레거시 배경에서 신규 기능을 추가하는 해가는 강의입니다!관심 있으시면 레거시 x AI 강의도 수강해보시길 권장 드립니다!

이력서 구성에 대한 질문드립니다.

안녕하세요 질문 감사드립니다![질문1]어필할 수 있는 부분이 있다면 신입/경력 공고 상관 없이 당연히 적어야합니다!실제 런칭까지 진행했고 분명 얻은 경험이 있을 것 이기에 이 부분을 어필하시면 좋을 것 같습니다다만 개인or팀 프로젝트 기에 "유사실무" 라고 봐야할 것 같으며 너무 과하게 어필하는 것 보다 핵심을 잘 녹이시는 걸 권장 드립니다![질문2]우선 저는 신입 때 부터 포트폴리오를 써본 적은 없습니다!그리고 검토자 입장일 때도 포트폴리오를 중요하게 본적은 손에 꼽는 것 같습니다(사실 이력서가 좀 아쉬울 때 보는 용도로 활용했습니다)이력서와 포트폴리오 내용이 겹치는 것은 당연한 부분이라고 생각합니다포트폴리오는 더욱 상세한 내용을 기술해야하기 때문에 이력서에 확장 된 디테일한 부분이 들어가도 된다고 생각합니다!(그럼에도 온전히 제 개인 기준으로는.. 일단 이력서에 집중하시는걸 추천 드립니다! 포트폴리오는 보강 자료라고 보시는게 좋을 것 같습니다!) [질문3]이 부분은 전략적으로 선택하셔야합니다, 우선 지원하려는 회사의 유형과 상태 채용공고 등을 보시고판단하셔야하는 부분이기에 정답이 정해져있지는 않습니다또 인턴에서 기간이 짧아도 유의미한 경험이 있었는지에 따라 다를 것 같습니다전략이 여러가지가 될 것 같습니다쓰고 경험에 대한 것을 잘 풀어낸다안쓰고 면접까지 간다면 면접 때 질문이 왔을때 설명한다시간에 대한 정보를 넣지 않고, 경력 순서를 조정한다이 부분은 일반화해서 어떤 정답을 말씀드리긴 어려우니 어렵지만 실험을 해보시는 것을 권장드립니다다만 질문의 뉘앙스로 짐작했을때엔 인턴 때 유의미한 경험이 없으신 느낌 같아서 그렇다면 안쓰거나 / 순서 조정하거나 를 선택하시는 게 좋지 않을까 싶습니다!이력서 또한 계속 반복하면서 실험하고 가공해야하니 충분히 버전을 나눠서 작성해보시길 권장드립니다!모쪼록 이력서 작성 화이팅 하시길 바라며 답이 되었길 바랍니다! 감사합니다!

직무 전환후 복귀시 고민

안녕하세요 질문 감사드립니다!일단 이직을 겨냥하는 회사에 따라 전략을 다르게 가져가야 할 것 같습니다만약 이직을 희망하는 곳이 스타트업이나 규모가 작다면, 초기팀에서 해낸 A-Z까지의 역할을 강조하는게 좋을 것 같습니다, 직군에 경계 없이 제품에 헌신한 부분이 있을 것 이라고 생각합니다그외 규모가 있는 회사에 백엔드로 지원한다면 클라이언트 부분을 조금 축약하고, 답변 가능하신 백엔드 경력 부분을 강조하면 좋을 것 같습니다다만 이전 백엔드 경력이 3년 초과로 지난 상태라면 검토자 입장에서도 상당히 애매한 부분(비교적 오래 된 경력으로 보이고 3년 사이에 산업의 변화가 크기에)이 있습니다그래서 그 점을 참고하셔서 전략을 구성하시면 좋을 것 같습니다규모가 있는 스타트업이나 빅테크에서도 초기 팀 부터 A-Z로 참여한 경험은 긍정적으로 보는 경우가 많습니다(다만 무슨/어떤 제품을 만들었는지, 제품이 시장에서 결과가 좋을수록 더욱 좋습니다만.. 이건 상황마다 다르니까요ㅠㅠ)그래서 최근 이력의 기본 축은 헌신, 인내, 노력, 초기 바닥 부터 진행하면서 얻은 것들을 중심으로 작성해보시면 좋을 것 같습니다 백엔드 직군 지원시에도 초기 팀에서 프론트엔드 사이드도 겸 해보니, 이런 부분을 깨닫게 되었다던가이런 시야가 분명히 있을겁니다!모쪼록 이력서 작성 화이팅 하시길 바라며 답이 되었길 바랍니다! 감사합니다!

이력서에 들어가도 되는 요소들인 지 궁금합니다

안녕하세요 질문 감사드립니다![질문1]소프트 스킬을 어필하려면 프로젝트 설명 부분에 짤막하게 문제 상황, 해결 전략에 대해서 핵심만 적는 것이 좋을 것 같습니다서류 전형에서는 소프트 스킬에 대한 부분을 주의깊게 보기 어렵습니다, 그래서 너무 장황해지는 것은 막는게 좋다고 생각합니다대신 자기소개에 적어주신 문장을 넣는다면, 이력서의 전체적인 내용이 저 자기소개와 호응이 되는 구조면 좋을 것 같습니다, 다이어그램을 써서 어떤 문제가 나아졌는지 이런 배경이 없이 자기소개에 떨렁 문장이 있고 이력서 전체 내용에서는 쏙 빠져있다면 소개의 내용이 기억에 남기는 어려울 것 같습니다! [질문2]공고에서 기여도를 쓰라는 것은 좀 특이하네요 🤔 사실 저는 기여도가 무의미하다고 생각하긴합니다(대신 참여인력 + 기간이 더 유의미하다고 생각하긴합니다)아무튼 채용 공고에서 원한다면 당연히 적어야겠지만, 제 기준에서는 서류 검토시 크게 유의미 하지 않은 부분이 많은 것 같습니다다만 이럴 순 있습니다, 업무를 해낸 내용이 방대하고 난이도가 높은데, 혼자서 기여도가 100%라면 그 부분은 긍정적으로 "오 고생 꽤나 하셨겠네?"로 받아들일 수 있을 것 같습니다그래서 제 기준에서는 기본적으론 기여도가 크게 중요치 않다지만, 어필 포인트에 따라 전략적으로 부분적으로 기입할 수 있다고 생각합니다답변을 적다 보니 강조하고 싶은 한, 두 군데 적는 것은 좋은 전략이 될 수 있을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

경력의 포트폴리오

안녕하세요 질문 감사드립니다!일단 중요한 것이..! 제가 포트폴리오를 작성해본적이 없습니다! 그래서 제 조언은 검토자 관점에서의 의견이며 참고만 부탁 드립니다!더 중요한 것으로 포트폴리오(경력기술서)에 회사 내부의 코드 결과물이나 문서를 넣는 것은 절대 안됩니다!저는 그런 경력기술서를 보게 되면 무조건 탈락 시켰습니다먼저 검토자 입장에서 한가지 중요한 부분은 이력서가 충분하면 경력기술서를 안 보게 됩니다, 이미 합격을 줬기 때문에 추가적으로 면접 준비 시점엔 볼 수 있으나 서류 전형에서는 의미가 없기도 합니다.그럼 포트폴리오를 언제 보냐하면, 이력서에서 충분한 정보를 얻지 못했을때 또는 이력서 내용 자체가 인상깊어서 더 깊이 보고싶을 때 이런 느낌인 것 같습니다 그리고 이력서와 경력기술서는 같이 제출하지만 별개의 문서입니다, 그래서 중복/반복 내용이 있는 것은 문제가 되지 않습니다저도 경력기술서를 적어본 적은 없지만, 제가 봤던 경력기술서 중 잘 적혀있는 서류는 이력서에서 부족한 설명과 디테일을 잘 풀어낸 서류였던 것 같습니다 그래서 뭐가 좋은 포트폴리오냐?라고 한다면 이력서의 디테일을 채워주는 서류라고 생각합니다다만 위에 적은대로 이력서가 별로인데 경력기술서로 서류를 통과 할 수 있나? 라 한다면 저는 어렵다고 생각합니다사실 저는 지원자의 경력기술서도 잘 안보게되는데요, 이는 현실적으로 지원자가 많고 시간은 없고 하다보니 경력기술서가 빡빡 할 수록 집중이 힘들어지며, 이 외에도 봐야할 서류가 많기 때문에 그런 것 같습니다그래서 오히려 포트폴리오 제출이 필수라고 알고 계신다는 것이 어떤 배경인지 모르겠지만제 기준에서는 그렇지 않은 것 같습니다 🤔+굳이 경력기술서를 어필하려면 이력서에서 초벌 설명을하고 경력기술서에 풍부하게 검토자를 설득 시킬 수 있는 매력을 담을 순 있을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

글 작성에 대해서 여쭤보고 싶은게 있습니다!

안녕하세요 질문 감사드립니다!아무래도 진지하게 첨삭을 커뮤니티 질문에서 진행해드리기에는 너무 많은 개인적 요청(메일 등)이 오고 있고, 올 것 같아서 어렵긴합니다만 😭 (+ 이벤트 진행과의 괴리 문제도 있네요ㅎㅎ;)그럼에도 많은 고민이 있으실 것 이기에 약식으로 의견을 드려보도록 하겠습니다, 양해 부탁드립니다!수정 차이 자체는 느껴집니다, 일단 초안에서 첫 문단이 너무 긴 느낌이 수정 본에선 줄은 것 같습니다충분한 배경으로 보여집니다, 오히려 초안이 너무 핵심이 안 보여지는 것 같습니다전체 이력서 분량과 이 부분이 얼마나 강조를 하고자하시는 지를 몰라서 판단이 어렵지만, 조금 긴 느낌이 있습니다수정 본 기준 두번쨰 문단을 좀 더 줄일 수 있으면 좋아보입니다점수를 의견으로 드리기에는 전체 자료가 없고, 커뮤니티란에서 평가를 드리기엔 어려울 것 같습니다ㅜㅜ 양해 부탁드립니다!약식으로 답변드려서 죄송하고 너른 양해 부탁드립니다!+ 추후 다른 방식(챌린지 강의 등..)의 피드백이 가능할지 검토 중입니다..!모쪼록 이력서 작성 계속 고민해보시길 바라며 질문 감사합니다!

ProductOption을 통한 FindProductOption에 관한 질문

안녕하세요 질문 감사드립니다!이 부분은 전략에 대한 것을 수강생 분들이 느끼셨으면해서 그렇게 구성해두었는데요! 아주 좋은 질문입니다!해당 코드에 대한 배경은 일반적으로 상품의 옵션은 많지 않다 를 전제로 하고 있습니다그 전제에서는 굳이 디비를 통해서 정렬이나 필터링을 하지 않아도 크게 부하의 차이가 없고(관련 인덱스가 없다는 전제) 오히려 DB의 쿼리 수행 속도가 더 올라가게 되는 이점이 있습니다.결국 디비에서 관련 인덱스가 없다면 DB의 컴퓨팅 리소스를 쓰게 되는 것 이니까요굳이 이 배경을 더 넓게 생각해보면 일반적으로 디비는 한정 자원입니다 (스케일 업과, 아웃이 다 가능하지만 읽기 지연, 멀티 마스터 등으로 가려고하면 할 수록 복잡해지죠)반대로 어플리케이션을 확장하기가 쉽습니다, 그래서 우리 서비스의 상황을 적절히 판단해서 적절한 엔지니어링을 해야한다고 생각합니다!+ 그치만 사실 일반적으로 상품의 옵션은 많지 않다 전제라면 DB로 인덱스 없이 조회 해도 상관 없습니다ㅎㅎㅎㅎ;;; 수강생 분들이 고민 한번 해보셨으면해서 구현을 적용 해두었습니다 다만 상황이 달라져서 이미 인덱스가 있고 옵션을 날마다 생성하고 삭제하는 서비스라면 DB에게 부하를 더 주는게 맞는 전략이 될 것 입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

상수에 관련해서 질문있습니다.

안녕하세요 질문 감사드립니다!저 같은 경우는 직관성이 높은 것을 선호해 대부분 경우 상수를 코드안에 넣는 것을 선호합니다!다만 환경상의 조건 또는 로직 변경 없이 수정되어야하는 상황 등 외부에서 다르게 설정해야하는 값 일 경우 환경 변수로 추출하여 관리하는 편 인 것 같습니다!비즈니스 로직적인 부분이라면 가급적 상수로 처리하여 코드와 일체하여 보는 것을 선호하는 것 같습니다프로퍼티로 빼게 되면 어쨋든 런타임 시점에 주입이 되기 때문에 그 부분을 참고해야하니까요!모쪼록 답이 되었길 바랍니다! 감사합니다!