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

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

ProductOption을 통한 FindProductOption에 관한 질문

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

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

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

histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/

안녕하세요 질문 감사드립니다!특별한 요구사항이 있지 않는 이상 말씀해주신대로 이미 데이터적으로 충분해 보여서 id는 내려가지 않아도 될 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

직무전환의 경우, 다른 직무 경험도 기입하는게 의미 있을까요?

안녕하세요 질문 감사드립니다!실제 이력서를 리뷰하는 수업 중 PM업무를 하셨던 현업 개발자분이 계십니다결국은 지금 최종으로 하고 있는 일과의 연결성이 중요할 것 같습니다 영업 보다는 비교적 기획 경력이 활용하긴 좋다고 생각됩니다만, 영업에서도 얻으신 것이 있을테고, 그것을 지금 최종 업무와 연결 시킬 수 있다면 의미가 없지는 않을 것 같습니다+ 별개의 관점으로 오래된 경력이라면, 서류 검토자에게는 내용을 떠나 오래 전 경력이기에, 크게 유의미하게 느껴지지 않을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

최근 업무에서 어필할 내용이 부족할 경우.

안녕하세요 질문 감사드립니다!아무래도 SI에서는 그런 상황이 흔하게 발생하는 것 같습니다사실 이런 상황에서 플젝들의 전체 내용에 따라 다르지만 한번 참고하셔서 이력서를 작성해보시면 좋을 것 같습니다 1. 전체 프로젝트를 묶어서 설명사실 프로젝트 마다 기간 자체를 꼭 명시하지 않아도 됩니다, 지금 회사에서 경험한 갖고있는 장점을 어필하는게 중요하기 때문에 프로젝트를 하나하나 나열하는게 아니라, 한개로 합쳐서 한 스토리로 묶어서 내는 전략이 있을 수 있을 것 같습니다여기서 키는 회사 사정에 대한 배경과 퐁당퐁당 진행하면서 유의미한 결과를 내셨냐가 포인트가 될 것 같습니다 2. 중도 투입 상황에서의 어필점 찾아보기제가 정확히 상황을 모르지만 단기로 들어가서 뭔가 의미있는 결과를 만들어냈다거나, 또는 단기로 들어갔을때의 상황이 열악하지만 해낸 부분이 있다거나, 그런 유의미한 부분을 짜내보시길 추천드립니다모쪼록 답이 되었길 바랍니다! 감사합니다!

"신규 개발"에 대한 소재는 어떤 식으로 접근하는게 좋을까요?

안녕하세요 질문 감사드립니다!대부분의 소재가 신규 서비스 개발이라면, 전략적으로 혼합해서 접근하는게 좋을 것 같습니다혼합이라함은 더 어필할게 많은 서비스를 골라서 그 서비스는 "신규로 무언가 만들었다"에 대해서 어필을 집중하고나머지 서비스들은 일반적인 주제와 마찬가지로 접근하는 게 좋을 것 같습니다저라면 1개 정도를 제외하고는 일반적인 주제로 접근할 것 같고, 1개 정도만 신규로 만든 부분을 강조해서 어필 해볼 것 같습니다 🤔사실 "신규로 무언가 만들었다" 만으로는 지원하는 회사의 상황 다르지만 무조건 강점이 되지 않을 수 있습니다, 가령 레거시 때문에 고통받는 회사라면 레거시 개선 경험이 더 궁금하고 긍적적으로 보이는 것과 같습니다모쪼록 답이 되었길 바랍니다! 감사합니다!

최근에 한 일이 대상 회사의 기술 스택에 맞지 않을 때

안녕하세요 질문 감사드립니다!상단히 고민해봐야하는 문제입니다우선 기존 Spring + Java 기반으로 프로그램은 지금 중단 된 것인지? 더 최신성이 있는지가 중요할 것 같습니다만약 Spring + Java도 최신성이 있는 상태에서 node 개발로 신규 플젝을 진행하고 있다면 Spring + Java를 먼저 쓰는 것도 괜찮을 것 같습니다그게 아니라 Spring + Java 프로젝트는 이미 종료 된 상태에서 node만 개발하고 있는 상태라면 node를 최상단에 쓰되 바로 이어서 Spring + Java 에 대한 것을 녹이는게 좋을 것 같습니다 추가로 검토할 사항은 지원하려는 회사가 타 언어 레거시 같은 것이 있다던가 (지금 배경에서는 node 레거시가 있는 회사라면 제일 좋겠죠, 드로이드님이 두개 다 할 수 있으니까요)그런 부분을 검토해서 순서를 조절 해보시는 것도 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

서류지원 시에 제출했던 포트폴리오를 면접관이 보지 않는 경우에 대해서

안녕하세요 질문 감사드립니다!당연히 경우에 따라 다릅니다만, 제 경험기반으로 유추해보면 50인 규모에 요즘 같이 지원자가 많은 상황을 가정하면 포트폴리오가 큰 영향을 주지 않았을 수도 있다고 보여집니다사실 이력서가 얼마나 잘 적혀있냐가 중요하긴했겠지만, 이력서로만 질문을 하기에도 면접 시간이 충분했다면 이력서에 어느정도 충분한 설명이 들어가 있었고, 경력 기술서까지는 넘어가지 않아도 됬을 것 같습니다다만 이건 정확상 상황을 제가 알 수 없으니 추정인 점은 참고 부탁드립니다추가로 일반적으로 포트폴리오(경력기술서)는 도움이 되는 자료로 쓰입니다, 1번 메인은 이력서가 맞습니다모쪼록 답이 되었길 바랍니다! 감사합니다!

프로젝트 내용 작성

안녕하세요 질문 감사드립니다!정확한 것은 프로젝트의 상태 및 운영 기간 등등에 따라 다를 것 같습니다만제 생각에는 일반적으로 사용 기술이나 팀구성에 대한 것은 엄청 중요한 정보라고 보여지지는 않습니다!대신 강의에서 설명한 것 처럼 충분한 서비스 설명과 함께 접속 가능한 링크정도 넣는 것은 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!