コーディングテストを見直した話 ~Android アプリエンジニア採用編~

こんにちは。Android アプリエンジニアの geckour です。
今回は、Android アプリ開発チームが先日アップデートした採用活動におけるコーディングテストについてお話します。

Android アプリ開発チームの採用活動

Android アプリ開発チームの採用フローは、ざっくりとまとめると

(Optional) カジュアル面談
1次面接
コーディングテスト
2次面接
(Optional) 最終面接

このようになっていて、コーディングテストが必ず含まれています。

コーディングテスト

コーディングテストではどのような課題が出るのかというと、実際に簡単な Android アプリを作成してもらっています。

では、なぜ必ずコーディングテストを実施していて、かつアプリを作ってもらっているのか？
それは、私達は会話やホワイトボードコーディングなどよりも、実際的なコーディングを用いた方が

我々が求める技術力があるか
どのような思想・方針で開発をしているのか

といったことを前提に、我々のチームと本当にマッチするのかという判断に適していると考えているからです。

見直したきっかけ

我々が求める技術力があるか

これをしっかり測るためには、現在のチームが抱える課題感の変遷に合わせてコーディングテストの要件をアップデートする必要があります。

そして、近頃チームの課題感とコーディングテスト要件のズレが大きくなってきた、具体的には

旧要件では動画再生機能を要件に含んでいた
ここ最近の開発では動画再生周りを改修することはあまりない

という共通認識がチームメンバー間で生まれたこと、また後述する新たな課題感の芽生えが今回の見直しに繋がりました。

新しいテスト要件のポイント

主だった現在のチームの課題感として、

ユニットテストの文化を根付かせたい
エラーハンドリングをよりしっかりとやっていきたい

というものがありました。

そこで、

ユニットテストを追加すること
エラーを適切に扱うこと

を必須要件として指定しています。

そして、「測りたいこと」をよりきちんと測るため、必須要件とボーナス要件を明示しました。
要件としては書いていないが必ず実装上考慮が必要なことを意図的に残しておいて、受験者の思想を推し量ることと、受験者の工夫の発揮ができるようにしています。

コーディングテスト用の API サーバ

ネットワーク通信を行うアプリであるため、コーディングテスト用の API サーバが必要となりました。

旧要件のテストでは静的レスポンスを返す単純なエンドポイントを用いていましたが、

エラーを適切に扱うこと

という要件のために、一定レートでエラーレスポンスを返す API サーバを新たにチームで開発して運用しています。
実際にテストを実施する (テスト要件とその元になった課題感などコンテクストを熟知している) チームで簡易的な API サーバを開発することで、今後のサーバのメンテナンスの容易性を確保できました。