ただし、テストに基づいて、現在のチームだけでなく将来も評価できます。 あるプロジェクトで面接に来たと想像してください。 インターネットについて、友人や同僚から会社について何かを学びましたが、インタビューするプロジェクトについて少し知っています。 あなたのカウンターパートに彼らのプロジェクトについて尋ねることは理にかなっています。 ほとんどの場合、雇用主からの応答は実質的な部分に限定されます-私たちが行うこと、顧客が誰であるか、どのくらいの期間、何が目標であり、彼らが探している人の種類とその理由。
この部分が好きで、このプロジェクトに進むことを考えたとしましょう。 これらの人々と今後数年間（少なくとも、少なくとも数ヶ月）潜在的に働くことができます。 したがって、プロジェクトについてさらに詳しく尋ねるのは理にかなっています。 同時に、将来のチームメイトをテストするために-彼らはどのような唐辛子ですか？ ;）
ここで、Joelの前述のテストは、プロジェクトの詳細を見つけるのに非常に適していることがわかりました。 重要な警告が1つありますが、テストは12年以上前に作成されました。 この間、業界は大きく前進しました。 したがって、この事実を考慮して質問をわずかに修正することは理にかなっています。
Joelの12の質問はそれぞれ少しずつ修正し、インタビューの対象となるチームの開発の特定の側面を議論するためのシードとして使用できます。 元の質問のそれぞれに続いて、それらを開発できるいくつかの領域をリストしました。
0. Joelテストプロジェクトは何ポイント獲得できますか？
対談者が6人以下だと主張する場合-私見ではすぐに別れを告げることができます。 7以上の場合-長く座って詳細を明確にすることができます。 特に、すべてがあまり良くない点について。 対話者の誰もがジョエルのテストが何であり、誰がジョエルであるかを知らない場合、丁寧に別れを告げて去ることは理にかなっています;）
1.バージョン管理システムを使用していますか？
現在、VCSがルールであるため、「no」という回答はおそらく聞こえないでしょう。 したがって、カウンターパートはどのバージョン管理システムを使用していますか？ これが古くて遅いシステムであることが判明した場合、おそらくプロジェクト（または会社全体）のプロセスが遅いか、人々は古いシステムと比較した最新のシステムの利点を理解していません。 近い将来にGitまたはMercurialが存在するかどうかを尋ねるのは理にかなっています。もしそうなら、以前にGitまたはMercurialに切り替えられなかった理由、移行中に受け取る予定のメリットを尋ねてください。
リポジトリでの作業がどのように構築されているのかを尋ねるのも理にかなっています-どのブランチで開発が行われ、どの瞬間に、どのルールに従ってマージが行われたか、トランクの安定性、コミット中のチェックがあるかどうか（プロジェクトがコンパイルされていること、テストに合格していること、そのコードスタイル正しい）など
そしてkamentyからの素晴らしい追加-リポジトリに統合する前にコードがチェックされますか？ 言い換えれば、プロジェクトにコードレビューはありますか？
2.ワンステップで製品を組み立てることができますか？
カウンターパートは、製品のアセンブリ/展開/チョーバスト（またはそこにある町）を1ステップで完了できますか？ 2つのステップで？ 言い換えれば、アセンブリは自動化されています。 そうでない場合は、なぜ自動化されていないのかを尋ねることは理にかなっています。 何が自動化を妨げ、それによって人的資源（および神経）を節約するのですか？ この段階では、プロジェクトについて多くの興味深いことがわかります。
3.毎日ビルドしますか？
ご存じのように、安定したナイトリービルドは、プロジェクトの品質が最小限であることの兆候であり、重大なエラーをすばやく見つける方法です。 カウンターパートはプロジェクトの毎日の組み立てを完了していますか？ プロジェクトに継続的インテグレーションサーバーはありますか？ どっち？ 彼はエンジニアをどのように助けますか？ CIにはどのリソースが割り当てられていますか？
4.エラーデータベースを使用していますか？
繰り返しますが、今では誰もがバグトラッカーを使用しています。 したがって、これは興味深いです。どのバグトラッカーが使用されますか？ その周りにどのプロセスが構築されていますか？ 誰が、どのように、誰にチケットを投げますか？ 便利ですか？ 現在のバグトラッカーまたはその周辺のプロセスについて、何が嫌いですか？ トラッカーに記録されるアクティビティ（バグ、機能、バックポート、通常のタスク）、および記録されないアクティビティ。
5.新しいコードを書く前にエラーを修正しますか？
カウンターパートは、新しいコードを書く前に既存のエラーを修正していますか？ 全部じゃない？ なんで？ 正しいものとそうでないもの このエラーまたはスコアを修正するかどうかは誰が決定しますか？ プロジェクトに多くの未解決のバグがある場合（P4とP5のみであっても）-これは、非常に高品質の製品ではなく、開発者のリソース不足の兆候です。 これは、かき回し、頭上、およびボロボロの神経を脅かす可能性があります。
さて、またはプロジェクトのすべてのFSUとすべての人が単にハンマーを打つだけです。 そのようなプロジェクトで働きたいですか？
6.最新の作業計画はありますか？
カウンターパートには勤務スケジュールがありますか？ 今日はどの程度関連していますか？ 今週の予定はありますか？ 一ヶ月？ 一年？ 最新の計画がないことは、経営陣の未熟さやプロジェクトの最終目標に対する誤解の兆候です。 このようなプロジェクトでは、競合が発生することがよくあります。たとえば、顧客が到着すると、
7.仕様はありますか？
ドラフトに仕様はありますか？ 誰がそれらを書きますか？ 彼らは頻繁に変わりますか？ 変更はどのように追跡されますか？ すでに機能している機能の仕様が突然変更された場合、どのようなアクションが取られますか？ 仕様は、顧客と請負業者が合意するためのほとんど唯一の方法です。 これは、タスクが完了したことと完了したことを確認する方法でもあり、一般にそれが完了したことを確認する方法です。
8.プログラマーにはリラックスした作業環境が提供されていますか？
エンジニアの仕事のために穏やかな条件が作成されていますか？ あなたが座っている部屋に座っている人は何人ですか？ 人々は職場で携帯電話で話しますか？ 彼らはコンピューターの前で食べますか？ 職場がどのように見えるべきかについてのルールはありますか？ 彼らは部屋で何かを議論し、他の人の注意をそらしていますか？
あなたのことは知りませんが、私にとってこれはすべて非常に重要です。 以前は静かな環境で働いていました。
9.使用可能な最高のツールを使用していますか？
エンジニアは仕事のために最新のコンピューターを与えられていますか、または時代遅れのスラグを使用せざるを得ませんか？ OS、IDE、ワードプロセッサ、アンチウイルスなどを自由に選択できますか？ オフィス（プロジェクト）のすべてのソフトウェアのライセンスはありますか？ Windows？ 言葉？ 仕事のために100ドルのソフトウェアが必要な場合、ライセンスを取得できますか？ そして500ドルで？ そして1000ドルで？
プログラマーの給与は現在、数千ドルと見積もられているため、これらの質問に対する否定的な答えは、プロジェクト管理者または会社全体が基本的な問題を理解していないことを示します。 さらに、適切な機器と宗教に忠実なソフトウェアの欠如は、エンジニアのやる気を簡単に失わせる可能性があります。
10.テスターはいますか？
そうでない場合は、
11.求職者はインタビュー中にコードを書きますか？
この質問への答えを知っていると思います））しかし、トピックは重要です。 インタビューのコードを書くように求められなかったと想像してください。 したがって、おそらく、あなたの将来の同僚も尋ねられませんでした。 これは、彼らがコードをあまり上手く書かない可能性がゼロでないことを意味します。 それとも彼らはこれを知っていて、あなたの前で台無しにすることを恐れていますか？ 一般に、コードの作成を求められない場合は、慎重に行うのが理にかなっています。
12.プログラムのユーザビリティの回廊テストを実施していますか？
「ランダムな」人々でプロジェクトをテストしていますか？ 開発者と顧客以外の誰かがプロジェクトを見ましたか？ 誰もプロジェクトを見ていない場合、プロジェクトが不適切である可能性があります。 事実、顧客と請負業者はプロジェクトの特定の側面に関して最も適切な当事者ではないということです。 彼らは偏見があり、興味を持っています。 サードパーティは、論争のある問題のように助けることができます。 ぼやけた目に見えない浅瀬を見るのは簡単です。
そのようなもの。
さらに、明らかな質問（給与、スケジュールの柔軟性など）がまだありますが、それらは開発プロセスに関連していないため、このトピックではそれらを省略します。
何をお願いしますか？