エンジニアの採用面談で出題してた問題

採用面談って難しい。1 時間とかの会話の中で候補者のスキルを測るわけだから。

色々試した結果、簡単な問題を出してみるのが判断しやすかった。

とは言え、その問題の正否で判断するのではなく、あくまでもコミュニケーションするツールとして問題を使うイメージ。

ということで、こんな問題を出していました、っていうのをご紹介！(主にバックエンド,フルスタックエンジニア向け)

こんな問題

なんらかの web サービスについて、その ER 図を書いてもらう。

なるべくその会社の事業に近いテーマを選んでいた。 例えば、SNS 系のサービスを作っていたときは、ミクシィのコミュニティ(古い?)のような機能を題材にしていた。

要求仕様

• ユーザーは名前とアイコン画像を持つ
• ユーザーは任意のコミュニティに参加できる
• コミュニティの機能はいわゆる掲示板。掲示板には投稿とレスの階層がある。
• 投稿とレスには”いいね”ができる

こんな感じの機能を実装するに当たり、RDB のテーブル設計をして ER 図をホワイトボード書いてもらう。オンライン面談の際は cacoo などのオンライン描画ツールを利用していた。

ER 図のお作法は問わない。意図が伝われば OK。

なぜ DB の設計か

なぜ DB の設計を題材に選んだかというと...

• いわゆるコーディング試験だと”慣れ”に左右される部分が大きい。また実務と直結しなかった。

• 特定の言語のスキルは求めていなかった。言語に関しては入社してから慣れれば良いという考え。

• 一方で DB テーブル設計はミスると後から改修しにくい。

• 正しく DB 設計するにはビジネス要件をちゃんと理解する必要がある。そのへんのコミュニケーション能力も測れる。

あと面談をこういった問題形式にすることで、候補者を相対評価できるというメリットもあった。

だんだん回数を重ねると、面談であれくらいだった人が入社後これくらいのパフォーマンスだから、、といった感じで相対的に評価できる。

回答例

例えばこんな感じに書けるかと思う。

このへんを見る

設計の基本

• 各テーブルに必要なカラムがあるか
• 1:N, N:N などリレーションを正しく設定できているか

コミュニケーション

要求仕様だけで不明確な部分をコミュニケーション取りながら確認できると頼もしい。

「ユーザーが所属できるコミュニティ数は制限ありますか?」

「コミュニティは何の順で表示しますか?」

などなど。

このように要求仕様の曖昧な点は実際の実務でもあるあるなので、こういったコミュニケーションが取れると心強い。

発展

基本ができていたらもう少し深堀りする。

どのような index を張るか?

例えばcommunity_postsのcommunity_id, created_atは投稿一覧を表示するのに必要。

もう少し深堀りすると「ユーザーのマイページに自分の投稿一覧を表示するならどういう index が必要ですか?」とか。

community_postsのuser_idにも index が必要になる。

"いいね"の数が多くなると今の設計だとキツそうでは?

community_postsテーブルにlike_countのようなカラムを設けて合計いいね数を格納しておく、などの対応が考えられる。

同様にcommunitiesテーブルにuser_count(ユーザー数)のカラムも欲しい。

(おまけ)ダメな例

実際あったダメな例。

1. だれがいいねしたかわからないので、いいね済みを判定できない。

2. 一つのコミュニティにしか参加できない。

3. 投稿>返信の階層構造が表現できない