프로그래밍은 사랑하지만 프로그래밍 산업은 혐오하는 개발자

 (deathbyabstraction.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 프로그래밍 자체의 즐거움과 달리, 소프트웨어 일터는 설계의 목적과 성공 기준을 묻기보다 더 많은 코드 생산을 요구하는 환경으로 느껴짐
  • 2023년 채용 공고를 몇 주간 본 경험은 “더 나은 곳”에 대한 기대를 꺾었고, 특히 스타트업 문화가 “질문은 줄이고 생산은 늘리라”는 태도를 노골적으로 드러냄
  • 대형 기술기업에서도 개발자는 백엔드 스택 규모, 면접 점수, 성과평가 점수 같은 숫자로 취급되며, 코드 작성 방식에 대한 개인의 판단은 더 무의미해짐
  • “더 많이 만들고 덜 묻는” 태도는 코드 양을 늘릴 수 있어도 더 나쁜 소프트웨어로 이어지고, 유행 기술과 관성은 언어·라이브러리·프레임워크·코드 패턴까지 스며듦
  • 글쓴이가 원하는 일은 사회에 이미 존재하는 필요에서 출발한 공학 문제를 푸는 것이며, 시스템의 “왜”가 언어·패러다임·아키텍처·문법까지 결정해야 함

소프트웨어 직장에서 느낀 불일치

  • 글쓴이는 자신이 거친 소프트웨어 엔지니어링 직무 어디에도 잘 맞지 않았다고 말함
  • 코드베이스의 내부 논리를 어느 정도 이해하고 나면 기술적 측면이 지루해졌고, 이후에는 더 많이 하는 것보다 다르게 하는 것을 원하게 됨
  • 설계 결정과 목적을 두고 다음 질문을 계속 떠올림
    • 왜 이 일을 하는가
    • 왜 이 방식으로 하는가
    • 더 나은 방식은 없는가
    • 성공을 판단하는 지표는 무엇이며 왜 그것을 쓰는가
  • 이런 질문을 항상 말로 꺼내지는 않았지만, 더 많은 코드를 찍어낼 수 있는 시간에 “너무 많이 생각한다”, “너무 많이 신경 쓴다”는 말을 들음
  • 단순히 재능과 직무가 맞지 않는 문제가 아니라, 조직이 운영되는 방식 자체에 동의하기 어려웠고 그것을 유지하기보다 바꾸는 일을 원함

스타트업 채용 공고와 “더 많이 만들고 덜 묻기”

  • 2023년에 몇 주 동안 채용 공고를 살펴본 경험은 “더 나은 곳이 있을 것”이라는 기대를 무너뜨림
  • 채용 설명의 90% 는 합격자가 쓰게 될 코드가 인류뿐 아니라 개인의 중요한 문제와도 동떨어져 보였다고 평가함
  • 스타트업 문화는 업계의 “더 많은 코드를 생산하고 질문은 덜 하라”는 태도를 가장 노골적으로 보여주는 사례로 제시됨
  • 많은 스타트업은 투자자의 돈을 이동시키며, 제한적으로만 유용한 제품을 사용자에게 필요하다고 설득해 유료 사용자를 얻으려 한다는 비판을 받음
  • 스타트업은 대개 실패하고, 그 결과 몇 달이 아니라 몇 주 안에 작성하도록 압박받은 유지보수 어려운 스파게티 코드가 남음
  • 그런 코드는 나쁜 코딩 관행의 예시 정도를 제외하면 다시 보지 않게 되고, 엔지니어의 시간은 낭비되며, 벤처 자본은 이미 상당한 자본을 가진 사람들에게 흘러가 다시 다른 스타트업에 투입될 수 있음
  • 채용 광고는 이런 일을 사람들의 삶을 풍요롭게 하고 엔지니어링 성장을 자극하는 흥미로운 일처럼 포장한다고 비판함

대형 기술기업에서도 사라지는 자율성

  • 기존 기술기업은 스타트업과 조직·재무 구조가 다르지만, 문화적으로 크게 대비되지 않음
  • FAANG에서 작성한 코드는 실제 사용자에게 도달할 수 있지만, 코드 작성의 어떤 측면에 대한 개인의 생각은 더 무관해짐
  • 개발자는 다음 방식으로 기계의 톱니바퀴가 된다고 비판함
    • 제품이 자본주의의 최악의 측면을 점점 더 음험한 방식으로 자동화할 가능성이 있음
    • 실무적으로는 백엔드 스택 규모, 기술 면접 점수, 성과평가 점수 같은 숫자가 됨
  • 문제는 이런 현실 자체뿐 아니라, 엔지니어가 공허하고 굴욕적인 반복 노동을 다른 노동자들보다 더 열망해야 하는 것처럼 기대받고, 그 어떤 측면도 묻지 못하도록 더 강하게 억제된다는 점임

비판적 사고가 배제된 엔지니어링

  • 프로그래머는 어떻게에만 집중하고, 무엇을 만들지에는 드물게만 관여하며, 왜 만드는지는 거의 묻지 못하는 위치에 놓임
  • 자신이 생산하는 시스템을 비판할 수 있고 비판하려는 개발자에게도, 그런 태도는 직장 밖에 두라는 메시지가 주어짐
  • 개발자는 직무에 내재한 자율성과 창의성 부족을 식별하는 것조차 금지된다고 느끼며, 더 많이 만들 수는 있어도 다르게 만들거나 더 나은 것을 만들기는 어렵다고 봄

코드 양은 늘지만 소프트웨어는 나빠지는 구조

  • 기술 업계의 do-more-ask-less 태도는 더 많은 코드를 만들 수 있지만, 동시에 더 나쁜 소프트웨어로 이어짐
  • 자본과 외부 조건이 지속 가능하거나 긍정적이거나 최소한 실용적으로 유용한 소프트웨어를 만들 여지를 줄 때도, 관성 때문에 그렇게 하지 않는 경우가 많음
  • 유행을 따르고 기존 상태를 재생산하는 편이 더 쉽고 보통 더 실현 가능함
  • 같은 관성은 사회적으로 쓸모없는 제품이 올라가는 전체 기술 스택에도 스며듦
    • 언어
    • 라이브러리
    • 프레임워크
    • 코드 패턴
  • 실제 혁신보다 새로움과 기믹을 앞세우는 성향이 산업 전체를 괴롭히고, 비전형적 문제를 풀지 않는다면 비전형적 엔지니어링도 필요하지 않게 됨

원하는 엔지니어링의 기준

  • 가장 흥미로운 공학 문제는 기술 발전 자체를 목적으로 삼거나 없는 시장 수요를 인위적으로 만들려는 문제가 아니라, 사회 안에서 자연스럽게 생기는 문제임
  • 사회적 필요는 혁신을 이끄는 가장 좋은 동력이며, 초기 컴퓨팅의 획기적 성과도 더 큰 공익을 위해 일어남
  • 원하는 작업 방식은 시스템을 구축하는 왜가 모든 어떻게를 이끄는 것임
    • 프로그래밍 언어
    • 패러다임
    • 아키텍처
    • 코드 한 줄
    • 문법 요소
  • 그 “왜”는 그 자체를 위해 존재하는 사업 지표가 아니라, 실제로 존재하는 진짜 필요를 반영해야 함

같은 가치를 가진 사람을 찾는 요청

  • 글쓴이는 지금까지 이런 가치를 의미 있게 공유하고 이런 종류의 엔지니어링 일을 하고 싶어 하는 사람을 만나지 못함
  • 업계와의 상호작용에서 고립감을 자주 느끼지만, 자신의 작업 가치와 말해야 할 것의 중요성에는 확신이 있음
  • 이런 사람이 있다면 연락해 달라고 요청하며, 이미 그런 장소가 있는지 알고 싶고 없다면 함께 만드는 것이 유익하다고 봄
  • 자신의 관심 분야에 있고 가치와 합리적으로 맞는 컨설팅 일에는 열려 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • OP가 싫어하는 건 “프로그래밍 업계”라기보다 기업 세계임. “현실”이 개발자에게 무엇을 요구하는지에 대한 기대가 어긋난 개발자들과 일해봤고, 나도 그런 적이 있음
    기업은 세련미, 추상화, 재치 있거나 아름다운 코드에는 관심 없음. 비즈니스 요구사항에 맞춰 기능을 찍어낼 개발자를 원함
    관리자, 임원, 동료 같은 톱니바퀴 속 개인들은 프로그래밍의 “예술”을 실천하게 해주겠다고 말할 수 있지만, 회사에 경제적으로 기여하지 못하면 결국 부담으로 취급됨
    기업 밖에서 프로그래밍의 즐거움과 예술성을 찾는 게 낫고, “업계”가 프로그래밍의 방법이나 이유에 신경 쓴다고 기대하지 않는 편이 좋음. 화면에 두드린 문자를 현금으로 바꾸는지만 봄. 이걸 받아들이면 삶이 훨씬 덜 답답해지고, 일에서도 재미를 찾을 수 있음. 다만 꼭 “예술”은 아닐 수 있음

    • “업계”라는 말은 강하게 기업 세계를 뜻한다고 봄
      다만 “기업은 세련미, 추상화, 재치, 아름다운 코드에 관심 없다”는 말에는, 그렇다면 내가 기업 세계인가 싶음
      동료들에게 말하고 싶은 건, 세련미나 추상화나 재치나 아름다움을 시도하기 전에 먼저 명세대로 동작하게 만들라는 것임. 안 그러면 전부 무가치함
      제대로 동작하게 만드는 데 어느 정도 능숙해진 다음에야 올바르게 만들고, 어쩌면 빠르게 만들 수도 있음
    • 더 단순하게 보면, 놀랍게도 일은 취미보다 덜 재미있음
      좋아하는 일을 자기 사업으로 해도, 예를 들어 가구를 만든다 해도 고객이 “틀린” 걸 원하거나 더 좋은 희귀 재료 값을 내지 않으려는 일이 생김
      일의 요소가 없는 취미로서 순수하게 좋아하는 일을 하는 쪽이 항상 더 나음
    • “기업 세계 밖에서 프로그래밍의 위안을 찾으라”는 건 지난 10년간 업계에서 배운 씁쓸한 진실임
      돈을 받는 이유는 납품하기 위해서임. 효율적인지, 문제를 해결했는지, 돈을 벌었는지, 체크박스를 채웠는지는 내 고민거리나 통제 대상이 아님. 할 일을 계획하고, 하고, 사람들에게 친절하게 대하고, 5시에 퇴근하면 됨
      나쁜 코드를 쓰거나, 결정의 하류 영향을 신경 쓰지 않는 식으로 대충 하면 안 됨. 그런 이유로 해고되는 사람도 있음
      더 중요한 건 과하게 하지 않는 것임. 제품이 어떻게 진화할지 예측해 모든 시나리오를 챙기려 하지 말고, 명백히 더 나은 설계를 밀어붙이려 하지 말고, 더 빨리 납품하려 하지 말고, 맡은 일을 하다가 발견한 다른 버그를 고치려 하지 않는 게 좋음. 승진을 좇는 건 스스로에게 가져온 최악의 스트레스 중 하나였음
      자신이 속한 프로젝트가 고강도인지, 고성장인지, 성숙 단계인지, 곧 잘릴 대상인지 파악하고 그에 맞게 행동해야 함
      그리고 공을 가져가고 눈에 띄어야 함. 분기마다 한 번 데모를 하고, 다른 사람의 코드를 리뷰하고, 설계 회의에 참석해 질문하고, 오후 5시 전에 온 이메일이나 메신저에는 빠르게 답하고, 하겠다고 한 일을 납품하면 됨. 유용한 자원으로 보이되, 납품 압박의 조짐이 조금이라도 보이면 행동으로 밀어내야 함
      마지막으로, 항상 2주 안에 다음 면접을 볼 수 있게 준비해두는 게 좋음
      직장은 직장일 뿐임. 가족도 아니고, 인력 파견소도 아님
    • 이런 사고방식이 정확히 Boeing처럼 되는 길이라고 느낌
      비행 중 날개가 붙어 있는 건 핵심 성과 지표를 올리지 않으니, 그런 무관한 걱정에 시간 쓰는 사람은 다 해고하자는 식이 됨
    • 관련성이 높아 보여서 자기 홍보를 해도 괜찮다면, 그런 이유 때문에 Handmade 콘퍼런스를 업으로 운영하고 있고 스폰서 없이 무료로 하고 있음 https://handmadecities.com/about
      암묵적 목표는 충분히 대중화되어, 프로그래머들이 집단적으로 “기업 세계”에서 발언권을 가져야 한다고 합의하는 지점까지 가는 것임. 예를 들어 새 기능을 “찍어내는” 속도를 늦추고 소프트웨어 품질에 더 많이 투자하라고 요구하는 식임

  • 개발자로 30년 넘게 일했지만, 안타깝게도 OP의 글에서 크게 반박할 부분이 많지 않음. 반박할 수 있으면 좋겠음
    젊은 사람들은 기술과 소프트웨어를 만드는 일이 타고난 열정을 발휘할 수 있는 창의적 활동이라고 배움. 기호, 추상화, 반복 활동에 끌리는 특정 유형의 사고방식이 이 일에 모임. 세월이 지나고 주주들은 살찜
    진실은 소프트웨어 개발이 거의 전적으로 경제 활동이고, 그것도 착취적 성격이 있다는 것임. 작업 환경은 금이나 보크사이트를 캐는 것보다는 확실히 낫지만, 거의 대부분은 다른 사람을 부유하게 만들기 위해 코드 광맥에서 코드를 캐고 있음. 모서리 사무실에 앉은 사람들, 그 위에서 요트를 가진 사람들 말임
    그들은 우리가 뭘 하는지, 우리가 그것을 예술이나 장인정신이라고 여기는 허세, 우리가 중요하다고 생각하는 것에 관심이 없음. 실제로는 대부분 우리가 시간을 낭비하는 패배자라고 생각함 https://ribbonfarm.wpenginepowered.com/wp-content/uploads/2009/10/hughMcLeodCompanyHierarchy.jpg
    여기 다른 사람들이 말한 것처럼 근본적인 오류는 기업 업무에서 의미를 찾으려는 데 있음. 하지만 사람에게는 의미가 필요하고, 단 한 번뿐인 삶의 너무 많은 시간을 일에 써야 하니 대안이 많지 않음. 답은 모르겠음

    • “우리가 시간 낭비하는 패배자라고 생각한다”는 건 실제로 꽤 여러 곳에서 나타나는 현상임
      소프트웨어 “하층민”을 패배자라고 보는 사람들에도 적어도 두 종류가 있음
      하나는 그 일이 숙련을 요구하고, 노동자가 가치 있는 전문성을 갖고 있으며, 들을 가치가 있다고 생각하는 부류임. 그래도 월급 받는 상품에 불과하고, 자신들처럼 “방 안에서 제일 똑똑한 사람”이나 “리더”가 되어 큰 보상을 받는 진짜 플레이어가 아니므로 패배자라고 봄
      다른 하나는 소프트웨어 일이 저숙련 잡무이고, 노동자는 일시적 필요악이며, 보상과 충성심 문제에서 건방지고 자기 자리를 모른다고 보는 부류임. 그들의 의견은 가치가 없다고 봄. 물론 비즈니스 세계에서는 소프트웨어 노동자가 진짜 플레이어처럼 움직이고 개인적으로 이익을 취하지 못하니 패배자라고 여김
      후자가 훨씬 더 나쁜 상황임
    • “다른 사람을 부유하게 만들기 위해 코드 광맥에서 코드를 캔다”는 건 흔히 일이라고 부르는 것임. 우리가 좋은 것들과 사회를 갖기 위해 하는 그 일 말임
      내가 만든 것이 다른 사람을 부유하게 한다면 좋음. 그건 내가 만든 것에 가치가 있다는 뜻이기 때문임. 내가 만드는 모든 것에 가치가 있기를 바람
      언젠가 충분히 연습하고 배우고 경험과 저축을 쌓으면, 다른 사람을 책임감 있게 고용할 수 있기를 바람
      좋은 아이디어가 있고 제대로 해낸다면 나도 그 요트를 가질 가능성이 있음. 우리는 그걸 경제적 유인, 혹은 동기라고 부름

  • “업계가 향하는 방향”은 예전부터 사기꾼들에게 침투당하는 과정이라고 봄. 소프트웨어를 작성해 창출할 수 있는 가치가 엄청나고, 기술 업계의 높은 연봉은 그걸 반영함. 그 부는 온갖 사기꾼을 끌어들임
    자격 있는 엔지니어를 뽑는 고양이와 쥐 게임에서 이게 가장 노골적으로 보임. 채용 깔때기의 상단 대비 하단 비율은 어느 때보다 높음
    덜 분명하게는 제품 관리자, 스크럼 마스터 같은 “사기꾼 역할” 전체가 생겼음. 일단 들어오면 수가 많을수록 안전하니 더 많이 데려옴
    혁신할 수 있는 똑똑한 사람들이 이제 창의성, 혁신, 연구, 발견, 공학의 과정을 무능한 인물들에게 손잡고 안내해야 함. 그 무능한 인물들이 똑똑한 사람들이 시간을 어디에 쓸지 최종 결정권을 가진 경우가 많기 때문임
    엔지니어들이 회의 첫 10분 만에 고객 문제를 어떻게 해결할지 알고 나면, 제품 관리자들이 돌아가며 같은 결론까지 손잡고 안내받는 회의를 겪어봤다면 그게 바로 이런 모습임

    • 사기꾼 침투에는 더 교묘한 효과도 있음. 겉으로는 훌륭해 보이지만 실제로 다루기에는 형편없는 소프트웨어가 만들어짐. 훌륭해 보이게 포장하는 것이 만든 사람들의 장기였고, 좋은 소프트웨어를 만드는 것은 장기가 아니었기 때문임
      성능 문제, 보안 구멍, 관측성 부재, 나쁜 확장성, 말도 안 되는 설정이나 의존성 문제가 생김
      특히 FAANG 회사들은 이런 쓰레기로 가득함. 승진을 위해 “자랑 글”용으로 작성하고, 싸구려 지름길이 드러나기 전에 다른 곳으로 가버리면서 사실상 방치한 코드들임
      탄탄한 설계보다 매끄러운 말솜씨가 소프트웨어 엔지니어에게 가장 가치 있는 기술이 되었고, 그 결과가 곳곳에 드러남

  • 기업용 소프트웨어 개발을 10년 넘게 해보니 결과나 이 서커스가 어디로 가는지는 더 이상 신경 쓰지 않게 됨
    지금 신경 쓰는 건 말도 안 되게 높은 연봉이 찍히는 월급뿐임

    • 그리고 스트레스를 최소화하는 것도 중요함. 대체로 가능한 최소한만 하되, 나중의 스트레스를 막기 위해 가끔은 조금 더 하기도 함
      이걸 나중에 많이 신경 쓰지 않기 위해 지금 딱 필요한 만큼만 신경 쓰는 개발이라고 부름

  • 프로그래머로 40년을 보냈지만, 늘 창의성과 상상력을 쓸 방법을 찾았고 기계적으로 코드만 치는 사람이 되지 않으려 했음
    마지막 직장에서 작은 팀을 이끌며 전략적으로 중요한 코드를 만들었고 성공도 거뒀음. 그 코드가 항상 동작하지 않으면 매일 10만 명이 화를 내고, 화난 임원들도 줄줄이 생기는 상황이었음
    결국 너무 열심히 일하는 데 지쳐 은퇴하기로 했음
    일이 동기를 주지 못한다면 프로그래머로 있을 새로운 방법이나 장소를 찾아야 함. 자기 회사를 시작하거나 새로운 걸 시도하는 식임. 아니면 다른 직종을 찾아야 함
    자신을 재창조하는 건 쉽지 않고 요즘은 훨씬 더 어렵지만, 충분히 원한다면 할 수 있음

  • 기업 지배자들을 위해 일할 때조차 프로그래밍은 활력을 줌. 기계를 설득해 내 뜻대로 움직이게 하는 일은 질리지 않음. 하루 종일 해도 지치지 않을 수 있음
    드물게 프로그래밍이 많이 필요한 시기에는 시간 가는 줄 모르고 15시간을 연속으로 했다는 걸 뒤늦게 깨닫곤 함. 거의 20년 동안 계속 그랬음
    안타깝게도 프로그래밍은 일의 작은 부분일 뿐임. 경력이 쌓일수록 더 그렇다는 게 분명해짐. 실제로 코딩하는 시간은 일주일에 한두 시간뿐일 때도 있음
    나머지는 우스꽝스러운 회의, 읽지 않는 사람들 손잡고 안내하기, 다른 사람들이 기계를 필요한 대로 설득하게 설득하기, “계획”, 비슷한 소음에 쓰임. 보람 있는 유일한 부분은 젊은 프로그래머를 멘토링하는 것임
    계속하는 이유는 은퇴까지 가는 안전한 길이고 거의 다 왔기 때문임. 은퇴 후 계획은 순수한 즐거움을 위해 내가 만들고 싶은 걸 프로그래밍하는 것임

  • 문제의 일부는 많은 개발자가 지금 $FAANG에서 받는 급여나 $STARTUP에서 받을 지분 수준을 유지하면서, 의미 있는 프로젝트와 좋은 사람들과 함께 일하고 싶어 한다는 데 있다고 봄
    실제로 직원들은 의미, 독립성, 주도권, 일과 삶의 균형을 화폐처럼 취급하고, 의미 있는 일을 얻기 위해 급여 삭감을 감수하기도 함
    더 나은 일자리는 있음. 나도 찾았음. 하지만 지금 광고 기술 회사나 AI 스타트업에서 일하고 있다면, 익숙한 것보다 훨씬 낮은 연봉을 볼 각오가 거의 반드시 필요함

    • 나는 정신 건강을 위해서라면 10번 중 9번은 꽤 큰 연봉 삭감도 기꺼이 받아들일 사람임
      저소득 가정에서 자랐고 성인이 된 뒤에도 여러 번 아주 적은 돈으로 살아봤기 때문에 자연스럽게 느껴짐. 어떤 면에서는 거의 더 선호하기도 함
      내 정신 건강은 빠듯한 예산보다 과도한 스트레스나 의미 없음 때문에 더 쉽게 위협받음
      별로 긍정적으로 느끼지 않는 일, 더 나쁘게는 부정적인 감정만 드는 일을 계속하는 게 말이 되는 경우는, 더 버는 돈에 대한 아주 구체적인 계획이 있고 그 계획을 실행할 가능성이 매우 높을 때뿐임
      이런 삶의 방식이 모두에게 맞지는 않지만, 평균보다 덜 물질주의적이거나 더 검소한 생활을 두려워하지 않는 사람이라면 고려해보길 강하게 권함. 특히 요즘 “이 좋은 직장”을 무너지지 않고 얼마나 더 견딜 수 있을지 일주일에 한 번 이상 스스로 묻고 있다면 더더욱
    • 대형 건설 회사에서 소프트웨어 엔지니어로 일하는데, 내 일은 깊이 의미 있음
      우리가 만든 도구로 실제 물건을 짓는 사람들이 더 안전하고 효율적으로 일하게 함. 눈이 번쩍 뜨이는, 손에 잡히는 프로젝트가 지어지는 걸 보는 건 정말 멋짐
      맞는 말처럼 FAANG 보상은 훨씬 높지만, 지금 일하는 곳이 정말 좋고 몇 년 지나면 다른 곳을 찾아야겠다는 충동이 오랫동안 처음으로 들지 않는 곳임
    • 동의함. 작은 회사는 많음. 초기 스타트업, 제품-시장 적합성을 찾기 전이나 막 찾는 단계의 회사들도 있음
      대부분 큰 연봉을 줄 여력은 없음. 관심 있고 자기 동기가 강한 사람이 필요함. 여러 방식으로 유연할 의향도 필요하고, 작은 회사에서는 훨씬 더 많은 것이 협상 가능함
      이런 회사들은 눈앞에 쉽게 나타나지 않으니 직접 찾아야 함

  • 해법은 독립해서 자기 아이디어를 만들고 소비자에게 파는 것임. 자기 스타트업일 수도 있지만, 내 경우에는 인디 게임 개발자가 되는 것이었음
    내 게임 중 하나인 YOYOZO가 Ars Technica의 “Best Video Games of 2023”에 선정됐으니, 내 결정이 옳았다고 느낌

    • 궁금한데, 게임을 만드는 동안 재정적으로는 어떻게 버텼는지 궁금함. 프리랜서도 했는지, 저축을 썼는지 같은 부분임
    • 이 전환을 어떻게 했는지 궁금함. 게임이 소개되기 전에는 결정에 대해 어떻게 느꼈는지도 궁금함. 나도 이 길을 생각해봤지만 뛰어들기엔 너무 망설여짐
    • 어떤 게임 개발 스택을 쓰는지 궁금함

  • 섹스는 좋아하지만 매춘부가 되는 건 싫은 것과 같음. 무엇을 하든 자기 조건으로 하지 못하면 비참해질 수 있음

    • 업계에 대해 느끼는 방식을 설명할 때 나도 거의 같은 비유를 항상 씀

  • LeetCode에 대해 비슷하게 느낌
    소프트웨어 공학은 좋아하지만 LeetCode는 소프트웨어 공학을 싫어하게 만듦
    그냥 멋진 걸 만들고 싶음. LRU 캐시나 또 다른 중상급 LeetCode 문제를 40분 안에 외워서 구현하고 싶지 않음

    • 그냥 거절하면 됨. 나는 공개적으로 LinkedIn에, 이제는 GitHub에도 안내문을 추가해서 LeetCode식 면접이나 그와 비슷한 것을 거부한다고 밝혔고, 그 뒤로 더 행복해졌음 https://github.com/mihaitodor
      물론 이 때문에 나와 이야기하지 않겠다는 회사들도 있겠지만 괜찮음. 어차피 그런 면접을 통과한 적도 없고, 항상 면접 중 라이브 코딩을 하지 않아도 되는 일자리를 가져야 했음
    • Linktree 클론 사이드 프로젝트에서 버블 정렬을 마지막으로 써본 게 언제였음?
    • 이런 면접의 문제는 문제를 얼마나 잘 사고하고 해법을 설계할 수 있는지도 제대로 테스트하지 않는다는 것임
      기대치는 사실상 최적해를 완벽하게 암기하는 것임. 그 최적해는 알고리즘을 연구하던 박사급 누군가가 찾아낸 것일 가능성이 큼
      결국에는 월간 활성 사용자 1천 명짜리 CRUD를 위한 엔드포인트를 구현하게 될 뿐임
답변달기