面接した会社のプルリクエストを書くのは本当に不適切だったのでしょうか？

明らかにこの会社にとっては良い戦術的な選択ではありませんでしたが、わざわざ公開リポジトリを立ち上げて、プルリクエストを提出する勇気がある人を軽蔑するのはかなり馬鹿げています。プルリクエストに「No」と言うことは、ほとんど負担にはなりません。

もし私が面接官だったら、会社に本当に興味を持っていることを示し、公開リポジトリでオープンソースプロジェクトを扱う方法を知っていることを示してボーナスポイントをあげていたでしょう。

仕事のオファーが来ているのだから、提出したコードが高品質であることを確認してください（他の誰かに見てもらいましょう）、コードやプルリクエストのコメントは謙虚で丁寧にしてください。

ここで私が最もため息をつくのは、"もっとシンプルで将来性のある方法で一つの関数を書く “という部分です。私はあなたのコードを見ていませんし、あなたの変更の文脈を理解していませんが、バグを修正したり、機能を追加したり、パフォーマンスを向上させたり、プロジェクトのメンテナが意味のあることをしたようには聞こえません。多くのオープンソースプロジェクト（そしてクローズドソースの開発プロジェクトもそうです）は、ウィキペディアの記事のように、誰もが小さな変更を常に行うように奨励されているわけではありません。どんな変更にもゼロではないコストがかかります：レビューやテスト、承認にかかる時間、何かを壊すリスク（堅牢なテストスイートを使っても）、より少ないチームメンバーが理解できるものを作ること、などなど。どんな関数でも書く方法は無限にありますし、既存の作業コードを定期的に変更して個人的な "ベスト "の定義を満たすようにしていては、何もできません。リファクタリングをするときには、初めての貢献者ではなく、プロジェクトのメンテナが参加する可能性が高く、通常は何らかの正当化を伴うものです。これらは規範であり、他の規範と同様に様々であり、一般的には教えられるというよりも、浸透して吸収することが期待されているものです。もしあなたが最近卒業したばかりであれば、その時にはこれらのどれもが特に明らかになっていなかったかもしれません。しかし、メンテナからすれば、あなたのことを正当な理由もなく作業コードを書き換えるような人だと思っていたかもしれません。このことは、彼らについての多くのことを教えてくれますし、彼らと一緒に仕事をすることがどのようなものであったかを教えてくれます。

**

彼は、私が大学の新卒者として彼らよりも多くのことを知っているように見えて、彼らがそれをどのようにコード化したかを考慮していないと言いました。

問題は、あなたがプルリクエストを発行したことではなく、あなた自身が傲慢で無知で、自分の限界を知らないように見える何かのためにそれをしたことです。あなたは彼らのコードを作るようにあなたの変更を記述します “はるかにシンプルで将来性のある”;それは彼らが同意しないことを上記の引用されたセクションから明らかであると思われます。さらに、彼らはあなたよりも経験豊富で、彼ら自身のコードベースに精通しているので、彼らが正しく、あなたが間違っている可能性が非常に高いのです。彼らがイライラしたのは、あなたがプルリクエストを出したからではなく、あなたが自分の限界を理解していないように見えたからであり、あなたが提出した提出物の中で彼らのスキルを尊重していないように見えたからです。おそらく、あなたは面接中にこのような印象を与えてしまったのでしょう。

最後に、特定の面接の特定の部分をあまり読み込まないでください。あなたは知りません。この挫折に執着しないで、代わりに次のアプリケーションに焦点を当ててください。頑張ってください。

“不適切 "というのは最良の言葉ではないかもしれませんが、"戦略的ではない "というのが正確でしょう。

技術的な分野ではおそらくまだ比較的新しい労働者のように聞こえるものとして、あなたが学ぶ必要がある最初のことの一つは、何かをどのように行うかについての意思決定、そしてそれを変更する価値があるとき、それは単純な問題ではないということです。あなたが何かを変更したいという衝動に駆られていることを考えると、変更のコスト、何かがそれまでの方法で行われていた複雑な理由、またはあなたのアイデアが導入するであろう新しい問題の全範囲を理解せずに、「新しくてピカピカのものを崇拝している」と非難されることがよくあるでしょう。

それとも、彼らはあなたがうっとうしいと思った心の狭い人たちなのかもしれませんね。変更は、既存の意識を壊すことに本当のコストを持っているので、新しい方法は、問題の方法でsubstantially_ better_である必要がありますし、理論的に少し良いだけではなく、現代の傾向や考え方に少し整列されていません。

もしあなたが何かに "ボランティア "したい場合は、に頼まれずに、あなたはおそらく、すでに働いていたものの大胆な書き換えを行うよりも、ユーザーに影響を与える本当の顕著なバグに取り組むためのより良い受信を得るでしょう。未解決の問題を理解したら、ファーストクラスのコミットメッセージを使って、できるだけ小さく最小限の diff で変更を加えられるかどうかを確認してください。なぜこの変更が問題を解決するための正しい方法なのかを明確にし、現在のコードのスタイルや方法論にシームレスにフィットするようにしてください。承認が簡単で、トレードオフの複雑な感情を呼び起こさないようなプルリクエストをしてください。

もしあなたが本当にセクションを書き直す必要があると思っているのなら、あなたが貢献するようにaskedされて、優先順位、歴史、コードベース全体の性質を認識するまで、その考えを保留してください。そして、あなたがしたい変更が彼らの優先順位や計画と一致していない理由を理解する準備をしてください。やや反直感的に、その伝統にシームレスにフィットする修正を行うことによって、現在のコードの理解を示すことができればするほど、新しい方向に物事を取るために信頼を得る可能性が高くなります。また、より非公式な方法で抜本的な変更をさりげなく浮かんでみることもできます。

机の反対側から話す - 個人的なレベルでは、応募者がGithubのリポジトリや他の種類のポートフォリオを持っていて、会社が何をしているかについてのバックグラウンドリサーチをしてくれたときは、とても嬉しいです。これは応募者全体の3-5%のようなものです。

当社のコードを修正/改善することで、これらの両方を非常に直接的に実証する可能性のある応募者？彼らはおそらく偉大な雇用を逃し、あなたは確かに恐ろしい文化に参加することを避けました。

あなたは何も間違ったことをしていません。もしコードの一つの機能をリファクタリングするプルリクエストが彼らの船を揺るがしたとしたら、それはより複雑な相互作用のための多くの余地を残さないでしょう。

プロジェクトメンテナ(またはレビュアー)の役割は、コード自体から政治的なもの(認識された傲慢さや無能さ)を切り離し、コードを客観的にレビューすることです。もしレビュアーがPull Requestを受け取って、政治的なこと（"How dare you raise this PR?“）だけに焦点を当て、コードをレビューしないのであれば、彼らの役割は非常に効果的ではありません。

正直に言うと、彼らはあなたのような優秀な人を探しているようには聞こえません。

@Kyralessaさんがおっしゃったように、それはあなたのPRではなく、あなたのcommentだったかもしれません プルリクエストのコメントとして何を入力したのですか？それがここで欠けている重要な部分です。あなたは無意識のうちに、オリジナルの開発者がバカで、あなたがはるかに優れていることをコメントで伝えていたかもしれません。ここでのキーワードは「意図せず」です。開発者として、それは非常に簡単なことです。あなたがやったとは言いませんが、確実に可能性はあります。 他の人が言っているように、もう一つの可能性としては、彼らはコードを過保護にしていて、おそらく彼らは（同じ船に乗っている他のすべての人と同じように）大きな失敗をしないことを確認するために重要な指導と監督を必要とするだろうイニシアチブを持つ新鮮な大学の卒業生を指導することに対処したくないということです（私は数年前に彼らの一人であったここでの経験から話しています）。

…Or they don’t know how to interview 彼らはただ、彼らが望む候補者のタイプのためにインタビューする方法を知らないかもしれませんし、インタビュープロセスの彼らの側を台無しにしました。

ほとんどの企業では、最終的にプルリクエストを拒否する正当な技術的理由があったとしても、あなたの行動はポジティブに見られるでしょう。あなたが書いたコードが、彼らが最初のインタビューからあなたが持っていたと仮定した経験を持っていないことを彼らに納得させる完全なナンセンスであったか、またはあなたが何とかコメントで彼らを侮辱するために管理していた場合を除き、それは、です。

仝それにしても、私の方が大学を卒業したばかりなので、私の方が知っているように見えて、なぜそのようにコーディングされたのかを考えたことがないと言っていました。仝それにしても、この会社で働いていて、このような変更を提案した場合、このような扱いを受けることになるのではないでしょうか。あなたが提案した方法ではなく、彼らが提案した方法でコードを作成しなければならない正当な理由が彼らにはあるということです。言い換えれば、私はあなたのコードはおそらくもっとシンプルだが、もっと悪いものだったと非常に信じています。

どんなに 、PRに失礼なコメントが含まれていない限り、単純な提案が「不適切」であるというシニアの仮定、それは「私はあなたよりも多くのことを知っている」と言う傲慢な方法であり、大学教育を受けた候補者cannot、実際には、彼らと同じくらい、またはそれ以上のことを知っているというは、トリプル赤旗**であるため。

• それはあなたがそこに働いていた場合、あなたの良いアイデアも、あなたがジュニアであることを理由に完全に解雇されるだろうという疑惑を提起し、ちょうどので、シニアは自分の役割と給料**を正当化することができます。
• それは彼らが自分の専門知識についていくつかの深刻な不安を持っていることを示しています - そして私はそれらの不安が正当化されるかもしれないと思うように傾いているでしょう。
• そのシニアがソフトウェアの正式な教育を受けていないことが起こる場合は、彼らが学位の重要性を軽視しようとするための追加のインセンティブがあります**と1つはそれから得る専門知識は、彼ら自身のマネージャーは最終的にも証明書を持っている同様に経験豊富な開発者とそれらを置き換えるようにしないようにしてください。

ちょっと視点を変えてみると、私は以前どこかで面接を受けたことがあるのですが、その際に先輩たちにシステムの構築中のシステムについて、ある過激な提案をしました。彼らはそれを歓迎し、検討しただけでなく、彼らはまた、その後まもなく私にオファーをしました。

そのような環境はdo存在します - すべての企業が、知識が厳密に先輩から後輩に流れる一方通行の教師/学生モデルを採用しているわけではありません。また、この業界の多くの先輩は、企業がどう呼ぼうと「エンジニア」ではありません。

問題はあなたの「改善」がナイーブで人工的なものだったということです あなたがどれだけ短くできたかということを私は知っています

これは私にはいつも起こることです。私はデータが多くのユーザーにサービスを提供できるように複雑なシステムを構築しています。そして、誰かがやってきて、「こんなものはいらない！」と言うのです。あなたは単純な問題をはるかに複雑にしています。" そして、彼らはハックとスラッシュ、および単純なシステムthatはよく彼らを提供していますにそれを削減し、彼らは自分自身に金星を与えます。

**彼らは唯一のユーザーではありません。だから、そこには何かがなければならない…会議、再教育、苦味、ロールバック、そのすべてが不必要でした。難しいのは問題点を理解して表現すること。あなたは、簡単な部分を簡単にするために、難しい部分を短絡的にしてしまったのです。

コーディングは王様だと教えられても、まあ、そうではありません。もう一方の側はお金になるところです：コーディングが可能で、すべてのユーザー/ニーズに対応できる仕様を書けることです。(スケールのもう一方の端では、オールシンギング/オールダンスのソリューションを設計することも可能ですが、書ききれないので、設計するためにコーディングを知る必要があります)。あなたはコードが解決しようとしている問題を完全に理解していませんでした。初心者」とは、その傲慢さが学習を妨げたり、他人の経験や年長者を一般的に尊重したりする初心者のことです。それはあなたがとても簡単にそのコードをとても短くすることができたので、それは後者があなたに適用されるように思える、そして、それはこれがtoo easyであったことをあなたに発生しませんでした、彼らはそれをとても複雑に書いていた理由がなければなりませんでした。

そうですね。プログラマーがコントロールできない特定の業務機能やルールをサポートするためにコードが書かれている場合もあります。

しばらく見ていたら、1つの機能を書くのにもっとシンプルで将来性のある方法を見つけたので、現在面接中であることには触れずに変更を加えてPRを公開しました。自分たちが全てを把握していると。真実は、あなたがそれを考え出したならば、他の人がやったことをググることによって、明らかにあなたがより良い方法を “見つけた "ので、他の誰かが同様に持っているかもしれないということです。あなたが何かを考えるときはいつでも、あなたは停止して、現在の方法で何が達成されているかを確認するために、最初にそれについて尋ねる必要があります露骨に何かを考えています。ビル・ゲイツはWindowsを構築するために自分の方法をググったのではなく、彼が考えて実装したのです。同じことができない限り、"より良い方法 "を見つけたわけではありません。あなたはただ最後の人よりも良い方法をググっただけです。

それは私がこれをすることは本当に不適切だったのですか？

彼らのマスターへのPRとして、はい、それはわずかに不適切でした。おそらく面接で共有できるあなた自身のブランチ。"Xのやり方を見て、調べてみたら、将来の証明にもなるし、修正もしやすいYを見つけました。あなたたちが書いたのは理由があってのことだとは思いますが、あなたたちのコードをもとにしたコンセプトを実証してみたかったのです。”_ git で @ 記号を使えば、議論の連鎖を開くこともできることは知っています。

@user あなたたちがここでXをやっているのに気づいたので、Yをつけてみました。あなたのコードを読んで修正する能力を見せたかったのです。その結果がどうなったかは想像がつくでしょう。

他の回答に補足すると、

*あなたのコードがその特定のコードベースで本当に正しくて有用なものであることを確認していますか? *

あなたが修正したコードはよりシンプルで堅牢に見えるかもしれません。

おそらく、あなたのプルリクエストで動作の一部が変更されたのかもしれませんが(バグを修正したと思っているかもしれません)、そのバグに依存しているコードがあるかもしれません。例えば、あなたのコードはマルチスレッド環境では動作していないかもしれませんし、コードが扱うデータは、古いコードをより良く、より速く動作させるような明らかでない特性を持っているかもしれません。

経験豊富な開発者にとっては明らかなはずの、愚かな理由(コードのバグや、コードの動作が遅いなど)を見落としているかもしれません。結局のところ、彼らは長い間このコードを使っていて、それがどのように動作するかをもっとよく知っているはずです。彼らが「[that [you] haven’t considered why they coded it how it was」と言ったという事実は、これを示唆しています。

これは言った、私はPRを開くことは何も悪いことではないと言う他の人に同意します。しかし、どんな新しいコードベースでもそうであるように、多くの場合、メンテナと話し合った方が良いでしょう。あなたがその時にインタビューのプロセスにあったことを考えると、あなたは単にインタビューでその質問を提起した可能性があります。

誰かのオープンソースプロジェクトのためにPRを書くことが intrinsically不適切であるとは考えにくいです。それは、コードや態度がナイーブだったか、傲慢だったか？親切でフレンドリーだったか？それ以上のことを知らなければ、適切かどうかを判断するのは難しいです。あなたのPRを見つけました。そして、それは私にそのような印象を与えたので、私はここでそれを共有することにしました。あなたにも会社にも秘密を漏らしたくないので、軽い判断ではありませんでしたが、それなりに実質的な文脈を持ってきてくれると思ったからです。具体的な詳細がないことで、確かに多くの根拠のない憶測につながっています

私は、カスタム変数、文字列、メソッド、コメントをすべて変更することで、PRを完全に匿名化し、難読化しました。ここでは、それは、その全体では、次のとおりです：

# if this is invoked with an argument then use that for target
- target = 'jadaskjafjldfsfsasf'
  if len(sys.argv) > 1:
      arg = sys.argv[1]
      if arg == '...':
          print '...'
      else:
          target = arg
-
- match = some_lookup(target)
+ match = some_lookup(target)

  if match:
      print "..."

コードは、ハードコードされたランダムな文字列に target を初期化します。(注意：この部分を難読化するために文字列の文字を shuffled しているだけです)。引数が与えられていない場合、some_lookup(target)は意図的に変なデフォルト文字列を検索することができないため、マッチを生成することに失敗します。

あなたの修正は改善されたように見えます。私自身、コードレビューの中で躊躇することなく、この点を指摘します。そして、私はあなたが書いたのと全く同じ25ワードのフレンドリーで対立しないコミットメッセージを書いているのを簡単に見ることができました。そして、それはプロとしての敬意を持って誠実に行われている場合、a PRは、面接時を含めて不適切であることはありません。