NT커널 바꾸지않을까요? 그리고 구데기같은 점 많아서 개선하고 다음 빌드 네임도 뭔가 바꿀거같습니다

질문이라는 단어 너무 야하네요

회사 사정에 따라 다를거같은데요.

1. 즉시 전력감 인력이 필요한 회사

이 케이스면 일단 서류를 볼 때 저희 팀에서 해야하는 업무와 해온 업무에 대한 핏을 볼 거 같습니다.

비슷한 도메인의 경험을 갖고 있는 분이면 더욱 선호를 할 것 같구요.

예시를 들자면 저는 이커머스 회사에서 상품리스팅 팀에 소속되어있다하면

1. 이커머스 도메인 경험자인지?

2. 리스팅 관련 업무를 진행해보았으며, 주요 트러블 슈팅을 할 수 있는 분인지?

사실 즉시인력이 필요한 회사의 경우에는 위 두 개의 핏이 안맞으면 서탈하기 쉽습니다.

위 두 가지 기준으로 서류를 검토할 것 같습니다.

2. 즉시 전력은 필요 없는 회사

이 케이스는 아마도 중견이상의 회사들이 가지고 있는 스탠스일 수도 있는데요.

이럴 경우에는 3년차가 가질 수 있는 기본기를 볼 것 같습니다. 이 경우에는 의외로 서류가 우리팀의 핏에 맞지않더라도 서류 검토 시 프로젝트 진행 어떠한 점을 고려했고, 트러블슈팅은 어떻게 해왔나를 보고 한 번 면접 봐보고 싶다하면 서류 합격 줄 것같네요.

기본기 자체는 기술블로그 링크가 있다면 해당 부분에 기고했던 내용이나 프로젝트 진행 시 이러한 부분까지 고려했을때 어느정도의 성숙도가 보이기에 나머지는 면접에서 볼 거 같습니다.

야까스 어떤가요

너무 야해요..

모쏠이세요 ㅅㅂ

엄마가 좋은 회사가면 여자 생긴다했는데 믿지마세요.

어머니는 디버깅이 안됩니다.

인텔을 안써서 몰?루

일단 취업해보고 어떤 직무인지에 따라 달라질듯요. 오히려 전산 일이 적성에 더 맞으면 이쪽테크 계속타면서 가도 좋아요

베이스가 낮다보니 다른 사람에 비해 짠 편이긴합니다 ㅋㅋ;

K8S나 AWS 쪽이 약하다면, 실제 프로젝트에서 사용했던 부분들에 대해서는 도큐먼트같은거 보고 구성보고 숙지하시는 게 좋아요.

예를 들면, AWS를 내가 잘 모르긴해도 내가 맡은 프로젝트에서 사용한 부분이 SQS, SNS같은걸 썼다면 그 서비스에 대한 개념은 딥하게 알고 있는게 좋습니다. SQS 예시를 들면, Standard나 FIFO가 있는데 내 프로젝트에는 Standard가 아니라 FIFO를 썼는데 그러한 이유? 이런게 프로젝트 당시에는 막썼더라도 어떻게든 당위성을 만들어내는게 중요합니다.

K8S도 마찬가지에요. K8S 자체는 현 회사와서 쓰고 있는데 저도 쓰는 입장에서 ISTIO나 내부구조는 잘모르고, 헬름차트만 짜는 수준이라 잘 모르는 부분 많거든요. 하지만, 이걸 기술스택으로 써먹으려면 저도 좀 딥하게 준비하긴해야겠죠.

그 외에 Spring 쪽은 뭐 기본적인 개념들? JPA쓰셨으면 당연하게 LTW(로드타임위빙), RTW(런타임위빙)와 같은 개념들과 프록시패턴들 물어볼 수 있을거같네요. OAuth도 어떤식으로 동작하는 지 세부 플로우 알아두는게 좋을거같습니다.

연협 자체는 일단 붙고 고민하시는걸 추천드려요. 그리고 여러군데 면접보시고 카운터 치는게 연협에서 우위를 설 수 있으니 한 회사만 팬다라기 보다 다양하게 지원해서 붙고나서 고민하는 카드를 여러개 만들어두시는 걸 추천드립니다.

LTW나 RTW 이런 개념은 어떻게 아신건가요?

이런 고급개념? 이런개념들은 어떻게 알고 어떻게 공부하게되는건지 궁금합니다

예를들어 실무에서 일하다보니 이런개념이 필요한거같고 그래서 공부하다보니

이런개념을 알게되어 공부하게되었다 이런 것처럼

어떻게 저런개념들을 알고 공부하게 되는지 궁금하네요

ㄴㄴ PS 잘 못합니다.

공부할 때도 백준은 효용가치를 못느껴서 릿코드만 풀었습니다.

실제 소비자가 사용하는 서비스나 플랫폼을 제작하는게 더 재밌었어서 선택한 거 같네요.

두번째 이직때 SI도 붙고, SI 회사가 연봉이 더 높은 편이긴했는데 고민하다가 서비스 회사로 간거같습니다.

깃헙은 따로 사이드할때만 쓰고, 블로그는 쓴지 7년정도 된거같은데 뜨문뜨문 씁니다.