去年我在面试一家公司的时候就发生了这样的事情，当时我在面试一个没有被录取的职位。我目前在其他地方工作，但我想知道在以后的应聘过程中，
我的电话筛选很顺利，据他们说–他们说我是一个很强的候选人，第一次技术面试有一个工程师，面试很顺利。在第二次面试和最后一次面试之间，我发现他们的软件在GitHub上有一个开源的API，用Python写的。我看了一会儿，发现一个函数的写法更简单，更有前途，于是我打开了一个PR，并没有提到我目前正在面试，
当我们开始第三次面试两个工程师的时候，其中一个工程师提到，他看到我的pull请求，我打开它不合适。他说我作为一个刚毕业的大学毕业生，感觉我比他们懂的多，而且我还没有考虑过他们为什么要这样编码。最终我没有得到这份工作，
我这样做真的不合适吗？
显然，这对这家公司来说，并不是一个好的战术选择，但如果去建立一个公共资源库，然后不屑于让人厚颜无耻地提交拉人请求，那就相当愚蠢了。对一个pull请求说 “不 "几乎不是一种负担。如果我是面试官的话，我会给你加分，因为你对公司有真正的兴趣，并表明你知道如何在公共资源库中使用开源项目。
既然工作机会就在眼前，你就应该确保你提交的代码是高质量的（找别人看一下），并且在代码中或在拉动请求中的任何评论都要保持谦虚和礼貌。
这里最让我停顿的部分是 “一个更简单、更适合未来的写一个函数的方法"。我没有看过你的代码，也不了解你的改动的背景，但听起来你并没有修复一个bug，增加一个功能，提高性能，或者做了一些项目维护者认为有意义的事情。我可以理解为这种性质的修改提交一个拉动请求可能不会给人留下最好的印象。
很多开源项目（也经常是封闭式的源代码开发项目）并不像维基百科的文章那样，鼓励每个人都做一些小的修改。任何改动都会带来非零成本：审查、测试和批准的时间、破坏的风险（即使有强大的测试套件）、创建的东西较少的团队成员理解的东西等等。因此，很多项目并不是特别注重改变东西，因为有无数种方法可以写出任何函数，如果每个人都定期改变现有的工作代码，以满足他们个人对 "最佳 "的定义，那么就不会有什么结果。当需要重构的时候，更有可能涉及到项目维护者，而不是第一次贡献者，而且通常会有一些理由。这些都是规范，就像所有的规范一样，它们也是各不相同的，一般来说，这些东西都是希望你通过潜移默化的方式来拾起，而不是被教导。如果你是应届毕业生，很可能这些在当时都不是特别明显。
大多数拉取请求都是为了解决一个比较明显的需求：修复一个bug或者增加一个功能。即使在这种情况下，通常最好先和维护者讨论一下这个任务，因为他们可能有你不知道的上下文和偏好。
所以我不认为在面试过程中提交一个pull request本质上是不合适的（这当然显示出了他们的兴趣和热情），但是从他们的角度来看，他们可能把你看成是一个很可能没有什么理由就重写工作代码的人，然后他们很不幸地对你做出了消极的、居高临下的反应。这一点，可以帮助你了解到很多关于他们的信息，以及与他们合作的情况。
**你误解了他们给你的反馈，并且把重点放在了错误的部分*
他说，这就像我作为一个刚毕业的大学生比他们知道的多一样，我还没有考虑过他们为什么要这样编码。你把你的改变描述为使他们的代码 “更简单，更面向未来"；从上面引用的部分看来，他们显然不同意。更重要的是，由于他们比你更有经验，而且熟悉他们自己的代码库，所以很可能他们是正确的，而你是错误的。
毕业生在毕业后强烈地高估自己的能力是很常见的。他们并不是因为你发出了拉人的要求而感到恼火，而是因为你在提交的材料中似乎表现出对自己的极限缺乏理解，对自己的能力缺乏尊重。很可能，你在面试过程中加重了这种印象。
最后，不要对任何一个特定的面试部分看得太多：可能这与你没有得到这份工作无关，他们只是有一个更好的候选人。你不知道。不要纠结于这个挫折，而是把注意力放在下一次的申请上。祝你在求职路上好运!
“不恰当 "可能不是最好的词，但 "不具有战略意义 "可能是准确的。
作为一个听起来可能仍是技术领域的新手，你首先需要学习的一件事是，关于如何做一件事的决策，以及什么时候值得改变它，并不是一件简单的事情。既然你有动力去改变一些已经起作用的东西而不被要求改变，那么你很可能会发现自己经常被指责为 "崇洋媚外"，而不了解改变的成本、复杂的原因，或者你的想法会带来的新问题的全部范围。
或者，也许他们只是心胸狭隘的人觉得你很讨厌。
事情是，在某种程度上，什么是客观上最好的并不重要，最重要的是在某一特定时间点上，什么是对组织的主观上最好的。变革在打破现有的意识上是要付出真正的代价的，所以一个新的方法需要在重要的方面实质上更好，而不仅仅是在理论上更好一点，或者更符合当代的趋势和思维。
如果你想在一些事情上 "自愿”不被要求，你很可能会得到更好的接待，因为你要解决影响用户的真正的突出的bug，而不是对已经起作用的东西进行大胆的改写。如果你了解到一个未解决的问题，看看你是否可以做一个尽可能小的、最小的改动，用一个一流的提交信息来进行修改。使其明显地说明为什么这个改动是解决问题的正确方法，并使其与当前的代码风格和方法论无缝地契合。
如果你真的认为某个部分需要重写，那就把这个想法留到你被要求做出贡献，并且了解优先级、历史和整个代码库的性质之后再考虑。并准备好理解为什么你想做的改变与他们的优先级和计划不一致。有点反其道而行之，你越是能通过做一些与代码传统完美契合的修复来表现出对当前代码的理解，你就越有可能获得信任，从而在新的方向上有所作为。你也可以用一种更非正式的方式随意地浮现出剧烈的变化–“嘿，我在想，如果我们把这部分重写成使用主轴折叠，我们可以把这部分做得更好"，然后在实际操作之前，你可以先评估一下大家的反应。
从另一个角度来说，从个人的角度来说，当一个申请者甚至_有Github repos或其他类型的投资组合，并且对公司的工作做了一些背景研究时，我很高兴。这就像所有应聘者中的3-5%。
一个有可能通过修复/改进我们的代码来直接证明这两点的应聘者？他们可能错过了一个很好的招聘机会，而你当然也避免了加入一个糟糕的文化。
正如@Kyralessa所说，可能是你的comment而不是你的PR 你在拉取请求中输入了什么评论？这就是这里缺失的关键部分。你可能在评论中无意中传达出了原开发者是白痴，而你是远超原开发者的意思。这里的关键词是 “无意中"。作为一个开发者，这很容易做到。我不是说你这样做了，但这是一个肯定的可能性。
…… 或者说他们害怕面对一个刚出道的新手 另一种可能是他们对自己的代码过于保护，也许他们不想去指导一个刚毕业的大学生，因为他们需要（就像其他同舟共济的人一样）大量的指导和监督，以确保自己不犯任何大的错误（我在这里说的是经验，因为多年前就已经是他们中的一员）。
……或者他们不知道如何面试* 他们可能只是不知道如何面试他们想要的候选人类型，在面试过程中搞砸了自己的那一面。
在大多数公司，即使最后有很好的技术理由拒绝你的拉人请求，你的行为也会被正面看待。
也就是说，除非你写的代码完全是废话，让他们相信你没有他们在第一次面试时认为你有的经验，或者你在评论中侮辱了他们。
他说，我作为一个刚毕业的大学生，感觉我比他们了解的多，而且我还没有考虑过他们为什么要这样编码。我最终没有得到这份工作。
没有得到这份工作，你应该庆幸自己没有得到这份工作，因为你因为这个要求而得到的待遇可能是你在那家公司工作并提出这个（或其他任何改变）的待遇的一个体现。是的，我觉得很有可能是你的公关不适合他们的，他们真的有充分的理由让他们的代码变成这样，而不是你提出的那样。换句话说，我非常相信你的代码可能更简单，但更糟糕。 *
**然而，除非你在PR中加入了一个粗鲁的评论，否则，学长的假设认为一个简单的建议是 “不合适的"，认为这是一种傲慢的说法，说 "我比你知道的多"，一个受过大学教育的候选人不能，事实上，知道的东西和他们一样多或更多，是三面红旗*因为。
—-这让人怀疑，如果你在那里工作，连你的好主意都会被完全以你是个小辈为由而否定，只是让学长们为自己的角色和工资待遇开脱。 - 这表明他们对自己的专业知识有一些严重的不安全感–而我倾向于认为这些不安全感可能是合理的。 - 如果这位前辈恰好在软件方面缺乏正规的教育，那么他们就会有的动机去淡化学位的重要性和从学位中获得的专业知识，以免他们自己的经理最终用同样有经验的开发人员取代他们，而他们的经理也会用同样有证书的开发人员取代他们。
只是想给大家一个参考，我曾经在某地面试过，在面试过程中，我向前辈们提出了一个有点激进的建议，说是他们正在建立一个系统。
这样的环境是存在的–不是所有的公司都采用单向的师生模式，知识从学长到学姐都是单向的。(记住，如果你已经毕业了，那么你就不是一个 "学生"，而且这个行业的很多学长也不是真正的 "工程师"，不管公司如何称呼他们。)
问题是，你的 “改进 "很天真，也很人工，我知道，因为你的 "改进 "是多么的短小精悍，
这种情况经常发生在我身上。我构建了一个复杂的系统，让数据为很多用户服务。然后有人来了，说："我们不需要这么多的schtuff! 你把一个简单的问题弄得太复杂了。” 然后他们就把它简化成了一个简单的系统，为他们提供了很好的服务，然后他们给自己颁发了一颗金星。那么就必须要有一个东西………..会议，再教育，再教育，苦口婆心，回滚，所有这些都是没有必要的。
编码是容易的部分。难的部分是理解和表达问题。你把难的部分短路了，是为了让容易的部分变得更容易，
如果你被灌输的是编码为王，嗯，其实不然。另一个方面是钱的所在：能够写出一个可编码的规范，并处理所有用户/需求。在另一端，也可以设计出全唱/全跳的方案，但不可写，这就是为什么你需要懂编码来设计的原因）。
这才是核心所在。你没有完全理解代码所要解决的问题。
而你把这一点以一种壮观的方式展示给他们。
在游戏中，"新手 “只是一个新手。而 "新手 "则是指那些自大的新手，他们的傲慢让他们无法学习，也无法尊重别人的经验或长辈一般。后者似乎更适用于你，因为你能把那段代码写得如此轻松，那么短小精悍，没有想到这****太容易了，一定有他们写得这么复杂的原因。
而我还没有考虑过他们为什么要这样编码。
是的没错。在某些情况下，写代码是为了支持某个特定的业务功能或规则，而程序员无法控制的。
我看了一会儿，发现了一个更简单、更有未来感的写法，我开了个PR，改了一下，没有提到我现在正在面试，
作为一个年轻人，我们喜欢认为自己很聪明。认为自己想通了。事实是，如果你想到了，别人可能也会想到，因为你显然是通过google搜索别人的做法 “找到 "了更好的方法。每当你想到这么明目张胆的事情时，你应该先停下来问一问，只需确定目前的方式是什么，就可以完成。比尔-盖茨没有用谷歌的方式来构建Windows，他想到了，并实现了。除非你也有能力做到这一点，否则你还没有找到 "更好的方法"。你只是比上一个人google得更好而已
我这样做真的不合适吗
作为对他们的主子的公关，是的，是的，是略显不合适。也许是自己的一个分支，可以在面试的时候分享一下。"我看到你们是怎么做X的，经过研究，我发现了Y，可以在以后的证明和修改上更方便。我知道你们写这个东西是有原因的，但是我很好奇，想根据你们的代码演示一个概念。”我知道在git中可以使用@符号，甚至可以打开讨论链。也许下次可能最好是在你修改的部分用一个，
@user我注意到你们这里做的是X，但我放了个Y，想展示一下我的能力，看懂你们的代码，进行修改等等
通过给自己的主人公做个PR，本质上和新闻里的那个想做水电工的人，找不到工作，所以决定 “修 "他家小区的煤气泄漏的故事是一样的。可想而知，最终的结果是怎样的。
为了补充其他答案，
*你确定你的代码在那个特定的代码库中确实是正确和有用的吗？ *
你的修复可能看起来更简单，更健壮；然而，很容易让人觉得旧的代码是故意写出来的。
可能你的拉动请求改变了某些方面的行为（你甚至可能认为你修复了一个bug），但是有一些远处的代码依赖于这个bug。例如，你的代码可能不是在多线程环境下工作，或者代码处理的数据可能有一些不明显的属性，使旧代码工作得更好、更快。
我们都知道，你可能忽略了一些愚蠢的原因（你的代码中的bug，或者你的代码运行速度更慢，等等），这对于一个有经验的开发者来说，应该是显而易见的。毕竟，他们已经用这段代码工作了很长时间，可能更应该知道它是如何工作的。他们说 “那[你]没有考虑过他们为什么要这样编码 "这一事实表明了这一点。
这句话，我同意其他人说的，开个PR并不是什么坏事。然而，就像任何新的代码库一样，往往和维护者讨论一下，会更好。考虑到你当时正在面试的过程中，你可以在面试的时候干脆就提出这个问题。
这很难理解为任何人的开源项目写公关怎么会是本质上不合适的。
因此，它必须归结到具体的细节，而我们对这些细节知之甚少。它在代码或态度上是天真还是傲慢？它是否乐于助人和友好？在不了解更多的情况下，我们很难判断是否合适。
我的好奇心让我有了更多的了解。我找到了你的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 "..."
&001
代码将初始化target为一个硬编码的随机字符串。(注意，我只对字符串的字符进行了shuffled以掩盖这部分内容)。如果没有提供一个参数，那么some_lookup(target)将无法产生匹配，因为它可能无法查找到那个有意为之的古怪的默认字符串。
你的修正似乎是一种改进。我自己也会在代码审查中毫不犹豫地评论这个问题。而且我很容易看到自己写出和你写的一样的25字长的友好、非对抗性的提交信息。只要是以专业的、尊重的方式和诚意的方式进行的，的公关是绝对不会不恰当的，包括面试时。