仕事を探しているシニアエンジニア。 技術面接でのタスクと理論的な問題について

技術面接については引き続きお話しします（読んでいない場合は、シリーズの以前の記事をご覧ください - 人事部と技術面の 面接について ）。 今回は、より主観的な経験、最小限のアドバイス、およびテストタスクと理論的な質問について少し説明します。 行こう



免責事項：著者はターボ開発者ではなく、文句のない普通のウェブマカクです。 したがって、上記のタスクと解決策は、あなたに微笑、尻込み、欲求、そして著者に自分の無能さを示したいという欲求を引き起こすかもしれません。 コメントでお会いできるのを楽しみにしています！ :)

完成した試験項目の議論

最後の部分では、2つのテストタスクを行う方法について説明しました。1つ目はDevOpsエンジニア、2つ目はRuby開発者です。 次に何が起こったのかを説明します。

Ruby開発者へのインタビュー -インタビュアーは私のテストを見ず、質問もせず、賛辞もしませんでした（少なくとも、採用担当者は私をflatめてくれました）。 彼は彼についてさえ知らなかったようです。 彼らは私に理論を尋ね始めたので、これは私を少し混乱させ、その結果、彼らは理論を通して拒否しました。

DevOpsエンジニアへのインタビュー -インタビュアーは割り当てを見て、賛辞を出し（定性的に完了したと言った）、ソリューションについていくつかのコントロールの質問をしました。この行はなぜここにあるのですか？ 条件をこれに置き換えた場合、どのファイルでこれを行う必要がありますか？ なぜこのアプローチがここで使用されているのですか？ などなど。 リクルーターが私に言ったように、一部の候補者は自分でタスクを実行せず、そのような質問に答えることができませんでした。 したがって、ここでは問題なく管理できました。

最初のケースでは、インタビュー対象者に、私のテストタスクをまったく見たかどうか、および彼がこれについてどう思ったかについて尋ねませんでした。 しかし、それは必要でした！ そのような状況がある場合は、インタビュー対象者にそのことを必ず伝えてください。

面接タスク

前の部分のテストタスクのトピックを継続し、インタビューでのコーディングのタスクを検討します。



タスクにはいくつかの種類があります。アルゴリズムの実装、擬似コードでのソリューションの作成、何かのリファクタリングなどです。 私たちのエンジニアはアルゴリズムの問​​題が最も好きです。



私を含む多くの人々は、これらのタスクは候補者のそのような問題を正確に解決する能力のみを示し、実際の作業タスク（通常は高レベル）にどのように対処するかをまったく示さないと考えています。 なぜ彼らはまだそれらを与えているのですか？ その理由は簡単だと思います。面接官は単にもっと良いものを思い付くことができません。 そして、これ以上良いものが思いつかない場合は、古き良きラインの反転、ソート、ツリーのバランスなどを見てみましょう。



ソリューションに使用されるツールとして、コードエディター+ repl +コラボレーションの可能性が最適です。 市販されているすべてのオプションの中で、私はCoderPadが最も好きです 。 あなたとインタビュアーが接続する部屋が作成されます。編集してコードを一緒に実行し、実行結果を確認できます。 とても快適です。 コードパッドにお金がない場合は、 repl.itが戦闘に入り、画面共有は基本的に同じですが、コラボレーションの可能性はありません。



更新：記事の翻訳中に、 repl.itはマルチプレイヤーモードを追加しました。これにより、無制限の数の参加者が同時にコードを操作できます。 完全無料！ CoderPadは不要になりました。

Java Developerの地位について会社とのインタビューがありました 。 同社はCRMのようなことをして、たくさんの統合を書いています。 Zoomの技術スペシャリストに連絡し、「アルゴリズムのタスクから始めましょう」と彼は言います。 私は答えます：「わかりました、私は仕事をしますが、質問があります：あなたは仕事でこの知識が必要ですか、あなたは同様のことを解決する必要がありますか？」 「驚異的なエンドポイントを記述し、json-chikiをやり取りしますが、それについて話すのは面白くないので、問題を解決しましょう。」 つまり、インタビュアー自身が自分の無能さを認めました。 誰がどうやっているのかはわかりませんが、その瞬間から私はそこに追いつかないことに気付きました。 しかし、スポーツへの関心から、会話は続きました。



コーディングパッドを開き、タスクに進みました。その条件は口頭で表明されました。「指定された文字列内の一意の文字の最長のシーケンスを見つけてください」。 その後、インタビュアーは「 動的プログラミングのタスクを与えることができますが、より単純なオプションに制限します」と述べました。 インタビューでダイナミックプログラミングのタスクを与える人を真剣に見たいと思います。



インタビュアーにタスクの条件を繰り返し、正しく理解したことを確認し、肯定的な回答を受け取って仕事を始めました。 5分後、部分文字列ではなくその長さ（これは簡単です）を見つける必要があるため、問題をまだ正しく理解していないことがわかりました。 しかし、「さて、始めてから、単純な問題ではなくアスタリスクで問題を解決しましょう」と答えました。 インタビュアーは、自分の状況に合わせてテストを準備していたため少し混乱していましたが、私はすでに、バックテストを提供せず、そのまま実行しようと決心しました。 どれくらいの時間（約40分）あるかを尋ね、コーディングを開始しました。 私は、彼らが割り当てを与えることを知っていたという事実にもかかわらず、私は特別に準備しなかったことに注意します。



だから、私はすぐにテストを書き、i、j、kインデックスでシャーマナイジングを開始しました:)ループ内のループなど。 15〜20分後、私は半解決策を講じましたが、インタビュアーが提示した境界ケースは通過しませんでした。 さらに20分かかりましたが、最終的にはタスクを正しく完了しました。 インタビュアーは満足しているように見え、データ構造について私に尋ね始めました。 彼が最初に与えたかった問題を解決するために、ハッシュセットまたはそのようなものを使用することが可能であり、彼はまさにそのような解決策を期待していましたが、私はそれをすべて壊しました。



次に、プロジェクト（フォームとパイル）について少し話しました。 そして、彼はこう言います。「その後、システム設計についてのインタビューがあります。 実際、私たちはここでこれを行わず、そのような知識は必要ないので、それを実行する理由はありませんが、順序は順序です。次の段階はこれです。」 さて、あなたは理解しています-候補者がこの会社の日常業務で必要とされないことを行うことができるかどうかを理解するために、2つの（！）インタビューが行われます。 それから私は、そのようなインタビューの無意味さについて少し話せるようにしました。 インタビュアーは私に同意したが、再び責任の委任を含め、「プロセスがどうあるべきかを決めていないので、私たちは何をすべきか」と言った。 私は、2回目のインタビュー（システム設計について）を行ったが、最初のインタビューと同じくらい無意味だったと付け加えた。

インタビュアーが犯した間違い-彼はテキストのタスクの条件を修正しませんでした。 このようなインタビューを行ったとき、候補者に質問がないように、タスクの条件をコードエディターにコピーしました。



どのような間違いを犯したか-条件を正しく理解したかどうかを3回指定せずに、すぐにコードを記述しました。 インタビューでそのようなタスクが与えられる場合、 すぐにチャットから切断し、より興味深いレッスンを見つけます。条件を正しく理解したかどうかを数回確認し、エディターでテストを書き、インタビュアーからすべてが正しいことを確認します。

また、Ruby Developerの地位についてインタビューを受けました 。 質問に答えてデフォルト設定した後、each_sliceメソッドを記述するタスクが与えられました。 知らない人にとっては、これは与えられたサイズの部分配列の配列にヒットし、それぞれにメソッドに渡したブロックを実行するか、これらの部分配列の反復子を返すようなものです。 私は書くために座って、それからタッピングが始まりました。 問題は、Rubyではかなり長い間Webメイキングのみに成功し、リファレンスホワイトリストとして、言語の基本的な構造の一部を知らなかったことです。 つまり-forループのインデックスが不変であることを知りませんでした（たとえば、Javaとは異なります）。



メソッド自体を多かれ少なかれ迅速に記述しましたが、機能せず、理由を理解できませんでした。 私は少しパニックになり始め、すべてを削除して再度書きましたが、私のコードは再び正常に機能しませんでした。

「うまくいきませんでした」と私は考え、対話者に次のように語った。「皆さん、ご存知のように、私はWebホスティングとプロジェクトの実行は得意ですが、あなたの愚かな仕事では何もできません。 これは簡単な作業であり、10年の経験を持つ人は、ただちにそれを行う義務があることを理解しています。 それで、もうあなたを遅らせないでください、そして、我々は分散します。」 二人は同意し、別れました。



私はそんなに簡単に失うことに慣れていなかったので、私は真剣に爆撃されました。 どういうわけか実存的なプラスになるために、私はリクルーターに、実際の仕事とは関係のないタスクを分解したと書きました。 その後、落ち着いて座って、インデックスがサイクルでどのように機能するかをすばやくテストしました。 ジュニアミスを犯し、インデックスを再編集し、既成のソリューションを得たことに気付きました。 実際、私が持っていたエラーは同じ行にありました。 私はこれについて人事部に伝え、彼らが興味を持っているなら、彼女が解決策へのリンクを渡すことを提案しました、私はまだ問題を解決したので。 しかし、彼女は答えました：「あなたは問題を解決していないので、あなたはそれ以上進んでいません、 さようなら 。」 どうにかして自分を正当化するために、壊れたインタビューのプロセスについて少し理解し、別れました。

その後、私はそのような仕事に対する態度を再考しました。 通常、私が監督下で何かをコーディングすることは決して問題ではありませんでしたが、いくつかの要因がここで働いていました：深刻な立場のための私のアプリケーション、基本的な言語構成の理解の欠如（私はそれらを必要としなかったが、私は解決策をグーグルできた5秒以内）およびオブザーバーの効果。 もちろん、多くの人は問題を見ると問題を解決できないと読みましたが、これは自分自身がeach_sliceでこれらの厳しい男に出くわすまでは、これが私自身の不安と無能さの言い訳であるように常に見えました。

また、Java Developerの地位についてのインタビューもありました。 今回は、わずかに異なる形式で開催されました。 Zoomからの連絡を受け、インタビュアーは次のように述べました。「メールを教えてください。タスクを送信し、それを読んで、すべてが明確かどうか教えてください。 2時間はありますが、私はミュート状態で、あなたがそこで何をしているのかを見ません（画面を再生しません）。 2時間後、私たちは連絡を取り、画面を調べて、そこで何をしたかを確認します。 何でも使用できます。」 タスクの状態を読み、インタビュアーと再度話し、ビデオをオフにし（ストリームのコーディングがCPUを消費するため）、混乱しました。 IDEを開いて開始しました。



タスクはI / Oに関連していました-ディスク上のファイルにデータを書き込むためのAPIを作成して、すべてがスレッドセーフで高速であり、これをチェックする単体テスト（スレッドセーフを含む）を作成する必要がありました。 私は長い間並行性とI / Oを扱っていないので、すぐにドックを調べて、何が起きているのかを覚えなければなりませんでした。 私は額に解決策を書き、それがスレッドセーフであることを確認しました。 すべてについてのすべてが私に約1時間半かかりました。 私はインタビュアーにpingをし、準備ができていると言ったが、磨く必要があるのはささいなことだけだ。 これに対して彼は答えた：「もう30分座って、まだ完了していないものをすべて終わらせましょう。」 OK、私は座ってすべてのささいなことと粗さを思い起こさせ、javadkiを終了し、もう一度I / Oについてできることをすべて読んで、私のソリューションの欠点が何であるかについて考えました。



30分後、私たちは連絡を取り、画面を共有し、コードを表示し、テストを実行しました。 次の30分では、特定の条件を変更する場合の問題の解決とその修正の可能なオプションについて厳密に話しました。 私は以前のインタビュー（および後続のインタビューでも）でタスクによる会話の基礎を準備した人はいなかったという事実に注意を喚起したいと思います。出力で0/1を与えるのは常にある種の抽象的な部分であり、次の質問に進みました。 そして、ここでのタスクは数時間で実行できるほど単純でしたが、同時に条件を追加し、候補者と決定を完了する方法について話し合うのに十分なほど徹底的でした。



このインタビューは本当に気に入りました。 フィズバズが解決できるだけでなく、アーキテクチャの何かを理解できることを示すことができました。 インタビュアーは、6月に座っていたのではなく、自分の作品で何かを撮影するスペシャリストであると確信していました。 これは今までで最高の技術面接でした。 インタビュアーは私たちのものではなかったとすでに推測したと思います:)また、合格し、さらに2つのステージを経て、最終的にオファーを受けたと付け加えます。 しかし、それは別の話です。

このタスクの何が良かったですか？

• 実際の仕事、彼らがその会社で行うことへの近接性。
• 制限時間。
• 観察の欠如。
• メモリチェックではなく、何でも使用できる機能。
• さらなる会話の基盤を作る。
• 候補者のスキルをテストして、コーディングし、IDEを使用して、一般的に考えます。

残念ながら、すべてのインタビューの中で、私はそのようなタスクを3つしか持っていなかったので、選択はわずかです。 おそらくもっと難しいテスト/タスクがあるかもしれませんが、私はそれらを取得しませんでした。

面接タスクの典型的な欠点

1. タスクは実際の作業とは関係ありません。 それは私を最も悩まします。 アルゴリズムは解くことができますが、実際にはパイルはリベットします。 関連タスクをしましょう、私はあなたに原油をやります！ 文字列内の部分文字列を検索する方法を知っている人が必要なのはなぜですか？
2. 組織的-多くの場合、ソリューション用の通常のツールはありません。 Google docsでコードを見せてくれた後、repl.itで画面をいじったら、かつてはCoderPadでした。
3. タスクは、さらに会話するためのコンテキストを作成しません-これは最初の段落の結果です。 後で議論しないのに、なぜタスクを与えるのですか？
4. すべての人々が監督下でタスクに対処できるわけではありません。 したがって、この段階で適切な候補を削除できます。

理論的な質問

これは私のお気に入りの部分です。 誰もが理論を尋ねるのが大好きです。これについて少し見てみましょう。



なんらかの理由で、たまたま私がRubyエンジニアの立場で理論を尋ねられたことがありました。 私は彼女の最悪の事態を知っていたので、私は常にインタビューを埋め尽くし、6月のように見えました。 私は座って、言語の教科書を読みました。これにより、「みんな、なぜこれを聞いているの？ 私は優れた開発者ですが、違いは何ですか、オブジェクトのメソッド検索の順序は何ですか？ 誰がこれを必要としますか？」

Ruby開発者として行った最初のインタビューは、まさにテストタスクが行われる場所でしたが、結局のところ、誰も興味を持ちませんでした。 私と通信するはずだったティムリッドは来なかった（彼は交通渋滞か何かで立ち往生していた）ので、彼らは私に別のものをくれた。 会議の後、彼は次のように述べています。「私にはルールがあります-すべてのインタビューを英語で行うため、英語に切り替えます。」 インタビュアーが非常に強いアクセントを持っているため、耳がグラフェンナノチューブにねじれています。 それは私を多少不安にさせました（英語で同胞とコミュニケーションを取ることは非常に困難です）。



次に質問がありました。モジュールとは、ブロックとは何か、歩留まりとは何か、そして私はファイルを始めました。 「教科書のように」と定義する代わりに、「まあ、正確な定義はわかりませんが、おそらくこれはそんなことです。私はそのように使いました。」 インタビュアーは不満でした。私はそれを感じ始め、誰もが到着したと思いました。



次に、特定のメソッドに関する質問がありました。「コレクション内のすべてのnilをフィルタリングするメソッドの名前は何ですか？」 次に、トロールをオンにして答えました。「これらの方法の知識について私の記憶を確認した場合、最近使用していないものについては何も言えません。 私は多くの言語とプラットフォームで書いていますが、すべてのSDKメソッドを覚えていません。」 これはインタビュアーを満足させるものではなく、次の質問は次のようなものでした。 どんな方法があり、誰がそれを拡張するのか。」 「おじさん、わかりませんでしたか？」と私は考えましたが、声を出して言いました：「わかりません。地図/縮小/スライスなどの方法があると思います。」 彼にも似合わなかった。



それから彼は、MVCのどこにロジックを配置するかについて、標準的な質問をしました。 私はモデルでそれを答えました、そして、それがモデルに合わないならば、それからいくつかの他のクラスで。 いわゆるサービスオブジェクトが正解であることが判明しました（このゴミもここにあるのでしょうか？）。 私はそれに応じて何かをつぶやきました。たとえば、あなたはそれを呼び出すことができますが、私はそれが好きではありません。



それから彼はSQLに関するデフォルトの質問をしましたが、それは私が正しく答えることができ、それから私が使用しなかったRSpecについて尋ねました、それがすべてです。 Rails（そして彼らはレールを持っていた）で、私は単一の質問を受けなかった。 また、私は以前の経験について単一の質問を受けていません。



その後、彼は私に毎日のスタンドアップについてどう思うか尋ねました。 その後、私は社会的に期待される答え（バーンが燃えた-やけどと小屋！）を出さないことに決めました、そして、それは時間の無駄であり、マネージャーが透明性と進捗状況の報告の容易さを確保できないチームで実践されたとすぐに言いました。 そして彼は、スクラムは植物油の中のゴミであり、スクラムによると誰も私たちのために普通に働かないし、誰もがふりをしていると付け加えました。 明らかに、私はまだマイナスを拾いました。



さらに、彼は彼に質問をすることを提案し（明らかに礼儀正しさから）、私は自分の頭で、プロセスやアーキテクチャなどについて尋ねました。 私が聞いたのは、彼らが典型的なタスクのために多くのサイクリングをしたので、好きではありませんでした。 私はただの開発者ではないことを男にはっきりと伝えたかったのですが、もう少しやることはできましたが、すべてが無駄になっていたので、すぐに彼は集結して出航する時だと言いました。



翌日、リクルーターが私に手紙を書き、拒否を知らせてくれました。 「そして神に感謝します」と私は思ったが、それでも少し焦げた。 インタビュアーが最初から偏見を持っていたという印象を受けました、わかりません。 ちなみに、これは最初の連絡から技術面接まで1か月かかったオフィスと同じでした。

だから、彼らは私が言語の基本を知らなかったので私を拒否しました（Ruby）。 では、先に進みましょう。

もう 2 人のインタビュアー、Ruby Debeloperでの別のインタビュー 。 少なくとも1つはロシア語、2つ目はウクライナ語で話されているのは良いことです。そのため、私は脳を壊す必要がありませんでした。 驚いたことに、同じ話が始まります。モジュールとは何か、ブロックとは何か。 私はまだ教科書を読んでいなかったので、答えをもう一度泳いだ。 Railsの関連付けのタイプについてさらに質問しました。 最後に、少なくとも何か、私は考えて、記憶から3種を命名しました。 インタビュアーはそれが好きではありませんでした（彼らがもっといたからです）だけでなく、私が言ったこと：「残りはドックに登ります」。 それから彼らは私に上記で説明したタスク-each_sliceについて教えてくれました。 その後、すでにご存じのとおり、締めくくりを提案しました。 インタビュアーの1人がついに彼の運を試すことにしました。「最後の質問があります。Rackミドルウェアを書いたことがありますか？」 彼が何を聞きたかったのかわかりません。 私は書いていないと言いましたが、それが何であるか（Java Servletのフィルター、またはLaravel / Expressのミドルウェアなど）を知っているので、必要に応じてすぐに理解できます。 そして再び、これは彼らに合わなかったので、私たちの会話は終わりました。

繰り返しますが、ソリューションの構築や関連分野での私の経験や知識に誰も興味がありませんでした。 私は彼らを非難しません。 たぶん、彼らは本当にラックミドルウェアの書き方を知っているプログラマを本当に必要としているかもしれませんが、実際、彼らはインタビューを行う方法を知らないだけだと思います。



2つの失敗の後、これはそうではないことに気づき、理論を読む必要があります。 尋ねられたら、知る必要があります。 誰も私がいい人だと信じて普通の仕事をするだけではないので、座って教科書を読んだり...

Ruby Developerでの3回目のインタビュー。 ティムリッドは再び休暇中なので、簡単な開発者が私に話しました。 モジュールとブロックに関する同じ質問ですが、私はすでに完全に装備されていたので、正しい答えをします。 インタビュアーはさらに進んで、Procとは何かを尋ねますが、ここでは正しい答えを出しましたが、私は使ったことはありませんでした:)それから彼は重い砲を使うことに決め、質問をします。クラス、それは別のものから拡張され、まだそこにモジュールと何か他のものがあります。 それから、私はまだ100％の正解を知らなかったので、どういうわけか論理的にどのチェーンにすべきかを推測しようとしました。 半分だと思いました。



次に、次のような別の質問がありました。「どのように作業が必要か」。 これらの人たちはもはやRailsではなくGrapeを持っていたので、おそらく彼らにとっては関係があったのでしょう。 私は再び答えました、「私はすぐに知りませんが、おそらくこれが好きで、それが好きです。」 正しく推測されていないようです。 次に、「ここにコードがありますが、何を出力しますか？」などの謎の質問がありました。 次に、ActiveRecordについて少しお話ししました。ここでは、ほとんどすべてを正しく答えました。



それから彼は並行性について私に尋ね始めます（ここでそれは私にとって面白くなりました）。 Rubyのどの並行性モデルが正確にわからない-それが私が答えた方法です。 同期プリミティブ、アトミック、ミューテックスなどについて知っていることを追加しました。 MRIでのあなたの競争はJVMと比較して腐った魚だとほのめかそうとしました。今はメモリモデル、volatileとsynchronizedの違いについてお話しします。Shipilevを引用しますが、インタビュアーにとってはうまくいきませんでした。 さらに、彼はプロジェクトで彼らは（できない！）並行性を使用しないことを認めました。 誰が考えたでしょうか？ なぜ尋ねるのですか？



その後、ホストは自慢して、SOLIDについて何か知っているかと尋ねました。 正確な復号化を忘れてしまったと言い、すべての意味はおおむね「普通にやる-それは正常だ」と訳され、ロガーにソリッドコードを書くすべての機能を外注しました。 インタビュアーは私に同意せず、建設的な対話に成功しませんでした。 これが流行語について尋ねられた唯一の時間でした。 その後、いくつかのアーキテクチャソリューション、アプローチなどについて説明しました。 その結果、私は継続することを許可され、最終的に「言語の基本を知らない」と書かれた申し出を受け取りました。 しかし、それについては後で。

これら3つのインタビューからどのような結論を導き出すことができますか？ それらの間で数日が経過しました。 この間、私は新しいプロジェクトを作成せず、新しい知識や新しい経験も受けず、私よりも優れた開発者になりませんでした。 私がそうだったように、私はそうであり続けました！ 実際に理論を知っていても、私にはまったく何も追加されませんでした（しゃれでごめんなさい）。 ただ、事前にCracking Ruby Interviewを読む代わりに、私は自分ですべての熊手を踏むことにしました。 私はこのようなインタビューをさらに2、3回受け、私の「尊厳」は誰にも疑いを引き起こさないと思います。



さらにいくつかのストーリーを純粋な理論と結び付けます。

Fullstack Java Developerについてインタビューを受けました。 バックエンドとフロントエンドの2つの部分で構成されると警告されました。 後者についてはあまりよくわからないので、リクルーターに報告しましたが、彼らは先に進むことにしました。 OK、みんなに連絡して、Javaから始めましょう。



正直なところ、質問は理論的でも実用的でもなく、ある種の退屈な負担でした。 私と話をしていた人は本当に何を尋ねるべきか分からなかったと思います。 それにもかかわらず、スズメが何度も撃ったので、私はそうすべきだと答えました。



前に行きました。 もう一方の端には、純粋にフロントエンドがありました。 彼は過去の経験について私に尋ね始め、その後、undefinedがnullと比較された場合に何が起こるか、scopeとvarがどのように機能するかなど、謎解きに切り替えました。 JSのデフォルトの質問をいくつか追加し、再びWATの質問に切り替えました。 私はすぐに言いました。「聞いてください、私の人生であなたのWATを扱ったことはありません。 本当に必要な場合は、グーグルで検索しますが、この知識は、帽子をかぶった男たちと笑う以外に、どこにも当てはまるとは思いません」。 インタビュアーは私に同意したが、それでもパズルの質問をし続けた。 最後に、彼は「JavaScript：The Good Parts」という本を読むように助言しました。その後、私はまだマネージャーと別れについて話しました。



私はすぐに私にふさわしいと知らされ、彼らは顧客とのインタビューを予定していました。 しばらくして、彼らは再び連絡を取り、顧客はフロントエンドの私の知識に満足していないと言いました（？）すべて大丈夫です。 その後、誰も私に手紙を書きませんでした。 おそらく納得していない:)

これらの人々はまた、純粋に理論的な質問を私から得ようとしましたが、フロントエンド自身は、彼らがそのような実際的なタスクを持っていなかったことを認めました。 jQueryの最前線であり、それに参加できる必要があります。 私はできると言って、問題はありません:)

また 、テストを行ったDevOps Engineerのインタビューもありました 。 会話に行き、インタビュアーは「サブネットマスクとは何ですか？」と尋ねました。 その時、私は恋に落ちました:)私はこれがサブネットアドレスを示す数字の数であり、他のすべてが範囲であると言いました。 しかし、私はそれをどうするか覚えていません、私は長い間ネットワークをセットアップしていません。 インタビュアーが適切であることが判明し、正しい答えに導かれ、そのような簡単な質問にすぐに正しい答えを出すことができないという事実に注意を払わなかったことは良いことです。 さらに、インタビューは理論的な質問なしで行われました。 （ソビエトの経歴はあるものの）インタビュー対象者が再び別の国から来たことに言及する価値はありますか？

私は、彼らがデザインパターンについての質問をやめたことに驚きました（MVCの場合を除く）。合計で（ハハ）5〜10年前、文字通り各インタビューで彼らはパターンの知識をチェックしました。それ以来、私はそれらのほとんどすべて（GoFから）を記念品として知っており、紙にそれらを実装することもできます。しかし、今年、すべてのインタビューの中で、テンプレートに関する質問を1つも受け取りませんでした。Ruby開発者はおそらくまだ理解できます-彼らはおそらく彼らについて何も知らないでしょう（彼らはMVCとActiveRecordを持っているので十分です）。しかし、Javaのインタビューでこのような質問がなかったことは本当に驚きました。



SOLIDについては、彼らはたった2回しか尋ねなかったようです。Rubyの職に1回、Javaに2回目。DRYについては尋ねませんでした:)

このすべてからどのような結論を引き出すことができますか？

1. 彼らはまだ理論、特に私たちの同胞に質問するのが好きです。
2. 理論の知識は実践の知識を保証するものではないため、理論にタスクを追加することを好みます。
3. 質問に答えたり、問題を解決したりする能力は、人がプログラミングの方法を知っていることを保証するものではありません。
4. 理論や問題解決策のあるファイルを知らなくても、開発者が悪いというわけではありません。

したがって、それがどんなに無意味であっても、私はあなたにアドバイスします：

• / . , . : « -AOP AspectJ Spring?» :) , , .
• LeetCode , .

繰り返しになりますが、多くのテキストがあります。皆さんが興味を持っていたことを願っています。次のパートでは、過去の経験に関する質問、システム設計に関する質問、「考えて考える」という質問、その他の適切な技術面接のようなものについてお話します。私の電報チャネル



を購読することを忘れないでください（私はそこに小さなテキストを書いていますが、それらも面白いです）、パンフレットを読みに行き、次の記事を見てください！