paiza times

paizaがお届けする、テック・キャリア・マネジメント領域における「今必要な情報」を届けるWebメディア

logo

paizaがお届けする、テック・キャリア・マネジメント領域の「今必要な情報」を届けるWebメディア

開発リーダーがエンジニアを面接する時、応募者に聞きたい7つのこと

f:id:paiza:20171122172314j:plain
Photo by Steven Cooper
高村です。

paiza(ギノ)で開発チームのリーダーをしているのですが、最近はエンジニアの採用活動に携わることも増えてきました。

エンジニア向けの転職サービスを運営しているギノで

  • エンジニアを採用する時は何を重視しているのか?
  • 採用する側のエンジニアは何を考えているのか?

ということって、興味ある人もいるかと思うので、書いてみたいと思います。

特にエンジニアを募集している企業の選考では、共通して見ている部分も多いかと思いますので、「これから転職したい!」というエンジニアの方にとって少しでも参考になればと思います。
(もちろん採用基準は会社によって異なるので、弊社特有な項目もあるとは思いますが…)

■自己紹介

経歴:大学(情報系)→メーカー系の大手SIer→paiza(ギノ)に来て2年弱ぐらいです。

担当業務:現在はpaiza新卒paizaラーニングにおける開発チームのリーダーをしています。ロジックサマナーなどのオンラインイベント系の開発もします。

そして、もう一人別の開発チームのリーダーと、エンジニア全体のリーダーであるチーフエンジニアと一緒に、エンジニアの採用選考業務も担当しています。

■エンジニアを採用選考する時に、エンジニアが見ているところ

paizaスキルチェック問題における提出コード

応募者の提出コードは事前に見ていますが、気になるのは「他人が読んでも理解しやすい、読みやすいコードが書けているかどうか」です。

組織の中で開発を進めていく以上、コードはコミュニケーションツールの一つでもあります。普段から意識して、誰が読んでもわかりやすいコードを書いているかどうかは、スキルチェックの提出コードを見ただけでも意外とわかりますし、そんなコードを書いている人にはぜひ会いたくなります。

逆にコードがぐちゃぐちゃでわかりにくかったり、コメントで長々と補足説明があったりする人は、あまりこちらから会ってみたいとは思いません。極端な話、コメントがなければ何をやっているのかわからないようなコードはいらないです。コメントは最終手段として、コメントではなくコードで語ってほしいので…。

実際、数か月前にも提出コードの印象がとてもよかった人を採用しましたが、やはり実務でも書いてくれるコードがきれいで理解しやすくて助かっています。「何がしたいのか」がわかりやすいコードは、たとえ間違いがあっても、気付きやすく直しやすいので安心感があります。本当に採用してよかった…。

そういうコードが書けるエンジニアは、たとえば直接のコミュニケーションが苦手な人でも積極的に採用したいですし、業務でも開発以外の部分は全面的にフォローしたいです。

paizaスキルチェック問題は競プロ感覚でスピード重視で解いてくださっている方も多いですが(もちろんそれはそれでよいのですが)、応募目的で解く場合は、コードのきれいさを重視して「業務として考えたときに、読みやすいコードになっているかどうか」を一度見直してから提出されるのもよいかと思います。そういうところを見ている企業もいっぱいありますので。

そして、「いいエンジニアがなかなか採用できない~」っていう企業の方も、エンジニアを採用するならまずはコードを見てほしいです!エンジニアの仕事っぷりはコードに出ますので!

paizaスキルチェック問題について詳しくはこちら

◆経歴、自分のやってきたこと、できることについて

「経歴を簡単に説明してください」という質問は、ほとんどの企業で聞かれると思います。弊社でも、ここでの説明や職務経歴書などをもとに、応募者の経歴やスキルについて深掘りしていきます。

◇課題解決のエピソード

経歴を深掘りしていくにあたっては、「あなたが仕事で見つけた課題と、それを解決まで持っていったエピソード」をよく聞きます。

こういった質問をすると、「Excelで進捗管理をしていた現場でRedmineを導入しました!」みたいなことを答えてくれる人が多いです。本当に多いです。

別にそのエピソード自体に問題はないのですが、そこで「どんな現場でExcelでは何が問題だったんですか?導入コストを考えればExcelのままでよかったのではないですか?いろいろなツールがありますがなぜRedmineにしたのですか?他のツールの方がよかったのでは?Redmineを導入してどんな結果が出たのですか?」ということを聞いていくと(こんなに一気に詰めるみたいに聞いたりはしませんが、話の中で順を追って…)、答えに詰まる人もいます。で、よくよく聞くと「上司に指示されて、言われた通りに導入しただけ」だったりする。

上司に指示されたことがきっかけでも「Excelではこんな問題があった、他のツールとも比べてRedmineのこういうところがよかった、JIRAもよかったけどこういう理由で導入できなかった、導入した結果こういう課題は解決できたがこういう課題は残った……」みたいなことが自分なりに分析できていて言えればよいのですが。

要は「Redmine導入しました!」だけでは全然アピールにはならないということです。ここで面接官が聞きたい大事なポイントは、自分で課題を見つけるまでの経緯や、課題を解決するまでの取り組みです。これがうまく含まれていないのであれば、Redmineの話をしてもあまり意味がないというか、印象が悪くなる可能性すらあります。

それよりは、もっと小さなこととか技術と関係ない内容になってもよいので、自分で課題を見つけて解決しようと取り組んだ経験を話してくれた方がよいと思います

こういうことを言うと「課題を解決した経験なんてない!」って言う人もいますが、そんなことはないはずです。課題って要は「困りごと」ですから、仕事をしていて「ちょっと困った経験が一度もない人」なんていないですよね。残業が多すぎるのを少しでも減らそうとしたとか、コミュニケーションエラーが起こりがちなのを解決しようとしたとか…何か困った経験がなかったか思い出してみてください。

◇役職名よりも実際にやったことに基づくエピソード

まず「職務経歴書」というのは、転職活動経験があってよく訓練されている人ほど、嘘じゃないギリギリのラインまで盛って書きますよね。それは面接する側もわかっています。

上の項目とも通じる話になりますが、例えば職務経歴書や自己アピールで「開発チームのリーダーをやっていました!」と言う人はすごく多いです。

でも、「どんな現場のどんな開発チームで、具体的にはどんなリーダー業務をやっていたのですか?リーダーとして、チームのどんな課題を解決した経験はありますか?チームをまとめるに当たって、どんなことが必要だと思いますか?」ということを聞いていくと(これも上の項目と同様でこんなに一気に詰めるみたいに聞いたりはしませんが、話の中で順を追って…)、答えに詰まる人もいます。で、よくよく聞いてみると「一応役職名がついていただけで、リーダーとしての業務はほぼやっていなかった」という経歴でした、なんてことが多い。

「チームリーダーやPLなどのポジションを務めました」という経歴を書くと、具体的な話を深掘りされるので、相応の業務経験を話せるようにしておく必要があります。

◇手元の業務だけでなく、全体を把握しているか

「前職ではSIerで業務が切り分けられていて、自分は末端にいたので、どんなシステムのどの部分を作っていたのか、お客さんやユーザーが誰だったのか、全然わかりません」という人もいるかと思います。

ただ、ところどころ不明な部分があるのは仕方ないとしても、「全体の中で自分がどんな役割を担っているか」を意識してこなかったような人は、ちょっと厳しいです。

私も前職はSIerで、本当にいろいろな案件を担当してきましたが、「他のチームが作っていたシステムと合わせると全体としてはこういうアプリケーションだったと思う」とか、「PLの発言を聞いているとエンドユーザーはこういう人が想定される」とか、気にしていれば推測はできるはずですよね。

他にも、例えば「業務でこういうバッチを作ってました」と言う人に「流れてくるデータはどこから来るんですか?どんなフォーマットで来るんですか?バッチが実行されるとシステム全体に対してどんな影響が出るんですか?」と聞いていくと、答えられない人がいます。そういう方は「データのフォーマットはあらかじめ決められていたので、何も考えずそれに従って作っていただけ」ということが多い。

自社サービスを開発している企業に入ったら、自分がサービス全体の中でどこを担当するのか、この機能を改修したら周りにどんな影響が出るのか…といったことは常に意識してもらわないといけないので、「全体の様子に興味はない、言われたことだけやっていたい」という人では困ります。

そもそもエンジニア気質がある人は、システム全体の作りや流れに興味を持って知ろうとするはずなので(把握しておかないと手戻りが起こる可能性もあるし…)、そこに全然興味を持てないのであれば、少なくともこういう仕事は向いていないと思います。

また、弊社では応募者の方に「自分の開発チームでコードをリファクタリングをする必要が出てきたときに、あなたならどうしますか?」といった課題を出すこともあります。(実際の課題はもっとちゃんとした形式で出しますが)

この課題で見たいのは、リファクタ経験の有無ではありません。経験がなくても、リファクタすると周りにどんな影響が出るか調査するとか、通常の開発業務とどう調整して推進していくか考えるとか、まずは影響の少ないところから始めて様子を見ながら進めていくとか、周りへの影響を現実的に想定できる人であればよいのです。

逆に、極端な例ですが「え、とりあえず強行しちゃえばいいんじゃないんですか?何が悪いの?」みたいな人は、組織の中で自分の仕事が周りにどんな影響を与えるかを全然意識できていないので、採用したいとは思えません。

◇勉強やアウトプットについて

「勉強してます」とか「本読んでます」とか、言うだけなら誰でもできるので、証拠としてアウトプットが閲覧できる状態になっていると、プラスになる可能性は高いです。

応募者のプロフィールにGitHubアカウントやブログ・Qiita・ポートフォリオのURLなどが貼ってあると、私はほぼ必ず見に行きます。少なくとも何もない人よりは「こういう勉強をしているんだな」というのがわかるし、面接でもその話題を広げられます。

特にpaizaはRailsを使って開発しているので、Railsを使って何か作っていた形跡があると「チュートリアルぐらいはやってそうだなー」というのがわかったりして、例えば業務でRailsを使った経験がない人でも「キャッチアップが早そう」という印象になるかもしれません。

逆に「勉強してます!技術ブログやってます!GitHubアカウントあります!」と言っていたのに、見に行ったら全然更新されていないようなケースは、「アカウント作っただけでやってないじゃないですかー」と思われてマイナスになる可能性も高いので、ただ作って終わりではなく、普段からの取り組みが重要だと思います。

あと、やみくもに勉強さえしていればOKというものでもないので、「なぜそれについて勉強しようと思ったのですか?」ということは聞きます。理由は「広く情報収集したいからまずこの分野からやってみた」とかでもいいんですけど、少なくとも目的意識がないと勉強してもあまり身につかないと思うので。

◆転職理由、今後やりたいことについて

f:id:paiza:20210508141352j:plain

◇転職理由について

「今回の転職で何を叶えたいのか」「転職を経て将来的にはどうなりたいのか」といった今後のビジョンについても聞きます。

「もし入社してもらったら、弊社がその人の希望するビジョンを実現する力になれそうか?」は重要なことなので、必ず確認しています。

例えば、スキル的には申し分ない応募者でも、「いずれは好きな分野の研究開発職につきたい」と考えているようであれば、「しばらく開発経験を積みたいというのであればその場所は提供できますが、なるべく早く研究開発がしたいというのであれば、今のところ弊社にはそういったキャリアパスが用意されていないので、力になれないかもしれないです」といったことをきちんと言います。

あと、「前職がSIerなんですけど、残業多いし、仕事の裁量は小さいし、お客さんとの調整が多くて嫌なんですよね!自社サービスを作っている会社ならそれが全部解決できていいですよねー!」みたいな感じで、転職に夢を見ている人は、エンジニアに限らず多いです。でも、この世に100%自分の理想通りの会社なんて存在しません。さらに言えば、課題をまったく抱えていない会社というのも存在しません。

こういった人には、「たしかに弊社だと勤務時間は自分で調整しやすいけど、仕事の裁量は大きくてもエンジニア一人一人に決定権があるわけではなくステークホルダーとの調整は絶対に発生するし、受託開発に比べると人員が固定されているのでコミュニケーションはより密になりますけど、それでも大丈夫ですか?」といったことを必ず聞きます。

「この条件は叶うかもしれませんけど、この部分は前職と変わらないし、この点はさらに大変になるかもしれませんよ」といったことは包み隠さずちゃんと提示した上で、「思ったより大変な部分があるのはわかったけど、頑張っていけると思う」と納得できた人には、ぜひ先の選考に進んでもらいたいですし、「思っていたのと全然違った、この会社では自分の希望が叶いそうにない」という人には、辞退してもらったほうがお互いのためです。

一番避けたいのは、夢を見たまま入社されて、後から「なんか思ってたのと違った…つらい…」となってしまうことです。誰も幸せになれないので…。

◇サービス志向があるかどうか

少なくともB2Cのサービスに進むのであれば、最低限そのサービスを一通り使ってから選考を受けるべきかと思います。弊社だと「paizaってどんなサービスなんですかー?」という人が来ると「うぅん…」となってしまいます。

それは極端なケースだとしても、弊社では選考中に「paizaをもっとよくするためにはどうするべきか?」といった旨の課題を出して、その結果から「サービスやユーザーのほうを向いて考えられる人かどうか」を重点的に見ています。

入社後は、エンジニアもサービスをよくするための取り組みとか、ユーザーの要望とか、そういった課題を見つけて解決する方法を考えなければならないので、エンジニアでもサービス志向じゃない人は厳しいです。

少なくとも「Railsが使えれば作るものは何でもいい」みたいな人は無理です。Railsが使えたら何でもいい、Pythonが使えたら何でもいいみたいなことを面接で言う人たちは、技術志向が高いつもりかもしれませんが、少なくとも企業の採用選考で「技術志向が高くていいエンジニアだなぁ!」と思われるケースはほとんどないのではないかと思います(既に技術を極めていて研究開発の経験などもあるスーパーエンジニアとかなら別ですが…)。

もちろん好きな技術があってそれについて熱く語れるのはとてもいいことです。ただ、開発環境はあくまで手段であって目的ではないので…。企業はRailsを使うため、Pythonを使うためにサービスを作っているのではありません。

「自分が使いたい技術を使って作りたいように作る」のは一人で趣味でやるべきことで、企業の中で開発をするなら、サービスやユーザーのことを考え続けなければなりません。

B2Cサービスの場合は特に、「このサービスをよくするために自分の経験やスキルを生かしたい」というサービス志向がある人じゃないと厳しいと思います。

■応募を始める前にやっておくといいこと

f:id:paiza:20210713182113j:plain

◆スキルの棚卸し

転職に興味がわいたら、自分のスキルや経験を棚卸しして、「自分がやってきたこと・できること(とそれを証明するエピソード)」を整理しておいたほうがいいです。経歴については、どんな企業の面接でも絶対に聞かれます。

棚卸しをしているつもりだけど、さらに質問を受けて深掘りされた時にうまく答えられない…という人は、棚卸しが「Redmineを導入しました!」「リーダーやってました!」レベルで終わっちゃっているかと思います。

繰り返しになりますが、Redmineを導入したとか、肩書としてリーダーをやっていたとか、それだけで評価が上がるわけではありません。重要なのは「具体的にどんな課題があって、それに対してどういう取り組みをして、どんな結果が出たか」なので、これが言えるエピソードを準備しておいたほうがいいです。

こういうことは、頭の中だけでうんうん考えているだけではうまく思い出せません。殴り書きでよいので、一度書き出しながら整理するのがよいかと思います。

◆転職で叶えたいことと今後のビジョンについて

スキルの棚卸しをしたら、「今回の転職で叶えたいこと」「この転職を経て今後どうなっていきたいか」も、箇条書きでよいので書き出してみたほうがいいでしょう。これも面接では絶対に聞かれる部分です。

棚卸しで自分の現状レベル(before)は把握できたかと思うので、そこから今後どうなっていきたいか(after)を考えてみるといいでしょう。

afterを目指すにはbeforeの自分には何が足りないのかわかりますし、「その足りない部分を伸ばせそうかどうか」というのが企業選びの軸にもなります。

◆勉強した内容のアウトプット

繰り返しになりますが、「勉強してます」とか「本読んでます」とか、言うだけなら誰でもできます。そしていくら「やってます」と言っても、聞かれたことに答えられない、やったことをうまく説明できない、アウトプットの証拠もないという状態では、何もやっていないのと同じです。

多分、口下手とかコミュニケーションが苦手だとかの自覚がある人ほど、見せられるアウトプットはあったほうがいいかと思います。一から十まで説明するより、アウトプットを見てもらったうえで質問を受けたり説明するほうがずっと楽だと思います。

GitHub、Qiita、技術ブログ、ポートフォリオなどが用意できるといいですね(これ全部じゃなくてもよいです)。paizaプロフィール欄でも、制作物・ポートフォリオ・GitHubアカウントなどが設定できるようになっています。

また現在「paizaラーニング」では、ふだん有料公開している「Webアプリ開発入門 Rails編」「ITエンジニアの就活準備編2: ポートフォリオ制作」を、毎週期間限定で連続無料公開しています。

何度も言いますが「やってます」だけなら誰でも言えるので、チュートリアルレベルでも、「ちゃんとやっているのがわかる人」と「本当にやってるのかやってないのかよくわかんない人」では印象が全然違います。アウトプットのレベル感だけじゃなくて、自分でちゃんとやってる人は入社後のキャッチアップも早そうに感じますから好印象です。

■まとめ

いろいろ書いてきましたが、こういう採用条件や重視するポイントというのは、企業のいるステージや規模、作っているサービスなどによって異なります。弊社は今はこんな感じで採用選考をしていますが、開発チームの規模やサービス内容が広がってきたらまた変わってくるかもしれません。

そして、これを読んで「この会社、全然合わないな」と思った人もいるかと思います。それはそれでいいことでして、採用選考においては「合わない企業をちゃんと見極める」のは、志望度が高い企業の選考を通過するのと同じくらい重要なのです。入社後に「思ってたのと違った…」ってなってしまうと、お互いにとって本当に不幸ですから。

paizaにはいろいろな企業のエンジニア求人が公開されていますので、ぜひ見てみてください。

そしてそしてギノは現在もエンジニアの方を絶賛募集中ですので、もし興味を持ってくれた方がいらしたら、ぜひご応募ください↓
【Webエンジニア】Railsによる大規模Webサービスの開発に興味のある方!

眼鏡率が高杉




paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

詳しくはこちら
paiza転職


まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。

詳しくはこちら
paizaのスキルチェック

paizaのおすすめコンテンツ

Webセキュリティ入門 ハッカー入門 Webセキュリティ講座がスタート!CVは内田真礼さん! Python✕AI 機械学習入門講座 CVに上坂すみれさんを起用!人気の機械学習講座を公開中!
paiza転職 paiza新卒 EN:TRY paizaラーニング 記事内に記載している情報は、記事公開時点でのものとなります。 Copyright Paiza, Inc, All rights reserved.