Skip to content

Instantly share code, notes, and snippets.

@umezo
Last active June 15, 2018 06:15
Show Gist options
  • Save umezo/0bb4e6e311e8a67caf13a65b680e4f39 to your computer and use it in GitHub Desktop.
Save umezo/0bb4e6e311e8a67caf13a65b680e4f39 to your computer and use it in GitHub Desktop.
面接で考えてたこと、やったこと、やらなかったこと

スーパーウルトラミラクルアナログです。

採用の目的

勝手に以下の5つだと思ってる

  1. 生産力の向上
  2. 生産性の向上
  3. チームバリューの増加
  4. 文化強化
  5. 意文化輸入

1. 生産力の向上

生産力はざっくりいうと、チームの単位時間あたりの総出力量のこと。 例えば書いたコードの合計とか、直したバグの合計とか、リリースした機能の合計とかそういうこと。

2. 生産性の向上

生産性は単位時間 + 一人あたりの出力量のこと。 生産力を人数で割ったものと思っていい。

厳密には既存メンバの出力が落ちなければいいかな。

1が増えたが2が減るなら失敗してると思っていい。

3. チームバリューの増加

チームバリューとは採用におけるミニマムではない要件以外の能力のこと あいつがいなかったらそれ進まねーな、みたいなやつ 外から見るとそのチームのちから

これがないとただ働き手が増えるだけでチームはスケールしたが成長はしていないのでもったいない。

アナログ感でてきたぞー

4. 文化強化

良いと思ってることを良いと思う人を増やすこと 悪いと思っていることを悪いと思う人を増やすこと

5. 異文化輸入

ほっとくと、考えない、やらない、知らないことを手に入れること。 3じゃん。

いまさっき文章にしたので定義が独自すぎる。 本読んだら書いて有りそう。

面接でやること

目的が定義されれば、やることの方向性はある程度きまる。

  • 自分たちを知る
    • 目的: 4
    • これをやっていないと4を測れなくなる
    • 自分たちが大事にしていてこれからも大事にしたいこと
      • 保守性の高さとか
    • 自分たちに足りないけどあったほうが良いこと
      • これは難しい
      • 想像できないから足りてないわけで
    • 自分たちがだめだと思っていること
      • PRで指摘があって直されたとことかから解るかもしれない
  • ソースコードを見る
    • 目的: 1, 2, 3, 4, 5
  • 理解を量る
    • 目的: 1, 2, 4
    • あるものの存在価値やその理由を聞いていかを量る
      • 飛躍なく論理的にものを考えているか?
        • お互いに理解し合うために絶対に必要
        • 適当に解った風解ってないパターンの人は最悪で受け入れ側のコストバク増
      • 論理の根底にある価値観が共通しているか?
    • 例1
      • Q. Reactの良いところは?
      • A. vdomでパフォーマンス!
      • だと
      • 4をみたさないかもしれない
      • A. fluxサイクルからくる保守性の高さ
      • みたいなやつだと4イケるな、ってなるかも
    • 例2
      • Q. PRに期待していることって何?
      • A. 言語ごとのイケてる書き方を教えてほしい
      • だと4に足りない
      • A. 設計や仕様を共有し妥当かどうか同意してもらう(ことによる責任の分担と属人性の排除
      • だんだんむずくなってきた
      • PRで設計を指摘したときにその根本理由を解ってもらうこととかそれを通して価値観を共有すること、できること

技術力を推し量る

目的: 1, 2

いわゆる技術力を確認する。 できればソースコードを直接みて判断したいやつ。 実績から判断することがおおい。

エンジニアの素質的なやつ?

    • 任意のライブラリのメリットをどのように捉えているか
    • 実務な経験とそこから得たもの
    • 仕組みを説明できるか
      • 想像でも飛躍がなければOK
      • 常に仕組みに気を払っているようだと加点
    • 質疑応答が一貫している
      • 面接を通して質問に回答として正しいものを返せるか
        • 回答ミス(本当はちゃんとわかってるのに表現だけ間違うなど)もあるので確認しながらすすめる

はーこんなん整理された文章に簡単になんねーよ!

総じて

整理できないので自由形式でかく。

2の低下を最大のリスクととらえて、4を敏感に判断している。 2, 4がOKで1に不安があったことは無いのでわからない。 3, 5はこっちの能力が不足しててどうせわからないので知らん!

つまり少なくとも4を測ろうといろいろやっている

特に「議論できるか?」(相互理解の可能性/コスト)と「価値観が同じか」(カルチャーマッチ?)で見ている。

  • 論理的な発言をするか
    • AだからB
  • 論理の根拠が納得できるか(こちらの価値観と同じ根拠か?
    • 「Aである」をこっちが納得できるか
    • 説明を求めることもある
    • 「Reactはvdomのおかげでパフォーマンスがいいから、採用する」
    • に「パフォーマンスが良ければReactじゃなくてもいいの?」とか。
    • これに「yes」なら一貫性があるが、4に反するかもしれない
    • 「no」で過去の意見を訂正し一貫性をもたせるのもあり

あんまり気にしてないのはいわゆる「意識高いエンジニア」かどうか

  • 毎日コミットするようにしてます!
  • 勉強会に積極的にさんかしてます!

とか、それ自体はあんまり重要じゃない。 「何を目的としていて、その手段が合理的かどうか」を検討しているかどうかが重要。

Q. なんで勉強会? A. 知らないことを知るため! Q. ググったりブログ読んだりじゃだめ? A. xxxxxx <--- このあたりの回答が重要

Q. なんで勉強会? A. え。懇親会でおしゃべりしながら酒飲むの楽しいじゃないですか! Q. え。なんか街コンとかなんか会社の人とか A. 自分で人集めるのめんどくさいじゃないっすか! Q. ゴウリテキィ~ ってなるかどうかはさておき。

これはこれで問題なくて、得られた情報が少ないだけ、質問としては効率がわるかったなって感じ。

目的と手段に合理性もあるし加点ではある。

Q. ある state を local state にすべきか redux store にすべきかってどういう風に使い分けてますか?その理由は?

利用経験者向けの質問。

  • 第1段階としては、自分の考えを持っていることが重要。
    • 根拠になっていることから飛躍なく結論につながっているか。
  • 4とそれる回答だった場合、こちらの使い分けを説明しどっちが重要か聞く
  • 懸念がのこる結論であれば、懸念をつたえどう対策するか聞く
    • 説明したことが懸念であると理解されるか
    • その対策にどのようなアイデアがだせるか
      • たとえば、コスパを理由に「対策をしない」という回答がいい場合も当然ある
  • わざと自分たちの理解と逆のことを挙げて反応をみるのもあり
    • 流されそうな人向け
    • これで流れてしまったら、価値観も合わないし自分の意思もない人だなって思う。

Q. 非同期処理は thunk, saga, promise のどれ使ってますか?その理由は?

類似ライブラリがあり比較して採用するようなシーンに対する質問

  • 各ライブラリの特徴を抑えているか?
  • 判断の基準とその結論に飛躍がないか
  • 判断基準そのものが4に反していないか?
  • あんまり比較して使ってないケースも多そうだが、「比較してないけど困ってません」って回答は、質問としては空振りになるが、正直に発言できるというところは加点できる

面接でやらないこと

  • 誘導尋問
    • ≒ yes/noで回答できる質問
    • what, why, how なんかを聞く
    • Is A B ? とか Do you xxxxx ? とか yes/noになる回答は効率が悪い
    • Do you think A ? じゃなくて What do you think about A ?
    • そのかわり質問を考えるのが難しい
    • あらかじめ用意しておきたい
  • 回答を遮る、急かす
    • 時間配分との兼ね合いなので意外と待つのは難しい
    • 遮るのは自由な発言と矛盾するので、やらないほうがいい
      • どんだけいい人でもパフォーマンスを出せない状況というのはある
      • 過剰な緊張や萎縮がありうるので基本的にはリスクがある行為
      • 時間の都合などでどうしても遮る場合は説明する
      • 「聞き方が悪かった」は割と使いやすい(実際そう)
    • 急かすことで論理的な思考の精度が落ちるかもしれない
      • 回転が早い人のほうがいいけど
      • ゆっくりでも着実なひともいい
      • 無言な空気がきまずくないようにブレイクアイス重要
  • 辛いことを隠さない
    • 聞かれなくても言う
    • 入社後のギャップはどっちにも良いことはない

ブレイクアイスしよう

やり方わかんなかったらとりあえず天気の話しろ天気、もしくは時間

MTGと同じで自由な発言を促すことで、高い精度の面接になることを目指す

  • 雨なのにあざーす!
  • あついのにあざーす!
  • 風強くてなんとかかんとか!
  • 晴れててUVがなんとかかんとか!
  • 昼間なのに仕事だいじょうぶでしたか?
  • 遅い時間だけどお腹へってないですか?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment