brunch

라이킷 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이십사 Dec 17. 2022

내일 개발자 면접에서 물어볼 것들

소규모 스타트업 CTO가 원하는 개발자란

여느 때와 같이 내일도 면접이다.

항상 어떤 질문을 해야지 명확하게 떠오르지가 않는다. 그날그날 느낌 따라 물어볼 수도 있고, 내가 좋은 개발자라고 생각하는 상에 대해서 질문하고 그 질문에 최대한 근접한 답을 주는 사람이 좋은 개발자라고 으레 생각할 수도 있다. 정말 좋지 않은 방법이지만 이전 대기업에 있을 때도 사실 그 방법으로 사람들을 뽑은 경우가 많았다. '이 사람은 어쨌거나 같이 일해도 전혀 어색하지 않겠다'라는 느낌을 주는 지원자가 눈에 띄는 건 어쩔 수 없나 보다.

하지만 더 좋은 개발자를 모셔오기 위해서는 우리 회사가 원하는 사람은 누군지, 내가 원하는 사람은 누군지 명확하게 정의할 필요가 있다는 생각이 많이 들었다. 특히 개발자들은 워낙에 특이한 사람들이 많고 스타 한두 명의 영향력이 크다 보니 더 그렇다.

그래서 나는 내일 면접에서 아래의 것들을 물어보려 한다.

1. 어떤 개발자가 되시렵니까?

개발자는 연차가 조금 쌓이면 두 가지 갈림길에 서게 되는 것 같다.
하나는 '서비스 지향' 개발자 - "기술적 완벽함보다는 사용자가 만족하는 게 코드 짜는 이유다."

다른 하나는 '기술 지향' 개발자 - "사용자의 만족도 중요하지만 좋은 코드와 아키텍처가 개발의 재미다."

물론 각 개발자가 본인은 그렇다고 인정하지 않을 수도 있지만, 보통은 이 두 가지에서 적절하게 비율을 맞춰 본인을 정의하게 된다.

개발을 하다 보면 회사에서 요구하는 방향과, 기술적인 방향 사이에서 고민을 할 경우가 상당히 많다. 그때 본인이 어느 의사결정을 할지 궁금하다. 둘 중에 정해진 답은 없다. 하지만 이런 고민은 시시각각 찾아올 것이고, 개발자가 내린 의사결정이 쌓이고 쌓여서 제품이 완성되기에 마치 나비효과처럼 태풍이 될지도 모른다.

개인적으로는 양쪽 어느 곳이든 간에 의견이 뚜렷할수록 더 좋게 생각한다. 현재 개발팀에 어떤 사람이 더 필요할지 판단할 수 있기 때문이다. 어느 조직이 그렇듯 한쪽으로만 몰려있으면 분명히 패착이 생기기 때문에 양 사이드 모두 필요하다.

2. HTTP가 어떻게 동작 하나요?

와 같이 기초적인 지식을 물어볼 것이다. (SQL 인덱싱, Join, CI/CD 와 같은 질문도 추가!)

요즘은 정말로 대 프레임워크의 시대이기 때문에 그냥 주어진 프레임워크로 코드를 짜서 결과물이 나오면, 그 이상을 생각하지 않는 경향이 있다. 하지만 서비스가 조금만 더 커져도, 저런 지식들 하나하나가 좋은 API 구조를 만들게 하고, 확장 가능하면서 무너지지 않는 서비스를 만들게 한다는데 매우 매우 동감하고 있다.

특히, HTTP는 있으니까 쓴다, 마치 물처럼.이라는 생각이 많이 드는 요즘이다. 각 status code는 왜 존재하고 각 method는 무얼 하는지? 각 시스템끼리는 어떻게 부호화해서 통신하는지를 이해해야 서비스가 쪼개지고, 개발 조직이 다양화되더라도 무리 없이 통신할 수 있다는 사실을 알고 있는 개발자가 팀에 들어오면 좋겠다.

이런 부분을 간과한 개발자들의 코드는 정말 많은 리뷰와 리딩이 들어가게 되고 그것 만으로도 매니저의 체력은 바닥이 나게 된다.

3. 장애 대응해보셨나요? (새벽에? 생일에? 주말에?)

개발자가 어쩔 수 없이 가져야 하는 오너십과 숙명에 대해서 묻는다.

난 여기서 두 가지가 궁금한데,

1. 장애를 어떻게 받아들이나? (역시나 답은 없지만 덤덤하게 숙명을 받아들이는 게 좋다)
- 다 내 탓이오.
- 다 저 사람 탓이오.
- 크리티컬 하지 않으면 업무시간을 준수한다.
- 그런 거 상관없고 무조건 고친다.

2. 원인이 뭔지 모르지만 내가 직접적으로 관련이 없어 보이는 장애에 대해서 어떻게 조치하는지?
(난 마이크로 서비스의 주인인지, 회사 전체 서비스의 주인인지 궁금하다. 둘 다 장단점이 있다.)

- 혹시 내가 관련 있을 수도 있으니 예의 주시한다.

- 아직도 어떤 게 원인인지 모르니 내 PR부터 뒤져본다.

- 서비스 전체적으로 어디가 원인인지 알아보려 애쓴다.
- 왜 아직도 탐지, 원인 발견이 안되고 있는지가 더 궁금하다.

이 질문이 개발자가 닥치는 가장 큰 위기에서 어떻게 행동할지 예측할 수 있게 해 주리라 믿는다.

4. 어떤 스택을 쓰셨나요?

경력직이면 스택의 숙련도를 볼 것이다.
- 각 스택에서 질문 가능한 깊이 있는 질문을 한다.
- 경력직이라면 어차피 스택이 이미 정해진 것이고, 해당 포지션을 원해서 온 것이기 때문에 이 능력치가 가장 중요할 수도 있다.

신입이면 포트폴리오 때 했던 스택이랑 다르더라도 어떻게 배워나갈지 볼 것이다.

- 학생 때, 공부할 때 수개월 써본 스택 (그마저도 본인 의지로 정하지 않은)을 전부라고 생각하는 개발자가 은근히 많다.
- 하지만 개발을 하다 보면 본인에게 뭐가 더 맞는지, 개발 시장은 어떻게 변하는지 알게 되면서 어차피 바뀌게 될 가능성이 많기 때문에 가능성을 활짝 열어두는 편이 훨씬 도움이 된다.

- 추가적으로 궁금한 건, 개발 문서를 어떻게 읽는지이다.

- 공식문서, 영어 미디엄 글, stack overflow 등 더 많은 지식은 곧 개발자의 힘이다. 한글 블로그만 읽는 개발자도 많은데 절대 발전할 수 없다.

이상의 질문들이 과연 면접자에게는 어떻게 느껴질지 잘 모르겠다.

나의 짧은 경험과, 편협된 생각들로 감히 좋은 개발자가 누구인지 평가할 수밖에 없지만.

그럼에도 불구하고 반드시 우리 팀에 맞는 분이 오셨으면 하는 진심으로 면접에 참가할 예정이다.

keyword