새로운 소프트웨어 개발자 일자리 찾기

 (henrikwarne.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 2023년 말 해고를 겪은 소프트웨어 개발자가 새 일자리를 찾으며 30개 회사와 접촉했고, 8곳 거절·6곳 무응답·3곳 오퍼를 통해 시장이 예상보다 빡빡함을 확인함
  • 구직 채널은 LinkedIn의 Open to work, 기존 관심 회사 목록, Demando 같은 개발자 매칭 사이트가 중심이었고, 원격 검색과 오래된 공고는 신뢰하기 어려웠음
  • 일반적인 채용 절차는 리크루터·매니저·기술 면접·과제·CTO/창업자 면접까지 4~5단계로 길었고, 과제형 코딩 테스트는 회사가 말한 것보다 훨씬 많은 시간이 들었음
  • 행동 질문용 STAR 답변, Python·Go 코드 스니펫, Leetcode, GoLand, ChatGPT, GitHub Copilot 등을 준비했지만 라이브 코딩에서는 긴장 때문에 평소보다 사고력이 떨어짐
  • 더 어려워진 시장에서는 언어별 경력 요구, 느린 응답, 급여 범위 확인, 여러 프로세스의 일정 조율이 오퍼 협상과 최종 선택을 좌우함

해고 직후의 상황과 준비 태도

  • 작년 10월 말 회사에서 17명이 해고됐고, 그중 개발자 8명이 포함됨
  • CEO와 Zoom 통화를 한 지 몇 분 뒤 회사 리소스 접근 권한이 모두 끊김
    • 작업 중이던 여러 변경사항을 푸시하지 못함
    • 동료들과 제대로 작별 인사를 나누기 어려워짐
  • 여러 동료가 LinkedIn으로 연락했고, 일부는 Zoom 통화를 잡아 상황을 이야기하고 작별할 수 있게 해줌
  • 이전 이직은 대부분 재직 중 본인 의지로 진행했으며, 스웨덴의 표준 통지 기간인 3개월 동안 마무리한 뒤 새 회사로 옮기는 방식이었음
  • 즉시 접근이 차단된 덕분에 급여를 받는 동안 바로 구직에 모든 시간을 쓸 수 있었음
  • 언제든 새 일을 찾을 수 있어야 한다는 생각으로 일하고 싶은 회사 목록을 유지했고, 과거 연락한 리크루터들과도 우호적인 관계를 이어옴

일자리 찾기 채널

  • LinkedIn 활용

    • LinkedIn의 Open to work 상태를 기존 “Flexible, I am casually looking”에서 “Immediately, I’m actively applying”으로 바꿈
    • 공개 범위는 전체 LinkedIn 회원이 아니라 리크루터로 제한했고, 초록색 #OpenToWork 사진 프레임은 사용하지 않음
    • 상태 변경 뒤 첫 주쯤 하루 약 5명의 리크루터에게 연락을 받음
    • 역할 품질은 평소와 비슷했지만 연락 빈도는 훨씬 높아짐
    • 관심 회사 목록을 확인하며 LinkedIn 회사 페이지의 Jobs 탭과 각 회사 채용 페이지를 함께 살핌
    • LinkedIn은 지원자 수, 공고 게시 시점, 회사 내 지인 여부, 공고 게시자를 확인할 수 있어 편리했음
    • “Golang Stockholm” 같은 키워드 검색, “Recommended for you”, Premium의 “Jobs where you’d be a top applicant”도 일부 괜찮은 공고를 보여줌
    • LinkedIn의 완전 원격 검색은 신뢰하기 어려웠음
      • 영국 내 원격만 가능한 역할이 섞여 나오는 식의 문제가 있었음
      • 스웨덴 내 완전 원격, EU 내 완전 원격, 전 세계 완전 원격처럼 범위를 나눠 검색할 수 있으면 좋겠다고 판단함
    • 최신 공고만 보기 어려워 이미 본 공고를 계속 넘겨야 했음
    • 이후 Google에서 기간을 지난주로 설정하고 golang fully remote site:linkedin.com/jobs처럼 검색하는 방법을 발견함
    • 과거 LinkedIn에서 연락했던 리크루터 약 15명에게 다시 연락했지만 결과는 없었음
    • 채용 중인 매니저에게 InMail을 보낸 경우도 있었지만 응답을 받지 못함

  • 다른 사이트와 검색 방법

    • 스웨덴 개발자-고용주 매칭 사이트 Demando를 사용함
    • 기술과 최소 희망 급여를 적은 프로필을 활성화했고, 이 사이트에서 연락한 한 회사로부터 나중에 오퍼를 받음
    • LinkedIn에서 보지 못한 다른 회사 공고도 Demando에서 찾아 지원했고, 그 회사에서도 오퍼를 받음
    • RemoteOK도 잠깐 봤지만 지원할 만한 공고를 찾지 못했고, 전반적으로 LinkedIn보다 공고 품질이 낮다고 느낌
    • Efinancialcareers는 완전 원격 역할이 거의 없고 검색도 어려웠음
    • Hacker News의 월간 Who’s hiring 스레드도 봤지만 관련 있는 항목을 찾기 어려웠음
    • 유사 회사를 찾기 위해 Google에서 “competitor to” 또는 “alternative to”와 회사명을 조합해 검색하는 방법도 발견함

지원 관리와 응답 경험

  • 모든 리크루터가 LinkedIn 프로필과 비슷한 정보가 있어도 CV를 요구함
  • 회사에 직접 지원할 때도 대부분 CV를 요구했고, 많은 회사가 자기소개서도 요청함
    • 작성한 자기소개서는 저장해두고, 새 지원 시 가장 비슷한 이전 글을 복사해 수정함
  • 지원 내역을 관리하기 위해 Excel 시트를 만들고 회사명, 지원 날짜, 리크루터 또는 담당자, 일반 메모를 기록함
    • 총 30개 항목이 있었지만 모두 정식 지원으로 이어진 것은 아님
  • 지원한 회사 중 6곳은 전혀 응답하지 않음
    • 일부 공고는 한 달 이상 된 상태였음
    • 유효하지 않은 공고라면 내려야 한다고 판단함
  • 회사 사람과 접촉이 없었다면 무응답을 크게 문제 삼지 않았지만, 인터뷰 후 무응답은 회사에 대한 인식을 나쁘게 만듦
    • 한 회사는 리크루터 초기 인터뷰 뒤 매니저 인터뷰를 잡겠다고 했지만 연락이 끊김
    • 2주 뒤 이메일을 보냈지만 답이 없었고, 다시 2주 뒤 관심 없다고 보낸 뒤에야 미지근한 사과를 받음

유료 도구와 준비 자료

  • LinkedIn Premium을 한 달 결제했지만 기대보다 유용하지 않았음
    • 프로필 조회자를 더 볼 수 있었는지는 확실하지 않았고, 구직에는 제한적 가치만 있었음
    • InMail도 몇 개 보냈지만 큰 도움이 되지 않음
    • “Jobs where you’d be a top applicant”도 결정적인 가치는 없었음
    • 한 달 뒤 취소했고, 취소 전 1개월 가격으로 2개월 연장 옵션을 받음
  • Go 일자리를 찾고 있었기 때문에 익숙한 환경에서 연습하려고 GoLand 라이선스를 두 달 결제함
  • GitHub Copilot도 써봤지만, 인터뷰에서는 스스로 코딩했음을 확실히 하기 위해 많이 사용하지 않음
  • 기존 ChatGPT 구독은 여러 과제형 테스트에서 원하는 작업의 기본 프레임워크를 빠르게 만드는 데 유용했음
  • Leetcode 유료 버전은 해설을 볼 수 있어 인터뷰 준비에 쓸 만했음
  • 한 회사가 Alva Labs의 IQ 테스트를 사용해, 12minprep의 Alva Logic Cram Course를 결제해 연습함
    • 사전 연습 덕분에 테스트를 훨씬 잘 봤다고 느낌

더 빡빡해진 시장과 언어 경력 요구

  • 이전 10년과 비교해 개발자 채용 시장은 확실히 더 어려워졌다고 느낌
  • 지원할 수 있는 공고는 여전히 많았지만, 역할당 지원자 수가 과거보다 많아 보였음
    • LinkedIn에서 지원자 수를 볼 수 있는 공고 중 많은 공고가 100명 이상 지원자를 표시함
  • 적합하다고 생각한 역할에서도 답을 받지 못한 회사 수가 많아진 점도 시장이 어려워졌다는 근거가 됨
  • 특정 언어 경력 요구가 커짐
    • 과거에는 Python이나 Golang 경험 없이도 해당 언어로 개발하는 직무를 시작했고, 빠르게 생산성을 냈음
    • 여러 명령형 언어가 서로 비슷해 언어 적응이 가능하다고 봄
    • 하지만 많은 리크루터가 채용 회사의 하드 요구사항으로 특정 언어 2~3년 경력을 전달함

인터뷰 절차와 준비 방식

  • 절차와 일정 부담

    • 일반적인 채용 절차는 4~5번의 인터뷰로 구성됨
      • 리크루터 초기 인터뷰
      • 채용 매니저 인터뷰
      • 기술 인터뷰 1~2회
      • 과제형 테스트 또는 라이브 코딩
      • 경우에 따라 제품 매니저, CTO, 창업자 인터뷰
    • 원격 역할은 Zoom, Meet, Teams로 진행됨
    • 스톡홀름 현지 직무는 대부분 대면 인터뷰를 원함
    • 출퇴근 시간 때문에 대면 인터뷰 하나가 반나절을 차지함
    • 반면 원격 인터뷰는 하루에 여러 개도 가능했음
    • 대면 인터뷰는 상대방과 사무실 분위기를 더 잘 파악할 수 있다는 장점이 있었음

  • 행동 질문과 기술 준비

    • 기존에 유지하던 Word 문서 Interview Tips에 인터뷰 전 볼 내용을 정리함
    • 이번에는 Behavioral Questions 섹션을 추가해 “동료와 의견이 달랐던 때를 말해보라” 같은 질문에 대비함
    • STAR 프레임워크인 Situation, Task, Action, Result, Reflection에 맞춰 답변을 준비함
    • Leetcode의 Rock the Behavioral Interview 질문 목록을 보고 사용할 사례를 정리함
    • 이번에는 행동 질문 때문에 떨어진 인터뷰가 없었음
    • Python과 Go의 짧은 코드 스니펫도 문서에 적어둠
      • 흔한 패턴과 관용구를 빠르게 떠올리기 위한 목적임
      • 모든 스니펫은 실행해 오류가 없는지 확인하고 관련 출력도 포함함
    • Gergely Orosz의 Confessions from a Big Tech Hiring Manager: Tips for Software Engineering Interviews 영상도 봄
    • 기술 인터뷰에서는 호기심 있고 협업적으로 행동하며 질문하는 점이 중요하다고 받아들임

면접과 코딩 테스트 경험

  • 일반 면접

    • 초기 인터뷰에서는 이전 직장에서 비용 절감 때문에 해고됐다는 사실을 공개함
    • 이를 밝힌 것이 불리하게 작용한 것 같지는 않았음
    • 리크루터나 매니저와의 대화에서는 원하는 일과 자신의 강점이 명확했기 때문에 긴장하지 않음
    • 비코딩 기술 면접도 익숙한 기술에 대해서는 긴장하지 않았고, 실패한 것은 한 번뿐이었음
    • 데이터베이스 연결 타임아웃을 얼마로 둘지 묻는 질문에 너무 큰 숫자를 말했고, 그 답이 탈락으로 이어짐

  • 과제형 테스트

    • 몇 년 전 마지막 인터뷰 때보다 과제형 테스트가 많아짐
    • 과제형 테스트는 라이브 코딩보다 덜 스트레스받지만 시간이 훨씬 많이 듦
    • 회사가 뭐라고 하든 각 과제는 최소 6시간이 걸렸다고 봄
    • 회사 입장에서는 초기에 과제를 요구하는 비용이 낮지만, 구직자에게는 성과가 불확실한 큰 시간 투입임
    • 과제형 테스트는 총 5개를 수행함
      • Java 2개
      • Python 2개
      • Go 1개
    • 1개 반 정도를 실패로 봄
    • Go 과제에서는 동작하는 해법을 냈지만 테스트를 포함하지 않음
      • 명시 요구사항은 아니었지만 테스트를 넣었어야 한다고 판단함
      • 반복 실행될지 명확하지 않다고 느꼈지만, 캐싱을 넣지 않아 속도 개선을 하지 않은 점도 실패 사유가 됨
    • 다른 과제에서는 기존 테스트는 통과했지만 숨겨진 테스트에서 빈 입력 관련 오류 2개가 드러남
      • 현업이었다면 추가 테스트를 직접 작성했을 것이라고 봄
      • 결국 해당 회사에서는 오퍼를 받았기 때문에 절반의 실패로 계산함

  • 라이브 코딩

    • 라이브 코딩에서는 긴장 때문에 머리가 평소의 50% 정도만 작동하는 것 같다고 느낌
    • 이번 라이브 코딩 중 3개는 통과하고 2개는 실패함
    • 첫 실패 사례는 제한된 체스 프로그램 작성 과제였음
      • 말 2종류만 지원했지만 프로젝트 구조, 데이터 모델, 유효 이동, 테스트가 필요했음
      • 2시간 안에 제출해야 했고 매우 빠듯했음
      • 대부분은 동작했지만 전체 기능을 완성하지 못했고 이동 코드에 버그가 있었음
    • 다른 실패 사례에서는 회사가 준비한 초기 코드 저장소의 테스트가 동작하지 않았고, 환경 설정에도 시간이 걸림
      • 로직이 어떻게 동작해야 하는지 여러 질문을 해야 했고, 결국 시간이 너무 오래 걸림
    • 모든 라이브 코딩 테스트는 본인 컴퓨터의 IDE를 사용하고 Zoom으로 화면을 공유함

급여 협상과 선택

  • 초기에 너무 높은 급여 숫자를 말해 인터뷰가 취소된 경우가 몇 번 있었음
  • 이후에는 지난 4년간의 연봉을 알려주며 희망 수준을 간접적으로 전달하는 방식으로 바꿈
    • 회사가 그만큼 줄 수 없다고 하면, 현재 무직이라 절대 최소 급여는 없고 제안에 따라 다르다고 답함
    • 이 방식으로 프로세스를 계속 진행할 수 있었고, 나중에 더 나은 제안으로 이어질 기회도 생김
  • 첫 오퍼를 받은 뒤에는 협상이 쉬워짐
  • 역할의 급여 범위를 물었을 때 의외로 자주 답을 받음
    • 수용 가능한 수준보다 낮은 회사는 early no를 할 수 있어 유용했음
  • 한 회사는 마음에 들어 급여를 미리 확인하지 않았고, 여러 인터뷰와 과제 후 매우 낮은 오퍼를 받음
    • 사전에 확인하지 않아 시간을 낭비했다고 봄
  • 스톡홀름 개발자 급여 감각도 더 좋아짐
    • 스웨덴에서는 월급 기준으로 생각함
    • 연금 기여금 포함 여부도 고려해야 하며, 대부분 포함되고 추가로 10~15% 가 암묵적으로 포함될 수 있음
    • 매우 평균적인 개발자 급여는 월 55K~65K SEK 수준임
    • 월 80K SEK 이상은 더 어렵지만, 빡빡한 시장에서도 불가능하지 않음
    • 급여 외에 옵션, 지분, 보너스를 제공하는 회사도 있음
  • 최종 선택에서는 제품과 회사의 흥미, 사용할 언어, 배울 점, 동료도 함께 고려해야 함

최종 결과와 배운 점

  • 한 회사는 매우 긍정적으로 진행하며 추천인 2명을 요청했지만 다음 날 다른 후보를 선택함
    • 추천인 2명의 시간을 쓰게 한 점이 실망스러웠음
  • 구직은 결국 숫자 게임에 가까움
    • 많은 인터뷰에서 실패해도 성공하는 회사 하나만 있으면 새 직장을 얻을 수 있음
  • 최종적으로 3개 반의 오퍼를 선택지로 갖게 됨
    • 한 회사는 공식 오퍼는 받지 않았지만 이미 받은 두 오퍼보다 낮을 것으로 보여 절반으로 계산함
  • 여러 회사의 절차가 비슷한 시점에 끝나도록 일부는 늦추고 일부는 빠르게 진행함
    • 인터뷰를 미루거나 가능한 한 빨리 잡는 식으로 조율함
  • 여러 오퍼가 있어 협상 위치가 훨씬 좋아졌고, 최종적으로 흥미로운 일과 좋은 급여를 모두 갖춘 Swissblock의 시니어 개발자 직무를 얻음
  • 새 일자리를 찾는 일은 매우 많은 작업이며 주말에도 준비할 일이 남아 쉬기 어려움
  • 4~5단계 인터뷰, 과제, 회사 조사, 일정 조율, 탈락까지 더하면 몇 달이 걸릴 수 있음
  • 인터뷰 결과를 스스로 판단하기 어렵고, 탈락할 때마다 놀라는 경우가 많았음
  • 구직 과정을 함께 논의할 전 동료가 큰 도움이 됨
  • 빠르게 응답하는 리크루터는 회사에 대한 신뢰를 쌓는 데 중요함
  • 동료가 해고됐을 때 LinkedIn 등으로 연락해 작별 인사를 하는 일은 당사자에게 큰 의미가 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • FAANG의 ML 엔지니어로 지난 반년 동안 소극적으로 이직을 알아봤지만, 회사들이 돈다발을 들고 몰려올 거라는 통념과는 전혀 달랐음
    프로필 덕분에 리크루터 메시지는 많이 오지만, 절반 이상이 과정 중간에 잠수 탔고, 리크루터 관심은 제안으로 전환되지 않으면 자존감용 허영 지표에 불과함
    수요는 많아도 채용 기준도 매우 높아서, 회사들은 자기들이 쓰는 정확한 기술 스택 경험을 요구함. 주요 ML 프레임워크가 몇 개 있는데 그중 하나만 익숙하다는 이유로 많은 포지션이 제외됐고, 어떤 회사는 특정 기술 경력이 6년이라 최소 8년 요건에 못 미친다며 탈락시킴
    지금까지 결과는 거절 1건과 시니어로의 하향 레벨 제안 2건뿐이고, 목표는 Staff+였음. 보상도 대부분 현재 총보상의 절반 정도에서 상한이 걸렸고, 더 줄 수 있는 회사는 손에 꼽을 정도였음
    전반적으로 ML 엔지니어 시장은 소프트웨어 엔지니어보다는 낫지만, 2020~2022년의 과열장과는 전혀 다름

    • 이제 FAANG 평판이 균일하지 않음
      Google 엔지니어는 여전히 대체로 고급 인력으로 여겨지고, Apple 엔지니어도 평판은 좋지만 시장에 잘 나오지 않음. Facebook/Meta 엔지니어는 평균 이상인 경우가 많지만 공격적인 사내 승진 경쟁자라는 이미지가 있음
      구직이 어렵다면 Amazon일 가능성이 떠오름. Amazon의 공격적인 채용 후 PIP 파이프라인은 적어도 내 경험상 평판을 망쳤고, 최근 몇 년간 함께 일한 전 Amazon 엔지니어들은 실력이 평균 이하인 경우가 많았음
      이제 “FAANG”이라고 묶어 말하는 건 별 의미가 없고, 각 회사 출신 엔지니어에 대한 기대치가 꽤 다름. 게다가 모두 몇 년 전만큼 주목받지 못하고, 순수 엔지니어링 역량보다 거대 기업에서 살아남는 능력을 요구하는 쪽으로 옮겨감
    • FAANG이 비FAANG 지원자에게 돈다발을 던진다는 가정이 더 맞고, 그 반대는 아님
      황금 수갑은 현실이고 의도적이며, FAANG 수준 보상을 ROI로 정당화할 만큼 큰 문제를 가진 회사도 많지 않음
      또 FAANG 내부 스택에는 외부에 없는 훌륭한 사내 도구가 많아서, “이 사람이 전문가인가, 아니면 Google 내부 스택을 잘 쓰는 전문가인가”라는 의심이 생김. 바로 생산성을 낼지, 아니면 먼저 그 도구들을 다시 만들어야 할지도 문제임
      모두가 CEO나 투자자에게 FAANG 인재를 빼 왔다고 말하고 싶어 하지만, 실제로 입찰 경쟁을 할 지갑이나 정확한 상황을 가진 회사는 드묾
      2020년에 채용 관리자로 ML 엔지니어를 뽑을 때도 이런 문제가 있었고, 중견 회사에서는 “ML 엔지니어를 대체 어디에 써야 하지”라는 문제도 자주 있음. 데이터 과학자나 범용 소프트웨어 엔지니어가 아니라면 중간 역할을 만들기 어렵고, 데이터팀이 엔지니어링 워크플로와 도구에 익숙하지 않으면 ML 엔지니어가 버전 관리되고 깔끔한 시스템을 만들어도 KPI가 아니라서 무시되기 쉬움
    • 모든 인기 기술 스택을 배우는 건 현실적이지 않지만, 소프트웨어 엔지니어나 다른 엔지니어가 구직할 때는 관심 분야의 전체 지형을 조사하고 익숙해지는 데 1~2개월을 쓰면 도움이 됨
      완전히 같은 일을 다른 회사에서 하려는 게 아니라면, 면접에서는 실제로 입사 후 익숙해지고 싶은 기술도 전문가처럼 보이게 준비해야 함. 경우에 따라 경험을 다소 부풀려야 할 수도 있음
      전문성은 결국 아는 사실보다 사고방식에 있어야 하지만, 채용 시장은 그렇게 보지 않으니, 잘 꾸며내고 나중에 야간 공부로 뒷받침할 각오가 필요함
      또한 레벨은 환경마다 그대로 대응되지 않음. 본인에게 맞는 일을 찾으면 올라갈 수 있고, 레벨이나 보상에 집착하면 오히려 선택지가 좁아질 수 있음
    • ML도 FAANG도 아니지만, EU에서도 최근 보상 상황은 비슷함
      경력과 책임에 비해 꽤 저평가되어 있다고 느끼는데도, 최근 공고의 보상과 복지는 처참한 수준임
      EU에서 흔히 말하는 것과 달리 많은 공고가 “하이브리드”와 “유연함”을 내세우지만, 면접 후반에야 주 3~4일 출근이 필요하고 “협업” 때문에 대면 회의를 선호한다고 밝힘
      인플레이션 조정을 말하면서도 임금은 내려가고 있고, EU는 미국식 과열과 불안정성은 따라가면서 임금 수준은 따라잡지 못하는 느낌임
    • FAANG에서 ML을 한다면, 다른 회사에서 더 많은 돈 말고 무엇을 얻고 싶은지 궁금함
      예를 들어 더 많은 칩을 확보하기는 어렵고, 이미 계산 자원이 빠듯한 환경에서 실험도 덜 돌리고 처리량도 줄어들 가능성이 큼

  • 현재 미국 채용난은 단순히 회사들이 까다로워진 것보다 더 악의적인 면이 있다고 봄
    첫째, 미국 회사들은 더 낮은 비용으로 해외 팀을 고용하는 방법을 익히고 있음. 매주 남미나 인도 팀을 낮은 단가로 제공하겠다는 이메일을 여러 통 받고, 이전 회사에서도 순수 비용 절감을 이유로 미국/북미 인력을 대폭 줄이고 인도 팀으로 대체하는 걸 직접 봤음
    둘째, 미국 회사들이 코로나 시기에 노동자가 가져갔던 통제권을 되찾으려는 흐름도 있어 보임
    구직을 막 시작했는데 이미 답답하고, 잠수, 무응답, “요건 대비 경력 연수가 부족함” 같은 일을 겪고 있음. 예를 들어 .NET 6 경력 3년 필수 같은 식임

    • 동의함. 내 회사도 미국 시민권자를 불균형하게 해고하고 라틴아메리카 채용을 선호함
      오늘 주요 경쟁사들을 살펴보니 한 곳은 멕시코에 프로그래밍 일자리를 잔뜩 열어두었고, 다른 곳은 주로 인도에서 채용 중이었음
      미국 엔지니어링 일자리를 가져갈 건 ChatGPT가 아니라 다른 나라의 더 싼 개발자들임. 그들 중 상당수는 영어와 프로그래밍 실력이 충분하고, 함께 일해 봐서 알고 있음
    • 북미 소프트웨어 개발자들은 사무실 복귀를 요구해야 한다고 몇 년째 말해 왔음
      일을 원격으로 할 수 있다면, 전 세계의 누군가도 같은 일을 5분의 1 비용으로 할 수 있음
    • 미국 회사들이 낮은 비용으로 해외 팀을 고용하는 방법은 이미 15~20년 전 인도 아웃소싱 1차 물결 때 알아냈음
    • 이제 음모론이 아님. 상위 100개 회사를 열어 3년 전 채용 지역과 올해 채용 지역을 비교해 보면, 미국 외 지역이 늘어난 걸 볼 수 있음

  • “구직용 마이크로사이트의 핵심 요소” 중 전문적인 프로필 사진을 넣으라는 조언은 따르지 않음
    사진가로 일해 보니 카메라 뒤에서 버튼 누르는 쪽이 훨씬 낫다는 걸 배웠고, 미국 채용에서는 사진이 들어가면 안 된다고 봄
    오랜 차별의 역사와 아직 남아 있는 편견 때문에, 가능하다면 이름도 성별, 인종·민족, 카스트, 사회경제적 배경의 단서가 되므로 제거하는 편이 더 나음
    사진은 채용 과정에서 제거하기 쉬웠고 실제로 미국에서는 사라졌었는데, LinkedIn 같은 “소셜 미디어”식 사이트가 이력서에 프로필 사진을 다시 들여왔음

    • 글쓴이는 미국이 아니라 스웨덴에 있음
      이상하게 들리겠지만 많은 유럽 국가에서는 이력서에 프로필 사진이 두드러지게 들어감. EU 사무실 채용을 처음 시작했을 때 충격이었지만, 현지에서는 그런 방식임
      유럽이 차별 문제에서 미국보다 앞서 있다는 말을 많이 들었기에 더 놀랐는데, 실제 이력서에는 프로필 사진은 물론 결혼 여부까지 적혀 있었음. 현지 리크루터에게 이런 정보를 지우게 했더니 내가 이상한 사람 취급을 받았음
    • 호주에서 독일로 옮겼을 때도 이것 때문에 놀랐고, 유럽식 관행처럼 보였음
      어떤 사람들은 이력서에 “미혼”이나 “기혼”도 적는데, 요즘은 줄어드는 중이라고 들음
    • 글을 읽었는데 그 내용을 못 봤음. 아마 글이 업데이트된 것 같음
    • 면접 교육을 받았을 때 이력서를 자동 파서에 넣으라고 강하게 요구하는 이유 중 하나가 사진이나 그런 정보를 제거하기 위해서였음
    • 미국 채용에 사진이 어울리지 않는다고 하지만, Don Burleson의 전문 복장 조언을 다시 읽어야 할지도 모름: https://www.dba-oracle.com/dress_code.htm
      깔끔하고 전문적인 외모를 보여주는 건 고용주에게 실제 차이를 만들고, 회사는 그런 기준을 지키지 않았다는 이유로 합법적으로 해고하거나 채용하지 않을 수 있음

  • 글쓴이처럼 경력 많은 개발자에게도 노력이 필요하다는 건 의심하지 않지만, 30건 지원에 3건 제안은 꿈같은 결과임
    초기 경력자 대부분은 100건 넘게 지원해서 면접 몇 개, 운 좋으면 제안 하나를 받는 수준일 가능성이 큼

    • 글쓴이는 30년 이상 경력이고 연 10만 달러 미만 일자리에 지원했음
      미국 개발자 평균과 비교하면 기대치가 꽤 소박했음
    • 2017년에 커리어 전환자로 시작한 시점이 운이 좋았던 것 같음
      6곳에 지원해 4곳 면접을 보고 2곳에서 제안을 받았고, 사실상 주니어였는데 미드레벨 포지션에 지원했음
      면접 수가 적어서 열정과 집중력을 그 면접들에 쏟을 수 있었다고 생각하고 싶지만, 생존자 편향일 수도 있음
      이후 면접 3번에서 좋은 제안 2개를 받았고, 미국 소프트웨어 엔지니어링 역할 기준 50퍼센타일 이상 보상이었음. 특별히 머리가 뛰어나서 압도한 건 아니라고 봄
      숫자 게임식 지원 전략을 할 에너지는 없고, 면접 자체를 싫어하며 라이브 코딩에서는 머리가 멈춤. 그래서 정말 일하고 싶은 곳, 그리고 그 회사도 협업 잘하는 평범한 개발자를 반길 만한 곳에만 지원함
      평범한 일에도 진심으로 흥미를 느낄 수 있고, 강한 의견을 갖되 쉽게 바꿀 수 있음. 아마 이 두 가지가 내 비결인 듯함
    • 비교하자면 2022년 중반에 스톡홀름에서 구직했을 때 12곳에 지원해 5곳에서 제안을 받았고, 2곳에서는 명시적으로 거절당했음
      나머지 5곳은 내가 거절했거나 절차를 끝낼 시간이 없었음. 지금 시장은 그때보다 구직하기 훨씬 나쁨
    • 시니어 개발자 입장에서도 제목을 보고 예상한 것만큼 어려운 이야기는 아니라고 느꼈음
    • 운이 정말 좋았는지 친구들과 이야기하다가 추천으로 세 가지 다른 일을 찾았음
      제대로 된 입사지원이나 면접을 해 본 적이 없고, 언젠가 이게 발목을 잡을 것 같음

  • 두 종류의 말만 지원하는 제한된 체스 프로그램을 2시간 안에 작성하라는 과제는 쉽지 않음
    체스 프로그램을 직접 작성해 봤지만, 2시간 안에 프로젝트 구조, 데이터 모델, 합법 이동, 테스트까지 만들 수 있을지 의심스럽고, 만든다 해도 버그투성이 코드가 될 것 같음

    • 최근 비슷하게 왕과 룩의 이동을 구현했는데, 체크나 체크메이트도 넣지 않았고 왕을 잡으면 이기는 수준이었음
      그래도 약 2.5시간 걸렸음
    • 전략 요구사항이 낮다면 2시간 안에 풀 수 있는 과제로 보임
      꽤 기계적이고 직선적인 구현처럼 들림

  • 일반적인 채용에 리크루터 1차, 채용 관리자 면접, 한두 번의 기술 면접, 경우에 따라 제품 관리자나 CTO/창업자 면접까지 있어서 총 네다섯 번을 거치는 건 이제 새롭진 않지만 그래도 꽤 미친 일임

    • 우리 회사도 1~2번 면접 뒤 이미 적합하다고 판단한 후보자를 놓친 적이 있음
      그래도 몇 주에 걸친 추가 면접 절차를 강제로 거쳐야 했고, 이건 미친 일일 뿐 아니라 시간과 자원 낭비임
    • 후보자 입장에서는 긴 하루이긴 하지만 크게 싫지는 않음
      첫째, 전화 선별까지 가면 거의 확실히 제안을 받는 편이라 실제 시간 비용이 생각보다 높지 않음. 전화 선별이 없으면 현 상태와 다를 게 없고, 선별이 있으면 면접 묶음의 지연 시간이 긴지 확인해 너무 길면 초기에 빠지면 됨. 하루 8시간은 괜찮지만 2개월에 걸친 8시간은 구직을 복잡하게 만듦
      둘째, 경쟁 제안이 있을 때는 시간 비용이 거슬림. 임금 40% 상승을 앞두고 하루 면접은 괜찮지만, 구직에 꽉 찬 5일을 쓰는 건 휴가가 유한할 때 부담임. 다만 고용주의 절반가량은 경쟁 제안 증빙을 실제로 요구하지 않는 듯하고, 원하는 보상 XYZ를 제시하며 맞춰 주면 바로 서명하겠다고 하면 의외로 맞춰 주려 노력함
      셋째, 평균적인 기술 면접은 10~20분이 기술 문제 풀이이고 30~50분은 회사와 팀에 대해 후보자가 무엇을 아는지 탐색하는 시간임. 새 회사는 위험하고 나쁜 증거를 외부에 숨기려 하므로, 경영진 배경 조사에 더해 여러 팀원의 현재 시각을 듣는 것이 문제 상황을 초기에 피하는 데 도움이 됨
    • 채용하는 사람들 입장도 생각해 봐야 함
      면접 본 후보자의 1%에게만 제안하고도 수습 기간에 30%는 실패한다면, 채용은 모두에게 엄청난 시간 소모임. 좋은 사람은 찾기 어렵고 좋은 일자리도 얻기 어려움
    • 그렇게까지 미친 건 아님. 일부는 30분, 기술 면접은 60분 정도라면 총 5시간쯤임
      예전 온사이트 면접은 왕복 한 시간, 총 여섯 시간 면접, 점심까지 있었고, 수요 많은 회사는 그런 걸 여러 라운드로 시켰음. 타지에서 비행기로 오는 경우도 있었음
      Google 면접을 보러 갔다가 동부 눈폭풍 때문에 SF에 3주 묶였고, 그 결과 Accenture에서 해고된 친구도 있었음
      이에 비하면 원하는 시간에 잡는 4~6시간 면접은 며칠로 쪼개져도 훨씬 낫다고 봄
    • 이쯤이면 관리인과도 면접해야 할 듯함

  • 소프트웨어 엔지니어 시장도 좋지 않지만, 엔지니어링 매니저, 제품 관리자, 디자이너, 개발자 관계 같은 지원 역할은 훨씬 더 나빠 보임
    내 주변에서는 이런 사람들이 특히 일 찾기에 고생하고, 개발자들은 속도는 느리고 혜택은 나빠졌어도 일자리를 찾는 편임. 내 주변만 그런 건지 궁금함

    • 고용주로서도, 주변 사례로도 비슷하게 봄
      전반적으로 관리자가 너무 많다는 경영 유행이 퍼져 있고, Instagram이 Technical Program Manager 역할 전체를 없앤 것처럼 움직임
      첫 번째 직장에서는 해고의 약 50%가 “관리” 쪽이었음. 우리 팀에는 더 이상 제품 관리자가 없고, 큰일이 아니면 디자인을 신경 쓰지 말라는 말을 들었음. 두 역할은 사실상 팀 리드에게 흡수됐고, 이제 그가 목업과 제품 결정을 맡음
      두 번째 직장에서는 해고의 70%가 관리 쪽이었음. 한 관리자가 5명짜리 한 팀에서 총 25명짜리 네 팀을 맡게 됐고, 디자이너와 제품 오너도 잃었음. 이제 그런 결정은 남은 제품 오너나 기술 팀 리드가 맡음
    • 충분한 경력이 있는 사람에게는 시장이 건강해 보임
      우리 회사도 채용 중이고, 내 받은편지함도 채용 회사들로 가득함. 제품 엔지니어링과 리더십 역할 기준임
      시장이 차가운 건 주니어에게이고, 언제 어떻게 바뀔지는 불분명함
      참고로 실리콘밸리 기준이고, 팬데믹 동안 이주하지 않았음. 결국 이렇게 될 수도 있다고 늘 의심했음

  • 오늘날 소프트웨어 개발자로 사는 건 끊임없이 헛소리를 처리하는 느낌임
    다들 괜찮은지 궁금하고, 솔직히 너무 지쳤음. 구직은 영혼을 깎아먹는 활동이고, 지원서를 보내는 일은 시간만 잡아먹고 불필요하게 번거로우며, 시시포스식 반복처럼 느껴지고, 삶을 낭비하는 느낌임. 유용한 걸 배우지도, 실용적인 걸 만들지도, 삶의 어떤 부분도 개선하지 못하며, 검증된 자동화 방법도 없어 보임
    왜 개발자가 이렇게 지쳐야 하는지 이해가 안 됨. Java, JavaScript, Python, Go, SQL 방언들, bash와 awk 같은 스크립팅, ansible, chef, terraform, AWS 서비스 수십 개, 여러 데이터베이스와 구현, 흔한 취약점 유형, DNS, TCP-IP, HTTP, WebSocket 등 프로토콜까지 알아야 하고, 무중력에서 이진 트리 뒤집기도 해야 하는 듯함
    GitHub 활동 그래프는 아마존 숲 항공사진 같아야 하고, 블로그를 유지하고, 컨퍼런스에서 발표하고, 가끔 논문 같은 글도 써야 함. 그래도 충분하지 않고, 알고리즘과 자료구조, 언어별, 프레임워크별, 페어 프로그래밍, 시스템 설계, 제품, 회사·업계 지식, 과제, 기술 발표, 인성 면접까지 여러 면접에 뛰어나야 함
    큰 회사에 들어가 “성공했다”고 느껴도 왜 안전하다고 느낄 수 없는지 모르겠음. 왜 무언가를 만들고 고치는 대신 계속 구직 모드로 살아야 하는지 한숨만 나옴

    • 의사, 변호사, 실제 공학 엔지니어처럼 고소득이고 선호도 높은 다른 직업의 채용 파이프라인이 어떤지 궁금함
      이런 방식이 소프트웨어 개발자에게만 특이한 건지 알고 싶음

  • 모든 리크루터가 LinkedIn에 있는 정보와 거의 같은데도 이력서를 요구하는 건, 고용주에게 전달할 수 있는 동의의 표시물처럼 보임
    어떤 외국 문화권을 방문했을 때 누군가 낯선 잔에 담긴 차를 권해서 한 모금 마셨더니, 나중에 다른 사람이 방금 결혼한 거라고 알려주는 이야기 같은 느낌임

    • 그래서 리크루터에게 채용 관리자와 직접 접촉이 있는지, 또는 그 회사 소속인지 물어보는 게 좋음
      리크루터 상당수는 제3자이고, 지원자 이력서를 받아 전달하는 것만이 일인 경우가 많아 콜드 지원보다 딱히 나을 게 없는 또 하나의 바보 같은 계층이 됨
      리크루터가 가져오는 공고가 같은 사이트에서 다른 제3자 회사들에 의해 직무 설명 한 글자도 안 바뀐 채 재게시된 경우도 흔함
      일부 리크루터는 연락처 정보를 지우고 자기 로고를 넣기 쉽게 MS Word 문서를 요구하기도 함
    • 가장 가능성 높은 이유는 HR 시스템에서 이력서 파일 업로드가 필수 입력란이기 때문임

  • 어떤 회사가 IQ 테스트를 썼다는 게 흥미로움
    아직 그런 건 안 겪어 봤지만, 지난주에는 “성격” 테스트에서 좌파 성향 후보에게 투표하는지 우파 성향 후보에게 투표하는지 묻는 지원서를 봤음. 헬스케어 분야 회사였음
    GitHub가 내 이력서를 AI로 검토해도 되는지 승인 요청한 것도 잠깐 멈칫하게 했음. 허락하지 않았고, 다른 지원자보다 불리해진 느낌이 확실히 들었음

    • 좌우 성향 후보에게 투표하는지 묻는 건 이미 여러 방식으로 불법이어야 함
      그리고 성격 검사 전반도 불법으로 만들어야 한다고 봄
    • 어디서 봤는지는 모르겠지만, 개발자 역할 공고에서 먼저 MBTI 검사를 요구하는 걸 봤음
      INFJ, INFP 같은 성격 유형을 묻는 그 검사임. 코딩 직무에서 이런 걸 요구하는 건 정말 별난 일이었고, LeetCode만 공부하면 되는 줄 알았음
    • 코딩 과제도 이미 거의 IQ 테스트에 가까운 느낌이라, 고유한 코딩 문제를 계속 만들어내느니 차라리 IQ 테스트를 하는 편이 더 단순할 수도 있음
    • IQ 테스트는 불법이라고 생각했음
답변달기