kik4 blog

Webエンジニアのつぼ焼き。技術的な考え事や報告など。技術TIPSはQiitaの方に書きます。

面接する時に考えること

面接する側になると「いい面接」とは何かについて考えます。 自分が求職者だったら、事前に経歴とコード見せて技術力知ってもらい、当日は現場の状況聞いて良さそうだったら脈があるかどうかその場で決めてもらって 15 分で終わりにしてもらった方がお互い時間を無駄にしなくてハッピーなんですが…それは置いておいて。

面接の意義とは、企業にとってはその求職者が現場にふさわしく、長く働いてくれるかどうかを知りたいです。求職者にとっては現場がどれだけ自分にフィットしてどれだけ良い環境で働けるのか知りたいことでしょう。 そんなものちょっと会って話しただけで見抜けるなら、入社してすぐの社員が数日後に行方不明になるなんてことは起きません。以前知り合ったリクルーターも数回の面接で人間性を見抜けるわけないじゃんと言っていました。専門でやっている方がそうなんだから私のような現場の人間が仕事の片手間に面接してわかるわけないです。 そこは努力と妥協をしていきます。

他に何が面接に大事でしょうか?

私はプレイバリューだと思います。例えお祈りする結果になろうが、求職者にいい面接だと思ってくれた方が断然良いです。いい面接=プレイバリューの高い面接だとして、どうすればそのような面接になるのでしょうか。

個人的に気を付けているのは以下の点です。

ウェルカム感を出す

第一印象は大事です。いくら仕事で疲れていても笑顔で出迎えます。誰も憔悴した職場で働いて自分も消耗したいとは思ってくれません。

技術的な話題を深掘りする

求職者の技術力を推し量り、また求職者側も職場の技術力を知ることができます。実践的な話なら具体的なエピソードが出るまで。理論ならどれだけ理解しているか引き出します。理論の話ならこちらもきちんと知識を身につける必要がありますね。

エンジニアやってるなら自信のある技術や面白い経験の一つや二つあるので、ここが一番盛り上げたいところ。楽しい面接にすることが大事です。盛り上がる話が出てくるまで質問の仕方を変えて無限に引き伸ばしてもいいほど。一度こちらから例を出してみるといいかも。

ただこれだけでは技術力を見抜けないので、必要なら別途コーディングの課題や GitHub でコードを見せてもらいます。正直なところ事前に見せてもらいたいですね…レジュメが当日持ち込みだと何話せばいいか決められないので。

自然に接する

人間関係は大事です。求職者はどんな人と一緒に働くのか見極めようとしています。私のような現場の人間がせっかく出てきているのだから、どのような人と接して働くことになるのかお互い伝えることができるといいです。

まとめ

とにかく楽しく、わざわざ時間を作って足を運んでよかったと思えるような面接にしたいです。上辺ではなく膝を突き合わせて正直ベースの方がお互いに価値のある面接になるのではないでしょうか。求職者は誰しもが面接が上手ではなく、こちらが仏頂面で構えて良い面接にしてくれる人ばかりではありません。こちらから求職者の素質を明らかにし、就職したいと思ってもらえるような面接にしたいです。

逆に私は面接官として本当に価値が作れているのか不安なので、もっと気軽に答えてくれると嬉しいです。

あ、最近は面接される側が多かったのですが他意はないです、念のため。

転職ドラフト&moffersを利用しました

はじめに

エンジニアの転職が売り手市場になって久しく、この傾向はまだ変わりそうにありません。ジョブホッピングにより労働条件を向上させていくことがイケてるエンジニアの在り方であり、あるいは反対にナウいエンジニアであることの証明条件であると言えます。

そこで、この度は私も時代の潮流に乗り遅れつつも機会を逃さないように重い腰をようやく上げることにしました。

多くの社会人は給金をいくら貰っているかなんてことは口に出すことはなく、主に女性の結婚の際の指標として口さがなく語られます。その中でエンジニアの給料は公に語っても良い考え方が浸透しており、おかげでお互いの労働環境が透明化され、業界全体として労働者の地位が向上するというありがたい風潮があります。その風潮を特色として色濃く出している転職サービスが転職ドラフトであり、この文脈でよく名前が上がるのも当然というわけです。

さて、私も数年ぶりに求職者となった今、時流に乗るべく転職ドラフトを利用しました。このエントリはその感想です。ついでにそのクローンサービスである moffers にも参加したのでその比較もちょいちょい入れていきます。

転職ドラフト参加概要

  • 第 14 回に参加
  • 開催日は 2018 年 09 月 19 日〜2018 年 10 月 04 日の 15 日間
  • 参加人数 527 人
  • 参加社数 114 社
  • 総指名数 1140 件

オファーは 6 件。うち 4 件は終盤にどかっと来ました。 指名額は平均して 520 万。ただし 1 社外れ値的に 750 万の指名があってこれを除くと平均は 490 万。

moffers 参加概要

  • 第 4 回に参加
  • 開催日は 2018 年 09 月 19 日〜2018 年 11 月 05 日まで延長
  • 参加人数 ? 人
  • 参加社数 100 強
  • 総指名数 ? 件

オファーは 5 件。週一回オファーが届いて 1-2 件。 指名額は平均して 510 万。

参加時について

両サービスとも開催期間の前にレジュメを書いてその審査を受け、通過しなければエントリすることすら叶いません。この項目というのが非常に多いです。一般的な職務経歴書 A4 二枚で収まる内容ではありません。

が、これを通して自分の経歴やバリューと向き合うことができ、己の長所短所を見つけ出すことができます。これはただの求人サイトを眺めるだけでは得がたい経験の一つだと言えます。

また、ここまで詳細に書かれているのは採用する側としてもメリットだと感じました。当日その場で履歴書職務経歴書を貰ってこのレベルまで深掘りできるのは面接者と受験者の両方にそれに類する技術が必要でしょう。うちの採用書類もこのフォーマットで送ってもらいたいです。

審査の際にレビューも受けられます。転職ドラフトは一発通過したのでもらえなかったんですが、moffers の方は通過してさらに不足点へ意見をもらえたので非常に有り難かったです。

入力項目はmoffers の方はさすがコピーというか、転職ドラフトから流用できます。

指名結果について

概要は上に。希望年収は 500 万でした。

転職ドラフトの方では設定しておらず、結果的に一件高額な指名以外はほぼほぼそれを下回る形になりました。自分の市場価値が全くわからなかったので入力しませんでしたが、結果的に額に不安を感じてしまったので今にして思えば設定しておいた方がよかったです。面談に行って勉強になったり興味が湧いたりした企業さんでも年収足りないしなー…って面談後に後悔しました。受けた以上は後から上げてもらえないし。あと実際に聞いたら下がる可能性はあるよって強調されまして。複数社で同様に言われたので転職ドラフト側でフォーマットが決まってるのか、あるいはそう誘導されるような作りになっているのか知らないですが、ポジティブな言い方じゃないと心象悪いよなーと思ってしまいました。

企業の傾向については転職ドラフトの方はイケイケ系、moffers はかっちり系という印象。印象です。

UI について

moffers の方がシンプルです。 転職ドラフトは事あるごとに入力が求められてちょっと煩わしいかもしれません。ただ FB 取りまくるのはサービス向上させるなら当然の帰着なのかも。

スケジューリングについて

転職ドラフトはサイトの機能(チャットやカレンダー)で面談日時を直接調整します。

moffers は使命を受けた後からエージェントが間に入り、あとはメールか電話でやりとり。以前にもエージェントのあるサービスを使ったことがあるんですが、日程調整がエージェント任せになっている間の不透明さとメールの煩雑さが苦手だったのを思い出しました。ただエージェントが似たような求人を提案してくれることもあるのがメリット。

総合的にどっちがいいかはケースバイケースかと。

面談・面接結果について

転職ドラフトは指名を受けたのが 4 社で全て面談に行きました。1 社面接を進めてお祈り(途中からミスマッチ感あった)。2 社、技術的に優れていて入りたいと思う会社があったんですが年収がネックで回答保留して多分自然消滅だと思われてます。残りの 1 社も興味がないわけじゃないんですが回答を伸ばしすぎたので今更連絡しづらい感じ。

moffers は受けたのが 3 社で 2 社だけ面談に行きました(残りは自己都合で断った)。2 社ともいい面と悪い面があって、金額も取り立てていいわけじゃなかったので辞退。

どっちを利用すべき?

余裕があれば両方がオススメです。オファーが来るまで待つだけなので、片方登録して開催を待つ間にもう片方登録できます。

転職ドラフトは他の利用者のオファーも見ることができる点で公平かもしれません。一方で転職ドラフトだけでは偏らないか?と疑問があるのであれば moffers の登録もオススメします。

終わりに

ここまで 2 サービスの所感を書きました。サービスの利用経験やオファーを送ってくれた企業さんとの面談の時間は私にとってとても貴重で全てが勉強になりました。

特に世の中のエンジニアの職場の平均像を推し量ることができたのが良い経験で、現職を飛び出して自身の見識を広げたい意欲が出てきました。

この機会でこれからより良いエンジニア人生を送れるのではないかと考えています。

… … …

ここまででわかると思うんですが、まだ決着が付いていません。決まっていれば綺麗なオチをかけたんですがーご縁ってそう簡単には結ばれないわけですね!

それでももちろん、上記の 2 サービス利用はオススメですよ。

転職ドラフトの終わる直前から Twitter で求職もしています。

これと続きを読んで興味の湧いた企業様はお声がけください。 いやまあ締め切った方がいいくらいの佳境ではあるんですが、もっといいところや案件があったら話だけでも聞いておかないと損なので何かございましたらご連絡ください。その時はなる早で!

と欲を出して終わりにします。

ポートフォリオサイト作成中

リポジトリgithub.com

サイト: kik4.work

まだちょっと書いただけですが…。 とりあえず今後の予定。

  • 内容を充実させる
    • 使える技術
    • 制作物一覧
    • Qiita記事の目次
  • デザインをいい感じにする
  • ドメイン取る
  • 自動デプロイ環境を作る
  • Twtterカード/OGタグを設定する
  • GA入れる
  • ブログ作る?
  • サイトマップ作る
  • デザインをもっといい感じにする

10/3更新

面接してわかった良いレジュメのポイント

面接される側から面接する側になって気がついたポイントのメモです。

  • 志望・転職理由がはっきりしているといい
    • ぼやけたポジティブな内容だと会社側からは何を求めていて何を与えられるのか、求めているポジションに的確なのかわからない。
    • 「なぜやめるのか・何をしたいのか・そのために何をしているのか」がわかるといい
  • 自己アピールのエピソードには具体性が欲しい
    • 課題・対策・結果と揃っていると嬉しい
      • 売上10%アップとか数字出すといいって指南書とかでよく見るけど本当に信頼度が違う
    • 何にどう取り組んだか業務への姿勢を想像できるといい
    • 逆に無いと印象がぼやけるし採用したくない気持ちが大きい
  • 主体性が欲しい
    • 自分でこういうプロダクト・サイト作ったは高ポイント
      • 自分はSSRとかPWAとか検証して満足してしまっていたのでどうにかしないと…
    • 作った理由も主体性があるといい
      • 受動的だとちょっとマイナス
  • 直近の経歴が重要視される
    • 面接する側の話題としてとっつきやすい
    • 古い話は参考にできない
  • レジュメがイマイチだと面接してもイマイチという先入観が生まれる
    • 面接で人柄を見たり深堀りできるのでひっくり返せないこともないけど
  • 技術力を測れるような要素を入れる
  • やりたいポジションとそれを目標にやっていることがあるといい
  • 年齢と経験が欲しいポジションに見合っているか見られる
    • 若いと生きの良さの比重が大きい
    • キャリア形成大事

よく言われるポイントばかりですが、面接すると確かにこういう視点で見てしまいますね。

理想の職場とは

最近転職を見据えているので、Webエンジニアとして職場に求められる要素を書き出し。

  • 全般
    • 私服可
      • Web系ではよくあるので結果的にスーツの一つも用意できないんです
    • リモート可
    • 始業時間は自由
      • 朝弱い…
      • 朝会などを朝やる必要は本質的に無い
        • 一日一回進捗を共有するという目的を達成するなら別に朝じゃなくて夕でいい
      • つまりフレックス・裁量労働などになる
    • 残業
      • 必要があればやる
        • なければ早く帰る
      • 常態化しているのはダメ
        • 実質的な労働時間が8時間じゃないってこと
        • 体感的に8時間働くのと9時間働くのではバリューが変わらない
          • 長い目で見ればパフォーマンスが落ちる
    • チャットで情報共有
      • 情報の文書化
      • オープンチャットでやる文化
        • 口頭やクローズドでやって知見を共有しないのは時間の無駄、できないなら咎めてもいいくらい
    • お給料は十分に
      • 言わずもがな
  • 技術
    • 設計と実装は同じ人がやる
      • 別だと細かいニュアンスが伝わらない、正確に設計できないなどの支障が出る
      • これなんで別の人がやるって話になってる場合があるんだろう…
    • 詳細設計書は作らない
      • コードを書いた方が早い
    • 技術的負債に理解がある
      • 基本的に技術的に楽をすると後からツケを払わないといけなくてどこかで棚卸しして処理していく必要がある
        • 楽をしなければいいという話ではない(時間的・技術的制約があるためどうしても負債は生まれる)
    • コードレビュー・テスト文化がある
      • 他人がやったことを把握しておく
      • やった人は説明する責任がある
      • 動くかどうかは属人性なくテストで保証されるべき
      • 技術力が低いとこれができないので一種の指標になる
    • 新しい技術に取り組む
      • 新しいことをやることがエンジニアのモチベーションになる
        • 反対にレガシーだからという理由で転職する人は多い
          • 本当によく見る
    • 工期は雑でいい
      • 開発のスケジュールなんて占いのようなもの
        • 設定して管理はするべき、設定しないのはダメ
      • となると自社開発の方が適している

開発環境のドメイン名とiOSで表示できない問題

開発中のサイトのドメイン名はexample.comないしは実験用のものを使うこと。

使うドメイン参考


実際に支障があった話。

開発環境のサイトのドメイン名をproduct.localにしていました。hostsを書いてlocalhostを参照。

途中でスマホ対応のために実機のiPhoneで閲覧。開発環境のMacsquidを立ち上げプロキシを踏ませ、同じhostsを見て参照するようにしました。ついでに自己署名証明書を入れてhttps対応。

ですが、いざiPhoneで見ようとしたら表示されない。MacでもWindowsでも見られるのに。

これを.localから.example.comにしたところ表示されました。どうやら妙なドメインだと表示されないようです。

そういうことがあったので、ドメインexample.comを使うようにしています。


iOSで見られない事象のソース

リフレクションはなぜ使ってはいけないのか

言語や用法によります。使っていいところでは使っていいです。今回はC#の話に限定します。もっといえばアプリケーションコードを想定。

よく言われる実行速度は大きな問題にはなりません。もちろんユースケースによりますが、計算機性能が上がった今では実行速度はそこまでシビアな要求にはなりません。 例えばWebでは他の通信の方がロスが大きいです。

真に問題なのは静的解析が効かなくなることです。呼び出されるメソッドが間違っていようがコンパイル時にエラーが出なくなってしまいます。

加えてエディタの機能にも問題が出ます。C#だとVisual Studioを使っていることが多いですが、 例えばメソッドがどこからどれだけ使われているか調べることができます。リフレクションだとこれがわかりません。 例えばメソッドの名前を変更すると参照している場所の名前も全て変更できます。リフレクションでは変更が付いてきません。

エディタはソースそのものではありません。が、開発を便利にするエディタを使用してソースを書いていれば、その機能があること前提のソースになります。機能を失くせば必ず変更時に見落としが発生します。

この問題に対処する方法は、テストコードを書いて動作を保証することです。これならリフレクションが使われていても問題はありません。

C#は型があるのでテストコードを書かなくても割と何とかなります。本当に。書いてない現場だって多数あるでしょう。 ですがリフレクションが出てくれば話が違います。 リフレクションを書くような需要が出てくれば一緒にテストコードを書くことを意識しなければなりません。

ちなみにC#ならReflectionTypeLoadExceptionとか気を付けたいです。わかっていれば踏みませんがリフレクションはわかっている率があまり高くないと感じます。