전 세계 유일, 대학생 개발자를 위한 챕터인 GDG Campus Korea에서
<GDG상사> 행사를 개최합니다!
면접을 보기 전, 이력서를 쓰기 전, 내가 이 회사에 잘 적응할 수 있을지 걱정되시나요?😞
실제 회사에서는 어떻게 일을 하고, 어떻게 온보딩을 거치는지 미리 경험해볼 수 있는 행사를 마련했습니다!
각 팀의 상사(=멘토)가 일하는 방식을 보고 회사생활을 차근차근 경험해봐요왜, 참여했는가?
평소 혼자서 코드를 짜다 보니, 정해진 형식에서 벗어나는 새로운 코드를 짜기가 힘들었다. 또한 기능을 구현할 때, 이 방법이 최선인지 아니면 다른 방법이 더 좋은지에 대한 의문도 들었다. 따라서, 현직자와의 커피챗이나 다른 안드로이드 개발자들과의 네트워킹의 필요성을 느끼고 있었다.
어떤 행사였는가?
해당 행사는 삼성역 3번 출구 부근의 구글 스타트업 캠퍼스에서 열렸다. 잠실역에서 삼성역으로 가는 2호선을 갈아타야 했지만, 내선과 외선을 착각해서 반대로 타고 말았다... 결국 20분 늦었지만, 아직 행사 소개 시간이었기 때문에 큰 영향은 없었다.
업무를 시작하기에 앞서 먼저 공수를 산정하고 회의를 들어가기 때문에, 상사분께서 해당 기능을 구현하는 데 어느 정도가 걸릴 것이라고 예상하는지 각 팀원에게 물어보았다. 나는 패기 있게 2시간을 제시했다. 내가 2시간을 제시한 바람인지 그 뒤의 분들도 3~4시간을 제시하였고, 자그마한 기능이라도 1~2달을 소모해야 한다는 것을 깨닫게 되었다.
이후에는 파트간의 회의 그리고 1시간 남짓의 짧은 구현 시간을 가졌었다.
커피챗
짧은 시간 동안 회의나 구현을 제대로할 수는 없었지만 무엇보다도 현업자분과의 커피챗이 많은 도움이 되었다.
1. 기업에서 신입들에게 필요한 역량은 무엇인가요? 사이드 프로젝트 또는 라이브러리를 만드는 경험이 도움이 되나요?
사이드 프로젝트로는 크게 어필되지 않으며, 해당 사이드 프로젝트를 진행하면서 어떤 문제를 당면했고, 어떻게 해결했는지를 설명하는 것이 중요하다.
2. 기업에서는 신규 기술 스택보다 기존 기술 스택을 아는 신입을 더 선호하나요?
xml과 compose를 예로 들어주셨다. 실제 회사에서는 xml을 compose로 바꾸는 작업이 진행 중이며, 이미 레거시 기술 스택은 경력자분들이 더 잘 알기 때문에 신규 기술 스택을 아는 것이 신입만의 차별점이 될 수 있다.
3. 신입으로 들어갔을 때 어떤 업무를 진행하나요?
주로 작은 기능의 개발, 새로운 기술 스택에 대한 소개 및 발표, 그리고 새로운 기술 스택으로의 리팩토링을 한다.
4. Paging3 라이브러리를 현업에서 사용하는가?
가공이 많이 필요한 데이터의 경우 손수 구현하고, 그렇지 않을 경우 Paging3를 사용한다.
5. 오프라인 상태에서의 데이터 조회를 위해 Room과 같은 DB에 내용을 저장하고 서버에서 받은 정보를 새로 고침하는가?
동기화 문제로 대부분은 로컬 DB에 저장하는 대신 즉각 서버로부터 데이터를 받아온다.
6. Data Layer 단에서 API 통신 결과를 Result class로 Wrapping 해주나요?
이 부분은 정답이 없다고 하셨다. 미리 가공해서 넘겨주어도 되고, 직접 뷰모델(presentation) 단에서 처리해도 된다.
7. 기존에 플랫폼에서 제공해주는 위젯으로 구현하기 힘든 UI가 있을 경우 직접 만들어서 구현하나요?
직접 만들었을 때의 퀄리티나 사이드 이펙트로 인해 주로 검증된 라이브러리를 사용한다. 또한, 최대한 커스텀을 피하기 위해 디자이너와 타협한다.
8. 안드로이드 개발자로 나아간다면 알고 있으면 도움이 될 다른 기술이 있을까요?
요즘 웹뷰의 사용이 많이 늘고 있기 때문에 리액트를 알면 도움이 된다. 이를 통해 웹뷰와 안드로이드가 어떻게 통신해야 하는지 알 수 있다. 또한, 크로스 플랫폼이 현재 유망한 기술 스택 중 하나다.
결론
행사에 가서 직접 기능을 구현하기보다는 실무의 프로세스를 간접적으로 체험하고 다른 개발자들과의 커피챗에 큰 의미가 있었다.
무엇보다 이번 행사로 가장 크게 와닿은 것은 개발할 때 왜?가 제일 중요하다는 점이다.
여태까지 IT 연합동아리의 면접도 그랬고, 기업의 면접도 결국 코드를 어떻게 짰냐보다는 코드를 왜 이렇게 짰는지를 설명할 수 있는 인재를 원하고 있었다.
이번 행사에서도 구현 후 코드 피드백을 받을 때, "이 부분은 왜 이렇게 짰냐"는 질문을 받고 말문이 막혔던 것 같다. 이제부터는 단순히 평소 하던 습관대로 또는 다른 사람이 이렇게 하니까가 아닌, 이렇게 짜는 합당한 이유를 생각하면서 개발해야겠다는 생각이 들었다.
