仕事を探しているシニアエンジニア。 15回の技術面接をどのように受けたのか、そしてそれについてどう思うか

さまざまな職種のさまざまな企業でのインタビューをどのように経験したかという話の続き。 今回は、最初の部分に関するいくつかの質問とコメントを閉じ、テストタスクと技術面接について引き続き話します。



驚いたことに、リクルーターと人事担当者とのインタビューに関する以前の記事は、予想外の関心を呼び起こしました。すべてのソースからの100,000回以上の視聴。 私はPMでたくさんの肯定的なフィードバックを得ました。彼らは私が5年前に最後に見た元同僚によって私に手紙を書きました。 いくつかの物語のヒロイン。 OLXを介して数週間前にシステムユニットを販売した人（Slandoのアナログ-約per。） 。 昨年、ガレージでメタルを演奏したドラマー、そして奇妙なことに、インタビューや採用の特定の側面についてどう思うかを尋ねたリクルーターがかなりいました。 何らかの理由で250人がLinkedInに追加されました:)。



仕事に取りかかる前に、最も一般的な質問と個人的なメッセージやコメントに答えます。

面接の給料を手配する方法

お金に関連する多くのコメント。 入札は別の問題であるため、私は意図的にこれにあまり注意を払いませんでしたが、コメンテーターはまだそれに触れ、私の戦略の欠点を指摘しました-例えば、すぐに価格に名前を付ける。 この問題をより詳細かつ専門的な方法で扱った2つの優れた記事を次に示します。

• インタビューでお金を議論する方法：申請者の交渉戦略
  
  
• 給与交渉：より多くのお金を稼ぎ、より高く評価される

仕事を探す前に読むことをお勧めします。

採用に関するいくつかの考え

決して私はリクルーターに彼らの仕事をする方法についてアドバイスをしません。 私はプロのリクルーターではなく、彼らの内なるキッチンがどのように機能するかわかりません。 スタッフを探す必要があるとき（技術面接の実施、つまり検索と雇用-フルサイクル）に、それらはそれぞれジュニアポジションでしたが、特別な困難はありませんでした。



プライベートメッセージで、彼らは仕事の申し出について最初のメッセージを作る方法を尋ねました。



残念ながら、リクルーターに依存するものはないようです。 採用担当者ができることは、必要なプロファイルの専門家の連絡先をできるだけ多く見つけ、それらすべてにオファーを送信することです。 その後、あなたは待って、そのうちの一人がためらうか、または積極的に仕事を探していることを期待する必要があります。 つまり、ベースでの作業の20％と運の80％があります。 ネットワークには欠員などを正しく作成する方法に関する多くの資料がありますが、私にとって重要なのは、候補者の仕事を変えたいという欲求です。



採用は、候補者への空席の売却です。 これをすぐに理解し、セールスマンのスキルを高め始めると、より良い結果が得られます。 ああ、私はアドバイスをしないと言った:)



また、求職中は、候補者が多かれ少なかれ適切な空席をすべて獲得する必要があると確信しています。実際、空席が何であるかを知ることは、技術専門家との会話の中でのみ可能だからです。 私の検索では、空席に書かれていることに実質的に注意を払わず、技術面接の段階で必要な詳細を見つけました。 標準のグレーの説明の後ろに隠れることのできるクールなプロジェクトを見つける可能性が大幅に増加するため、この方法が最も正しいと考えています。 私の経験では、この論文を明確に確認しています。 欠員になったことは一度もありませんでした。具体的に何をする必要があるかが書かれていました。 「コードのコーディング、テストのテスト、展開の展開」などの一般的なフレーズのみ。

会社またはプロジェクトに参加する

私たちの現実では-間違いなくプロジェクトのために。

タイトルの選び方

チーム/技術リーダー、プリンシパルエンジニア、ソフトウェアアーキテクト、プロジェクトマネージャー、ピープル/グループマネージャーなど、シニアソフトウェアエンジニア以上のレベルで自分を候補者として位置付けました。 これは、「上位」が「シニア+」の「+」によって意味するものです。



タイトルには何の意味もないように思えます。 唯一の重要なことは、あなたが実際にやっていることであり、これはあなたが一緒に働く人からのみ見つけることができます。



それでは、皆さん、技術面接に移りましょう。

ステージ2。 技術面接

この部分では、アドバイスよりも私の主観的な経験と哲学のほうが多くなります。 技術面接で何が求められるのか、それらを準備する方法については、インターネット上で多くの情報があります。



免責事項：著者はターボエンジンのオリンピック選手ではないため、いくつかの決定やコメントは、著者に自分の過ちや低い資格を指摘したいという笑顔、お尻の痛みを引き起こす可能性があります。 コンストラクトを聞いてうれしいです。



合計で、15回の技術面接を受けましたが、私にとってはそれほどではありません。 私はもっ​​と多くのことを経験することができましたが、リクルーターとの最初の接触から技術専門家との会話まで平均して1週間かかりました。 これは、実際には時間制限がなかったという事実にもかかわらずです。 すでに別のインタビューを予定していた時間に、一度だけインタビューをスケジュールしました。 また、すべての企業やリクルーターが自分自身に来たことにも注意してください。 私は最初にどの会社にも履歴書を送りませんでした。 これは、仕事を探しているのは聖職者ではなく、仕事-聖職者であるということです。

テストタスク

多くの企業は、関係のない候補者を排除するために会話に移る前にテストの割り当てを行います。 多くの人々がテストタスクに時間を費やすことを好まないという事実にもかかわらず、特に彼らが非常に膨大である場合、これはまだ良い習慣だと思います。 テストタスクが何であるかを考えてみましょう。



「プロジェクトを最初から作成し（おそらく特定の技術を使用して）GitHubに配置します」 -私にとっては最悪のオプションです。 ボイラープレート、ソリューション周辺のインフラストラクチャに多くの時間を費やすことができ、インタビュアーは原則として、タスクの条件に定められたいくつかの小さな実装の詳細に興味を持ちます。 たとえば、プロジェクトテンプレートが手元にある場合、5分でサーバーを持ち上げて、必要なものをすばやくダウンロードできます。 それ以外の場合は、すべてを覚えて、ゼロから始める必要があります。 また、タスクに外部の依存関係を使用する条件（埋め込みデータベース以外など）がある場合も問題があります。

DevOpsエンジニアを配置します。 彼らは、Vagrantに複数の仮想マシンの構成を作成するタスクを送ってくれました。その中には、静的なWebサーバー、それらのバランサー、およびJenkinsが必要です。 これらはすべて、Chefを使用してインストールおよび構成する必要がありました。 想像してみてください-私はVagrant、Chefを使用したことがなく、タスクに必要なWebサーバーを構成しませんでした。 私はそれがすべてどのように機能するかを理解し、同様のツールを扱ったが、これらを特に使用したことはない。



私は一晩座って、すべてを修正し、たくさんの熊手を集めて、最終的にタスクを完了しなければなりませんでした。 主な難点は、15年目の古いMacBook Proがあり、物理的にコンテナを再起動する時間がなかったことと、Vagrantの経験がなかったことです。



タスクの本質-何をインストールするかを理解するのに-おそらく30分かかりました。 残りの時間（7時間後）に、すべてのツールのインストール、再起動、再起動、設定が動作しない理由を理解するための設定などに費やしました。

おそらく、Docker Composeで同じタスクを1時間で、おそらくそれよりも少ない時間で実行できます。 候補者をツールに限定できませんか？ それは可能であるように思えます。



このクエストは役に立ちましたか？ 間違いなくはい！ 今、私はVagrantとChefからあなたが離れておく必要があることを知っています:)



費やした時間-8時間 。

残念ながら、私はこのタイプのタスクについての話はこれ以上ありません。なぜなら、一般的にはそれほど多くのテストがなかったからです:(



「ここにテストのあるサイトへのリンクがあります-それらを確認してください」は非常にクールなオプションです。 ポイントは何ですか？ 実用的および理論的な一連の質問を構成できるSaaSがあり、ソリューションのためにブラウザーで直接REPLとコードエディターを提供し、検証テストを実行する機会を提供します。 次に、割り当てに進み、既存のコードを修正するか、独自のコードを作成して実行し、結果を確認します。 テスト自体は非表示であり、結果（合格/不合格）とテストの簡単な説明のみが表示されますが、これは同時にヒントにもなります。 このオプションが一番好きなのはなぜですか？ なぜなら、課題の質には明確な基準があり、候補者は自分が採点したポイントの数、意思決定が機能するかどうかなどを正確に知っているからです。 私は個人的にもこれらのタスクを実行することに興味がありました。 「このコードが実行されるとどうなるか」などの理論的な質問のポイントが表示されない唯一のこと-それらは簡単にグーグルです。

Rubyソフトウェアエンジニアの位置 もちろん、カスタムテストへのTestDome Webサイトへのリンクを送信します。 クリックして、実際のテストに入ります。 セット全体を完了するのに2.5時間かかります。質問ごとに5〜20分かかります。 実際、私はそれが本当に好きでした、私は長い間そのようなことを経験していません。 私は特にTDDアプローチが好きでした。それをダウンロードし、開始し、落ちたものを見て、さらにコーディングします。 とても嬉しく思いました。



タスク自体は非常に簡単でした。コード（Ruby / JS / CSS / HTML）の修正、バリデーター（Ruby）の作成、データ構造（Ruby）の実装、特別なことは何もありませんでした。 ただし、ソリューションが機能するかどうかをすぐに確認できるという事実は非常に役立ちます。



わずか1時間で93/100ポイントのタスクを完了しました。 残念ながら、この結果は将来私をまったく助けませんでした。



TDDは意思決定に役立ちます。インフラストラクチャの構築に時間を費やす必要がなく、ブラウザーで直接再生できます。要するに、非常にクールです。 このために、1か月待つことができました-最後に、ドーパミン（私は素晴らしい仕事をしました）とアドレナリン（時計が刻々と過ぎ、時間がなくなっています！）の私の部分を得ました。



費やした時間-1時間。

また、このタイプのタスクの大きな利点は、検証が自動化されることです。 インタビュアーがどのように割り当てを確認するのが「大好き」であるかを知っています。ここでは、マシンがすべてを行います。少なくともコードを取り出して収集する必要がないのは非常に便利です。 おそらく、将来採用するときにこの方法を使用するでしょう。



「ここにリポジトリがあり、タスクがあり、プルリクエストにソリューションを送信します」 -私はそのようなオプションに出くわしませんでしたが、同僚はそれを使用しました。 他の候補者がどのようにタスクを実行したかを見ることができるので、私は彼があまり好きではありません（もしそうなら）。



この方法の欠点は明らかです。テスターはコードをダウンロードし、収集し、そこにあるものを監視する必要があり、長くて退屈です。 もちろん、ブラウザで表面的にコードを見ることができますが、なぜタスクが必要なのですか？ 擬似コードで書きましょう。



「ここにリポジトリがあり、コードがあります。可能な限りそれをリファクタリングしてください」 -前のもののバリエーション。 これは、最初からフレームワークが作成され、そこで作業できるためです。 欠点は同じです。いつ停止するかが明確ではありません。 Egor Bugaenkoが言ったように 、どのプログラムにも無限の数のエラーが含まれており、それらは無期限に修正することもできます。



課題の作成者は、おそらく作成時に頭に何かを持っているでしょう。私たちはおそらく、彼らだけで主なものが何であるかを知らないでしょう。 タスクに明確な基準がある場合、それはクールです。 たとえば、「コードがあり、そのようなハードウェアの速度で結果を生成し、リファクタリングして2倍速く動作するようにします。」 基準なしで作業するのは難しいです。 実際には、実際の仕事では常にフレームワークがあり、このフレームワークと常識に基づいて最適なソリューションを探しています。 開発者の主な仕事は、このバランスを感じて適切な解決策を見つけることです。



残念なことに、誰もテストタスクを与えなかったので、私の選択は非常に小さいです。 何年も前に行ったテストを思い出せない限り。 それらはすべて最初のタイプでした-プロジェクトを作成する必要がありました。 興味深いことに、GitHubがまだあまり人気がなく、zipアーカイブのソリューションをメールで送信する必要があった当時、私はそれらを実行しました:)



テスト項目に関する私の推奨事項

1. それが好きではない-しないでください。 たとえば、タスクがサイト全体を完成させるか、粗悪品を書くことである場合は、浴場に置きます。 課題は短くし、足場の作り方をテストするだけでなく、次の議論のためにコンテキストを作成することに焦点を当てる必要があります。
2. タスクが最初のタイプの場合-readmeリポジトリに追加します。詳細は開始手順を説明し、そのような決定をした理由、その欠点は何か、あなたが好きまたは嫌いなもの、タスクを解決する方法についての短い注釈もっと時間がありました。 これが本当に役立つかどうかはわかりませんが、インタビュアーとして、そのような決定の文書を間違いなく指摘します。
3. 普通に書いてください。しかし、パーツをなめるのに多くの時間を費やすべきではありません。 私については、それがバトルコードである場合に改善できるすべてのものをreadmeに単純にリストするだけで十分です。
4. 実装に関してどのような質問があるかを考え、使用したAPIに関する追加のドキュメントを読んでください。 私は長い間並行性を扱っていないとします。 私はこれを長い間練習していませんでしたので、決定の後、私はすべての関連トピックをすばやく調べ、すべての典型的なタスクを思い出し、会話の準備ができました。

さて、テスト、あなたは正常に完了し、この情報を採用担当者に渡し、無期限にあなたが直接話すように招待されるでしょう。

技術面接。 イントロ

そもそも、彼らはインタビューのためにオフィスに招待されることはほとんどありません。 ソリューションアーキテクト、テクニカルリードの職務へのインタビューのために、そして管理職のために一度だけオフィスに呼ばれました。 他のすべてのインタビューは、Skype、Zoom、Hangoutsを介して開催されました。 リクルーターとの前回のインタビューのように、推奨事項は同じです-良いカメラ、良いヘッドセット、良いインターネット。 これに、画面を手探りする条件も追加します。 したがって、オープンな作業プロジェクト（これが重要な場合）や、そのために人々に見せる必要のない他の個人的なものがないことを確認してください。 念のため（IDEまたはrepl.it ）コーディングのために、タブとREPLのないきれいなブラウザを手元に置いてください。



すべての通信方法の中で、私はZoomが最も好きです。 実際、最も頻繁に使用されました。

ニュースグループでの適切な通信に関する重要なヒント：他の人が話しているときは、キーボードで話したりタイプしたりせず、外部のラップトップマイクや外部スピーカーなどではなく、ヘッドセットで話します。



なぜこれが重要なのですか？ ほとんどの場合、2人がそれぞれあなたと話しますが、ヘッドセットは使用しません。 あなたが話すとき、彼らの側には、ソフトウェアがノイズリダクションを含みます。それはフィードバック効果が現れるのを防ぎます（バックグラウンド、ホイッスル、エコー）。 ノイズキャンセラーがオンになっている場合、マイクは実質的に何もキャッチしませんので、あなたが彼らに言っていることは聞こえません。



キーボードで入力すると、反対側に送信されるノイズが作成され、ノイズ低減も含まれます。 この結果、フレーズが途切れ、接続不良の印象が生まれます。 したがって、人々が会話を終えるまで、常に待つ必要があります。 そうしないと、彼らが言いたかったことを聞くことができません（対談者がgarntiruも使用する場合を除く）。 奇妙なことに、多くの人々はこれらのメカニズムを知りません。 部屋からの音が人に伝わらないように、通話中にマイクをミュートすることも便利です。 私は誰もがこれらのルールを知っている企業で長年育ちましたので、私にとってこれはすべて明白ですが、人々がこれらの基本的なルールに従わず、悪いインターネットで罪を犯した多くの状況を見ました。

すべてが正常で、pingが行き来している場合、会話が開始されます。 多くの場合、インタビュアー自身が会話計画を提案します。 彼らは計画を持っていないことがありますが、少なくとも1つのトピックは常に関連しています： 「あなた自身とあなたの経験について教えてください 。 」



面接の前に、空席をもう一度確認し、候補者に適用される要件に注意を払い、スピーチを準備します。 Tech Lead、DevOps / SRE、Ruby / Java Software Engineerでインタビューを行いましたが、いずれの場合も、インタビュアーにとってより興味深いと思うさまざまなことを話しました。 詳細には触れないでくださいが、さらなる議論のためのベクトルを作成する情報を提供してください。 5年前に何をしたかについて詳細に話すべきではありません（もちろん、これが特別なことではなかった場合を除きます）。



たとえば、次のように言いました。「8年間、主にJavaを使用するエンタープライズオフィスで働いていました。 それから私はスタートアップに行き、そこでインフラストラクチャに携わりました。 過去2年間、私はほとんどRailsで書いてきました。」 それだけです。インタビュアーは十分な情報を持っているので、彼らは興味のあることを話し合います。



そして今、予想外の事実。

誰もあなたの履歴書を読まない

正直なところ、これは私にとって大きな発見でした。 採用担当者は、LinkedInのプロファイルを読むことはありません。更新されない可能性があるため、HRは履歴書を斜めに表示し、主要なものを自分で強調する機能を備えています。 しかし、技術面接を行う人々は、確かにあなたの履歴書を読まないでしょう。 私が書いたものを少なくとも片方の目で見る人は一度もいなかったと強調します。 原則として、彼らは実際のインタビューの1日前に技術面接を行う必要があることを知り、電話の5分前にCVを読むことにしました。

誤解しないでください。私は水仙でもバレリーナでもありません。 私は多くの弱点があることを知っています（技術者とマネージャーの両方から）。 面接官が私をオベリスクの猿のように見るとは思わない。



私は、会話の最初の数分から賞賛を歌い、敬意を示すことを要求しません。



特に10分しかかからないため、人々がトレーニングを受けることを期待しています。 CVを読み直すと、そこにあるリンクを確認して、おおよその質問リストを作成し、全体的な会話時間を短縮できます。



個人的には、面接前に常に履歴書を読んで、候補者との会話に何が興味があるかを考えました。 残念ながら、通常の履歴書を準備する方法を知っている人はほとんどいないため、タスクは簡単ではありません。

そして再び、私はこの態度に不満を表明します。 私とあなたは、もしあなたがすでにシニアトマトであるなら、私の分野で比較的深刻なレベルの専門家です（私はこのフォーム中傷と山を持っていることを思い出します）。 市場に私たちのような人はあまりいないので、尊敬を示し、私がやったことを知ってください。 あなたの会社、プロジェクト、クライアントについて読みました。 私は人として扱われることを期待しています。 なぜ逆のことが起こるのですか？

誰もあなたを必要としない

しかし、これが一番気になります。 ケースの80％で、私は明らかに誰かを雇うことに興味がなかった、怒り、眠気、疲れた内向者に対処しました。 彼らは技術的に有能な人であり、優秀な専門家でしたが、何らかの理由で実際に同僚を雇いたいという欲求がなく、彼らを助けるために優秀なエンジニアを雇いたいという欲求もありませんでした。



私は、これらがインタビューを行う義務を単に放棄した人々であると確信しています。 何回か、彼らは私に、正しい人は休暇中である、到着する時間がない、忙しい、または何か他のものだと言った。 彼らはすでにやるべきことがたくさんあります。製品の問題、スプリントする時間がありません。クライアントと結集し、次の候補者が再びトラブルに巻き込まれました。 問題はこれから生じます。インタビュアーは、あなたをあなたが働く必要のある人とは見なさず、単にあなたの観点からあなたが正常かどうかを評価しようとします。 「オハイオ州ティムリッドは今忙しいので、別の人が面接する」という状況は非常に頻繁でした。



エンジニアとの会話は数回しかありませんでした。それは、はい、彼らは本当に人を必要としている、彼らは良い専門家を雇いたい、彼らは私のために計画を立てているなどを示しました。 そして、次の段落に進みます。

将来の上司やチームリーダーと話すことはありません

これは前のものの結果です。 正式にまたは非公式にあなたが従う人々と話をしなければならないと私は深く確信しています。 スクラムチームであれ、血まみれの企業であれ、すべての組織には何らかの階層があります。 どこにでも（少なくとも最初は）あなたの面倒を見る人がいます。



残念ながら、それについては何もできません。 Yegor Bugaenkoの投稿「なぜGoogleリクルーターと話をしないのか」は、この状況を非常によく説明しています。 将来の上司との会話が必要な場合、面接は受けられません。



今、これは私たちにとって最大の雇用問題の1つであるように思えます。 おそらくこれは、プロジェクトの詳細、つまり人々がストリーム上で何かをするアウトソーシングによって決まります。 おそらく、一般的にコミュニケーション文化が貧弱で、人道的な精神性ではないのでしょうか。

英語のブログでは、雇用は成功する会社を築くために重要な分野の1つであるとしばしば書かれています。 私たちの会社はこれに来て適切な文化を形成するのに多くの時間を必要とすると思います。 それまでの間、顧客はこれを外部委託する必要があります。

過去の経験。 仕事に就いたとき、CTOとCEOと直接話をしました。 私はスタートアップの最初のエンジニアにならなければならないので、私に対する態度は非常に綿密で真面目でした。 その結果、私たちは一緒にうまく機能し、インタビューは私が経験した中で最高のものの一つでした。 技術的な詳細だけでなく、数か月前の最初の手順と計画についても話し合いました。

直属の上司が面接を行わない場合でも、申し出を受け入れる前に、必ず連絡を取り合ってからビールの補充を要求してください（もちろん、すべての段階を通過した場合）。

これまでのところ、私がどのように試しても、すべて、多くの材料と考え、ロングライドが再び出てきました。 次のパートでは、トピックを引き続き検討し、技術面接で使用される特定の問題と手法に進みます。