最近、技術面接の前後で多くのコピーが壊れています。明らかに、ボード上の二分木を反転することは、実際のプログラマーの実践的なスキルとはほとんど関係がありません。原始的な Fizzbuzzは今でも最も効果的なテストです。その結果、オープンソースプロジェクトへの注目が高まっていますが、ほとんどの専門家には時間がないため、これ もあまり良い指標ではないことがわかりました。



今日、当社で最も効果的なコーディング面接があります。これは通常、候補者がバグを修正するか、小さな機能を実装するように求められる、数日間のある種の宿題です。これは時間がかかり、人が外部の助けを得ることができるので良くありません（または機能が十分に一般的である場合はグーグル）。一方、一部の大企業は、代わりにホワイトボードインタビュー（およびアルゴリズム）の数を2倍にし、将来のエンジニアをさまざまなレベルの侵襲的監視を伴う数時間のオンラインプログラミングセッションにさらしています 。



これらのインタビュー手法はすべて、Factorioを一緒にプレイするという非常に単純な指標とは一致しません。 ..。Factorioサイクル全体を通過することは、人が一般的な技術的問題をどれだけうまく解決しているかを示すほぼ完璧な指標です。将来のポジションに基づいてプレイスルーをカスタマイズして、候補者が自分の役割をどのように処理するかをよりよく理解することもできます。

Factorio？

Factorioは自動化ゲームです。このトレーラーはおそらく最高の紹介になるでしょうが、 本質的にあなたの仕事は宇宙にロケットを発射することができる自動化されたプラントを構築することです。



ゼロから始めます。鉄鉱石と石を手作業で採掘し、製錬所を建設して鉄鉱石を鉄板に製錬し、そこから自動固形燃料ドリルを作成できます。ドリルから鉄鉱石を個別に取り出して製錬所に入れることもできますが、自動コンベヤーを使用する方が効率的です。次に、得られた鉄を使用して、炭鉱を自動化する別のドリルを作成できます。次に、石炭を収集するためのコンベヤーと、それをドリルに移すためのコンベヤーが構築されます。この小さな工場では、3番目のドリルの作成に使用できる鉄板を製造しています。銅鉱石の採掘を開始すると、銅板を作成できます。そこから、水中ポンプに必要な銅線を作成できます。蒸気ボイラーと蒸気エンジンを組み合わせることで、これは私たちに最初の電気を与えます。研究センターや組立機などの新技術の発明に利用できます。組立機のロックを解除すると、手作りのワイヤーを使用して、それらのワイヤーを自動的に製造する組立機を作成できます。



最後に、ゲームの複雑化するロジスティクスに対処するのに役立つ列車、ロボット、ロジスティクスシステムのロックを解除します。さて、最終的には、ロケットを宇宙に打ち上げることができるようになります。

方向の選択

ゲームはゴールも方向もほとんどない状態で始まります。リードプログラマーは、UIを学習して目標を定義し、それを達成するための計画を立てることができる必要があります。ジュニアは、リード開発者によって設定されたタスクを正しく完了することが期待されています。研修生はメンターと協力することになっていますが、ジュニアは、シニアに助けを求める前に、コードの根本的な問題を自分で修正できる必要があります。ミドルは、任務が与えられるとすぐに独立して働くことができなければなりませんが、建築設計をすることは期待されていません。



具体的な期待は次のように定式化できます。

• 研修生は通常、青写真を配置し、それを鉱床などの他の何かに接続できる必要があります。
  
  
• , . , .
  
  
• , ( ) .
  
  
• , , .

ソフトウェア開発の最も重要な側面はチームワークです。これは、他の人の仕事と統合するためにデザインを変更することを拒否したときに自分で作業するのではなく、他の人と調整し、他の人のプロジェクトのニーズを満たし、チームと協力することを意味します。当然、このような状況はFactorioで常に発生します。これは、標準の青写真が物理的なスペースに限定されているためです。その結果、他の人の行動を注意深く研究する必要があり、場合によっては、サイズ制限内に収まるようにデザインを調整したり、予想よりも多くのスペースを占めた他の人の図面に適応したりする必要があります。



プレイヤーが自分自身に引きこもり、自分ですべてをやり始めたり、問題を黙って修正したりすると、同僚がカウボーイプログラマーに腹を立てているのと同じ理由で、チームの怒りがすぐに発生します。幸い、Factorioには同等の機能が組み込まれ git blame



ています。つまり、エンティティを変更した最後のプレーヤーが表示されます。したがって、誰かが松葉杖をつけてチームに問題について知らせなかった場合、この松葉杖がついに壊れたとき、誰が責任を負うべきかが誰にでもわかります。勝ちたいのなら、チームメイトと緊密に協力しなければなりません。

デバッグ

デバッグは、プログラマーの主要なスキルの1つです。これはおそらく、Factorioと実際のソフトウェア開発の間の最も明白な類似点です。何かが問題の実際の原因から非常に遠く離れている可能性があります。実際の問題をすばやく把握する能力は重要なスキルであり、思考のプロセスは、実際のプログラムの失敗の原因を追跡することとほとんど同じです。ピッカーが機能しなくなった場合は、最初に発信フローを確認する必要があります。次に、入り口で不足している材料を確認します。次に、工場で原料を追跡し、どこで製造されているかを調べます。そして、吐き気が出るまで、このプロセスを何度も繰り返します。



Factorioでのデバッグはすぐに複雑になります。石油精製所を建設するとすぐに、出口に3つの異なるパイプ（燃料油、ディーゼル燃料、および関連する石油ガス）があり、何らかの理由でそれらのいずれかが停止した場合は、精製所全体がクラッキングに従事します。動作を停止します。



黄色い科学を必要としない何かを研究し始めたために、プラント全体が停止することがありました。その結果、潤滑油が使用されていた電気モーターが付属しなくなったドローンフレームを使用して、燃料油を製造することをやめました。その結果、製油所の出口管が失速し、関連する石油ガス（石油）が不足し、プラスチックの生産が停止しました。その結果、信号の赤いワイヤーの生産が停止され、工場全体が故障しました。経験豊富なプレイヤーは、このようなシナリオを予測し、自己バランス型オイルクラッキングを実装して、システムのバランスが常に取れていることを確認します。このようなプラントは、関連するガスのある出口パイプが詰まっている場合にのみ停止します。優れたプログラマーに分解された製油所が与えられた場合、彼らは通常、問題をソースまでさかのぼって追跡し、何が起こったのかを理解し、迅速に解決策を見つけようとします。一方、人が正当な理由もなく地面にいくつかの新しいタンクを置くだけの場合（彼は潤滑油が常に必要であると絶対に確信しています）、これは問題を解決する方法の大きな危険信号です彼のプログラム。



このような状況により、Factorioは、プログラマーが通常扱う複雑な相互依存関係を正確に模倣することができます。ゲームプレイに新しい概念が追加されると、難易度は高くなります。これは、使用しているフレームワークの1つで発生した可能性のあるクラッシュのデバッグにおける抽象化レイヤーの追加による複雑さの増加と非常によく似ています。

コードレビュー

多くの場合、パフォーマンスやスループットを向上させるために、元のデザインを微調整する必要があります。優れたプログラマーは、自分たちのデザインに対する批判を受け入れるだけでなく、将来の作業でもそれを考慮に入れます。彼らが変更に同意しない場合は、チームが提案された変更の賛否両論をより正確に反映できるように、具体的な説明を提供します。



正当な理由もなくフィードバックに抵抗することは、よく知られている危険信号です。さらに、提案された変更を受け入れることを躊躇し、それに応じて将来のプロジェクトを調整することを拒否するプログラマーは、注意を引き起こします。その結果、彼は問題を解決するための何らかの標準的な方法に従う必要があることを常に思い出さなければなりません。同時に、その人は提案された方法が好きではない理由を説明しません。彼は無人で同僚の技術的負債をすぐに蓄積する可能性があるため、これは組織にとって時限爆弾になる可能性があります。この種の問題は、従来の面接では、インターンシップ中にのみ把握することはほとんど不可能です。

コーディングスタイルとフレームワーク

アドバイスに従わないことは、プログラマーが既存の構造に適切に統合できない場合のはるかに大きな問題の一部にすぎません。 Factorioでファクトリを構築する方法はたくさんあり、それぞれに標準の構築方法が必要です。標準に従わないと、工場全体がすぐに停止します。多くの場合、不注意な開発者には明らかではない微妙な方法で停止します。



メインベルトコンベヤーの設計には、2つのセクションに分割された4〜8個のコンベヤーが含まれます（地下コンベヤー用）。工場の中央に配置され、すべての生産はベルトに対して垂直に行われます。この設計はいくつかのルールに依存しており、それらに違反すると完全な混乱につながる可能性があります。まず、コンベヤーの出口で常にセパレーターを使用する必要があります。テープ全体をリダイレクトしないでください。別のテープ用の空きスペースがあるということは、アップグレードした後でも、リソースのパイプライン全体が失われることを意味します。第二に、すべての工場はメインコンベヤーに対して垂直にスケーリングする必要があります。迅速に拡張できないと、スペースが大量に浪費されるか、他の生産ラインに囲まれているために生産ラインを拡張できなくなります。





ロジスティクスネットワークロジスティクスネットワーク



を構築するには、さまざまな方法があります。最も簡単なのはパッシブサプライチェストです。しかし、別の方法があります-ゴミの問題を解決するフィルター収納箱。どちらの方法でも、拘束具を適切な場所に正しく配置する必要があります。パッシブサプライチェストは通常​​、チェストのスペースによって制限されます。チェストをロジスティクスネットワークに接続するには、マニピュレータをストレージチェストに配置する必要があります。また、マニピュレータを取り付ける前に、少なくともN個のアイテムを用意してください。これらの手順を忘れると、膨大なリソースが無駄になります。プログラマーが常に出力リミッターを忘れている場合、 実際のアプリケーションでのパフォーマンスに不注意があることは危険信号です。



その他の場合、チームは、原子炉の設計やロボットドローンファクトリー（ボットファクトリー）など、事前に設計された青写真を使用する場合があります。それらは非常に難しい場合がありますが、努力してそれを理解すると、非常に時間を節約できます。複雑な制御ロジックをトレースできないという理由だけで、ファクトリで新しい要素をカスタマイズしたくない候補者には注意してください。または、コンベヤーに対するドローンの明らかな利点にもかかわらず、そのようなプラントの機能のためのアルゴリズムを理解しようとすることをあきらめる人。 最適ではないドローンプラントの設計、ソース

マルチスレッド

Factorioのトレインは、マルチスレッドの直接の類似物です。1つのトレインは1つの実行スレッドであり、各トレインの交差点または停止は、2つのスレッドが同時に書き込む可能性のあるメモリ内の場所です。信号機はロック（またはミューテックス）です。鉄道ネットワークのすべてのバグは、文字通り物理的な競合状態であるため、ソフトウェアの競合状態と同じように現れます。ここでもすべてのトレードオフが適用されます。ブロックが長すぎるとスループットが低下します。信号機の不適切な設計は、ソフトウェアの場合と同様に、通常、デッドロックを引き起こします。これは、最終的には循環的なインターロック依存関係になるためです。最も一般的なデッドロックは、列車が長すぎて、最初の交差点に入るのを待っている間に2番目の交差点を予期せずブロックした場合です。この2番目の交差点は、別の列車が出発するのを防ぎ、最初の交差点のブロックが解除されるのを防ぎます。



鉄道ネットワークのトラック数は、CPUコアの数に対応しています。待機エリアがあっても、システム全体の容量が非常に迅速に制限されるため、単一のトラックを数レーン以上にスケーリングすることは困難です。最も一般的な設計は、両側に1車線の2車線設計です。これは、列車を絶えず降ろす必要が生じたときに容量の問題が発生する場所です。したがって、大規模な鉄道ネットワークには最低4車線があり、外側の2車線は、可能な限り交差を回避するためのバイパストラックとして機能します。



これらのシステムの信号機の問題は、驚くほどの時間で現れる可能性があります。同じ鉄道網で信号機が1つ見落とされたため、2週間正常に動作した後、デッドロックが発生しました 。同様に、プログラムでは、負荷が高いときにスレッドの同時実行性が高くなると、競合状態が発生するのは月に1回だけです。

スケーリング

ソフトウェアと同様に、Factorioの生産スケーリングは、元の設計図の設計に新たな課題をもたらし、生産性モジュールとビーコン付きの速度モジュールをインストールして、生産性を最大化するために完全なオーバーホールを必要とすることがよくあります。コンベアは最大ベルト速度でもパフォーマンスのボトルネックになり、後でより多くのベルトを挿入できるように構造を分割したり、工場をモジュールに分割したりする方法を余儀なくされます。



ロジスティクスネットワーク自体の管理は、広大なドローンネットワークが引き起こす多くの問題のために、ゲームの終わりにロジスティクスの課題になります。通常、サプライチェーンのセグメント化を開始し、列車を使用してセグメント間で商品を輸送するか、国境を越えて商品を転送するリクエストとサプライチェストを構築する必要があります。



ゲームの終わりに、プッシュアーキテクチャは高帯域幅を処理できないため、列車管理ではプッシュアーキテクチャからプルアーキテクチャに移行する必要があります。これは必然的に列車制限機能の使用につながり、論理ネットワークを使用して基本ロジックをエンコードする方法を学習します。これにより、ステーションは、ゲームの始まり、列車の束が単に鉄のために行くように命令されたとき。新しいスキームは、ネットワーク上のすべての駅にサービスを提供しながら、列車の数を最小限に抑えます。



高速コンピューティングでCPUのボトルネックの知識が必要になるのと同様に、組立機への入力ラインの制約とマニピュレータの速度制限により、周囲の工場の再設計が必要になることがよくあります。これらのボトルネックは、特定のスケールに達するまではほとんど問題になりませんが、その後はパフォーマンスが制限され始めます。

マイクロサービスとモジュール

最終的に、工場は非常に巨大になり、メインコンベヤーベルトまたはスパゲッティデザインを使用した単純なデザインを放棄して、よりスケーラブルな構造に移行する必要があります。メガレベルに到達するために、工場は通常、マイクロサービスまたはプラグインアーキテクチャにほぼ対応するトレインシステムまたはモジュラーシステムのいずれかを使用します。



列車ベースのメガベースは、「街区」設計と呼ばれることもあります。この設計では、プラントブロックの周りの列車がすべての入口と出口を制御します。このように、すべての入力は鉄道ネットワークからのものであるという意味で「クリーン」であるため、個々のブロックは他のすべてのブロックから分離されます。これは、マイクロサービス（HTTP経由）またはプロセス間通信（IPC）のアーキテクチャとほぼ同じですが、I / O遅延による同様の潜在的な問題があります。結果は常に受信できるわけではないため、「パケット」で送信する必要があります。または鉄道網を介して列車。



モジュラーアーキテクチャは、メインコンベヤーの類似性を維持しようとしますが、代わりに工場でベルトを分離し、標準入力と標準出力を受け入れるモジュラーブロックを使用します。これはドローンで完全に達成できる場合もありますが、通常、材料はコンベヤーベルトによって長距離を輸送する必要があります。これは、モノリシックアプリケーションのモジュールシステムと非常に似ていますが、同じトレードオフがあります。



これらのメガベースは、デフォルトのFactorioサーバーの最上位層を表します。もちろん、ゲームをはるかに難しくする多くのmodがあります。

分散システム

Space Exploration は、宇宙移民のためにFactorioを完全に作り直したバージョンです。ここでは、惑星はリソースに制約があり、プレイヤーは他の世界に植民地化し、ロケットを使用して惑星間でリソースを転送する必要があります。惑星間の材料の配達が大幅に遅れているため、これらの基地の調整は、グローバルに分散されたデータベースシステムと同様の問題を引き起こします。論理ネットワークでも、自動システムは起動されたがまだターゲット惑星に到達していない要素を見失うため、遅延に苦労する必要があります。これが考慮されていない場合 、必要なすべての要素に対して重複したクエリがあります。分散システムは、ノード間の一貫性を確保しようとすると、まったく同じ問題に直面します。

出力

一般に、ソフトウェア業界は、最高の開発者を見つけて採用する方法を知りません。おそらくFactorioを一緒にプレイすることは、これまでに行った中で最高の技術インタビューでした。そして、 これは私たちを大いに混乱させます。このインタビューは非常に非現実的で、初めてマルチプレイヤーで20時間以上、経験豊富なプレイヤーのチームで8時間以上かかります。これから何を学ぶことができますか？私は知らない。面接の方法としてFactorioに切り替えることはできません。候補者に宿題を与えるだけです。



しかし、それはホワイトボードのインタビューよりも優れています。