私がソフトウェア エンジニアからエンジニアリング マネージャーに転向して以来、テクニカル インタビューは大きく進化しました。特にコロナ後の時代に がより重視されるようになりました。これは重要で歓迎すべき変化だと思います。 は、人 10 年以上にわたり、何百人ものプログラマーにインタビューしてきましたが、LinkedIn でさまざまなブートキャンプ、大学、何百人もの求職者と仕事をすることもできました。過去数年間のすべての変化において、さまざまな場所や媒体にわたって、何かが一貫して維持されていました: 私が尋ねられる質問. そこで、採用担当者としての視点でFAQを作ってみませんか? これは私の見解ですが、長年の観察と裏付けデータに基づいています。しかし、そうは言っても、アドバイスは事実ではありません。特定の点に同意しない場合がありますが、それは問題ありません。私たちが同意しない意見は、私たち自身の見解をよりよく理解することを可能にします.せいぜい、これらの回答があなたが夢の仕事に就くのに役立つことを願っています.最悪の場合でも、キャリアへのアプローチ方法について独自のアイデアを形成するのに役立つことを願っています。 このパートでは、 受け取った質問に焦点を当てます。 ポートフォリオと GitHub に関して ポートフォリオについて ポートフォリオ/ウェブサイトは本当に必要ですか? それは本当に場合によりますが、私はそれらに非常に賛成です。履歴書はあなたのプロフェッショナルな一面を見せてくれます。ポートフォリオは、あなたの個性や興味を示します。彼らは、あなたが誰であるか、どのように成長しようとしているのかについて、採用担当者に異なる感覚を与えます. もちろん、誰もが必要とするわけではありません。私は、ポートフォリオ/ウェブサイトを持っておらず、それを必要としていない多くの成功したコーダーを知っています.実際、私が知っている の開発者はそれを持っていません。もしそうなら、なぜ私はそれらを求めるのですか? ほとんど 簡単な答えは、オッズ ゲームです。現在、技術者の雇用は野蛮な世界です。多くの需要があり、多くの候補者がおり、非常に競争が激しいですが、人々は仕事を見つけるのにも苦労しています.ポートフォリオは、就職を保証するものではありませんが、適切に行えば、他の候補者よりも優位に立つことが できます。 ポートフォリオは個人的なものなので、人々 に圧倒され、実際には何も生み出さないと思います。 ポートフォリオは大がかりなものである必要はありません。利益がコストをはるかに上回るため、ポートフォリオを構築することは非常に理にかなっていると思います。 は「可能性の芸術」 ポートフォリオを繰り返し構築し、小さく始めて、必要に応じて時間があるときにのみ拡大する場合、それは自分自身を確立するための優れた方法です. 詳細については、キラーポートフォリオを自分で構築する方法に関するいくつかのリソースを次に示します。 ポートフォリオについて話しましょう! ! ポートフォリオについて(もっと!)話しましょう ポートフォリオ MVP を構築するための 7 つのステップ ランボット ポートフォリオには何を入れますか? まず、聴衆を知ってください。あなたのポートフォリオは、友人や家族のためのものではありません。あなたの本当の聴衆は採用担当者です。消費しやすいようにコンテンツに焦点を当てたいので、物事をどのようにレイアウトするかに焦点を当てます.履歴書 + 創造性と考えてください。それにいくつかのスタイルを追加しますが、使用できるようにします。 私は、あなたができることの印象を誰かがつかむのに役立つ簡単なビジュアルの大ファンです。つまり、言語のリスト、各言語での長年の経験のリスト、プロジェクトのリストなど、視覚的でインタラクティブなものにしますが、そうではありませんそれに「摩擦」を追加します。つまり、座って物事がフェードインまたはフェードアウトするのを待つ必要がある遅いスライドショーは、良いアプローチではありません.それをすべてリストして、私がそれを見て、消費して、次に進むことができるようにします。 もう1つは、命を吹き込むことです。何年も前に作ったものを忘れてしまったように見せるのではなく、動的な要素を追加して、常に新鮮に見えるようにします。ツイッターからフィードを取得するか、ブログに小さな統合を構築するか、作業中の最新情報を人々に提供する「マイクロブログ」を作成します。 主なコンテンツは、プロジェクトのすべてです。何を構築したか、何を構築しているか。あなたが学んだこと、挑戦したこと、誇りに思っていること、もっとうまくやりたいことなどをカバーする素敵な記事を含めてください。 影響と結果。 私が作成したこのテンプレートは、リストする必要がある最低限のものです。すべて静的で、最小限のデザイン要素しかありませんが、採用マネージャーがあなたが誰であるかを理解するのに本当に役立ちます。 ご覧のとおり、リストする主なものは次のとおりです。 あなたが知っている技術スタックと方法論 ミニバイオ 重要なリンク - GitHub、履歴書、LinkedIn、 あなたのキャリアをまとめたクイックビジュアル 技術スタックと GitHub へのリンクを含むプロジェクト 取り組んでいることや読んでいることを簡単に更新できる「ライブ」セクション (おそらく月に 1 回更新します)。 前に言ったように、このようなものを構築するには週末以上かかるはずであり、アプリケーションに余分な優位性を与えるのに役立ちます. キャリアを積むにつれて、それを更新することは非常に簡単になります。 GitHub だけを使用することはできませんか? できます - はい。しかし、単にプロジェクトを GitHub にダンプして、それで終わりにしないでください。適切な GitHub ランディング ページを作成し、それをポートフォリオとして使用します。 を使用して構築できます。上に挙げたのと同じ原則に従ってください。 GitHub Pages 独自のドメイン名を取得する必要がありますか? 必要ありませんが、独自のドメインを持つことは、文房具を持つようなものです。いい感じです。 Web サイトでどの程度個人的な情報を表示する必要がありますか?家族の写真を共有する必要がありますか?レシピ?私のペットのサンショウウオの写真? 好きなものを共有してください。最終的にはそれが目的であることを理解してください。 Facebook のプロフィールを意図したものではありませんが、LinkedIn のプロフィールを意図したものでもありません。あなたの聴衆は採用担当者でしょう。 あなたを彼らに知ってもらいましょう。 社交的でありながらプロフェッショナルな SEOやページランクなどを気にする必要はありますか? いいえ、それはやり過ぎです。 HTML をきれいに保ちます。ただし、強調しないでください。 自分が追求する役割に最も関連することだけを行います。Node 開発者の場合は、Node を使用して構築します。 SEO の場合は、検索エンジン向けに最適化してください。しかし、あなたが SQL エンジニアであれば、HTML/CSS のスキルを判断するつもりはありません。 ダウンロード可能な履歴書/メールを含める必要がありますか? それは最終的にはあなた次第ですが、どちらかを含める場合は、公開する情報にうんざりしてください.ダウンロード可能な履歴書から電話番号を削除してください。メール プロバイダーがスパムをフィルター処理していることを確認してください。 または、LinkedIn に誘導するか、あなたと連絡を取るためのフォームを含めます。 GitHub で GitHub ランディング ページはどのように表示されるべきですか? ポートフォリオの内容を模倣した簡単な ReadMe を作成します。シンプル、クリーン、そしてエレガント。最新の状態に保つ必要があるため、労力が最小限になるようにビルドしてください。 プロジェクトをピン留めし、ポートフォリオ/LinkedIn への重要なリンクを含めます。 といってもやり過ぎる必要はありません。素晴らしいものもいくつかありますが、シンプルに保つことが最善のアプローチだと思います (ポートフォリオの代わりにこれを構築する場合を除きます)。 参考までに、ここに私自身の GitHub ランディング ページを示します: GitHub - Alishah Novin プロジェクト ページを実際に作成する必要がありますか? ReadMe ファイルがあることを確認してください。あなたは彼らと一緒に多くのことができます - そして私はあなたが他の開発者のためにそれを書いているかのように彼らにアプローチします (ひそかに採用マネージャーについて考えています)。 プロフェッショナルな環境では、製品や機能の機能、使用方法、制限事項などを説明する必要があることがよくあります。これは、採用マネージャーにそれを紹介する機会です。あなたのプロジェクトを消費する他の開発者は、あなた が採用マネージャーであることを忘れないでください。 の本当の聴衆 概要を提供し、スクリーンショットを提供し、変更ログを提供します。技術的な概念を伝えることができることを示すために、物事を文書化します。 別の例として、参考までに、 の私のGitHubページがあります。はるかに優れたものがあることを覚えておいてください. コード/衝突 プロジェクトをアップロードするだけで終わらないでください。 コードの品質やコメントの量について心配する必要はありますか? はい、あなたのコードが見られます。人々はコメントを探して読みます。詳細には触れない可能性がありますが、コード ファイルが表示可能であることを確認する必要があります。 実際のプロジェクトと同じように扱ってください。特にアルゴリズムを改善した場合は、それがコミット コメントに表示されることを確認してください。 採用マネージャーはおそらくそこに座ってコードを分析し、それが非常に効率的であることを確認することはありません。 過剰なエンジニアリングや過度に複雑なスパゲッティ コードの記述には注意してください。実際、コードのにおいを減らすようにしてください。 非常に見栄えのするコードを書くのに役立つ、私が気に入っている優れたリソースは です。 、 Refactoring and Design Patterns はい。リンクされたテキストではなく URL として。履歴書は印刷されます。そして、私の知る限り、紙のリンクをクリックすることはできません。 履歴書に GitHub を含める必要がありますか? はい。 LinkedIn に GitHub を含める必要がありますか? いいえ。これは、私たちコーダーが自分自身にかける不必要なプレッシャーです。誰もが欲しがる緑の壁が欲しい。毎日複数のコミットを行うことは素晴らしいことですが、仕事が保証されるわけではありません。コミットの頻度が高いことを心配するよりも、影響力のあるコミット (開発者としての進化と成長を示すプロジェクト) があることを心配してください。それも月に数回かもしれません。 反対に、大量の放棄された/未完成のプロジェクトがないことを確認してください。完全なアイデアを持っている - それらはすべてさまざまな完成段階にある可能性がありますが、MVP 段階にないプロジェクトは 2 つまでです。始めたことを終わらせる。ニュアンスのために目新しさを犠牲にします。 自分の GitHub がどれだけアクティブかについて心配する必要はありますか? コースプロジェクトを含める必要がありますか? コースワークは、独自のプロジェクトがない場合にのみ有効です。独自のプロジェクトが作成されるまでコースワークを表示したままにしておきます。その後、課題を非表示にします。 完全で完全なアイデアのみを含めます。完全な製品である必要はありません。私はプロジェクトと製品を区別するのが好きです。 「製品」は完全な Twitter/Facebook クローンを構築しています。製品のサイズと範囲は非常に大きく、実際に完成させることはできないかもしれません。採用マネージャーを圧倒するため、あまり役に立ちません。 「プロジェクト」は、より個別の作業単位です。図書館。実験。 必ずプロジェクトを共有し、その内容や達成しようとしたことを記事に含める必要があります。 自立できるほど十分に離れている場合は、「製品」を含めます。ログイン画面を超えたことがない場合は、含めないでください。 繰り返します* (実際には、コピーして貼り付けているだけです)*: 大量の放棄された/未完成のプロジェクトがないことを確認してください。完全なアイデアを持っている - それらはすべてさまざまな完成段階にある可能性がありますが、MVP 段階にないプロジェクトは 2 つまでです。始めたことを終わらせる。ニュアンスのために目新しさを犠牲にします。 すべてのプロジェクトを含める必要がありますか? 注目に値するのは、これらの回答はすべて、大小の企業に一般化した私自身の主観的な見解です.それらは私の個人的なスタイルを反映していますが、100% 正しいとも言えません。それは私にとってうまくいったことですが、他の人から意見や考えを得るのが大好きです. まだ答えていない質問がありますか? 送ってください! LinkedIn で私とつながり、私に も掲載されています。 ここに