設計・実技の面接

まず要件として、1対1かグループか、既読や画像の送信が要るか、規模はどれくらいかを確かめます。そのうえで、画面は端末の DB だけを読む形にし、送るメッセージは DB と送信待ちのキューに同じトランザクションで入れて、すぐ「送信中」として表示します。つながったら端末で作った ID を冪等キーにして古い順に送り、二重送信を防ぎます。

受信は、アプリが開いている間は WebSocket、閉じている間はプッシュ通知で知らせ、戻ったときにカーソルで差分を取り直して DB に入れます。並び順はサーバーが付けた順番を正にし、送信に失敗し続けたメッセージは再送のボタンを出します。最後に、届くまでの時間と送信の失敗率をどう計るかも話します。

まず、写真の大きさと枚数、動画も扱うか、アップロード中にアプリを閉じてもよいかを確かめます。写真は送る前に端末で縮めて圧縮し、通信量を減らします。大きなファイルは分割して送る方式か、サーバーが発行する署名付きの URL にストレージへ直接送る方式にし、途中で切れても続きから再開できるようにします。

アプリを閉じても続けたいので、iOS ならバックグラウンドの URLSession、Android なら WorkManager に頼み、送る予定は DB に保存しておきます。進み具合を画面に出し、何度も失敗したら利用者に知らせます。完了の通知はサーバーで処理が終わってから受け取り、同じ写真の二重登録は ID で防ぎます。

黙り込まずに、まず問題を自分の言葉で言い直して前提を確かめます。そのうえで、効率は悪くても確実に動く素直なやり方を先に書いてよいかを聞き、例を1つ手で動かして考えを声に出します。動くものができたら、計算量や読みやすさの改善を話します。

例えば検索欄の入力ごとに通信する課題なら、まず毎回呼ぶ形を書き、次にデバウンスで呼ぶ回数を減らし、古い結果が後から届いて上書きしないように前の要求を取り消す、と段階的に直します。行き詰まったときに、どこで迷っているかを言えることが評価につながります。

指定された機能を全部作るより、読みやすい設計とテスト、うまくいかない場面の扱いに時間をかけます。画面・ViewModel・Repository を分け、主要なロジックには単体テストを書き、読み込み中・空・エラーの表示と再試行を入れます。

そして README に、設計の判断とその理由、時間があればやりたかったこと、動かし方を書きます。例えば「オフラインのキャッシュは時間の都合で省いたが、入れるなら Repository で DB を正にする」のように書いておくと、面接での話のきっかけにもなります。