Interviewing Android Developer
Brendan Fahy
안드로이드 위클리를 통해 안드로이드 개발자 면접에 대한 글을 읽고, 괜찮은 내용인 거 같아 작성자(Brendan Fahy)의 허락을 받아 한글로 번역했습니다. (부족한 영어 실력이기에 의역과 오역이 있을 수 도 있습니다ㅠ)
안드로이드 개발자 면접
최근에 친구로부터 안드로이드 개발자 면접에 대한 조언을 부탁받았습니다.
우리는 잠시 이야기를 나누었고, 이에 대한 것들을 작성해서 알려주기로 했습니다.
지난 몇 년간 전 세계의 수많은 면접자들을 인터뷰했고, 그 과정을 통해 여러 동료들을 만나 함께 많은 일들을 해왔습니다.
그 결과, 이메일과 위키 페이지는 우리의 생각을 유용하고 간결하게 만들려는 시도로 가득 차 있었습니다.
제가 이 주제에 대한 전문가는 아니지만, 이 일을 시작했을 때 선임과 함께 공유하고 물어보고 찾아봤던 생각들 속에서 엄청난 가치를 발견했습니다.
이 글이 언젠가 다른 사람에게 그 가치가 제공할 수 있기를 바랍니다.
인터뷰는 면접자, 면접관 모두에게 힘듭니다.
면접은 면접자로서 신경 쓰이는 일이 많습니다.
또한 그들에게 위협적? 일 수도 있고, 드문 경우이긴 하지만 굴욕적이기도 합니다.
만약 백의 고혈압(White-Coat Hypertension)으로 영향을 많이 받는다면, 인터뷰에 불참하는 것만도 못한 경우도 발생할 수 있습니다.
백의 고혈압
하얀 가운을 입은 사람만 보면 가슴이 두근거리면서 긴장이 되며 혈압이 상승하는 것을 말합니다.
면접관을 보면 더 긴장하는 현상을 말하는 거 같습니다.
반대로 면접관들도 힘듭니다.
짧은 시간 안에 회사와 우리 모두에게 잠재적으로 큰 영향을 미칠 수 있는 인재인지 충분히 파악하고 결정을 내려야 하기 때문입니다.
인터뷰는 대화(conversation)가 되어야 합니다.
저는 질문에 대해 그저 옳고 그른 대답만 하는 일방적인 면접 방식을 싫어합니다.
일방적인 면접이라면 서류에 그저 질문에 대해 답을 작성하도록 할 수도 있습니다.
하지만 이런 방식이라면 굳이 면접을 해야 할까요? 불필요한 낭비입니다.
마치 면접자에게 서치라이트를 비추어, 서치라이트의 좁은 빛 범위 내에서만 알아 갈 수 있도록 제한을 거는 겁니다. 면접관은 자신이 묻지 않은 것에 대해서는 아무것도 들을 수 없고, 면접자들도 면접관이 자신을 대하는 방식을 제외하고는 회사에 대해 아무것도 알 수 없습니다.
그러면 이 회사에서 일할 마음이 생길까요?
물론 대부분의 인터뷰 문항은 면접자들이 가질 수 있는 질문에 답할 수 도 있습니다.
하지만 요점은 뭘까요?
이러한 일방적인 면접 방식은 실제로 팀에서 이뤄지는 대화 방식과는 다르다는 겁니다.
만약 이 사람과 함께 일하는 것이 어떨지 알고자 한다면, 면접을 통해 파악하고자 해야 하지 않을까요?
저는 평범한 대화처럼 느껴지는 면접을 좋아합니다.
물론 면접자가 일자리를 얻고자 설득하는 자리이지만, 대화를 할 수 없다는 의미는 아닙니다.
만약 누군가를 인터뷰하고 합격시킨다면 그들과 긴밀히 협력할 가능성이 있습니다.
즉, 하루에 8시간 이상, 일주일에 5일 동안 항상 같이 일을 할 거나, 서로의 코드를 다룰 수 도 있습니다.
그게 아니더라도 그들과 자유롭고 편안하게 대화할 수 있어야 합니다.
대화를 나누는 방법
대화를 통해 면접을 보고 싶지만, 목표는 있어야 합니다.
우선 제가 면접자에게 알고 싶은 것과 말하고자 하는 것 두 가지가 있습니다.
저는 면접을 여러 섹션으로 나누고, 먼저 면접 시작 시 이들을 소개합니다.
이 섹션은 시간과 주제와 관련된 특성 측면 모두에서 유연성이 있습니다.
이를 공유함으로써, 그들에게 무엇을 기대하는지 알려주고, 그 과정 속에서의 호의적인 태도 통해 좀 더 편안하게 느낄 수 있게 해 줍니다. 미묘하지만 도움이 됩니다.
일단 준비가 되면, 토론을 시작하기 위해 질문을 하거나, 좀 더 자세한 내용을 확인하기 위해 후속 질문을 합니다. 정답 / 오답만 있는 폐쇄적인 질문은 일반적으로 덜 유용합니다.
Openers: 안드로이드 기초
안드로이드 기초에 관한 간단한 질문부터 시작합니다.
간단하고 쉬운 질문을 통해 면접자가 안심을 느끼게 하는 동시에, 안드로이드에 대해 잘 모르는 사람인지를 구분할 수 있습니다.
Activity lifecycle에 대해 설명할 수 있나요?
Service와 ContentProvider 사이의 차이점을 설명할 수 있나요?
안드로이드 앱에서 어떻게 데이터를 유지(persist)할 수 있나요?
앱에서 오랜 시간이 걸리는 작업을 수행하려면 어떻게 해야 하나요?
두 개의 Fragment 사이에 통신(communicate)은 어떻게 하나요?
만약 이 질문들이 여러분들에 애매하게 보인다면, 면접자들에게도 애매하게 보일 겁니다.
Activity lifecycle 자체는 매우 간단하고 명확하게 답해야 하지만, 그 외의 질문들은 Activity lifecycle과 관련이 있거나 역으로 면접자의 질문으로부터 답해져야 합니다.
이는 서로 간의 의사소통이 많아지기 때문에 대화적 성격이 강해지게 됩니다.
유능한 안드로이드 개발자는 이미 데이터를 유지하고 오랜 시간이 걸리는 작업 수행하고 Fragment 간 통신하는 여러 방법을 이미 알 고 있습니다.
이러한 모든 것들은(심지어 Fragment를 이용하는 것조차도) 가치 있는 토론 주제들입니다.
이를 통해 누군가에게 어떻게 접근하고 무엇을 해왔는지 많이 알 수 있습니다.
도구 및 기술
면접자가 이용했던 도구(Tool)와 기술에 대해 물어보는 것은 좋은 아이디어입니다.
만약 아직도 Eclipse나 vim을 이용하거나, Git을 이용하지 않는다면, 그 이유를 알고 싶습니다.
대부분의 사람들은 Android Studio와 Git을 이용한다 답합니다.
잘 됐네요. 하지만 특이한 점을 발견하는 것도 좋습니다.
안드로이드 개발은 외부 오픈 소스 라이브러리의 방대한 커뮤니티를 가지고 있으며, 이러한 라이브러리들을 이용하여 쓸데없는 시간을 낭비하는 것을 피할 수 있습니다.
물론, 앱 내의 문제점을 완벽히 이해하지 않고도 외부 솔루션을 적용하여 이 문제를 해결할 수 있습니다.
특정 라이브러리가 아닌, 범주(category)에 초점을 맞춰서 이용했던 솔루션에 대해 질문하는 것이 도움이 됩니다.
#01 Networking
요즘은 Okhttp와 Retrofit가 상당히 보편화되었습니다.
Volley가 여전히 가끔 튀어 오르긴 하는데, 왜 아직도 선호하는지 궁금합니다.
저는 아직도 Spring RestTemplate에 대한 악몽을 꿉니다.
#02 JSON serialisation/deserialisation
Moshi는 인기가 높아지고 있지만 아직도 대부분의 사람들이 GSON을 사용합니다.
Moshi를 들여다보지 않은 한 GSON보다 장점이 많은 것을 모르기 때문에 Moshi가 토론하기에 좋은 주제가 될 수 있다고 생각합니다.
저는 Jackson을 이용하거나 수동으로 작업하는 것 중 어느 것이 더 안 좋은지 결정할 수 없습니다.
Jackson의 method 개수를 생각하면 완전히 미친 짓이고, 자신만의 JSON 처리 로직을 직접 만드는 것은 시간이 많이 걸리고, 어렵고, 불필요한 일입니다.
#03 Source control
앞서 언급한 바와 같이, 요즘 시대에 Git을 이용하지 않거나 이용해 본 적이 없다면 매우 이상합니다.
저는 프로세스의 관점과 도구의 관점에서 어떻게 Git을 이용하는지 궁금합니다.
branch 기능을 이용하나요?
pull request를 이용하나요?
develop branch와 master branch 구분해서 이용하나요?
개인적으로 일반적인 요구 사항(creating/switching branches, creating commits, rebasing, merging etc)에 대해 터미널 및 Android Studio의 Git 클라이언트를 이용하고, 때때로 시각화를 위해 SourceTree를 이용하곤 합니다.
그러나 뭔가가 꼬여서 conflict 상태에 빠지면, 모든 GUI를 제쳐두고 진리의 터미널로 돌아갑니다.
몇몇 사람들은 command line을 통해 Git을 이용해 본 적 없겠지만, 충분히 이야기할 만한 가치가 있다고 생각합니다.
#04 Dependency injection
Dagger1, 2가 등장하면서 안드로이드 앱에서 의존성 주입(Dependency injection)이 훨씬 더 보편화되었습니다. 그리고 환상적입니다.
그러나 의존성 주입이 무엇인지, 어떻게 구현되는지, 그리고 왜 이용하고 싶어 하는지 아는 것이 중요합니다.
Dagger 2가 Dagger 1보다 나은 점은 무엇입니까?
Android 용 다른 의존성 주입 솔루션이 있습니까?
장단점은?
#05 RxJava
저는 RxJava의 열렬한 팬입니다.
RxJava는 제가 안드로이드 앱 개발하는 방법을 바꿨습니다. 사랑합니다.
만약 면접자가 RxJava를 사용하지 않고, 사용해본 적도 없어도 괜찮습니다.
하지만 안드로이드 커뮤니티에서 지금까지 뜨거운 화제가 되어 왔기에, 들어보지 못했거나 시도조차도 하지 않았다면, 최신 기술에 대한 인식이나 흥미가 없는 것처럼 보일 수 있습니다.
당신이 RxJava와 함께 했던 것 중에서 가장 좋아하는 것은 무엇입니까?
RxJava의 단점이나 결점은 무엇이었나요?
#06 Kotlin
Kotlin은 사랑스러운 언어입니다.
안드로이드 개발 커뮤니티에서 RxJava와 마찬가지로 인기 있는 주제입니다. Kotlin을 사용해봤는지 궁금합니다.
가장 좋아하는 언어의 기능은 무엇입니까?
혹시 문제가 있었나요?
#07 Android Support Libraries
기술 저널리스트들이 자랑하는 안드로이드의 오래된 파편화 문제에 대한 구글의 부분적 해결책으로, 지원 및
머티리얼 디자인이 생겨남으로써 디자인 Support Libraries는 꽤 보편화되어있습니다.
하지만 Support Libraries를 이용함에 있어 많은 문제가 생길 수 있기에 이에 대해 대화하는 것은 좋습니다.
그리고 보편적이진 않지만 새로운 구성 요소에 대해 물어보는 것도 좋습니다.
ConstraintLayout?
VectorDrawable?
#08 Google Play Services
개인적으로 최근에 GoogleApiClient 및 일부 Google Play 서비스 API로 불만을 터트렸습니다.
사용하기가 다소 어색할 수 있지만 올바르게 사용될 때 앱에 엄청난 힘(immense power)을 줍니다.
Google Play 서비스를 통해 얻은 경험에 대해 듣고 싶습니다.
테스트
저는 테스트가 중요하다고 생각합니다.
예전에는 안드로이드에서 테스트하기가 쉽지 않았지만, JVM JUnit 테스트, Espresso 및 안드로이드 Testing Support Library로 인해 지난 몇 년간 비약적으로 발전했습니다.
테스트에 대해 이야기하는 것은 자연스럽게 앱 아키텍처에 대해 이야기하는 것과 관련이 있습니다. 앱은 테스트가 가능하게 코딩되지 않은 한 테스트할 수 없기 때문입니다. 따라서 위에서 언급한 의존성 주입 질문과 교차점이 있을 뿐만 아니라, MVP, MVVM 같은 패턴과 앱 코드를 구조화하기 위해 이용할 수 있는 다른 전략들도 도입할 가능성도 있습니다.
중급 이상의 실력을 가진 개발자들에게 저는 테스트와 관련된 의견들을 듣고 싶습니다.
Unit testing
Instrumentation testing
UI testing with Espresso
이력서 프로젝트와 전쟁 이야기(war stories)
이력서를 읽을 때 눈에 띄는 것을 메모해 두세요. 그리고 모두 물어보세요.
이력서 작성은 짧은 시간 안에 공백이 많은 친절한? 형식에 많은 정보를 넣어야 하는 끔찍한 일입니다.
우선 이력서에서 우선순위를 정하고 내용을 걷어내고 수정하면, 한 페이지에서 Best이거나 흥미로운 몇 가지의 단어를 발견할 수 있습니다. 면접자들이 이것들에 대해 이야기할 기회를 제공하는 것이 중요합니다.
이력서에는 없지만 물어보기 좋은 질문들도 있습니다.
당신이 가장 좋아하거나 최고의 프로젝트는 무엇이었나요? 이유는?
좋았던 점뿐만 아니라 안 좋았던 점들에 대해서도 물어보는 것도 좋습니다.
저는 면접자가 직면했던 가장 어려웠던 프로젝트(또는 문제)와 이를 해결하기 위해 무엇을 했는지 물어보고 싶습니다.
어떻게 그 문제에 접근했나요?
꼭 기술적이지 않아도 괜찮습니다. 팀이나 고객에 관한 것일 수 도 있습니다.
어느 쪽이든 간에, 당신에게 많은 것을 알려 줄 수 있습니다.
안드로이드/기술에 대한 개인적인 관심
마지막 섹션입니다.
가장 평범하고 비공식적인 부분이 될 수 있다고 생각합니다.
이 대화의 목표는 면접자가 안드로이드 나 기술 전반에 실제로 얼마나 관심이 있는지를 파악하는 것입니다.
어떤 이들에게는 안드로이드나 기술이 단지 직업일 뿐이지만, 또 다른 이들은 매일 밤 집에 돌아가서 개인적인 프로젝트를 하거나, 기술과 관련된 기사를 읽습니다.
면접자들을 더 잘 이해하기 위해서는 이를 파악하는 것이 좋습니다.
저는 가급적이면 최근에 있었던 좀 더 넓은 안드로이드와 기술에 대한 경험(흥미)에 대해 질문을 하려 합니다.
손목에 Moto 360이 있습니까?
지난주 Droidcon에 있었습니까?
어제 I/O 기조연설을 보셨습니까?
이 모든 질문은 더 많은 대화를 위한 주제를 여는데 도움이 됩니다.
저는 개인적으로, 면접자가 I/O 기조 연결을 봤다는 말을 듣고 싶습니다 —적어도 하나 이상의 발표에 대해 최소한 한 가지의 의견을 가져야 합니다. 그리고 더 많이 듣고 싶어 하고 궁금한 점도 있어야 합니다.
안드로이드에 대한 최신 정보를 유지하려면 어떻게 해야 할까요?
저는 항상 마지막에 이 질문을 합니다.
이 질문이 누구를 위한 것인지는 잘 모르겠습니다.
제가 따라갈 수 있는 모든 것들(특정 블로그, 웹 사이트, 팟 캐스트 등)을 통해 최신 정보를 유지하려 하고 있지만, 다른 사람들이 무엇을 활용하고 있는지 항상 궁금합니다.
마무리
면접자가 질문을 할 수 있는 시간을 두는 것이 중요합니다.
면접이 끝날 때까지 기다리지 않고 언제든 질문할 수 있다고 분명히 알려주는 게 좋습니다
당신은 면접자들과 인터뷰를 하고 있지만, 그들 또한 당신과 당신의 회사에 대해서 알아가고 있습니다.
기억하세요, 서로 간의 대화입니다.
예전 기억을 돌이켜 보면 대화를 했던 면접도 있었지만, 정말 질문에 대한 대답만 하는 단방향의 면접들도 있었네요.
어떤 면접이든 간에 자신이 실력이 있다면 상관없는 거 같아요.
공부합시다.
