안녕하세요 질문 감사드립니다! 먼저 고민하시는 부분은 면접관들이 다르게 생각합니다! “잘못된 방식인 것을 알면서도 바로잡으려는 노력이 부족했던 것 아닌가?” , “주도적으로 개선하려고 하지 않은 것 아닌가?” 라고 받아들일 수도 있지 않을까 하는 점입니다. 일반적으로 이렇게 받아들이지 않습니다! 다만 말씀하신 것 처럼 혼자 방향을 바꾸기 어려운 상황 에 대한 충분한 배경, 지금은 더 나은 방법이 있었다는 것을 알고 있다 에 대한 설명이 더욱 중요합니다 면접관 들도 그렇고 수 많은 개발자들이 더 나은 방법 을 알고 있지만 우리는 현실속에서 일을 하고 있기 때문에 언제나 최고의 선택을 할 수는 없습니다 전 이게 진리라고 생각하고 면접관 정도 되는 경험을 갖고 있는 사람이 이걸 이해 못하고 있다면 그런 사람이 면접관인 곳은 가면 실망한 할 것이라고 생각합니다. 그러면 뭐가 중요하냐, 결국 이력서에 어필이 될만한 부분은 모두 적고 면접에서 충분히 위에 말씀드린 부분을 설명하고 논리가 있고, 그리고 지금 하면 어떻게 할 것인지, 왜 그게 더 나은 선택인지 등등을 설명만 잘 하면 아무 문제 없다고 생각합니다. 그래서 결론은 절대 이력서에 제외 하지마시고 잘 준비하셔서 면접에서 어필 하시기 바랍니다! 저도 보통 그러한 경험의 지원자 분들이 있으면 단골 질문으로 "만약 그런 배경이나 환경이 다 받쳐줄 때 할 수 있다면 어떤게 최고의 방법이라고 생각하세요?" 같은 것을 물어봅니다 이러한 질문을 답변 잘 할 수 있다면 아무 문제 없다고 생각합니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 주희님 질문 감사드립니다! [질문1] 현재 주희님 상황이라면 전 직량 경력을 충분히 어필하는게 좋을 것 같습니다! 특히 희망하시는 회사가 금융권이라고 하시니, 핀테크 경험을 어필하는게 중요할 것 같습니다 이 경우는 직전 직장(심지어 얼마 안되었으므로) 경력을 최대한 잘 풀어내서 어필하시는 것을 권장드립니다! [질문2] 이 부분은 지원하시는 회사의 현재 채용 기조 타이밍, 원하는 인재 형태에 따라 천차만별이긴합니다 다만 현재 회사의 경력이 짧은 상태에서 이직을 한다하면 말씀해주신대로 충분히 이직 사유를 설명 할 수 있어야합니다 그런데 이력서에 이직 사유를 적기에는 참 애매합니다, 보통은 면접때 조심스럽게 체크를 한다던가 하곤 합니다 그래서 일반적으로 이력서에 이직 동기를 적는 것 보다는 이력서로는 경력을 잘 나타내주시고 그 다음 전형에서 충분히 설득 하는게 필요한 것 같습니다 결국 회사가 원하는 인재와 핏이 맞는 상황이라면 현재 회사 경력이 짧더라도 타당한 이직 동기가 있어서 설득이 가능하다면 면접을 잘 봤다는 전제하에 납득이 될 수 있는 부분이라고 생각합니다 사실 당장 적어주신 것을 보더라도 핀테크에 계시다가 타 도메인에 가셨다가 다시 금융권을 가시려는게 궁금해지기는 하는 것 같습니다, 이게 긍정/부정의 영역은 아니고 궁금증을 만들어내는 것 같습니다 아무튼 이력서를 잘 준비해보시면 돌파구가 있을 것 이라고 생각합니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! 흠… 지원동기라.. 케이스마다 꽤나 어려운 항목입니다, 지원동기에 대해 뻔하지 않고 어필이 되면서 꼭 적어야할 내용이 있다면 유효 할 수 있을 것 같습니다만… 저 같은 경우는 지원동기의 경우는 상황에 따라 궁금해지면 면접에서 자주 여쭤보는 편입니다 서류를 볼때는 지원 동기 자체는 중요하게 안 보는 편인 것 같습니다 (이건 서류 검토자별 개인차가 있을 수 있습니다, 다만 지원 동기 때문에 서류의 합/불이 결정 되지 않는 것은 99% 팩트인 것 같습니다) 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! 전략이 여러가지가 있을 것 같습니다만 당장 생각나는 것에 대해서 의견드립니다! 우선 첫째 로 개인 프로젝트의 수준을 최대한 프로덕션 수준 으로 끌어올려서 서비스를 하나 띄워놓는 것 까지 하시면 어떨까 싶습니다 실제 사용자 까지 모집 하여 실제 유사 서비스의 경계에 있다고 설득하면 더 좋다고 생각합니다 (백엔드 영역은 없거나 최소화하여 정적페이지 수준으로 되어도 된다 생각합니다) 두번째 로는 기존 JSP 유지보수 업무에서 이력서에 어필 할 것이 없는지 재고가 필요해보입니다 정말정말 단순 유지보수였다면 쓸게 없을 수 있지만, 분명히 기존 레거시 때문에 고생해서 처리한 영역이라던가, 프론트엔드 사이드 측면으로 고민해서 해결한 부분이 있을 겁니다, 그 부분을 최대한 이력서에 잘 녹혀내는 수 밖에 없다고 생각합니다 말씀하신대로 개인프로젝트를 부흥 시켜서 어필 포인트가 강하다면 +가 많이 되지만, 기본적으로 유사 실무 고 그게 에너지를 쏟아야하고 여러 여건상 마냥 쉽지는 않기 때문에, 기본은 기존 경력 에 대한 것으로 평가 된다고 생각합니다 그렇기에 기존 경력에서 최대한 쥐어짜는게 핵심이라고 보긴합니다 세번째 로는 리액트를 사용하는 회사에서도 결국 근본적으로 면접까지 간다 했을때 물어보는 것의 근본은 프론트엔드에 대한 이해도 및 역량으로 시작한다고 생각합니다, 단순히 리액트 자체로만 보지는 않는다고 합니다. (이건 최근에도 지인 프론트엔드 면접관에게 들은 것 입니다, 제가 백엔드 베이스라 100% 직접 면접을 본 것은 아니라서 정확하지 않을 수 있습니다) 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! [질문1] 100%로 의미가 있다고 보긴 어렵지만 0%의 의미가 있다고 생각하진 않습니다 (이 부분은 사실 회사가 채용하는 시점, 수준 등등에 따라 너무 변수가 큽니다) 그러므로 대체 할 수 있는 방법이 없다면 준비하는게 효과적이라고 생각하는 편입니다. 그치만 결국 얼마나 퀄리티가 있냐에 따라 효과가 천차만별이라고 생각합니다 단순히 그냥 '만들어져있다'만으로는 부족하다고 생각합니다 결국 개인프로젝트의 경우는 최대한으로 효과를 보려고해도 기본 시선은 '유사실무'로 바라 볼 수 밖에 없습니다 이 점을 참고하여 고민해보시길 바랍니다! [질문2] 제 기준에서는 기본은 이력서로 1차적인 설명을 하고 서비스 확인이 가능한 주소와 깃헙 정도가 중요하다고 생각합니다 그 다음에 더 어필을 하는데 노력을 하고자한다면 포트폴리오를 작성하는 것도 의미가 아예 없다고 생각하지는 않습니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! 이건 상황마다 다르긴합니다 만, 제 경우에는 기본적으로 자격요건이 맞은 분들만 지원했을거라고 가정하고 서류를 보기 때문에 스킬셋을 1순위로 보지 않습니다 상황이 다르다고 말씀드린 것은 채용하는 회사마다 언어+프레임워크 스택이 맞는 것을 꼼꼼히 보려는 회사가 있고, 언어와 프레임워크는 수단이기에 웹 기반의 1개의 언어와 1개의 프레임워크 를 기준으로 보는 곳이 있어서 다른 것 같습니다 방금 간단히 회사들 채용공고를 훑어봤는데 적어주신 것 처럼 스택을 자격 요건 에 명시한 곳이 절반 정도 되는 것 같네요 당연히 서류 검토자마다 생각이 다를 것 같긴한데, 제 경험상으로 대부분 검토자들은 스택을 먼저 찾는 것 보다 경험을 먼저 보는 걸 우선시 했던 것 같습니다 (그래서 막상 서류 합격 후 면접 때 스택이 틀리단걸 안 적도 있었습니다) 또 한가지 추가적인 부분은 회사가 좀 규모가 있다면 채용팀에서 이력서를 1차로 걸러줍니다 그래서 서류 검토자가 보는 서류에서는 그런 피로감이 없는 부분도 있습니다 어쨋든 그래서 본론으로 돌아와보면, 기술 스택에 대해 문제해결 및 프로젝트로 자연스럽게 녹이기 을 한다고 해서 검토자들이 피로감을 느끼지는 않는다고 생각합니다! 다만 지원하는 회사가 자격요건 에 기술스택 에 대한 기준을 명확히 적은 상황에서 갖고 계신 경력의 프로젝트 내용 이 기술스택을 언급하거나 녹이는게 모호하다면 명시적으로 적어서 지원하는 전략을 쓰시면 좋을 것 같다고 생각합니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 도현님 질문 감사드립니다! 우선 건강이 회복 되셨다니 정말로 다행입니다! 제가 감히 과정을 모르지만 대단히 고생 많으셨습니다!! 개인 프로젝트로 실 사용자가 있는 서비스를 운영하고 있는 것은 아주 좋게 보이는 부분이라고 생각합니다 또한 스토리를 덧대면 건강 회복 과정에서도 꾸준히 그 서비스를 운영 했다는 것은 도현님이 어떤 사람인지 보여줄 수 있는 부분이라고 생각합니다 제 생각에는 단순 개인프로젝트 처럼 아래에 두기에는 너무 아깝다고 생각합니다 그래서 상단에 배치하는게 맞다고 생각하구요, 그에 대해서 충분히 이력서에서 보여주고 면접에서도 배경 설명이 된다면, 전혀 나쁘게 보지 않을 것이라고 생각합니다 결국은 서류 검토자, 면접관을 설득하는 과정이기에 그 기준에서만 부합하면 나쁘게 볼 이유는 없다고 생각합니다 해당 내용을 이력서에 충분히 설명하시면 좋을 것 같습니다! 앞으로도 건강 유의하시길 바라며 취준도 화이팅 하시길 바랍니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! [질문1] 맞습니다, 그래서 보통은 lmit(한번에 조회 하는 수) 가 달라지면 첫 페이지부터 다시 조회하는 식으로 하거나 현재 페이지 기준으로 재 계산하여 조회하는 처리가 필요합니다 [질문2] 일반적인 경우에서는 offset, limit 이 자연스럽습니다, 다만 성능이나 변경이 너무 빠르거나 조회 정합성이 중요하다면 커서 방식을 검토해봐야합니다 [질문3] 어느 정도 범용성을 제공해야하는 API 관점에서는 limit을 고정시키는게 좋지 않다고 생각합니다 클라이언트 스펙이 바뀔때 서버가 바뀌는 구조가 되니까요! [질문4] 이 부분은 99% 요구사항에 따라 결정 됩니다, 다만 대부분 규모의 서비스에서는 offset / limit 으로 처리하면 되었던 것 같고, 관리자 페이지나 어드민 같은 경우는 page/size 방식이 적합한 경우가 많은 것 같습니다 두 가지에서 선택의 기준이 기술적 관점 보다는 요구사항을 맞추는 관점이 크다고 보며, 이 조회 방식 자체는 비즈니스 로직 보다는 노출 영역에 가까운 스펙이라고 생각하는 편입니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! 첫째로 어느 정도의 상황과 제약에 대해서 언급하는 것은 괜찮다고 생각합니다 다만 너무 다 써서 내용이 과해지지 않는 것을 조심해야할 것 같고, 서류 검토자에게 상황이 전달 될 정도의 정보만 넣으면 될 것 같습니다 고객사에 요청 자체가 why가 되는 것은 케이스마다 다르지만 대부분 어려울 수 있습니다 단순히 고객사가 요청을 해서 그대로 했다 이런 뉘앙스로 빠질 수 있기 때문에 한번 작성해보시고 검토자 입장에서 충분히 아 그럴만한 이유가 있었네 가 나올지 고민 해보시면 좋을 것 같습니다 그리고 결과적으로 그러한 배경과 상황에서 유의미한 결과와 임팩트를 만들 었다면 그 점을 강조하면 더욱 좋을 것 같습니다 두번째로 레거시 개선은 지원하는/팀 마다 받아들이는 관점이 다르지만 대부분 회사가 레거시가 없을 수 없기 때문에 부정적으로 보지는 않는 것 같습니다 그래서 적어주신 예시는 유의미한 어필이 가능한 부분이라고 생각합니다 자체적으로 모니터링과 운영에서 발견했다는 점은 단순 개발만 하는게 아니라 운영에 대한 경험이 있다는 것을 설명하는 것 이기에 잘 풀어내면 검토자들의 호기심을 유발 할 수 있을 것 입니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
안녕하세요 질문 감사드립니다! 저는 개인적으로 usecase를 빠르게 사용하는 것을 선호하지 않습니다! 대부분의 경우 과한 경우가 많다고 생각하고 각 개념 서비스 단위가 성숙해진다면 그것을 조합할 때 usecase를 쓸까에 대한 고민을 하는 편입니다 추가적으로 이것도 많이 개인적이지만 usecase라는 네이밍 자체를 선호하진 않습니다! 이유는 너무 특정 아키텍처에 기인하여 맹목적이고 관습적인 네이밍이라고 생각하기 때문입니다 그렇지만 모든 경우가 그렇지는 않을 것 이기 때문에 적절히 잘 판단해서 쓰면 된다고 생각합니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
