Blog

Takahiko Wada (Twitter, GitHub)
Software engineer / Tokyo.

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

August 22, 2020

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

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

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

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

こんな問題

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

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

spec

要求仕様

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

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

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

なぜ DB の設計か

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

  • いわゆるコーディング試験だと”慣れ”に左右される部分が大きい。また実務と直結しなかった。
  • 特定の言語のスキルは求めていなかった。言語に関しては入社してから慣れれば良いという考え。
  • 一方で DB テーブル設計はミスると後から改修しにくい。
  • 正しく DB 設計するにはビジネス要件をちゃんと理解する必要がある。そのへんのコミュニケーション能力も測れる。

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

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

回答例

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

spec

このへんを見る

設計の基本

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

コミュニケーション

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

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

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

などなど。

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

発展

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

どのような index を張るか?

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

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

community_postsuser_idにも index が必要になる。

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

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

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

(おまけ)ダメな例

実際あったダメな例。

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

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

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

Archives
2020 2019 2018 2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004