インタビュー中に構文的に正しいことはどれくらい重要ですか？[閉まっている]

面接候補者にホワイトボードでプログラムを書くように頼むとき、候補者が構文的に正しいコードを書くと期待しますか？

私は2つの候補を持っていました。1つは構文的に正しいプログラムを作成しましたが、ロジックは基準に達していませんでした。

私は最初の候補者を支持します。

私は問題を推論し、良い解決策を考え出し、その解決策を私に説明できる人を支持します。たとえ論理が100％でなくても、彼らが正しい軌道に乗って問題を推論し、正しい質問をし、正しい道を進んでいるなら、それが私の勝者になるでしょう。

ジョブでコードを開発するとき、構文とロジックの間違いを見つけるための多くのツール（IDE、コンパイラ、静的解析、単体テスト、統合テスト、受け入れテスト手順）があります。ホワイトボードに書いている場合、これらのツールはなく、構文の間違い（メソッド名、セミコロン、中かっこを忘れる）を犯すに違いないので、私はそれを許すことができます。

あなたに対する私の唯一の質問：候補者に、アルゴリズム、設計戦略、論理的思考に焦点を合わせるのではなく、ホワイトボードに実際のコードを書いてもらうのはなぜですか？プログラミング言語は変わりますが、問題解決は変わりません。

私は2番目の候補者を支持します。ロジックを正確に取得するのは難しい場合があります（非常に難しい場合もあります）。IDE、コンパイラ、その他の各種ツールが役立つ場合、構文を非常に簡単に正しく取得できます。

最初の候補者がコンパイラエラーを引き起こすことはないかもしれませんが、彼のコードがあらゆる種類の奇妙な（そしてそれほど奇妙ではない）境界のケースでしばしば失敗するなら、セミコロンを置く場所を知ることはそれほど価値がありません。

実際の構文エラーに応じて、2番目の候補を好むと思います。これは、通常、構文のチェックはマシンに任せるほうがよいためです。

関数の呼び出し時に引数の順序を切り替えるなどの非構文エラーであっても、セミコロンの欠落、閉じ括弧の忘れ、コンマの忘れなどのエラーは、通常、構文ハイライター、コンパイラー、またはコードの初回実行時にキャッチされます、通常使用するすべてのものですが、ホワイトボードでは利用できません。

ただし、いくつかのエラーがあります。技術的には構文エラーのみですが、より深い誤解を示しています。

ポイントを理解するためのやや人工的な例として、すべての変数の前に$を付けるか、forループをとして記述するPythonプログラマーを考えてくださいfor list as item。技術的には、どちらも構文エラーですが、Pythonに限られた露出しかない場合でも、正当な文字とforループについて知っておく必要があります。候補者がphp（またはperl？）を知っていて、自分のpythonスキルについてブラフしようとするのは良い推測です

ホワイトボードはロジックよりもシンタックスに大きな影響を与え、シンタックスの間違いは修正が簡単だという理論上、2番目の候補者をお勧めします。IDEまたはコンパイラのどちらでも通常はそれを行うことができます。

私は13年近くSQLとCSS（私が知っている最も単純で基本的な言語）を書いてきましたが、構文を常に覚えているとは限りません。

私の友人（開発者でもある）はヘッジファンドで働いており、彼は挿入ステートメントの構文を決して覚えていません。

私たちは両方ともW3CSchoolsに行き着きます。

しかし、正直に言うと、優先順位は正しいと思います。構文は重要なスキルではありません。

構文エラーについてのいくつかの考え...私はあなたが両方の構文が正しい必要があることを明確にしたかどうか疑問に思っていました。擬似コードは問題ないと思う人もいます。

また、誰かが言語の長年の経験を主張し、基本的な構文を正しくできない場合は、その主張を疑う必要があります。

構文エラーはさまざまな可能性があるため、誰かがメソッド名を忘れても大丈夫です（私にとって）が、誰かがクラス内のメソッドを参照する方法を知らない場合（ドット表記）、または単純なクラスの場合、この人が長い間この言語を使用していない可能性があります。

構文が正しくなかった人にとって、彼の間違いは適切な言語エディターで簡単に修正できたと思いますか？もしそうなら、私は彼に投票します。

私がここで考えているのは、構文エラーは制限内で許容されるということです。

ジュニアアシスタントプログラマーまたはソフトウェアツールでさえ、ロジックが良好であれば、悪い構文を見つけて修正できる可能性があります。悪いロジック...修正はあまり保証されません。すべてのプログラマーが台無しになります。私は、ねじ込み式のものを見つけて修正しやすい方を選びます。

問題が微妙で、ほとんどのインタビューの質問がそうでない場合を除き、最初の候補者は失格となります。アルゴリズムの設計よりも言語構文を学ぶ方がはるかに簡単です。現在の技術の経験がなくても、複数の言語で成功した仕事の歴史を持つプログラマーを雇います。今日何かをする必要がある場合、これは最善の戦略ではありませんが、今後12か月間に多くのことを行う必要がある場合は、特定の経験よりも常に一般的な能力を選択します。

構文チェックはコンパイラの目的です。コンパイラはロジックを改善することはできませんが、構文を修正する方法を伝えることができます。つまり、コンパイラを使用してコードを記述するジョブは、論理的には構文的に正しいよりも本質的にはるかに価値があります。

インタビューは常に厄介な状況です-外に出たときに、あなたが言ったはずのすべてのことをすぐに考えるか、質問への正しい答えとあなたがそれらを尋ねたいが忘れていたものを考えるので、あなたはこれを伝えることができます。したがって、これを考えると、構文エラーのない完全に記述されたコードを期待するのは非現実的です。

さらに、完璧なコード（ホワイトボード上の！）に対する期待は、インタビュアーと一致しない場合があります。たとえば、私が出席したあるインタビューで、クラスを書くように頼まれました。コピーコンストラクター。それで、私はa = bを設定する以外は何もしませんでしたが、彼を満足させるのに十分でした。問題に対する私の期待はコピーアクターを必要としなかったので、解決される問題に無関係であるとは考えていませんでした-完全に準拠したコンパイルコード（彼の隠されたコーディング標準）を書く必要はありませんソリューションの私の理解。（この同じインタビュアーも私の解決策を好まなかった。それは彼がそれをどのように行うかではなかったので、明らかに間違っていた、ため息だ）。

インタビュー対象者の作業コードが必要な場合は、コンパイラーを提供してください。その後、彼らがあなたに請求するときに文句を言わないでください:)

だから、彼が何をしているのかを知っている人のために、言葉をオウムすることはできるが意味を理解していない人のために行ってください。

インタビュー中、インタビュアーはあなたの

1. 問題へのアプローチ
2. 問題を解決するために使用されるスキルと
3. 適切なソリューションを効果的に提供するのにかかる時間

ただし、構文はそれほど重要ではありませんが、問題を解決する際に重要な位置を占めます。構文に大きな間違いがあるため、インタビュアーに感銘を与えることは期待できません。

適切なロジックと構文を組み合わせることで、インタビューであなたのためのトリックを行うことができます。

ロジックが十分であれば、小さなミスや小さなミスは決して犠牲になりません。

さらに、適切な形状の構文を簡単に作成できるIDEが利用できる場合があります。しかし、使用する方法をどこで、いつ、そして最も重要なのはなぜ、唯一の実際の被写体の適切なロジックや知識を持つ人に知られているであろう。

コードを書くために、ホワイトボードやメモ帳以外のものを提供することを望みます。

2番目の候補者と一緒に行きます。..

優れたJava開発者、優れたC＃開発者、優れたC ++開発者などを望んでいる人もいます。もしそうなら、Aを使ってもっと力を入れましょう。私が抱える懸念の1つは、彼らが問題を解決する理由がない場合、どうすればビジネス上の問題を推論して解決できると期待できるかということです。

他の人々は、必要な言語で作業できる優秀な開発者が欲しいだけです。彼らは問題を考え/モデル化し、それをどんな言語でも実装します。.NETが突然Javaに移行する、またはその逆を行うと判断した場合、これらは開発者であり、飛び跳ねたり学習を拒否したりしません。また、独自の言語を備えた何らかの自動化パッケージ/計算パッケージを入手し、いくつかのタスクを自動化する必要がある場合、これらはそれを行うことができる開発者のタイプです。実生活の例...古い雇用主のカスタム描画領域の郵便番号を抽出するために、マッピングソフトウェアパッケージ用のカスタム専用スクリプト言語を把握する必要がありました。別の例...私の現在の雇用者は、レポートを書くためのカスタム言語を含む独自のプロパティ管理システムを持っています...いずれにしても、

また、ホワイトボードには余分な圧力/神経質があるため、誰も最高の状態ではありません。加えて、コーディングするたびに完璧なものになることを非常に疑います。コンパイルするか、単に実行していくつかのエラーを見つけると思われます。また、言語によって異なります。Cは十分に小さいので、おそらくほとんどの言語/コアライブラリを記憶できます（ただし、必要ありません）。Java / C＃には非常に大きなライブラリがあり（頻繁に変更されるため）、ライブラリを記憶することは問題外です。

また、複数の言語を知っていることはあなたに反する可能性があります。C＃とJavaは互いに干渉します。しかし、特にC＃/ Javaに加えてスクリプト言語と関数型言語を知っている場合は、複数の言語を理解することで視野を広げることもできます。

それでも、両方の候補者が正しいロジックで問題を解決する場合、正しい構文を持つ人がおそらく利点を持っています。問題を解決しても解決しない場合は、個人的に問題を解決できる人と一緒に行きます。

それでも誰かがJavaの専門家であると主張し、ifステートメントまたはwhileループの使用の配列を宣言できない場合、嘘をついている可能性があります。しかし、誰かがJavaの専門家であるが、最近多くのC＃を習得し、Mapなどをやろうとしていることを理解しているかもしれません。 .Lengthまたはstring.length（）の代わりのstring.length（）/ string.Length / string.length ...ちょっとしたことは許します。または、ライブラリ呼び出しの引数の順序を忘れた場合。または、ここまたはそこにあるタイプミス/セミコロン....

私はそれらのいずれも取りません。

プログラマーが問題解決が得意でない場合、優れた構文は役に立ちません。そして、与えられた言語の構文が貧弱だということは、候補者がその特定の言語に慣れていないことを意味します。直接的な経験がないかもしれません。

とにかく、ロジックは構文よりもはるかに重要です。

それは、いつものように、依存します。構文エラーが比較的小さい場合は、無視します。それらが地球を揺るがすほど巨大である場合、私はそれらに注意を払い、なぜそこにあるのかを推測しようとします。

論理エラーは構文エラーよりも悪いと思います。後者はほとんど常に機械的に捕らえられ、前者はそうではありません（ある程度、あなたが書いている言語に依存します。推論とチェック）。

それは間違いなくインタビューの位置に依存し、おそらく言語にも依存します。

C ++に取り組んで、構文にsyntax音を立てている人がいるのは怖いです。C ++は暗いコーナーでいっぱいで、トラップは基本的にどこにでもあります。構文のon音は、言語への不十分な説明を意味し、C ++初心者は多くの間違いを犯します（他の人が時々しないとは言いません）。

質問に答えるには：

• 単純な開発者のポジションを埋める必要がある場合は、C ++構文を十分に把握してください。彼は輝きませんが、あまりにも多くの大惨事を引き起こすべきではありません。
• 主任開発者のポジションを埋める必要がある場合は、どちらも受け入れません。リード開発者は経験と論理の両方を持っていることになっています。

警告が1つだけあります。経験の不足を認める人々です。理想的には、選択した言語でコーディングするか、必要に応じて擬似コード（学生など）でコーディングする必要があります。

実を言うと、C＃イベントの構文を手で書き出さなければならないとき、私はまだ忘れています。それは時々インタビューで起こります。キーボードでコーディングするときに問題はありません。

構文を覚えることはできないが覚えることができる人ではなく、コーディングできる人を選んでください。

就職の面接であっても、紙/ホワイトボードでコードを書いているときは、基本的に構文の大部分をスキップします。私はセミコロンを使用せず、メソッド呼び出しなどをします。コード自体よりも、実際に基本的なコードの4行を説明する文章を書く可能性が高くなります。本当に、私はphpのような擬似コードを使用し、それをしている間、私がやっていることを話し、そして私がつやつやすることを説明するために簡単なコメントを書き留めます（理論的には、プログラム）

インタビューでコーディングするときの私の目標は、タイピストがメモ帳に入力して実行したものを口述するのではなく、問題の解決方法を示すことです。

簡単に言えば、最初のプログラマーがなぜくだらない構文を持っていたのかを検討する必要があると思います。彼はそれを非常によく知っていましたが、インタビューには無関係であると考え、この仕事の難しい部分（論理的および問題解決）に集中することを好みました。

論理的に答えを満たせない人は資格がありません。私たちの業界には、準拠しているが実際にすべきことをしておらず、エラーやエッジケースを処理していないガベージコードを作成している人が多すぎます。

二人目は、エラーの種類と数、およびあなたが書くことを期待していることの難しさに応じて、資格がない場合と資格がない場合があります。SQLの用語（私が書いている言語）で、明示的な結合の構文を覚えていない人は、データベースのクエリを必要とするジョブには適格ではありません。例外はありません。寛大なCTEの作り方を覚えていない人（しかし、存在することを知っていて、それを使用しようとする人）はそうではありません。言い換えれば、私は常にあなたが書いている基本的なコードに対して構文がより正しいと期待するでしょうが、たまにしか行われないことや複雑な構文に対してはそうではありません。

関連分野で優秀な資格を持っているが、特定の言語の最低限の知識しか持っていないことを知っていた人を考えていたら、おそらく構文エラーもより寛容になるでしょう。私はむしろ、SQL Serverの仕事のために平凡なSQl Server開発者よりも優れたOracle開発者を雇いたいです（もちろん、SQL Serverの優秀な人が最適です）。 Oracleで実行します。JavaとC＃の人々についても同様です。優れた問題解決スキルを持つ人は優れた言語スキルを持つ人に勝りますが、両方を持つ人は毎回勝ちます（時々見つけるのは難しいです）。