현재버전

[징징글 주의] 이직 준비 해야하는데 너무 하기가 싫습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술이 있다는걸 인지하는게 중요하다는 이야기입니다.
간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

사실 cs, 알고리즘, 다양한 기술스택, 디버깅, 구현 능력 전부 갖춘 사람이 짱이긴 하죠...
근데 이렇게 따져보면 문서화 능력, 말빨(?) 등 안 중요한게 없는데 선택적으로 볼거면 디버깅 등을 우선적으로 보면 좋겠다..라는 푸념이었습니다.

댓글들 읽어보면서 이런 글을 쓴게 너무 창피했네요..! 열심히 해서 내년 초에 꼭,, 만족스러운 이직 성공 하겠습니다. 화이팅!!

수정이력

2022-09-24 13:48:13 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술이 있다는걸 인지하는게 중요하다는 이야기입니다.
일반적인 기술들이 공식문서보면 금방 따라할 수 있다는 말에 전적으로 동의하지만, 관련된 다양한 기술 스택이 있다는걸 먼저 인지해야 해당 기술 스택을 선택하고, 구현을 하겠죠!

간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

사실 cs, 알고리즘, 다양한 기술스택, 디버깅, 구현 능력 전부 갖춘 사람이 짱이긴 하죠...
근데 이렇게 따져보면 문서화 능력, 말빨(?) 등 안 중요한게 없는데 선택적으로 볼거면 디버깅 등을 우선적으로 보면 좋겠다..라는 푸념이었습니다.(cs와 알고리즘 공부가 싫어서 핑계를 대는게...... 아닐거에요!!!)

2022-09-24 13:38:53 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술이 있다는걸 인지하는게 중요하다는 이야기입니다.
일반적인 기술들이 공식문서보면 금방 따라할 수 있다는 말에 전적으로 동의하지만, 관련된 다양한 기술 스택이 있다는걸 먼저 인지해야 해당 기술 스택을 선택하고, 구현을 하겠죠!

간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

사실 cs, 알고리즘, 다양한 기술스택, 디버깅, 구현 능력 전부 갖춘 사람이 짱이긴 하죠...
근데 이렇게 따져보면 문서화 능력, 말빨(?) 등 안 중요한게 없는데 선택적으로 볼거면 디버깅을 우선적으로 봐야하지 않을까요??

2022-09-24 13:35:35 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술이 있다는걸 인지하는게 중요하다는 이야기입니다.
일반적인 기술들이 공식문서보면 금방 따라할 수 있다는 말에 전적으로 동의하지만, 관련된 다양한 기술 스택이 있다는걸 먼저 인지해야 해당 기술 스택을 선택하고, 구현을 하겠죠!

간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

사실 cs, 알고리즘, 다양한 기술스택, 디버깅, 구현 능력 전부 갖춘 사람이 짱이긴 하죠...
근데 이렇게 따져보면 개발과 전혀 관련 없어보이는 문서화 능력, 말빨(?) 등 안 중요한게 없는데 선택적으로 볼거면 디버깅을 우선적으로 봐야하지 않을까요??

2022-09-24 13:34:29 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술이 있다는걸 인지하는게 중요하다는 이야기입니다.
일반적인 기술들이 공식문서보면 금방 따라할 수 있다는 말에 전적으로 동의하지만, 관련된 다양한 기술 스택이 있다는걸 먼저 인지해야 해당 기술 스택을 선택하고, 구현을 하겠죠!

간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

2022-09-24 13:30:01 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

추가)
위에서 다양한 기술 스택이 중요하다는건 해당 기술을 아는게 중요하다는 이야기입니다.
일반적인 기술들이 공식문서보면 금방 따라할 수 있다는 말에 전적으로 동의하지만, 관련된 다양한 기술 스택이 있다는걸 먼저 인지해야 해당 기술 스택을 선택하고, 구현을 하겠죠!

간단하게 'cs 기초는 부족하지만 다양한 기술 스택에 관심이 있는 사람 >> cs 기초는 튼튼하지만 새로운 기술 스택에 관심 없는 사람'

2022-09-24 13:29:34 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...

아, 디자인패턴도 cs의 범주에 들어가는지는 모르겠는데, 디자인패턴은 예외입니다.


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

2022-09-21 10:33:43 에 아래 내용에서 변경되었습니다.

트렌드를 따라가기도 바쁘고 배워야 하는 기술들도 산더미처럼 쌓여있고, 하나 하나 적용해볼 수가 없다는 것이 너무 슬픕니다.
RSocket gRPC Webflux fargate k8s 등등... 셀 수 없이 많네요....
사이드 프로젝트를 좋아해서 하나 하나 적용해보고는 있지만, 이것도 한계가 있네요.

현재 목표는 빡세게 이직 준비를 시작해서 내년 초에 이직하는 것이 목표입니다.

현재 처우가 그렇게 좋지 않기에......좋은 곳으로 가고 싶어요. 그런데 이직 준비를 하려니, 실무에서 필요한건 알고리즘이 아닌 디버깅인데? 실무에서 필요한건 cs가 아니라 문제가 생겼을때 폭넓은 선택을 하기 위한 많은 기술들인데? 이런 생각들이 머릿속에 꽉 차서 손이 도저히 안가네요.

저는 현재 채용 프로세스가 이해가 되질 않습니다. AI와 같은 분야라면 알고리즘..당연히 최우선이겠죠.

그런데 단순 웹/앱 개발자나 API와 Socket을 제공하는 백엔드 개발자에게 알고리즘이 필요한가???


코딩 테스트로 문제 해결능력을 본다는게 이해가 되질 않습니다. 문제 해결능력을 보려면 디버깅 능력을 봐야지, 왜 알고리즘을 봅니까? '자신의 회사에서 있었던 문제(이미 해결한)들을 똑같은 상황을 만들어놓고 해결해봐라' 가 되어야지 왜 뜬금 알고리즘을 볼까요?


CS도 마찬가지입니다. cs 중요하죠... deep한 문제일수록 cs 기초가 있어야 쉽게 풀 수 있습니다.
그런데, 그런 deep한 문제를 과연 1년에 몇 번이나 겪을까요? 그리고, 과연 기초가 부족하다고 그 문제를 풀지 못할까요?
적어도 저는 기초가 부족해서 해결하지 못했던 경험은 없었습니다. 물론 기초가 부족해서 문제가 생겼던 적은 있었죠.
그리고 그럴 때는 기초가 부족해서 당면한 문제라도 그 문제를 해결해나가는 과정에서 어떤게 문제였구나..를 알게되고, 자연스럽게 해결해나갔습니다. 그리고 머릿속에서 지워버리죠. 왜? 다시 직면해도 충분히 해결할 수 있는 문제니까. 내 뇌용량은 그런걸 기억해둘 만큼 크지 않으니까...


cs를 모를 때는 단지 시간이 조금, 조금 더 걸릴 뿐입니다. 반면 기술 스택을 모른다면? 내가 쓰는 기술 스택 외에는 관심이 없다면? 그게 cs 기초가 부족한 것보다 100배는 더 큰 문제 아닌가요?
내가 RSocket을 공부하는데 그게 1계층을 쓰든 5계층을 7계층을 쓰든 RSocket을 어떻게 쓰는지 아는게 더 중요한거 아닌가요?

분명 기술마다 장단점이 있습니다.
HTTP를 사용하는 API와 Socket.io, 5/6 계층을 쓰는 RSocket, 그리고 WebSocket, HTTP/2를 사용하는 gRPC 등등........
각 기술마다 장단점이 있을겁니다. 그리고 어떤 작업을 선택할 때, 선택의 폭이 넓어지죠.


예시가 금방 금방 생각이 안나서 좀 억지를 부리자면...

마이크로서비스로 만들어라...했을때 자연스럽게 게이트웨이 등을 떠올리죠. 그런데 게이트웨이를 모르면? 그 사람은 게이트웨이 없이 만들겠죠. 솔직히 게이트웨이 없이도 도메인만 다르게 주면 그냥 만들 수 있으니까. 근데 이게 cs 기초가 부족해서 시간을 더쓰는것보다도 더 큰 문제 아닌가요?


근데 왜 취업을 하기 위해서는, 이직을 하기 위해서는 기술 스택이나 디버깅 능력 혹은 구현 능력을 보는게 아니라 알고리즘과 cs를 보나요? 도저히 이해가 안가요.............................................................

cat-footer