最終的なオンサイトインタビューでの「採用」と正直な「ほぼ」の違いは何ですか。[閉まっている]


9

そのため、私は最近、GoogleとAmazonへのオンサイトインタビューを行い、自分が近いことを通知する丁寧な拒否通知を受け取りましたが、彼らが求めていたスキルにはあま​​り適していませんでした。

私はこれまでに行ったすべてのインタビューの最終ラウンドに行きました(ただし、練習のためにインタビューした小さな興味のないポジションからのオファーは除きます)、これまでのところ、1日あたり5〜8回のインタビューを行うことで、私のミスが足りないので、実行から外してください。

私は少なくともコーディングの質問と他の一般的な技術的な質問でうまくやったことを知っていますが、カードゲームや駐車場などのOOPの設計は得意ではないようです(1つのオブジェクトに深く入りすぎて、すべての時間を使い果たしました。より広い)と私のコーディングの回答は全体的に機能しますが、私が見逃したいくつかのバグ/エッジケースはありませんでした(入力ノードを実際に区別する必要がなく、回答である場合など)。そして、「わからない」と言っても問題はありませんが、多分ちょっと迷っていて、答えられると思う質問に答える必要があるかもしれませんが、明確な答えを出すことはできません...

では、あなたが上手くなったからといって、それでも「雇う」には至らない理由は何ですか。

あなたが何を探しているのか、またはあなたにその少しの追加のブーストを与えたあなたが知っている何かについて何かアドバイスはありますか?


ただ注意して、私は新しい卒業生のポジション(またはほぼ同じ経験レベル)に応募しています。
Joshua Olson、2011年

2
あなたが最初にすべきことはあなたの英語に取り組むことです。おそらくそれはあなたの母国語ではありませんが、それでも私が知っているすべての優れたプログラマーは正確に話したり書いたりすることに関心がありました。それは「得た」のではなく、「得た」または「得た」または「受けた」のいずれかです。「インタビュー」ではなく「インタビュー」。「深く潜る」ではなく「深く潜る」。
kevin cline

痛い、いくつかのコロキウムとタイプミス、そして「おそらくそれはあなたの母国語ではない」。それは痛い。:Pさて、私は私のグラマーエラーを修正しました。
Joshua Olson

2
コロキウムは会議です。
ケビンクライン

口語表現。愚かなスペルチェック。
Joshua Olson

回答:


9

まず、両社の人事担当者に連絡し、「なぜ」の詳細を教えてもらえるかどうか尋ねることをお勧めします。どこが間違っているのか、どのような作業をすべきかについてのヒントを彼らが与えることができる可能性は非常に高いです。

第二に、あきらめないでください!これらの会社の1つで本当に働きたい場合は、数か月、おそらく1年待って、別の仕事に応募してください。特定の面接担当者と「ゲル化」しなかっただけかもしれません。他の誰かと面接した場合、彼らは「雇う」と言うでしょう。

最後に、技術的な回答に関して大丈夫だったと思われる場合、彼らが探している重要な側面の1つは、「文化的」適合であるかどうかです。つまり、あなたがチームの他のメンバーと調和するかどうか、そしてあなたの性格は良い試合かどうかです。会社の文化を調査し、それが自分に合っていると思うかどうかを判断し、インタビューでもそれを実証するようにします。

頑張って、あきらめてはいけません!


残念ながら、Googleの採用担当者には厳格なノーフィードバックポリシーがありました(ポリシーであると言い続けましたが、人々は何をすべきかについて「ヒント」を得ていることを知っています)。
Joshua Olson、2011年

1
アマゾンのみんなが所有権を取ることについて話し続けているのに気づいたので、私はその側面をもっと上手くやったはずだと思います。
Joshua Olson

1
これは良い答えです...私は2つのことを追加します:最初に、質問の全体的なトーンを読む方法を学ぶようにしてください。「所有権」についていくつかの質問を受けた場合、彼らはあなたが入ってきて過度のガイダンスが必要であることを恐れるか、または「それは私の仕事ではない」というテーマを常に理解しているかもしれません。第二に、本当に可能性がありますが、会社で働くことができると場合であってもよいが、ちょうどそのチームのためにベストフィットませんでした。ここでは、何かが影響を与える可能性があります。多分それはあなたと他の男の間にあったかもしれませんが、他の男はチームの半分がそうであるように、パンクロックとマウンテンバイクが好きでした。
赤く汚れた

Amazonからもフィードバックはありませんでした。どの種類の私は彼らが偉大なフィードバックがあっただろうだから吸います...
チェルボ

いいえ。AmazonはフィードバックもMSFTも提供していません。私も同じような経験をしました。ただし、Googleは、面接時に徹底的なフィードバックを提供します。私はまた、すべての大きな3つの社内で失敗した同じ経験があります。私が彼らから得た知識は非常に重要です。あなたのスキルセットとパフォーマンスに加えて、それは運のストロークにも起因します。あなたのスキルセットを向上させ、再び戦いに参加し、ロバート・ブルースとクモを常に思い出してください:D
Venki

3

ディーンが言ったように、あなたは複数の属性について評価されており、これらは通常:

  • 技術的なスキル
  • チームに入るかどうか
  • 思考プロセス

役割に必要な技術的スキルは、面接しているチームによって異なります。そのため、1つのチームでうまくいかなかった場合、(会社によっては)再申請して、別のチームとの相性が良いことがわかります。だから希望を失わないでください!

技術スキルの大部分は通常、コーディングの問題でテストされます。あなたは時々ボーダーケースを逃し、いくつかのバグが忍び込んだと述べました(ホワイトボードにコードを書くように頼まれたとき彼らは必然的にそうするので)。これらのコーディングの質問に答える良い方法は、次のことです。

  • 質問されている内容を理解します(必要に応じて、特定の部分を繰り返すように求めます)
  • 明確な質問をする(反復的/再帰的に、特定の制約が存在するか、どの言語か、など)
  • 使用できる適切なデータ構造、アルゴリズム、設計パターンを特定します(公開されたプログラミングインタビュープログラミングパールがこれに役立ちます)
  • あなたの思考プロセスが何であるかをインタビューに大声で説明しながら、コードを書いてください。インタビュアーがあなたの考えていることを知っている場合、彼らはあなたのアプローチの問題を早期に特定し、より良い解決策に導くことができるかもしれません。
  • 完了したことをインタビュアーに伝える前に、作成したソフトウェアをどのようにテストするかを考えてインタビュアーに説明します。単純なケース、境界ケース、並行性、アプローチが他の文化、セキュリティへの影響、ストレステストなどに意味があるかどうかについて考えます。

最後に、あなたが何かを知らないことを認めることは、それを偽造しようとつまずくことよりも(私見)望ましいです。確かに、インタビューは問題を解決するように求めていますが、どこから始めればよいかわからない場合は、有効なアプローチについて話し合い、与えられた制約に対処する正しいアプローチを絞り込もうとすることをお勧めします。どこから始めればよいかわからない場合は、それを説明するときかもしれません(これはまた、チームにどのように適合するかと関係しています。方向性を早期に求めるほうがいいと思います)。だから私はあなたが知らないことを言うのは悪いことだとは思いません(言われていることがすべてではないと仮定すると=])

面接担当者の個人的な意見に帰着することが多いので、フィットについてできることは特に多くありませんが、15分間黙ってコーディングして宣言するよりも、考えていることや行っていることについて面接担当者と会話する方が望ましいです。 "終わりました"。

これらは通常、双方向のインタビューであることを覚えておいてください。彼らはあなたにインタビューしているだけでなく、あなたも彼らにインタビューしています。仕事/チーム/会社について気軽に質問してください。

最後に、Microsoftの採用担当者は電話スクリーン/インタビュー中に彼らが探しているものについてかなりの量の情報を投稿しているので、私は読むことをお勧めします。さらに、GlassDoorには企業の面接プロセスに関する多くの情報があります(ただし、ユーザーが送信した回答が常に正しいとは限りません)。MS / Google / Amazon / Apple / etcインタビューの質問をグーグル検索しても結果が得られます。

幸運を。


3

これはエリート主義に聞こえるかもしれませんが、残酷な真実は、あなたが雇われるためにあなたがすることができなかったかもしれないということです。彼らはある程度の才能を探していますが、誰もがそれを持っているわけではありません。私たちは、この難しい事実を舞台芸術で受け入れます。どれほど多くの人が練習しても、ニューヨークフィルハーモニーで採用されることはありません。博士号 英語では、素晴らしい小説を書くことはできません。これは、エリートソフトウェアチームにも当てはまります。彼らは、特定のテクノロジーを知っている人を見つけるためにインタビューをしません。彼らはインタビューに参加して、プログラムに精通し、チームに追いつき、動きの速い技術的なディスカッションをフォローし、新しい言語を取り上げ、新しいアイデアを取り入れ、新しいテクノロジーを作成できる人を見つけます。

==== 2014年3月7日====

ラズロ・ボックとのこのインタビューは同意するようです。Googleは学位や学年、テストの得点を気にしません。

すべてのデータ処理からわかったことの1つは、GPAは採用の基準としては無価値であり、テストのスコアは無意味であることです。まったく新しい大学の卒業生を除いて、相関はまったくありません。Googleは、筆記録とGPAとテストのスコアをすべての人に要求することで有名でしたが、あなたが学校を卒業して数年しか経っていない場合を除き、私たちはもうそれをしません。彼らは何も予測しないことがわかりました。...会社全体で5つの雇用属性があります。それが技術的な役割である場合、私たちはあなたのコーディング能力を評価し、会社の役割の半分は技術的な役割です。しかし、どの仕事でも、私たちが最も重要なことは一般的な認知能力であり、それはIQではなく、学習能力です。それはその場で処理する能力です。それは、異なる情報のビットをまとめる能力です。私たちは、彼らが予測的であることを確認するために検証する構造化された行動面接を使用してそれを評価します。


5
エリート主義で全く役に立たない。あなたが言っているすべてが「あなたが愚かすぎるようにしようとしないでください」である場合、質問に答える意味は何ですか?
Joshua Olson

さらに、グーグルとアマゾンの採用は、世界クラスのチェリストであるのと同じクラスではありません。彼らの採用バーはその高さに近くはありません。
Joshua Olson

4
申し訳ありませんが、面接プロセスを完全には理解していないという考えは間違いなくありました。私はたくさんの人にインタビューしたことがあり、何度もインタビューを受けてきました。エリートチームからのインタビューの勉強は、SATの勉強と同じくらい効果的です。インタビューは知識テストではありません。これは問題解決能力と思考の明確さのテストであり、コードは表現の媒体です。これらのスキルは、何時間ものプログラミングとプログラミングについての考えの産物です。ここでの多くの時間は、「学校の割り当てとは関係のない多くの独立したプログラミング」を意味します。
kevin cline

笑。私は望む。いいえ、面接プロセスはおそらく知識テストではないはずですが、SVでは通常、特にGoogle、Facebook、Amazonなどの企業で行われます。面接は絶対にスキルであり、勉強すればするほど、上手に習得することができます。
ジョシュアオルソン

2
@josh-私もそのようなインタビューを受けました。面接が些細な追求のゲームのように感じられるなら、それはおそらく働くのに良い場所ではありません。インタビューがうまく整理されていない場合は、プロジェクトも可能性が高いです。ソフトウェアプロセスについて考えるチームは、インタビュープロセスについても考えるでしょう。
kevin cline

1

自分で改善できるいくつかの領域をすでに特定しているようです。

これらの側面を前の質問と組み合わせて、あなたについて何も知らずに、実用的なソフトウェアを設計し、その設計を明確に伝えることができるように、エンジニアリング側で少し努力することをお勧めします。より多くのCS理論を学ぶのではなく、プログラミング真珠リファクタリングC ++コーディング標準コード完了などの本を読んでください。「つまらない」仕事の一つは、あなたの本当のソフトウェアの設計を超える責任を与えた場合は、仕事を取り、作る、それが面白いです。現実の世界では、この男のように感じることがよくあります、しかし、それが平凡なアプリケーションであっても、難しい問題に取り組んだことを知ることは、非常に満足のいくものです。


私は本当にうるさいわけではありません。実際のソフトウェアで作業したいだけです。あちこちの小さなスクリプトではなく、10年前に作成されたいくつかのifステートメントを変更して、このわずかに異なるビジネスルールまたは代数式で動作するようにします。
ジョシュアオルソン

エンジニアリングの側面に取り組むことが、ソフトウェア会社(ソフトウェア製品を持っているb2b企業ではない)での仕事を探している理由です。
ジョシュアオルソン

1

わかりました、ここで実際の経験をいくつか紹介します。

私はこれらのエリートソフトウェア会社の1つで働いています。私たちの採用ポリシーは、優秀な人材を「見逃さない」ためではなく、平凡な人材を「採用しない」ためのものです。これらの会社のいくつかは本当に優れた人材を採用したいと思っていますが、本当に優秀な(紙面の)多くの開発者にインタビューし、彼らが望まない企業を選別することでそうしています。誰かが雇われると、それらを取り除くのは非常に難しいので、実際には非常に適していると思われる候補者を辞退することは価値がありますが、面接官の1人がいくつかの赤い旗を見ました。

私が現在働いている会社では、面接担当者の1人(最も重要な人)だけがイマイチをくれたので、断られました。このインタビュアーは私に非常にドメイン固有の質問をし、流暢な英語を話しませんでした。彼らは私を雇わなかったが、チームは会社が潜在的に良い雇用を逃してしまうだろうと考えました。彼らは翌週、別のチームとの別の面接に私を送り、私は仕事を得ました(追加する可能性のある「強力な採用」マークを付けました)。

私のアドバイスは、あなたが本当に必要なものを持っていると本当に信じているなら、この会社にインタビューし続け、あなたが仕事を着陸するまでそれぞれの経験から学ぶことです。これらの企業のほとんどは、面接するすべての人のレジストリを保持しており、彼らは貧しい候補者をブラックリストに載せています(そのため、彼らはもう一撃を得ることがありません)。ただし、優れた候補者であるが、その日は成績がよくなかった、またはチームとの適合性が低かった候補者は、採用プールに残ります。採用担当者の電話がたった1日停止しただけでブラックリストに登録されているかどうかがすぐにわかり、それ以降の連絡先はすべて耳を貸さないようです。今後会社からの問い合わせがあれば大丈夫です。あなたがブラックリストに載っていなかった限り、あなたが最初の拒絶の後にさらにインタビューをセットアップすることに全く害はありません。実際には、一度に複数のチームにインタビューすることを強くお勧めします。面接担当者は、それが本当の問題であるかどうかにかかわらず、最初に気づいた問題の兆候であなたを拒否します。彼らは用心深く、良い採用をしたい以上に悪い採用をしたくありません。

さらにいくつかの考え:

-これらの会社のどれもあなたにフィードバックを与えるつもりはありません。それは法的責任です。これが現状であるとは思えませんが、そうならないことをお約束します。

-私が個人的に優秀なエンジニアと話をしたとき、私はマイクロソフトにインタビューしたとき、彼が最終的に採用されるまでに5回以上のトライを要したと語っていました。この男は上級レベルのSDEだったので、MSFTは彼を昇進させることによって、彼が優れた採用者であることを明らかに確認しました。

いくつかのヒント:

データ構造とアルゴリズムを前後に把握します。グラフ走査までのすべてを知る必要があります。

アーキテクチャ、特に分散システムと規模の問題を理解している

自分が主導したプロジェクトのリストを覚えておいてください。覚えている仕事であなたが示したリーダーシップの原則の例のリストを用意してください。これらは、面接(行動面接)で回答するのが最も難しい質問です。あなたは技術面で完璧であることができます、そしてあなたが行動面接を生き延びなければあなたは雇われません。

彼らが探しているプログラミング言語について心配する必要はありません。あるオブジェクト指向言語を後方および前方に認識し、その中のコードを理解します。インタビュアーは通常、どの言語でコーディングするかを気にせず、それに基づいてあなたを判断しません。

最後に、履歴書をメールで送ってください。; =)


0

間違っいるとは限らない

たぶんあなたは何も悪いことをしなかったかもしれませんが、誰か他の人がもっとうまくやったでしょう。おそらく、性格、コミュニケーション能力、相互関係、過去の同様のプロジェクト経験などの面で。

あなたは雇われても大丈夫だったかもしれませんが、それはあなただけではありませんでした。あまり心配しません。すべては目的のために起こります。


確かに、私は幸運なものを得るのが難しくなるので、自分を「幸運」にする方法を見つけようとしているだけです。:)
ジョシュアオルソン

1
いいえ、採用数に制限があることはほとんどありません。あなたがカットをした場合、彼らはあなたを雇います。彼らは彼らの基準を満たす人のために会社内の場所を見つけるでしょう。私は個人的にこれがグーグル、アマゾン、そしてMSFTに当てはまることを発見しました。
ジョナサンヘンソン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.