1. 会社とチームがどのような人材を必要としているかを評価する
採用には、当初の意図を明確に理解し、ソフトウェア エンジニア候補者を検討するための明確な戦略と、「まず勝ってから戦う」という明確な計画が必要です。
会社やチームはどのような技術的才能を必要としていますか? これは面接評価制度全体を構築する際の最も基本的な疑問符です。
(1) 共通の考え方:
1.勤務・残業が可能な方
この本来の意図は理解できますが、実行するのは非常に困難です。おそらくこれは一部の業界では真実ですが、ソフトウェア エンジニアリングの世界ではまったく逆です。
この見解を持つ人々は、ソフトウェア エンジニアリングの複雑な動作を単純な分業を使用して分割します。歴史上、このアプローチを試みた人が誰もいなかったわけではありませんが、ほとんどの試みは失敗したか、最終的には他のリンクのコストが非常に高くなり、そうする意味を失いました。
たとえば、ソフトウェア エンジニアリング プロセスを、要件、設計、実装、テスト、メンテナンスといういくつかのステップに単純に分割することができます。「実装」リンクの人員要件を下げ、それに応じて品質要件も下げると、バランスをとるために他のリンクにさらに人員を投入する必要があり、最終的に研究開発コストは大幅には改善されませんが、改善されています。実装プロセスには、将来のメンテナンスや拡張に落とし穴を生み出す貧弱なコード設計など、隠れた危険が潜んでいます。
そのようなバランスとは、より詳細な設計文書を完成させるためにより多くの時間を費やすことかもしれないし、より多くのテストスタッフを追加してより包括的なテストを実行することかもしれないし、バージョンの試用期間やバグ修正にもっと長い時間を費やすことかもしれないし、あるいは採用担当者をより専念させることかもしれない。マネージャーは、これらのプログラマーがプロセスを厳格に遵守しているかどうかを監視する必要があります。
このような考えで採用したわけではありませんが、客観的な理由から初心者の方が多い採用となりました。そしてベテランには教える能力がないので、新人に教えることを強制するとベテランの悪い習慣が汚染されてしまいます。チームもこのジレンマに陥っている。人を育てるのとチームを育てるのとでは、難しさには大きな違いがあります。したがって、私は初心者にもっと多くのエネルギー、つまり管理コストと教育コストを注ぎたいと考えています。
率直に言うと、ソフトウェア エンジニアリングの他の側面でより多くの作業を行い、不十分な実装側面の費用を支払うことを意味します。
2.「アルゴリズムが良い」
ソフトウェア エンジニアとの面接として始まりましたが、結果を確認するための質疑応答の会議になりました。
理由はとても簡単で、4つの言葉でまとめると「ある部分から他の部分まで一般化するため」です。
ソフトウェア エンジニアリングは多次元で複雑な動作であり、コード実装はその一部にすぎず、アルゴリズムもコード実装の一部にすぎません。実際、単純なアルゴリズムの専門家と本物のソフトウェア エンジニアの間には、依然として大きな隔たりがあります。
3.「すごい」
「優秀な人材」を「優れた技術力を持った人材」と理解すると、本当にチームにはあらゆる人材が必要なのでしょうか？私はそうではないと思いますが、チームには「優秀な人材」よりも「適切な人材」が必要です。
技術的な観点から始めましょう。理想的なチームには、技術的にある程度の補完性が必要です。たとえば、フルスタックのチームでは、システムの最下層が得意なメンバー、Web アプリケーションが得意なメンバー、厳密なシステム思考を持つメンバー、製品に対する鋭い直感を持つメンバーがいます。問題の場所に応じて、チームの意思決定は、互いの強みから学ぶことで一定のバランスに達することができます。
非技術的な観点から見てみましょう。たとえ候補者が技術的なレベルで非の打ち所がないとしても、考慮すべき非技術的な要素はまだたくさんあります。候補者が個人的な非技術的なレベルで非の打ちどころのないとしても、候補者とチームのスタイルとの適合性を考慮する必要があります。 。例えば、テクノロジーに特に優れている人の中には、個性が際立っていたり、付き合いにくい人もいます。そのような候補者に対してイエスかノーと言うべきでしょうか?
これには、会社の文化とチームの受け入れが関係します。チームが「とげのある頭」でいっぱいで、意見が激しく衝突する場合、これは間違いなく悪い状況になるのは明らかです。監督は毎日対立を解決するのに忙しいでしょうし、チームが満員の場合は、 「とげのある頭」の場合、「良い人」は賞賛と意見の認識しかありませんが、意見の欠如は決定権の欠如を意味することが多いため、これは実際には憂慮すべき状況です。
4. 賢くて可能性がある」
会社であってもチームであっても、経験豊富なエンジニアと潜在的なエンジニアの構成には一定のバランスが必要です。
技術が比較的成熟しており、体制が安定し、プロセスがしっかりしているチームもあり、経験豊富なエンジニアがある程度の時間をかけて新人を指導し成長させ、チームとしてのバックボーンを育てていくことができるチームです。最善を尽くす。
一方で、その逆のチーム、特に起業家チームや製品立ち上げチームなどは、全員が主導的な役割を果たさなければならず、全員が火消しに忙しい場合もあります。強力な自己管理能力、総合的な資質と経験を備えた退役軍人、そのような候補者は現時点では適していません。
当社の開発チームは 2 番目のカテゴリーに属しており、この状況を早急に変える必要があります。
(2) 探査角度
会社やチームはどのような技術的才能を必要としていますか? つまり、面接を踏まえて、どのような角度から人材を吟味し、選考すればよいのでしょうか？ソフトウェアエンジニア候補者選考の次元をマクロな視点から把握するにはどうすればよいでしょうか?
1. よく使われる角度
よく使われる視点は、優秀なソフトウェアエンジニアの共通かつ客観的な理解です。
(1) 技術レベル
技術レベルでは、ソフトウェアエンジニアの基本的なスキルを検討する必要があります。実践的な問題解決能力、コード設計と実装能力、システム分析と設計能力、テストと検証能力が含まれます。
a. 実践的な問題解決能力
私は、面接でより単純なアルゴリズムとデータ構造の質問を使用することに同意しません。調査的ではないということではありませんが、対象範囲が狭すぎるということです。具体的には、典型的な実際的な問題の解決策には、次の 2 つの部分が必要です。
- 1.特定の問題をいくつかの解決可能なソフトウェア問題に抽象化します。
- 2. ソフトウェア エンジニアリングの知識とスキルを使用して、これらの問題を解決します。
純粋なアルゴリズムとデータ構造の問題は、上記の 2 つの点のうち 2 番目の点を解決できるだけでなく、この 2 番目の点はコーディング レベル、またはその範囲が狭いことを示す数学レベルにさえ該当する問題である必要があります。面接で良い質問とはどのような質問なのかというと。
b. コード設計および実装機能
これはソフトウェア エンジニアの基本的なスキルです。単純なアルゴリズムやデータ構造よりもはるかに広い範囲をカバーします。たとえば、一部の企業が特に検討することを好むオブジェクト指向のスキルは、このカテゴリに分類されます。
c. システム分析および設計機能
問題に対して合理的なシステム見積もり、アーキテクチャ設計などができるかどうかも含みます。この部分は経験と密接に関係しています。
一般的に、豊富な実務経験とは、一定のシステム分析および設計能力を意味します。
ここで言う「システム」とは、一般に「分散システム」ではなく「ソフトウェアシステム」を指します。
今日のインターネットの波は、「分散」などのホットワードの過剰な追求など、技術者にも悪影響を及ぼしています。システムというと、ビッグデータ、大容量、高スループットを意味するようで、単純なシステムを軽視するようなこともあるのですが、これは非常に不適切ではないかと思います。
このシステムを理解するには、数学の基礎が初等算数であるのと同じように、やはりしっかりとした基礎を築く必要があります。
d.その他総合エンジニアリング力
テストや検証機能など。重要ではないというわけでも、試験しないわけでもありませんが、面接ではソフトウェアエンジニアの技術試験に重点を置くべきです。たとえば、技術検査時間の 20% のみをこの部分に費やすことに同意するだけです。
コンピューターの基本知識テストはどこで行われますか? 実は上記の検査項目に含まれております。
たとえば、Web サイト システムを設計するには、ネットワーク プロトコル、特に HTTP プロトコルの基本的な理解、ミドルウェアとコンテナーの基本的な知識、およびデータベースの基本的な理解が必要です。
(2) 非技術レベル
エンジニアの基本的な性格、チームワーク能力、学習能力、コミュニケーション能力、タスク管理能力など を重視します。
たとえば、面接中に候補者とのコミュニケーションに大きな問題があることがわかった場合、それに気づくのは仕方のないことであり、コミュニケーション能力を「具体的に」試すような質問をわざわざする必要はありません。
要約すると、ソフトウェア エンジニア候補者の場合、面接ラウンドではその大部分が技術面接の形式でカバーされるようにする必要がありますが、非技術面接の形式で少数の面接が許可されることになります (たとえば、4 ラウンドの面接)。 5 ラウンドのうち技術面接、1 ラウンドの非技術面接）。ただし、技術面談の各ラウンドから得られるデータは両方をカバーする必要があります。
社会に出たばかりのエンジニアにとって、提案を聞いて考えることができるか、興味や熱意があるかといったポテンシャルに関わる資質は、学べないものなのでより重視すべきです。
豊富な経験を持つエンジニアの場合、ビジョン、技術的理解の深さ、プロフェッショナリズムにさらに注意を払う必要があります。
2.他の角度
これは、ソフトウェア エンジニア候補者に異なる要件を持つ、さまざまなチームと細分化されたポジションを指します。
たとえば、技術レベルでは、一部のポジションではフロントエンドのスキルが必要で、一部のポジションでは AI のバックグラウンドが必要で、一部のチームではクラウド コンピューティングでの実務経験が必要です。
非技術レベルでは、多くの大企業がいくつかの具体的な指針を設定しており、これらの原則は、候補者の非技術部分を評価するプロセスをガイドするプログラムのようなものです。たとえば、Amazon のリーダーシップ原則についてはここ数年多くの人が議論しており、Amazon での面接では毎回、そのうちの 1 つまたは 2 つを取り上げることが求められています。
細分化された特定のポジションのスキル要件がより詳細かつ明確である場合でも、大企業の面接では、共通の角度の割合がより大きいことがよくあります。
ポジションを細分化し、要件を具体化するほど候補者のマッチングが向上するのは明らかですが、それは人材選考の普遍性を低下させ、採用を非常に困難にすることにもなります。そのため、こうした大手企業は採用基準が曖昧で、採用後にさらに研修を行うことを選択しています。これは意図的なものであると同時に、無力なものでもあります。
面接の「共通の角度」の部分で優れた成績を収めたソフトウェア エンジニアは、一般的な意味で優れたソフトウェア エンジニアである可能性が高くなります。たとえ特定のポジションで特定のスキルをすぐに備えていなかったとしても、短期間の入社後には、勉強して馴染んでいるので、すぐにその役割を果たせる可能性も高いでしょう。
どのような企業やチームであっても、「良い人材」を採用するのではなく、「適切な人材」を採用することが重要であり、単なる費用対効果ではなく、候補者とともに勝利することが最大の目標です。
2. 面接計画を立てる
(1) 計画分析
まず、チームのニーズと制約を理解し、合理的な期待を設定します。私たちは間違った人材を採用したくありませんが、優秀で適切な人材を逃すことも望んでいません。
私たちが明確にする必要があるのは、時間と人件費への適切な投資と、検査角度の合理的な範囲は、この 2 つはまったく別のものであり、不可欠なことであるということです。私たちが達成したい効果は、面接チームが十分な投資を通じて、特定の角度からの取材を過度に繰り返すことなく、候補者の評価に役立つより包括的なデータを取得できることです。
プロセスが正しく、データが十分であれば、妥当な結果が得られます。
第三に、検査角度、検査焦点、検査内容も一貫性の原則に従わなければなりません。
最後に、検査ラウンドは段階的に行う必要があります。
チームのニーズと調査の観点を理解し、候補者と計画を整理すると、実際の面接ラウンドは正式に始まっていませんが、すでに戦いは半分です。
(2) 電話面接及び現地面接
電話面接の最大の役割は、明らかに信頼できない人を比較的少ないコストで「ふるい落とす」ことだ。
プランでは電話面談の回数は通常1～2回と少なく、最も気になる内容は電話面談でカバーできるはずです。電話面接での意思決定は非常に早く、電話面接の面接官同士が直接会って面接を通過し、採用担当者が大きな問題がないと判断した場合にはそのまま現場面接に進むことができます。
電話面接に合格するかどうか迷っている場合は、候補者が少なくとも 1 回の現場面接に適切に合格できると思いますか? 可能であれば、電話面接を受けてください。
非技術的な観点からは、相手が明確な要件を持っているかどうか、そしてそれがチームが提供できるものと一致しているかどうかに焦点を当てる必要があります。たとえば、このポジションで海外出張が必要であり、候補者がこれを受け入れることができない場合は、全員の時間を節約するために、電話面接の前または事前にその旨を明確に伝える必要があります。
(3) 新卒者とベテラン
新卒とベテランは真逆のタイプの候補者であり、試験の焦点も異なります。
経験の浅いエンジニアの場合、私たちは可能性をより重視します。
経験豊富なエンジニアにとって、私たちが重視するのはシステム設計能力の要件からもわかるように、能力です。
1. 新卒採用面接：
- 一般的に、新卒採用やキャンパス採用の場合、時間の投資は適切に削減できます。
- システムのアーキテクチャと設計が主な試験内容であってはなりません。システムを理解するには、時間と経験を徐々に蓄積する必要があります。
- 工学的な理解に関する試験を減らします。新卒者のプロジェクト管理とタスク管理の理解を調べると、上記と同じ理由で、ソフトウェア エンジニアリングの理解はほとんど重要ではないことがよくあります。
- 興味・関心、熱意、学習能力、意見を受け入れる力などの「潜在的資質」の割合を高める。一言で言えば、彼はチームの助けで急速に成長し、すぐに上級エンジニアに昇進できると思いますか?
- 捜査の観点によれば、比較的明確かつ具体的な要求を与えることができる。
2.ソーシャル採用面接：
- システムのアーキテクチャと設計が調査の焦点になる可能性があります
- 思考力やアイデアが豊かかどうかをテストするために、質問は曖昧でも構いません
3. 問題設計
(1) 悪い技術的問題
1. 知識ベースの質問。エンジニアの核となる能力ではなく、知識と記憶をテストします。時間をかけて調べるのには不向きです。それは一方では普遍的ではなく、他方ではあまりにもランダムだからです。
普遍性の欠如は、候補者が特定のフレームワークやライブラリを理解する必要があることを意味しますが、優秀な候補者が異なる知識背景を持っていることを考慮すると、この要件はあまりにも恣意的すぎます。
ランダム性が強すぎるとは、受験者がこの知識ポイントを知っているかどうかを指します。ランダム性が強すぎるため、受験者のスキル レベルが反映されません。
特定のプログラミング言語、フレームワーク、ライブラリに限定される問題がいくつかありますが、その 1 つが問題です。
「atoi アルゴリズムを C++ で実装してください。」
この質問は、チームが候補者に C++ スキルを要求している場合には問題ありませんが、ほとんどのチームではそうではないため、この質問は、通常 Java をメインのプログラミング言語として使用する候補者にとっては不公平です。このため、多くの大手企業は、面接プロセスのトレーニングにおいて、候補者が使用するプログラミング言語を制限しないという基本原則を設けています。
2. よくある質問
何度も使用された質問は候補者によって準備された可能性が高く、捜査の信頼性が大幅に低下します。正直な候補者は、私がこの質問をしたと言うでしょうが、すべての候補者がこれを行うことを期待することはできません。
それどころか、私たちはまさに「新しい」質問を通じて候補者の「古い」能力を調べたいと考えています。問題は常に変化するが、ルーチンは永遠であると言われるのはこのためです。
3. 複雑すぎるルールの問題
複雑な問題を単純化するアプローチは、検査項目と密接に関係しています。
そして、実際に解決したい問題や業務シナリオとはかけ離れており、ビジネスの内容も技術的な内容も含まれておらず、技術面談としての価値は実は非常に低いのです。たとえば、いくつかの頭の体操です。
(2) 技術的課題に対する設計原則
1. 検査角度と焦点を一致させる
面接計画と面接の目的に焦点を当てることで、面接後の意思決定に役立つ効果的な調査データを取得できます。
たとえば、面接官は「実際的な問題の解決とシステムの理解」に重点を置いて候補者との面接を行いたいと考えています。そこで同氏は「オンライン配車システムの設計」を主な質問とし、面接中に候補者と話し合うことにした。したがって、ここから、面接官は次の 2 つの重要なポイントを把握する必要があることが大まかにわかります。
- 実践的な問題を解決する：面接官は実践的な問題を与え、候補者が徐々にエンジニアのスキルに合格し、この「オンライン配車」（実際の配車サービスである滴滴タクシーなど）の中核となる実践的な問題を解決できるかどうかに注目するつもりです。システム) の部分をソフトウェアの問題に単純化および抽象化し、解決します。
- システムの理解: 面接官は候補者と要件を話し合った後、それを実装するためのソフトウェア システムの設計を候補者に依頼する予定であり、このプロセスでは、候補者がシステム設計スキルを持っているかどうか、および問題を解決できるかどうかに焦点が当てられます。問題の特徴に応じて問題を解決し、適切なテクノロジーを選択します。
2. 曖昧なものから明確なものへ、実用的なものから抽象的なものへ
曖昧さから明確さへ移行するのは理解できますが、現実から抽象化へ移行するとはどういう意味でしょうか? 抽象的なものから実践的なものまでではないでしょうか？実践してこそ実現できる！
ソフトウェアエンジニアはエンジニアリングを行うことを目的としており、エンジニアリングとは本質的には実際的な問題を解決することです。
曖昧さから明確さへ、そして現実から抽象化へ、それらは 2 つのプロセスのように見えますが、実際にはまったく同じです。
実際の問題は曖昧なことが多く、顧客からの苦情、ユーザーからの提案、または不明瞭な問題点から発生する場合があります。
ソフトウェアのアプローチで解決できる問題は明確かつ単純でなければならない ソフトウェアの設計者自身でも要件やロジックを明確に説明できなければ実装は不可能である 明確に説明できるため、この記述は簡略化されている必要がある抽象化して細部を取り除き、問題の核心だけを保持します。
したがって、ソフトウェアで解決できるのは特定の問題の核心部分の一部だけであり、残りのほとんどは補助としてしか使用できません。この原則は実際には「深さ」について語っています。
面接官は候補者に次のような技術的な質問をしました。
“请你设计一个网约车系统。”受験者の中には、問題を理解した後、「何から始めればいいの?」と途方に暮れる人もいるでしょう。はい、この問題は非常に大きいように思えますが、エンジニアが解決しなければならない実践的な問題でもあり、多くの場合、漠然とした実践的な問題です。 。
私たちは、候補者と協力して、曖昧なものから明確なものへ、実用的なものから抽象的なものへ、そのような変換プロセスを作成したいと考えています。システム設計の検査パスを例として考えてみましょう。
- 曖昧な発言に基づいて、私たちが解決したい中心的な問題は何ですか? オンライン配車システムは非常に大きなものですが、解決すべき問題の中で、私たちが最も懸念しているのはどのような問題でしょうか?
- 私たちが特定した最大の懸念事項に基づいて、関連する機能要件と非機能要件をリストします。要件は数多くある可能性がありますが、私たちの目標は、面接時間中に重要なものを特定することです。
- クライアント、ネットワーク、サービス、ストレージなどのすべてのレイヤーを含む、ニーズに応じてシステムを設計します。大まかな計画を立てた後、その中から最も懸念される部分を選択して議論することが目標です。
- それでもコード レベルを調べたい場合は、上記の設計から特定のコンポーネントまたはメカニズムを選択して、コード レベルの設計について話し合います。
- コードレベルの設計に応じて、コアロジックやコアデータ構造などの実装を要求するなど、実装を選択できます。
このことからわかるように、全体のアイデアは次のとおりです。
問題 > 要件 > システム設計 > コード設計 > コード実装
操作性を考慮して、ステップが進むごとに範囲が狭まり、さまざまなレベルで候補者のスキルが詳しく検査されます。複数の調査角度、複数のソリューション。
「複数の調査角度」とは、最初は同様の曖昧な説明を指しますが、面接計画の取り決めに従って、徐々に特定の調査角度に誘導することができます。この原則は実際には「幅」について語っています。
検査の焦点がデータ構造とアルゴリズムを調べるパスを取る必要がある場合は、開始点から終了点までの単純なパスファインディング アルゴリズムをコードに実装するなど、それも可能です。オブジェクト指向設計検査のパスと設計の主要なユースケース、関係するクラス (その構造と関係など)
「複数の解決策」とは、下位レベルでは、上記の特定の質問に絞り込んだ後、回答が一意ではなく、複数の異なる方法が存在する必要があることを意味します。たとえば、経路探索アルゴリズムの問題の場合、ブルート フォース バックトラッキングを使用して解決できる場合もあれば、最適化された動的プログラミング手法を使用して解決できる場合もあります。
候補者がソフトウェアの経験が豊富であればあるほど、より漠然とした問題を与え、分解と改良のプロセスを彼に主導してもらうことができます。
学校への入学については、比較的明確かつ具体的な要求を与えることができます。もちろん、この過程では、
難易度が高すぎると判断した場合は、無理のない範囲で積極的にヒントを与えたり、一部のプロセスを完了するのを手伝ったりすることができます。
(3) 技術的な課題に対する設計スキル
1. 身近な分野から問題を設計する
たとえ意見が分かれているとしても、あなたはどのような問題をまだコントロールできていると感じていますか? それはあなたもよく知っているはずです。
2. 浅いところから深いところまで階層的に展開
「オンライン配車システムを設計してください。」
質問が提起された後、落ち着いてさらにコミュニケーションを取り、問題を明確にすることができる候補者もいますが、面接官からの段階的な指導が必要な候補者もいます - 「この質問には具体的に何が含まれていますか?」はい、これはまさに分析と分析です。要件を絞り込むプロセスでは、候補者と面接官の間で話し合う必要があります。
コアのユースケースの観点から考え、どのような役割があるのか、システムを通じてどのような機能を実現できるのかを考えることができます。たとえば、次のとおりです。
- 乗客はいつでもどこでも配車をリクエストできます。
- システムは近くのドライバーを探してリクエストを転送し、注文を受け付けられない場合は引き続き検索範囲を拡大します。
- ドライバーは配車を取得できます。つまり、配車リクエストを受け入れるか拒否することができます。
- 双方とも地図上の自分の位置を更新し、お互いの現在位置を確認できます。
- 待機期間中、双方は互いの情報を表示できます。
- 双方は互いの評価を確認し、乗車完了後にお互いを評価することができます。
- ……
したがって、候補者とのディスカッションを続けるために最も重要な機能を 1 つまたはいくつか選択することができます。結局のところ、面接時間は限られており、噛むことができる以上のものを噛むことはできません。
機能要件が明確になったら、設計ステップに入る前に、いくつかの重要な非機能要件についても議論して決定する必要があります。たとえば、ユーザーの数、毎日のリクエストの数などです。これらの値は正確である必要はありませんが、値の大きさはシステムの設計に影響します。
候補者と面接官が一緒に問題を層ごとに整理し、漠然とした問題を単純化したビジネス上の問題に変換し、実現すべき要求点は限られたものにします。
次のステップは、以前に選択した要求ポイントに基づいて、技術的な観点からそれを実装する方法を検討することです。技術的な実装に関しては、依然として同じ原則に準拠し、曖昧さから明確さまで、徐々に改善する必要があります。
- システム全体を見て、コンポーネントやサービスは何でしょうか? (コンポーネントの呼び出しと依存関係)
- システムコンポーネントとユーザーの役割を組み合わせると、乗客とドライバーはどのようにシステムと対話するのでしょうか? （対話タイミング関係）
- 各サービスにはどのような責任がありますか?また、システム内のデータ ストレージにはどのようなテクノロジが使用されていますか? (ストレージ層の設計)
一般的に実現可能なシステム設計を行った後、レイヤー、コンポーネント、またはメカニズムを選択して、それをさらに洗練し、拡張します。
たとえば、ストレージに関して、候補者がリレーショナル データを使用して乗客とドライバーの位置情報を保存することを提案した場合、次のアイデアを通じて開発できます。
- そのような情報を保存するためにどのようなテーブル構造を設計する予定ですか?
- このようなソリューションには隠れた危険はありますか?製品の発売後にどのような問題が発生する可能性がありますか?
- そのような問題をどのように解決する予定ですか?
3. つま先立ちで到達できる最高の難易度を設定します
候補者が異なれば能力も異なり、同じ問題に対して達成できる進歩も異なります。問題の深さは階層的であり、徐々に問題を洗練させ、繭を剥がし、最終的には短期間で完了できる部分的な実装として実装する必要があります。
候補者にとって質問が難しいとわかった場合、面接官は質問のヒントを与えたり、質問の範囲を積極的に狭めたり、質問の要件を弱めたり、あるいは直接的に質問のヒントを与えたりすることで、難しさを軽減するために動的な調整を行う必要があります。問題分析を促進します。
また、問題が受験者にとって単純すぎる場合は、プロセスの時間配分を短縮し、問題解決後のさらなる改善を図るための「フォローアップ」ディスカッションにより多くの時間を費やす必要があります。
アルゴリズムの問題が、非再帰アルゴリズムを使用してバイナリ ツリーの事前順序および事後探索を実装することであり、候補が無知であると思われる場合は、次のようにすることができます。
- 質問プロンプトを与えます: 「バイナリ ツリーとはどのようなデータ構造ですか? 事前順序トラバーサルと事後順序トラバーサルの定義は何ですか?」;
- 問題の範囲を縮小します。「まずプリオーダー トラバーサルを実装しましょう!」;
- 弱めの質問: 「再帰を使用してこれを実行できたらどうなるでしょうか?」
- 高度な問題分析: 事前順序または事後探索のアイデアを直接導入し、非再帰的実装を使用します。
ヒントであれ、明示的な提案であれ、私たちは難易度が上がる各層の課題をさらに深め、克服し続けます。最も理想的な効果は、このミニプロジェクトの最高の難易度、つまり候補者が「到達できる難易度」に到達することです。つま先立ち」は、簡単すぎず、達成が難しすぎません。
シンプルすぎて退屈ですし、候補者も会社やチームがあまり良くないと感じるでしょう。
難しすぎると、候補者に大きな影響を与えたり、問題解決プロセス全体を完了できなくなったりする可能性があります。
上記の 4 つの方法を使用して、候補者がコーディングを開始できるようになるまでアイデアを明確にするようにガイドできます。
この動的調整プロセスを自由に制御できるようになるには、経験の蓄積が必要です。しかし、私たちは最初からそのような目標を設定することができ、さまざまなレベルの候補者が「来るときは幸せで、帰るときはそのことを考えずにはいられない」と願っています。
4. 継続的にデータを収集し、質問を調整する
「引き続きデータを収集し、質問を微調整してください。」複雑なことをうまくやるには調整が必要であるのと同じように、問題を設計した後は、それを実際に繰り返し使用する必要があります。
一方では、データを継続的に取得できます。そのようなデータは、独自の「座標参照系」を確立するのに役立ちます。新しい候補者を評価するとき、その候補者がおおよそどこにいるのかがわかります。他方では、問題を調整したり、改善したり、状況に応じて問題の範囲を適切に拡大または縮小するなど、結果に基づいて置き換えることもできます。
自分でデザインした問題を使用することは、候補者に一定の「新鮮さ」をもたらすことにもなります。インターネットでたくさんの問題を検索する代わりに、このミニ プロジェクトを実行して、斬新で興味深い問題を解決してください。これは簡単に言えることのように感じましたが、彼は知らなかったことですが、この質問は面接官によって注意深く準備され、実際に調整されたものでした。
5. 問題の幅を広げ、複数の角度からの拡張を設定する
“如果你所在的团队拥有一个重要的 service，它的平均请求响应时间为 1 秒，有一天你部署
了软件新版本后，留意到它的平均请求响应时间异常地增大到了 10 秒，你该怎么做？”拡張 1 -ユーザー エクスペリエンスとエンジニアリングについての理解を検討する: ユーザーへの影響を最小限に抑えるには、まず何をすべきでしょうか? ロールバックについて話してから、運用について話しましょう。今後この問題を回避するにはどうすればよいでしょうか? これにより、ソフトウェア エンジニアリング プロセス、品質保証、CI/CD、グレースケール リリースなどについて話し合うことができます。この拡張機能では、ソフトウェア エンジニアリング プロセスの側面とエンジニアリング エクセレンスの側面を調べることができます。
拡張 2 -監視および警報システムの設計を検討する: システムに問題があることをできるだけ早く知るにはどうすればよいでしょうか? これはソフトウェアの監視とアラートについて説明することができますが、どのような種類のデータを監視し、アラートする必要があるのでしょうか? データをどのように収集し、どのように送信するか、つまり警報システムをどのように設計するか。この拡張機能は、監視システム設計の問題やコードレベルの検査にさらに絞り込むことができます。
拡張 3 -問題解決のアイデアと体系的な理解を検討する: 問題をどのように見つけるべきか、問題はどのレベルで発生する可能性があるか? たとえば、サービスはまったく問題ないかもしれませんが、クライアントに問題があるか、ネットワークに問題があるか、サービスに問題がある可能性があります。サービスの問題に関しては、考えられる原因は何でしょうか?問題を上位層から下位層までレイヤごとに特定するためにどのような戦略を採用できるでしょうか? この拡張機能では、特に要求と応答のプロセスを通じて、候補者のシステムに対する理解度を引き続き調査し、システムの完全なスタックに対する候補者の理解を調べることができます。
拡張 4 -システムの特定の層に焦点を当てる: 特定の層に絞り込んでさらに拡張することで、この部分には多くのアイデアがあり、ニーズに応じていくつかの共通のエントリ ポイントを選択できます。たとえば、リレーショナル データベースのステートメントが遅すぎることが問題の原因である場合は、ここでさらに焦点を当て、一般的なリレーショナル データベースのパフォーマンス問題の原因とそれに対応する解決策について説明します。アプリケーションのメモリ不足など、アプリケーション レベルの問題である場合は、この観点からさらに拡張できます。
拡張 5 -システムの電流制限問題に焦点を当てる: 特定のクライアントがその時点で短期間に多すぎるリクエストを送信し、システムがそれらを時間内に処理できないことが問題の原因である場合、フロー制御から始めることができます 角度拡張。フロー制御の問題も古典的なシステム問題の 1 つであり、システム設計またはコード設計の観点から検討できます。
ご存知のとおり、漠然とした実際的な問題はさまざまな方向に拡張でき、これらの拡張は密接に関連しています。必要に応じて、インタビュー中に調査する拡張角度の 1 つを選択できます。
6. 調査の深さと幅のバランスを取る
常にテクノロジーを研究することができ、単純で漠然とした実際的な問題から始めて、徐々にそれを深め、最終的には完全な問題解決プロセスで終わることができれば、深さと幅の両方を達成したとほぼ言えます。
面接で単純かつ粗雑なアルゴリズムの質問を使用することをお勧めしないのはなぜですか? 単にアルゴリズムの質問を調べるだけでも、十分な深さの調査の例ですが、調査の幅が失われがちです。
候補者に最もよく知っているプロジェクト、または最も誇りに思っているプロジェクトについて話してもらい、そこから特定のポイントをつかみ、さらに深く掘り下げていく面接スタイルがあります。これ自体、調査にとっては非常に良いアイデアのように思えますが、これは、先ほど説明した質問を準備するという面接官のアイデアとはまったく逆で、候補者がプロセスを主導します。
しかし、実際には、経験の浅い面接官には上記の方法はお勧めできません。主な理由は、実際には、この方法は非常に高い品質の面接官を必要とするからです。面接官が面接官に慣れていれば説明は簡単ですが、面接官が慣れていないと、ここでのポイントが掴みにくくなり、面接官が誘導されやすくなります。おそらく、このラウンドの面接で候補者は一般的な言葉で話し、多くの側面について話していますが、面接官は鋭い質問をすることができません。