科学計算の仕事の応募者を調べるための、適切で客観的な質問/テストを知っていますか？
（実際、このテストは候補者が面接に合格した後に行われます。）
1番目）彼らは知的である必要があります。（編集、トレントからの言葉に感謝します）
2番目）彼らは主にプログラミング（C ++とPython、科学ライブラリを使用）、数値と数学を扱う必要がありますが、工学と物理学のトピックも扱う必要があります。また、CのようなスタイルやFortranのようなスタイルは望ましくありません...オブジェクト指向の概念を使用するとよいでしょう。
申請者は、コンパイラ、ツール、ライブラリ、およびインターネットにアクセスできる場合があります。テストの期間は4時間以内である必要があります。
知的な人を見つければ、彼らはあなたの特定の要件に適応できるようになります。これは、すべての「チェックボックス」を満たす人を探すよりもはるかに優れています。
ただし、それでも、それらがコンピューティングに影響を与えるかどうかを確認するためにテストする必要があります。インタビューのプログラミングテストに関する投稿はいくつもあります。特定のドメインについて心配する必要はありません。コーディングできるかどうかを確認してください。
それは常に目を見張るものです。決して退屈ではありません。そして、大規模なテストよりも、小規模なテストを行って彼らと話し合う方がよいでしょう。なぜ彼らがさまざまな選択をしたのかなどを尋ねます。次に、彼らが自分自身を明確に説明できるかどうかを確認します。
簡単な問題は、使用したいライブラリを使用して単純なODEシステムを解決するように誰かに依頼することです。私が知っているライブラリはどれも、テスト中に学習できるほど単純ではありません。たとえば、このシステムを次のように解きx=1:10ますdx/dt = -k (x^2/x)。
より難しいのは、誰かに硬い常微分方程式を解くように頼むことです。ここでは、アルゴリズムの選択が重要になり、「推測」はおそらく機能しません。たとえば、ほとんどのミカエリスメンテン方程式は堅いです。
dS/dt = - vmax * S/(Ks + S)
ここで、dSは基質の枯渇率であり、vmaxとKsは定数です（候補を与えることができます）。ここで間違ったソルバーを選択すると、私が直接知ったように、かなり悲惨な結果につながります。
どちらの問題もそれ自体では何の問題もありません。ほとんどの人が、4時間の試行錯誤でどちらかを解決できるからです。しかし、より大規模なテストの一部として、それらは役立つかもしれません。
編集：それは何を証明しますか？そうですね、ODEは科学計算のいたるところにあります。少なくともある時点でそれらを大雑把に扱っていないのであれば、それはあなたの知識の大きな穴です。私は尋ねられたように質問に答えようとしただけです。「科学計算の仕事に応募者に尋ねる具体的な質問は何ですか？」問題を解決するために、申請者は知っておく必要があります
1）基本的な微積分。
2）ある種の科学計算ライブラリ（MATLAB、SciPy、GSL）。
3）質問が適切に行われた場合（たとえば、加速率を計算するように求められた場合）、ドメイン知識（この場合は物理学）もテストされます。
私はこれがすべてのボックスをチェックすると思います:)
私はおそらくこれを後悔するでしょうが、これが私の非常に一般的なアドバイスですFWIW
1）職務仕様ではなく、候補者に面接します。
妥協しないように、スペックに「エッセンシャル」の最小セットを用意します。その後、候補者を見て、彼らがそのポジションにもたらす他のスキルを確認します。彼らは、あなたが必要だとは知らなかったスキルをもたらす可能性さえあります。
2）候補者をテストします
テストは、いくつかの口頭での質問、筆記試験などである可能性があります。それは実際には重要ではありませんが、候補者が知っていることと知らないことを確実に感じる必要があります。
3）候補者にコードを書かせてください
問題にどのようにアプローチしたか、どのように実装したか、そして何よりも重要なことに、彼らがあなたに何をしたかをどのように説明したかによって、誰かについて詳しく知ることができます。覚えておいてください、これはあなたが彼らを雇っていることです、これは彼らが一日の大部分をするために費やすものです
4）「記憶に関する質問」をたくさん聞かないでください</ p>
std::algorithmの正確な形式またはSystem.Xml.XmlDocumentのすべてのメソッドを覚えておくように誰かに依頼しても意味がありません。人々はドキュメントとIntellisenseを使用します–それを乗り越えてください。
5）自由形式の質問をする
「正しい」または「間違った」答えがないいくつかの質問をします。このようにして、候補者に意見を述べる機会を与え、栄光の「ダニリスト」ではなく会話をします。双方向の会話は、候補者がリラックスできるので役立ちます。また、重要なこととして、リラックスできるのです。話し合いをすることで、候補者について多くのことを知ることができます。つまり、彼らはあなたの意見に耳を傾けますか、反論にどのように対応しますか
6）彼らが彼らの研究をしたかどうか見てください
あなたの製品/チーム/ゲーム/会社について聞いたことがあるかどうか、常に候補者に尋ねてください。彼らが応募している会社についてほんの少しだけあなたに話すことができないなら、あなたはあなたの会社で彼らを望まない可能性があります。結局のところ、Googleに入力するのに30秒かかるので、これについては残忍です。私を信じて。
7）自分で面接しないでください
あなたは非常に賢いかもしれませんし、あなたが望むものを知っているかもしれません、あなたは人々を読むことができると思うかもしれませんが、ソフトウェア開発は主に共同作業なので、数人で参加し、別のマネージャーやシニアコーダーに参加するだけではありません-持ってきてくださいあなたのチームで、彼らの意見に耳を傾けます。重要なのは、後で追いついて、まだ頭の中で新鮮なうちに候補者について話し合うことです。
8）面接を急がないでください
面接に割り当てる時間は、面接対象のポジションのタイプ、つまり、ジュニア、経験豊富、シニアによって大きく異なりますが、必要だと思う時間に加えて、常に30分余分に時間を取ってください。これはあなたに呼吸する余地を与えます、そしてあなたが早く終わったならそれから大丈夫です。必要に応じて、2回目の面接に進みます。私は頻繁に2つのインタビューを行います。1つ目は技術的なもので、2つ目は性格とチームに焦点を当てています。
あなたはそれが適切であると感じないかもしれないか、あなたには時間がないかもしれません、しかしそれを軽視しないでください。初めて候補者から十分に得られなかったと感じ、まだ可能性がある場合は、彼らを元に戻します。彼らがあなたの会社/チームで働きたい場合は、彼らは戻ってきます。
9）証拠を求めてください
候補者が「…..の開発に大きく貢献した」と言った場合は、彼らが何をしたか、詳細に、彼らが経験から学んだこと、そして彼らが再び何をするかを尋ねます。彼らがあなたに証拠と詳細を与えることができないならば、彼らは「大きく貢献しなかった」可能性があります。常に「私たちがやった」を使用する候補者に注意してください。確かに、開発はチームで行われますが、チームの努力を説明するだけでなく、彼らが貢献したことを言うことができなければなりません。
10）正直で率直になるように準備してください。
ほとんどの候補者は自分自身をわずかに売り過ぎています。これは問題ありません、彼らの履歴書は彼らにインタビューをするものです。ただし、候補者が自分の経験について完全に前向きではないと思う場合は、そう言ってください。必ず長所と短所を調べてください。面接が多すぎると、販売交換が長引くことになります。うん、候補者がUDPの詳細を知っているのは素晴らしいことですが、彼らが悪い決定をしたとき、そして彼らはそれをどのように処理するかを知っていますか？彼らが最後に間違っていたのか、最後に悪い決断をしたのかを尋ねます。ただし、手に負えない、または判断力が強すぎないように注意してください。-間違いを犯すことは完全に自然であり、私たちのほとんどは常にそれを行います。それが重要なのです。
11）自信を持って受け入れられないでください。
自分のことを知ることと、自分が他の誰よりも優れていると考えることの間には、微妙な境界線があります。プログラミングのような知識ベースの職業では、これは常に私たち全員にとっての誘惑です。私はこれについてジェフ・アトウッドに同意します。優れたプログラマーは、コーディングが難しいこと、間違いを犯すこと、そしてコードがひどいことに多くの時間を費やすことを知っています。悪いプログラマーはそうしません–彼らは他のみんなのコードがダメだと思っています。買い手責任負担。
私はあなたがカバーしたいと思うかもしれないいくつかのポイントを考えることができます：
問題に直面したときに彼らがどのように推論するかを見るために、その人と問題について話し合うことを試みたほうがよいと思います。彼らはどのようなアルゴリズムを考えていますか、問題に取り組むためのどのような方法に精通していますか？彼らはどのような落とし穴を目にしますか？
その人があなたと話し合うことを許可することで、あなたは彼らの特定のスキルに適応することができ、テストに神経質になる候補者を拒否するリスクも少なくなります。また、その人があなたのチームに適しているかどうかについても良い感触を得ることができます-面接タイプの問題を解決するのが本当に得意であるが、他の解決方法などについて話し合うことに煩わされることのない人は望んでいません。
彼らの数学をテストします。ドメイン固有の数学の知識が必要な場合のいくつかの簡単な質問は非常に客観的であり、現場にいなくてもビジネスを行っていない応募者の90％をすばやく選別できます。
私たちはしばしば、いくつかの基本的な線形代数の質問から応募者を始めます。クロス積が何であるかを誰かが知らなければ、インタビューを続ける意味はあまりありません。
私が以前は電話スクリーンのインタビューを開始するのが好きだった1人の（良い）上司は、「2から8は何ですか？」という質問をしました。多くの人がこれを間違えたのは驚くべきことでした。（それをフラビングしても電話の画面は終了しませんが、一般的にいくつかの深刻な問題を抱えている候補者の非常に強力な予測因子でした。）
これまでの回答のいずれも、ドメイン固有の知識について言及しているようには見えませんでした。科学のどの部分（21世紀にかなり大きくなった）で働いていますか？私は、計算EM問題に取り組んでいる地球物理学者のチームと協力しています。彼らの領域は私たちの領域から遠く離れているので、私たちが二度と見ないであろう非常に多くの優れた科学計算家がいます。
正しいドメイン知識と間違ったプログラミング知識を持つ人を訓練する方が、その逆よりも簡単であることをお勧めします。
「あなたがこの仕事にふさわしい人物だと私に納得させてください」
この質問を使用すると、優れたプログラマーに必要なすべてのスキルをテストできます。
...テストされていないのはチームワーク能力だけですが、とにかくそれをテストするのは難しいことです。
PS知識に関しては、PythonとC ++の両方で、インターネットにアクセスせずに、「彼が知っている最も再利用可能な方法」で循環リングバッファを実装するようにいつでも依頼できます。実際の「使用可能な」コードは、チェックボックスの質問のトンよりも、人々とそのコーディング文化について多くを語っています。
これはかなり興味深く難しい科学的な問題の1つですが、候補者が本当に良ければ4時間で解決できます。そうでない場合は、ソリューションを実装する代わりに説明するように依頼するか、不完全なソリューションを判断することができます。優れたプログラミングスキルに加えて、高校レベルの物理学が必要です。
セントラルヒーティングシステムには、ツリー構造として接続されたパイプペアで構成される水循環ネットワークがあります。葉にはラジエーターがあり、それぞれが同じ加熱電力P（一定）を放出する必要があります。ルートでは、ネットワーク（パイプペアのホットパイプ）に入る水が温度T1（一定）に加熱されます。ツリーの内部ノードはパイプペアであり、それぞれが特定の長さ（一定の長さ）であると想定されています。
ホットパイプで放散（失われる）される熱はU * len *（T1-T0）です。ここで、T0は室温（一定）、Uは熱伝達定数（W /（m * K））です。この電力損失のため、水はラジエーターに到達する前に冷却されます（わずかに低い温度でも、ラジエーターから放出される電力がはるかに少なくなります）。
各ラジエーターには、流量（kg / s）を調整するバルブがあります。流れと温度が一緒になって、ラジエーターから放射される電力を決定します。次の関数を使用できます。
radiatorPower(flow, temperature) -> power
ネットワークをツリーとして記述するデータ構造と、各ラジエーターに必要なフローを決定するアルゴリズムを実装して、radiatorPower（フロー、温度）がPに等しくなるようにします。
戻る冷水の温度は、放出される電力によって制御され、直接制御または測定できないことに注意してください。また、ツリーのすべてのブランチで、パイプペアによって運ばれる水がノードのすべての子（ラジエーターまたは他のパイプペア）に分割されていることに注意してください。パイプの熱損失の式では、ツリーの上位のパイプによる熱損失は熱損失の計算には重要ではないと想定されるため、すべてのパイプで初期T1が使用されます（T1 >> T0であり、損失は小さい）。
Water specific heat: c = 4190 J/(kg*K)
彼の経験について聞いてみるべきだと思います。質問について：言語機能の質問（a = b ?? c ?? dなど）について質問しないでください。プログラマーは、アルゴリズム、問題の解決、チーム内の優れたコミュニケーションスキルについてのアイデアを持っている必要があります（これは非常に重要です）。
そのようなものには特定のテストは必要ないと思います。その分野ですでに働いている賢い人を何人か集めて、応募者とチャットしてください。たぶん、KornelKisielewiczによって提案されたようなものも含まれます。以前のプロジェクト、使用されたテクノロジー、好きなもの、嫌いなものなどについて彼または彼女に尋ねてください。インタビュアーが賢い場合、彼らは彼がその仕事に適しているかどうかを知ることができます。
私は、一般的なソフトウェア開発者の立場について一度インタビューを受けました。ちょっとしたおしゃべりの後、彼らは次のように言いました。「履歴書では、C ++とJavaをよく知っていると言っています。言語自体に限らず、これら2つの違いをすべて教えてください。」そこからそれはうまく流れていて、あなたは彼らが合うときに簡単に質問を投げることができます。C ++は通常マシンコードに変換され、Javaはバイトコードに変換されると言ったときのように、バイトコードの意味、どちらのアプローチの長所と短所などを尋ねられます。