プログラマーとそのリーダーの間で広範な調査を実施しました。 トップ企業の上級開発者の要件、このレベルまで開発する機会と方法を収集し、あらゆる種類の洞察とライフハックを生成して、この記事に変換しました。 これについてはさらに説明します。
シニア、誰が... アリスシニアですか？
hhに関する職務記述書の分析と、マネージャーが対面式の会話で共有した要件から、 上級レベルを決定するための単一のアプローチはないことがわかりました。 ある会社では、これは自分で複雑なモジュールを設計できる会社です。別の会社では、個別のソリューションの洗練に接続するために、別の会社では、他のソリューションよりもクールな会社です。 企業自体の中で、要件はマネージャー、チームリーダー、HR、プログラマー自身の間でも大きく異なります。
その結果、開発者には多くの問題が生じます。要件を適切に定義しないと、キャリアパスと開発手順に関する明確なビジョンがありません。 質問：「現在、どのレベルになっていますか？ 彼に比例して稼げますか？ 次のレベルにどのくらいアップグレードする必要がありますか？」
体系的な開発の代わりに、標準的なタスクを解決し、経営者の注意を待ち、フレームワークを学び、キャリアを先に進めるかどうかを理解しないことが必要です。 私たちはアドバイスします。会社の入り口で、または今すぐ-現在のレベルだけでなく、可能な限り最高の要件についても学びます。 したがって、開発の展望を得ることができ、あらゆる段階でそれに関連することができます。
プログラマーの評価-プログラマー自身の仕事？
開発は、現在の段階に依存します。 しかし、それを評価する方法は？ これが2番目の問題です。
世論調査からいくつかの洞察が得られました。 ジュニアの 70％- 中間プログラマーは自分で評価しようとします。 パラドックス：評価のレベルが低いほど、彼は自分のアイデアで操作します。
最初の段階では、知識の深さや広さはありません-写真は非常に限られています。 そして、このような評価は、86％のケースでレベルの概念を過大評価しています。
できるだけ早く「内部」評価方法（あなた自身の意見、経験）から「外部」に切り替える-リーダー自身からフィードバックを求め、最も経験豊富な同僚を攻撃し、タスクと解決方法を比較し、トップ企業へのインタビューに行く要件が高く、テストベースが優れているなど。 マネージャーの評価は、会社/部門/プロジェクトの現在の能力と要件の制限のtrapに陥らないように、代替ソースからの結果によって客観化される必要があります。
しかし、もっと短い方法があります。 私たち自身が、 上級プロフェッショナル向けのトップ企業の要件のリストをまとめました。 そして、彼らは中級レベルと上級レベルの間に形成される深刻な遅れを発見しました。
行き先がわからない場合は、間違った場所にいる可能性が高くなります。
要件をまとめたところ、優れたコードだけでジュニアスペシャリストがmiddlに変わるわけではないことがわかりました 。 ジュニアレベルでは、プログラマーは、必要なすべての技術と、典型的な問題を原則的に解決する能力を習得し、コードを適切かつ迅速に書くことを学ばなければなりません。 中間開発者レベルでは、コード文化、より深くより広く考え、より大きなタスクを独立して実装し、さまざまな開発ツールを適用できる能力がすでに必要です。
ミドルとシニアの違いははるかに薄いです。 開発者が遅れを形成するのはここであり、誰もが自分で克服できるわけではありません。 これは暗示されている一連のスキルと個人の資質ですが、開発システムの大部分の責任、メンタリング、最適な技術的ソリューションを独自に策定および提案する能力、コミュニケーションスキルなどについては誰も明確に語っていません。
だから、誰がスーパーシニアですか？ 要件を形式化するために、Yandex、Luxoft、Mail.Ru Group、さらにはGoogleレベルのオープンソースの企業が示すすべてのものを可能な限り統合する必要がありました。 また、著名な企業の開発マネージャーとの会話でこの情報を検証しました。
ハードスキル
1.コードの清潔さ。
2.上位レベルのハードスキル：
- アルゴリズムとデータ構造の知識（これがベースであり、これがないとどこにもありません）。
- OOPの原則に関する知識。
- 最新のフレームワークに関する知識（およびリストが長いほど優れています。定期的な補充を歓迎します）。
- 設計原理、基本アーキテクチャの理解（システム/モジュールを独立してプロジェクトヘッドライナーとして設計するか、大規模システムの設計に参加します。最小限-プロジェクトの現在のアーキテクチャを考慮して膨大なタスクを解決します）。
- 設計パターンの知識（自転車を適時に認識して適用し、車輪を再発明することはありません。広い意味では、解決策をすばやく見つけたり同僚の決定を評価することは1つの言語でのチームコミュニケーションです）。
- リレーショナルDBMSとNoSQL DBMSの両方の操作、クエリの構築、最適化と管理のスキルの経験;
- テスト組織の原則、単体テストの知識、理想的には-手動テストの代わりに自動テストに切り替える。
- 少なくとも1つのバージョン管理システムの所有（ほとんどの場合、会社の要件に応じて特定のシステムが必要です）。
ソフトスキルとプロの視野
プログラマ自身が必死に過小評価していた、これらの神秘的な要件。 多くの場合、会社の経営陣とHRは、「チームワーク」と「責任」の概念に基づいて業務を行いますが、基準や生活の中での症状のいずれも正式化しません。 その結果、開発者の90％がこれらの側面を開発にとって重要だとは言わなかった。
- 柔軟な開発方法論の理解、それらと連携し、プロジェクトの仕様に適応させる能力。
- メンタリング：ジュニア、ビギナー、そして時にはチーム全体を緊急時に緊急に必要とする能力。
- テクノロジー、最適な実装のためのツール、一連のタスクの有能な評価を見つけて提供する能力。
- チームワークスキル：合意の作成、チームの決定、関係の維持、チームの結果への集中、共通の関心事の追求。
- 個人的な責任のレベルは、目標と計画、専門家との関係、リーダーシップ、キャリア開発の分野での責任の受容です。
リストされているすべてのブロックの習熟度をテストするというアイデアは、ロシア市場での言語習熟度以外のレベルを評価するためのツールがまったく不足していることによって示されました。 私たちの研究プロジェクトのニーズに合わせて、3つの言語のテストの試用版をコンパイルしました。これは、現在のレベルですばやくナビゲートするのに役立ち、長所と短所も強調しています。
要約すると、外部リソースの最大量を使用して適切に評価することは非常に重要です。 労働市場における古典的な問題を回避するために-「開発者の期待対。 「開発者が彼らのスキルを評価し、その価値が企業が行う準備ができているよりも高い場合。 彼らはまた、この程度までは行われない迅速な離陸と開発を望んでいます（詳細については、次の記事を参照してください）。
PS記事の最初のバージョンでは、すべての人にテストを渡すことを提案しました。 ただし、このような強力な回答者の流入は期待していませんでした。 そして、連絡先の詳細を残した人への現在の回答と結果を処理できるようにするために、テストを終了せざるを得ませんでした。 忍耐力のテストを記入してください:)