はじめに
私はエンジニア未経験から受託企業に転職します(24年1月から就業)
そこで、これまでの面接でよく聞かれた質問について振り返るにあたって、各質問にはどのような意図やポイントがあったのか整理していきたいと思います
構成としては意識したポイント、
避けたポイント、私の回答例という形になります！
回答例について
- 簡潔にできるところはなるべく簡潔にしてます
- (実際の面接で自分の話が長くなりすぎないように)
- 深掘りされたら具体的に話せるように準備しているのが前提となります
本記事はあくまで参考程度に留めてください
- 採用経験のある方の意見も参考にしましたが私の考えです
- (GPT4で内容がおかしくないかは確認しました
) - 同じ質問内容でも採用担当によって見るポイントの個人差があります
- 結局のところ採用は相性なので回答に正解はありません
定番の質問リスト
◆プログラミング関連
プログラミングの意欲や将来的な適性を測っていると思います
プログラミングを学んでみてどうか？
意識したポイント
- 実務についた後もプログラミングを楽しめそうか
- 真剣に取り組めそうか
エンジニアとして仕事するにはプログラミングとずっと付き合っていくはずです。
そのプログラミングに対してのイメージを聞くことで、
プログラミングとずっと付き合っていけそうか、成長できそうか見られると思います。
避けたこと
- 「辛かった」や「難しくて苦手」などネガティブな表現だけ残すこと
ネガティブな表現だけ残すと入社後に挫折して
退職されてしまう懸念があると思います。
♣私の回答例
新しく何かやるたびに濁流のようにエラーに押し寄せてくるので、
正直なところつらい部分が多かったです。
なぜかというと、なんでエラーになったか分からず、
論理的に物事を進められない場面が多いからです。
状況としては何か実装できた時につかの間の大きな喜びがきても、
また次の作業で再びのエラーの波が押し寄せてくる次第です。
しかしながら、楽しみの割合が増えていくことを確信しています。
現在は知識面の中でパズルのピースを一つずつ集めている状況ですが、
それらを組み合わせた発想で実装する機会に私は大きく楽しさと喜びを感じて、
それは普段の学びとともに加速度的に増えていくはずだと思います。
なので、スタート地点が辛い中でも諦めず根気強く学びを積み重ねていけば、
右肩上がりに楽しさは増していくのではと感じています。
プログラミングを始めたきっかけは？
意識したポイント
- プログラミングに対しての興味の深さ
- プログラミングを通して何を成し遂げたいか
始めたキッカケは結構人によって、バラバラで価値観が見えます。
単純に楽しそうからでという人もいれば、
システム導入で業務改善された場面を見て
自分もそのような形で貢献したいと興味を持つ人もいます。
稼げそうだからとか、あからさまに外的な要因でなければ
正直に話すのがよいと思われます！
避けたこと
- プログラミングに対する情熱や興味が少しも感じられない
- 「理由はないけど、なんとなく始めた」というような非常に曖昧
先程の質問と被りますが、プログラミングを始めたキッカケはいわば
その人の原点であり初心です。
そのバックボーンが弱いとプログラミングで挫折が起きたら、
すぐに心が折れてしまう懸念が出てくると思われます。
♣私の回答例
エピソードとしての大きなキッカケがあったわけではないでが、
仕組みづくりというものに興味を持ち始め、
そこに自分も携わりたいと思うようになり、現在に至ります。
社会人になってからシステムに触れる機会、
またはシステムを使わないことの不便さの両方を体感したという点と、
営業活動のように既存のプロダクトを提供するために動くのではなく、
プロダクト自身を自分が考えて作ることに興味を湧きました。
これまでのプログラミング学習で、出来るようになったことや成長した点は何か?
意識したポイント
- 自分の口からしっかり話せるようにする
ポートフォリオを見れば本人のスキル感というのは分かると思いますが、
正直なところ企業側は一人一人じっくり見る暇がないとよく聞きます。
なので、口頭でも話せる必要があると思います。
避けたこと
- 実際のスキルや経験より誇張して話す
- 「いろいろなことを学びました」というような曖昧な回答
当たり前の話ですが嘘をつくのはやめましょう。
技術質問に派生しやすい質問なので、その後でどうせすぐにバレます。
学習による進歩が全く見えない説明も一気に不安になることが予想されるので、
自分が何をできるようになったか必ず振り返るようにするとよいと思います。
♣私の回答例
- エラーへの恐怖が薄れて冷静に対応できるようになってきた
- 自分の疑問点を整理できて調べられるようになった
- 一見無理だと思っても、やってみれば出来ることがあるということを知れた
プログラミング学習は普段どのように行っている？
意識したポイント
- 自走力があるか
- プログラミングの将来的な適性
学習方法というのはいわゆる成長速度です。
書籍やドキュメントを見たりなど体系的に学習している様子があれば、
エンジニアとして成長していけそうだなと安心できると思います。
避けたこと
- 学習方法の具体性が全く感じられない
- 答えを全てChatGPTに聞いている
プログラミングは実装の前に土台となる理解がないと、
保守性に欠けたりなどで現場では通用しません。
体系的な理解に努めない姿勢であるとエンジニアとしてのポテンシャルを感じないと思われます。
♣私の回答例
書籍やUdemyの教材をベースに学習を進めています。
書籍でも分からないときはググったり、
同じようなエラーになっていることがないかQiitaの記事を見ています。
そして、それでも分からなければリファレンスやドキュメントに目を通して、
もう一度、原理原則のところから考え直したりなどしています。
本当にどうしようもなくなってきたら、
実装したいこと、エラー等の仮説や状況を整理してから人に聞いています。
～～って何？というような座学的な学習については
ChatGPTと壁打ちして落とし込もうとすることが多いです。
なぜ、その技術を使おう(学習しよう)と思ったのか？
意識したポイント
- 論理的思考能力を問いている
- 目的意識を持って行動できているか
エンジニアに限らず目的意識をもって行動することは
仕事をするうえでかなり大切です。
目的意識が感じられると、能動的に動いて将来的に成果を出してくれると
期待をすることができると思われます。
避けたこと
- なんとなく学習した
- スクールのカリキュラムだから
全く考えもなしに行動している様子が見られると
機能を実装する際にも何事も常になんとなくで動いてしまうことを連想してしまいます。
これでは受動的な人間の印象があり、大きなアウトプットは期待できないと思います。
♣私の回答例
Rails(Ruby)については大きく2点あります。
1つめはエンドユーザーと距離が近くなりがちな
自社開発や受託開発で採用されてることが多いということ
(顧客の要件に迅速に対応することや、短いサイクルでのフィードバック取得・反映が重要なので)。
2つめは開発速度が速く、短期間でのプロダクト完成が可能であり、
個人開発に向いているためです
(「DRY」（繰り返しを避ける）や「CoC」（設定より規約を重視する）等の原則に基づいている)
将来つくりたいプロダクトは何か？
意識したポイント
- エンジニアとしてのシステムに対する価値観やビジョン
- 技術的にどんな分野に興味があるか
- 顧客や社会にどのような価値を提供したいか
これも人によって結構別れているのではないかと思います。
開発に興味を持っていたら少なからず何かしら
絶対に開発したいものがあるはずです。
特に正解は無く、楽しい話題でもあると思うので
よりリラックスして話していきましょう
避けたこと
- 作りたいものが無い
- 面接先の企業のビジョンや事業内容と大きくかけ離れている
- (特に自社開発は要注意！！)
作りたいものが無いと熱意は感じません。
そして、基本的には正直に回答することをオススメするのですが、
企業のビジョンや事業内容からあまりに離れてしまうと
エンジニアとしての魅力以前に自社とは合わなそうな人材の印象を
持たれてしまい非常に勿体ないので、そこだけ注意しましよう。
♣私の回答例
(※面接先によって内容は変えます)
私が個人的に開発したいものという話ですと、
自己成長に助けになるようなアプリを開発したいと思っています。
勉強や読書、運動などの自己研鑽の行動をしたときに、
それを記録して、経験値を得てレベルアップに
向かっている感を可視化できるものを作りたいと思っています。
そのアプリにゲーミフィケーションの要素を入れて、
ドラクエやパワプロの育成ゲームをやるような感覚で日々の自己研鑽に
向かっていけるアプリを作成してみたいと思っています。
◆現職・前職関連
エンジニア以前に一人のビジネスマン(人間)としてどうか見られていると思います
現職 or 前職の入社理由は？
意識したポイント
- 企業に求める要素や価値観を見られている
- 自社(面接先)に対して求めていることを間接的に見られている
やりたい業務内容とかは変わるかと思いますが、
働き方や企業に対して求めるものは特別に大きな出来事が無い限り、
簡単に変わらなかったりします。
ですので、現職や前職での入社理由は自社にも
求めてくることだと無意識に判断します。
面接先の企業と一致する要素を答えたほうがマッチ度が高いと
思われるのでオススメです！
もし、その求めるものが過去からガラッと変わった場合は、
質問を待つ前に自分から言っておくとよいと思います
避けたこと
- 収入や福利厚生など外的な要因
- (決して悪いわけではないですが、それ相応の理由が求められます)
- 曖昧な回答やハッキリとした理由がない(なんとなく等)
- 他に選択肢が無かったなどの否定的な理由
正直なところ、実態として入社理由は何となくで決めるケースも
結構ありがちなので後付けや回答のお化粧が求められやすいと思います。
あくまで過去形になるので正直に答えるのも一つの手ですが、
その場合は相応の理由を言ったり、これからの肯定的な姿勢を見せるなどの
カバーが必須となると思います。
♣私の回答例
若くして所長になっているケースもあるなどで
実力主義を採用していると思ったことと、
法人営業ということで1社と強い信頼関係をじっくり築いていくような、
営業スタイルができると思っていたからです。
現職 or 前職の退社理由は？
意識したポイント
- 他責思考ではないか
- 自社(面接先)に入ってもすぐ辞めなそうな人材であるか
理想としてはキャリアチェンジなどの目的を持った退職です。
その職場で何を学び、今後どのようなキャリアや成長を求めているか答えられると
非常にキレイな回答となると思います！
避けたこと
- 単なる批判や愚痴
- 失敗を全て環境や他人のせいにしてしまう
正直なところ、良いところを見つけるのが難しいブラック企業も存在します。
そのような企業の退職理由だとポジティブなものにはなりにくいと思います。
しかしながら、厳しいようですがミスマッチは自身の就職活動時の
リサーチ不足等による要因も結構大きかったりします(私がそうでした)。
就職活動時やその企業で働いていた時に自分が何ができたか
必ず考えて他責思考な回答だけは絶対にやめるようにと
知り合いのエージェントには口酸っぱく言われました。
♣私の回答例
当時の私の就職活動の拙さから結果的に
入社前に想定していたこととギャップを感じたからです。
(いわゆるミスマッチ)
それは個人の実力や創意工夫の要素が比較的、少ないことや
評価制度において抽象的な部分があると入社後に感じました。
そして、よっぽど突き抜けた数字がないと
新規開拓へのプレッシャーが強く、1社あたりに割けるリソースが少なかったり、
構造上の問題から1社と深い関係を築いてこれた人は
現実としてかなり限られていたこともギャップがあり退社に至りました。
仕事をする際に工夫していた点は(現職 or 前職で)？
意識したポイント
一人のビジネスマンとしての力を見られていること
エンジニアは確かに専門職に分類はされますが、
スペシャリストであろうとコミュニケーションが大切だったり、
他の仕事とも共通する部分は多いです。
ですので、単純に仕事をうまく進んでいけそうか見られています。
これはイメージしやすいように具体的であれば具体的であるほど良いので、
しっかり前もって振り返っておくといいと思います
避けたこと
- 曖昧な回答
- (周りとうまくコミュニケーションをとれるように意識した等)
- 工夫した点がエンジニアの業務に活きる余地がない
至極当たり前ですが、大前提としてエンジニアとして活躍できそうか見られています。
ですので、曖昧な回答では仕事を進める能力を計れません。
また、あまりないケースだと思いますが、もし工夫していた点があっても、
それがエンジニアの業務に活きるものでなかったら成果を出せる見込みが
薄い印象になると思うので他の工夫した点を考えましょう。
♣私の回答例
認識のズレを発生させないためにも
コミュニケーションの手間は極力惜しまないことです。
そのコミュニケーションを取る際には
自分の不明点を前もって言語化することと、
相手の発言にどのような背景があるのか、
なるべく伺うようにしていることを普段から意識してます。
◆人間性やキャリアプラン関連
全体的に単純なマッチ度を測っていると思われます
あなたの強み or 弱みは？
意識したポイント
- 単純に自分自身のことについて知りたがっている
- 自己認識と自己分析の能力があるか計られている
ド定番の質問ですが、その人自身について知りたがっています。
そして、自己認識や自己分析の能力はエンジニア以前に
社会人の基礎的な能力なので高いに越したことはありません。
強みは企業目線で自社で活かせそうか、
弱みは自社で致命的になるか見られていると思います。
強みは弱みは一つだけではないと思うので、
強みの場合はエンジニアとしての働き方に存分に活きるか、
その企業で活かせるものであるものをピックアップしましょう！
避けたこと
- 具体例が無い一般的な回答
- (単に「コミュニケーション能力が強みです」と言う等)
- 面接先の企業の業務であまりにも致命的になってしまう弱みを言う
- 強みが業務との関連性が低い
強みと弱みというのは業務内容によって少なからず相性があります。
その人の弱みが特定の業務にはさほど影響が無かったり、
逆に強みがあまり活きないこともあります。
例えば、人から言われたことを機械のように正確にこなせる強みが
創造性が強く求められる芸術家やYouTuberのような職業とは相性が悪いです。
具体例を用意した上で、その強みや弱みと業務の相性がどうか
考えておくとよいと思います。
♣私の回答例
主に強みは2つあると思っていまして、
【忍耐力】と 【質問力】があると思っています。
忍耐力に関しては、
先程軽く触れた通りで新聞配達と
受験生活の両立に現れたのではないと思っています。
朝刊と夕刊の配達の業務をこなしながら、
1日4時間半の睡眠をとる受験生活の日々を送りながら、
現役の時に落ちた大学に受かることができました。
なので目指すものを決めた時にやり遂げるまでの忍耐があると思います。
質問力に関しては、徐々に磨かれてきたと思います。
これは大きなエピソードがあるというより日々役に立っている次第です。
業務でのチャットでのコミュニケーションも含めて、
何が分かっていないか等をちゃんとした言語化を意識して、
モヤモヤしたことなどは基本的に解決できており、
プライベートでも人と距離を縮めるのに役立っています。
弱みとしては行動する前に考えすぎてしまって、行動までが重いことがあります。
例えば、会話一つとっても、こんなニュアンスの言葉だと
相手にストレスを与えてしまうかな？
とか考えすぎてしまい何か言いたいことがあっても
結果的に言わずにいたりすることがあります。
行動をする前に根拠や理論を固めることに
注力しすぎてしまうのが仇となることがあるのが弱みです。
ですので、行動をしないリスクを考えるようにもしています。
転職しよう(エンジニアを目指そう)と思った経緯は？
意識したポイント
- エンジニアとしての仕事に何を求めているか
- エンジニアとしてのキャリアに対する情熱、目標、期待を見られている
単純に技術がかなり好きなのか、システム提供を通じての課題解決への関心が高いか、
これも人によってエンジニアを目指す経緯は別れてきます。
リモートで働きたいからとか稼げそうだからとか外的な要因でなければ、
正直に情熱的に話せばよいかと思われます！
避けたこと
- 短期的な利益や表面的な理由
- (「稼げそうだから」、「リモートで働きたいから」)
- エンジニア以外の一般的な仕事でも叶えられると思われるような回答
最初は将来性がありそうだから、リモートで働きたいからという理由で
プログラミングを始めたりで高尚な理由は持っていないことも多いと思います。
しかしながら、学習過程でプログラミングの楽しさや
社会貢献できそうな余地を見つけたりすることがあると思います。
それを自分の言葉で語っていきましょう。
もし、外的な要因が強くても、なぜプログラミングに固執しているのか
理由が必ずあるはずなのでそれを考えていきましょう。
プログラミングに少しも楽しさを感じておらず、
キャリアの目標がエンジニア以外の仕事で明らかに代替可能なら
プログラミング自体がわりと時間の無駄だと思われます。
♣私の回答例
これまでの生活や仕事を通して、
自分が興味あるポイントや喜ぶポイントがエンジニアの仕事を通した
ポイントとマッチしているのでは感じました。
それは主に仕組みを変えていくことです。
私は無駄を省いて、省いたリソースを
本来やりたいことに特化したがる特性があります。
例えばスポーツだったら、この練習は本当に必要なのか？
代わりに他の練習をするか、
その分休みにしたほうがいいのかと考えてしまいます。
日々の業務やプライベートでの手続き等にしても、
テクノロジーの力があって仕組みを
変えていくことが実現できていると感じます。
それは現職の会社でもツールを多く使われているので尚更強く思いました。
簡潔に述べますとそのような背景から仕組みづくりに
携わりたくエンジニアを目指しました。
どんなエンジニアになりたい？今後のキャリアプランは？
意識したポイント
- 自社の求めているポジションとマッチしそうか
- 求めているポジションを提供できるか見られている
- エンジニアとしてのキャリアにある程度の理解があるか
どんなことに興味を持っているのか聞くことで、
それを自社で実現できそうか見られています。
具体的な目標があれば、熱く語ってください！
ただ、企業の求めるポジションも関係ありますので、そこだけ注意です。
避けたこと
- 明確な目標や興味がないと感じられる曖昧な回答
- 面接先の企業の事業内容や内部事情により需要が無いと思われるポジション
エンジニアとしての全体的な仕事に理解が無いとこれは語れません。
(システム開発にはどういう業務があり、どのようなポジションがあるか)
ですので、業界知識が欠けていれば、
周りの現役エンジニアに聞いてみるなり調べるなり必ずしましょう。
そして、具体的なキャリアの目標を持っていても、
面接先の企業がそのポジションを求めていなかったり、
叶える余地が無いと厳しいと思われます。
例えば、将来のプロジェクトマネージャー候補を強く探している企業があるとすると
スペシャリストを強く目指す方とはミスマッチになると思います。
♣私の回答例
上流工程に関わっていけるようになり、ビジネス的な部分も強く、
コンサルタント的な部分もできる、エンジニアになりたいです。
なぜかというと、そもそもエンジニアを目指す理由が、
お客様の課題解決を仕組みづくりから携わっていきたい思いであるからです。
その仕組みづくりのほんの一部分というより、
より広く網羅していきたいと思っております。
プログラマーとしての面だとでコード一行書く際にも、
これはユーザーの為であるかとか考えられるようになりたいと思ってます。
ただ、一エンジニア(プログラマー)として成長して、
仮に社内のポジション等からプログラミングする
機会が少なくなることがあっても、休日等の時間を使って
技術のキャッチアップをしていきたいなと思っております。
技術力部分としては思いついたアイデアを
自分1人で実装までできるようになれるようになりたいとも思っています。
5年後にはどうなっていたい？
意識したポイント
- 長期的に活躍したい意志があるかどうか
- 成長意欲があるかどうか
- 現実的かつ具体的なキャリア観があるか
- (キャリアへの理解があるか)
先程の質問との違いは将来性を強く見ている点にあります。
そして、時系列の概念が加わると長期的に見る必要があり、
ある程度計画も考える必要があります。
そして、現実的に達成できそうな計画が
立てられているかも見られていると思います。
なりたいポジションへ到達できる一般的なペースを頭に入れた上で、
どんなポジションにどのくらいの年数で到達したいか考えていきましょう！
避けたこと
- 著しく具体性に欠ける回答
- 非現実的な目標
- (ある程度大きな企業で5年でCEOになりたいなど)
根拠も述べられないのに非現実的に見える目標を掲げていると、
キャリアへの理解が不足している or 現実的な視点を持っていないと
見なされると思います。
一般的なラインを知ってもなおハイペースな計画を考えているなら、
それ相応の達成できる根拠を整理しときましょう。
そして、企業の規模が大きければ、
すぐに役職が上がるわけではないことも頭に入れておきましょう。
♣私の回答例
5年後にはプロジェクトマネージャーとして活躍したいと思っています。
(一般的には早いが志望する企業の規模が小さいため可能)
そこでお客様のニーズを正確に汲み取り、
システム開発の成功に大きく貢献できるようになりたいと思っています。
そのために最初は一人のプログラマーとして成長して、
より早く独り立ちするために休日の時間なども使って、
技術のキャッチアップは行っていこうと思います。
そして、下流で仕事をこなせるようになり、
上流工程でも意見を出せたりとだんだんと力を発揮して、
プロジェクトマネージャーとしても
力を発揮できるように目指したいと思います。
企業を選ぶ軸は？
意識したポイント
- 求めていることを自社で提供できそうか単純なマッチ度を見られている
企業を選ぶ軸も人によって別れていると思います。
ふんだんに技術力を上げれる環境があるのか、実力主義なのか、ホント様々だと思います。
選ぶ軸もそれぞれで強弱はあれど1つだけではないと思います。
面接先の企業の強みや特徴と共通しているものをピックアップして答えていきましょう！
1つだけだと他の企業でもよいのではないかと無意識に思われるかもしれないので
2つほどピックアップして用意するのがオススメだと思います。
避けたこと
- 企業の強みや特徴と一致していないことを話してしまう
大前提ですがあまりにも一般的で曖昧な回答はアウトです。
(「良さそうな会社」など)
そして、完全無欠の企業は存在せず、各企業にも必ず強みと弱みがあります。
同じ企業でもある人にとっては働いてて幸せになれることもあれば、
ある人にとっては不幸になることもあります。
求める軸と企業の強みや特徴が一致しないと仮に働いても
お互いに不幸になることを面接官視点で感じるので、
かならず各企業に合わせた回答をするようにすると思います。
♣私の回答例
2つあります。
システム開発を通じたお客様の課題解決への姿勢が誠実であるか。
技術者としての成長を貪欲に求めた際に、
それをバックアップしていただけるような環境があるかどうか。
これらの要素がある企業さんには魅力を感じています。
◆ポートフォリオ関連
技術的な適性(成長できそうか)とサービス提供の価値観を見ています
そのプロダクトを作った理由は？
意識したポイント
- どんな課題解決をしたいのかというサービス提供の視点を見られている
システム開発はリリースして終わりではなく、提供して価値を生み出すのが真の目的です。
そこで課題解決の視点を持っているか見られていると思われます。
誰のどんな問題を解決したかったか、述べられるようにしときましょう！
避けたこと
- 完全な自己満足となるプロダクトの開発
- 実用性や利用者のニーズを全く抑えていない
恐らく相当高度で複雑な技術を用いていない限り、
ただの自己満足のプロダクトだと印象悪いです。
実務でも顧客の視点に立って開発できない方だと連想されると思います。
仮に技術的なクオリティ自体は高くても、
面接官がその技術力の高さを理解できなかったらおしまいです。
なので、もしユーザー視点があまり無かったら
後付けで無理やり考える必要があるくらい重要だと思います。
♣私の回答例
友人の課題解決の為につくりました。
自分としては何か手間を減らすようなアプリを
作成したいと思っていたところ、友人が自炊生活などを通じて
「献立を考えるのが面倒」とボヤいていたことから、
その献立を考える手助けとなるアプリを作ってみようと思いました
誰かに使ってもらった(プロダクトを)？
意識したポイント
- 実際に誰かの課題解決になっているかどうか
- 開発が単なる自己満足に留まっていないか否か
誰かの課題解決をしようとしているか意志が見られています。
必ず実際に誰かに使ってもらったほうが好印象だと思われます。
使ってみてどんな反応であったかも聞かれがちなので、
頭に入れておきましょう！
避けたこと
- 誰からも使われておらずフィードバックも受けていない
先程のことと被りますが自己満足での開発はやめましょう。
フィードバックがこわいという気持ちは分かりますが、
誰にも使ってもらっていないという事実は
顧客の課題解決への意欲が低いと見なされてしまうと思います。
♣私の回答例
主にはターゲットとなる友人に使ってもらい、
友人の感想から機能不足も感じた一面がありますが、
使いやすさの評価は頂いて、面白がって使ってくれているという
有り難い結果にはなりました。
そのプロダクトを作る上で苦労した部分は？どう乗り越えた？
ポイント
- エンジニアとしての自走力を見られている
- 問題解決能力、困難な状況における対応方法を見られている
研修でも無い限り、現場では経験が浅いからと言って
先輩が付きっきりで教えることはできません。
なので、付きっきりでなくてもある程度のアウトプットが
出せるように自走力が大事であり、それを測っていると思われます。
プロダクト作成から時間が経つと忘れる部分もあるかもしれませんが、
どのようにアプローチしたかなど具体的に話せるようにしましょう！
そうすれば正解のない難しい問題に直面しても、
解決できる人材だと期待できると思います。
避けたこと
- ChatGPTに丸投げで解決してもらった
- 全て他の人に教えてもらった
ChatGPTや他の人の力を借りるのは非常に有効なアプローチでありますが、
自分で考えて解決した様子が全く見られないのはアウトです。
それだと、もし実務で困難な問題に直面した時には
貢献できない人材だと見なされてしまうと思います。
♣私の回答例
一番苦労した点はレシピ登録において
食材データを送信する際に1つずつではなく、
入力した複数のデータを一気に送信できるようにした点です。
食材リストについては単純に「複数登録」を
キーワードに選択したことや、Qiitaの記事の情報を最初は見てました。
また、GitHubで使用していそうなメソッド等を
使用しているコードを検索したりもしました。
結果的にそっくりそのままのコードで
実装できることは無かったのでRailsガイド等を見て、
原理原則を振り返りながら試行錯誤していきました。
ユーザー視点では、複数のデータが一括で送られていても、
データ処理としては食材を一つずつ繰り返し処理していけば、
結果的に複数のデータ処理が可能になることに
気づけたのが決め手で実装できました。
今のプロダクトで改善したい部分は？
意識したポイント
- 課題解決の視点があるか見られている
- 技術的な探究心を持っているか見られている
課題解決というのは一筋縄ではいかないので、
世のアプリケーションも随時アップデートが行われています。
改善に必要とする単純な技術的な探究心も見られている一方で
課題解決の視点をかなり見られていると思われます。
なので、ユーザーの視点に立てるように誰かに使ってもらったら、
そのフィードバックを参考に改善案を考えておきましょう！
避けたこと
- 技術的な面のみに焦点を当てすぎて、ユーザーの視点を無視している
- 改善する点がないという回答
例え機能自体が高度なものを実装(追加)しても、
それが実際に役に立たず使われなければ意味がありません。
役に立たないということは利益を出せないということなので、
利益を出すための開発をしようとしない印象を受けてしまうと思われます。
改善する点がないという回答も探究心を感じられないので
アウトだと思います。
♣私の回答例
ユーザーの観点も考慮しての一番の優先順位となるのは
ページの読み込み速度の改善をすべくTurbo Driveの活用です。
Tubo Driveを使わなくても動きはしますが、
活用できるに越したことがないと思ってます。
単純な使い心地の部分を解決できたら機能面での一番の課題となる、
最初のレシピ登録に手間がかかる問題を解決すべく、
他の人のレシピ複製機能などを実装したいと考えております。
さいごに
いかかだったでしょうか？
面接官が質問をするのには必ず質問内容に意図があります！
ただ、これは個人差があれど傾向はあると思います。
そして、企業のホームページや求める人物像などを見ていけば、どのような答えをすればいいか想像もできることもあると思います。
転職活動(採用活動)はあくまでマッチングなので、魅力的な求職者が落とされてしまうケースは多々あります。
ただ、何十社も連続で落とされるようでしたら、
さすがに何かしらの原因があるはずなので改善していきましょう！
みなさんには絶対に何かしらの良い面があるので、
それを発揮できるように質問の受け答えを準備して頑張ってください