Было ли это действительно неуместно писать запрос на подтягивание компании, с которой я проводил собеседование?

Очевидно, что это не был хороший тактический выбор для этой компании, но довольно глупо идти на проблему создания публичного репозитория, а затем презирать людей за то, что у них есть наглость подавать запросы на вытаскивание. Говорить “Нет” на запрос о вытаскивании вряд ли является обузой. Чёрт возьми, они могли бы просто проигнорировать это.

Если бы я был интервьюером, я бы дал вам бонусные очки за то, что вы продемонстрировали реальный интерес к компании и показали, что вы знаете, как работать с проектом с открытым исходным кодом в публичном репозитории. Это было бы верно, даже если бы присланный код был наивен по поводу решения проблемы.

Так как предложение о работе стоит на очереди, вы должны быть уверены, что присланный вами код высокого качества (попросите кого-нибудь другого взглянуть на него), и держать любые комментарии в коде или в запросе на вытаскивание скромными и вежливыми.

Часть, которая дает мне наибольшую паузу здесь, это “гораздо более простой и перспективный способ написания одной функции”. Я не видел ваш код и не понимаю контекста ваших изменений, но это не похоже на то, что вы исправили ошибку, добавили функцию, улучшили производительность или сделали что-то другое, что мейнтейнеры проекта посчитали значимым. Я вижу, как отправка запроса на подтягивание для незатребованного изменения такого рода, возможно, не оставила лучшего впечатления.

Многие проекты с открытым исходным кодом (и часто закрытые проекты по разработке тоже) не выполняются так, как статьи в Википедии, где каждому рекомендуется постоянно вносить небольшие изменения. Есть ненулевая стоимость, которая приходит с любыми изменениями: время на просмотр, тестирование и одобрение, риск что-то сломать (даже с помощью надежного набора тестов), создание чего-то, что понимает меньшее количество членов команды, и т.д…. В результате, многие проекты не очень любят менять вещи только потому, что; существует бесконечное количество способов написания любой функции, и ничего бы не получилось, если бы все регулярно меняли существующий рабочий код в соответствии со своим личным определением “лучший”. Когда наступает время рефакторинга, это, скорее всего, привлечёт мейнтейнера проекта, а не первого участника, и обычно к нему прилагается какое-то обоснование. Это нормы, и, как и все нормы, они варьируются и, как правило, это то, что от вас ожидают, что вы будете воспринимать через осмос, а не учиться. Если вы были недавним выпускником, то, скорее всего, ничего из этого не было особенно заметно в то время.

Большинство запросов на вытаскивание адресуют более очевидную потребность: исправление ошибки или добавление функции. И даже в этих случаях часто лучше сначала обсудить задачу с мейнтейнером, так как у них может быть контекст и предпочтения, о которых вы не знаете.

Поэтому я не думаю, что когда-либо подавать запрос на подтягивание во время собеседования неуместно (это, конечно, проявляет интерес и энтузиазм), но с их точки зрения, они, возможно, видели в вас кого-то, кто, скорее всего, перепишет рабочий код без особых на то оснований, а затем, к сожалению, отреагировали отрицательно и снисходительно по отношению к вам. Что, к счастью, многое говорит вам о них и о том, каково было бы работать с ними.

Вы неправильно поняли обратную связь и сосредоточились на неправильной части

Он сказал, что это произошло, как будто я знаю больше, чем они, как свежий выпускник колледжа, и что я не думал, почему они закодировали его, как это было.

Проблема не в том, что вы выпустили запрос на вытаскивание, а в том, что вы сделали это для чего-то, что заставило себя выглядеть высокомерным, невежественным, и не осознавая своих собственных ограничений. Вы описываете ваше изменение как “намного более простое и перспективное”; из процитированного выше раздела кажется очевидным, что они не согласны с этим. Более того, поскольку они более опытны, чем вы, и знакомы со своей собственной кодовой базой, вполне вероятно, что они правы, а вы ошибаетесь.

Обычно выпускники выходят из своих дипломов, сильно переоценивая свою собственную компетентность. Они были раздражены не потому, что вы подали запрос на подтягивание, а потому, что вы, похоже, продемонстрировали недостаточное понимание собственных ограничений и неуважение к их навыкам в заявке, которую вы подали. Вероятно, вы усугубили это впечатление во время интервью.

Наконец, не читайте слишком много о какой-то конкретной части интервью: может быть, это не имело никакого отношения к тому, что вы не получили работу, и у них просто был лучший кандидат. Вы не знаете. Не зацикливайтесь на этой неудаче и вместо этого сосредоточьтесь на следующем заявлении. Удачи в поиске работы!

“Неуместный”, возможно, не самое лучшее слово, но “не стратегический”, скорее всего, будет точным.

Поскольку то, что звучит как, возможно, еще относительно новый работник в технической области, одна из первых вещей, которую вам нужно будет узнать, это то, что принятие решения о том, как что-то сделать, и когда это стоит изменить, не является простым делом. Учитывая, что у вас есть стимул изменить что-то, что already работал без просьбы, вы, вероятно, найдете себя часто обвиняют в “поклонении новым и блестящим”, не понимая кост изменения, сложные причины, почему что-то было сделано так, как это было, или полный объем new issues ваша идея будет представлять.

Или, может быть, они просто мелкие люди, которые нашли вас раздражающими.

Дело в том, что в какой-то степени не имеет значения, что объективно лучше, в основном имеет значение то, что субъективно лучше для организации в данный момент времени. Изменение имеет реальную стоимость в разрушении существующей осведомленности, так что новый метод должен быть substanstanly better в ways, что имеет значение, а не просто немного лучше в теории или немного больше в соответствии с современными тенденциями и мышлением.

Если вы хотите “добровольно” на что-то без просьбы о, вы, вероятно, получите лучший прием для решения реальных выдающихся ошибок, которые влияют на пользователей, чем в создании смелых переписывает вещи, которые уже работали. Если вы придете к пониманию неразрешенной проблемы, посмотрите, сможете ли вы внести изменения, которые будут минимально возможны, с помощью первоклассного сообщения о коммите. Сделайте очевидным, почему это изменение является правильным способом решения проблемы, и сделайте так, чтобы оно органично вписывалось в существующий стиль и методологию кода. Дайте им запрос на подтягивание, который easy одобряется и не вызывает никаких сложных чувств компромиссов.

Если вы действительно считаете, что раздел необходимо переписать, за исключением этой мысли, пока вы не задачник, чтобы внести свой вклад, и знаете приоритеты, историю и природу кодовой базы в целом. И будьте готовы понять, почему изменения, которые вы хотите внести, не соответствуют их приоритетам и планам. Что-то контр-интуитивно, чем больше вы сможете продемонстрировать понимание текущего кода, сделав исправления, которые органично вписываются в его традиции, тем больше вероятность того, что вы получите доверие, чтобы принять вещи в новых направлениях. Вы также можете случайно внести радикальные изменения более неформальным способом - “эй, я подумал, что мы могли бы сделать эту часть намного лучше, если бы переписали ее, чтобы использовать складывание шпинделя”, и измерить реакцию до фактического выполнения.

Говоря с другой стороны стола - на личном уровне, я вполне доволен, когда аппликант даже has Github репозитория или какого-то другого рода портфолио, и провел некоторое фоновое исследование о том, чем занимается компания. Это как 3-5% всех заявителей.

Заявитель, который потенциально демонстрирует both из них очень непосредственно, исправляя / улучшая наш код? Вероятно, они пропустили отличную работу, и вы, конечно же, избегали присоединения к ужасной культуре.

Ты не сделал ничего плохого. Если запрос Pull Request, который рефакторирует одну из функций кода, раскачивает их лодку, это не оставляет места для более сложных взаимодействий.

Роль сопровождающего проекта (или рецензента) состоит в том, чтобы высвободить любую политику (воспринимаемую высокомерие, некомпетентность) из самого кода, и объективно просмотреть код. Если рецензент получает Pull Request и only фокусируется на политике (“Как вы смеете поднимать этот PR?”) и даже не просматривает код, они очень неэффективны в своей роли.

Честно говоря, это не похоже на то, что они ищут кого-то вашего калибра, будьте счастливы, что вы присоединитесь к лучшей компании в ближайшее время.

As @Kyralessa said, it may have been your comment not your PR What did you enter as the comment to your pull request? Это недостающая часть ключа. Возможно, вы непреднамеренно сообщили в своем комментарии, что первоначальные разработчики были идиотами, и что вы намного превосходите их. Ключевое слово здесь - “непреднамеренно”. Как разработчику это очень просто сделать. Я не говорю, что вы это сделали, но это вполне возможно.

…. Или они боятся иметь дело с только что вышедшим из игры инициатором Другая возможность, как упоминали другие, это то, что они чрезмерно защищают свой код, и, возможно, они не хотят иметь дело с наставничеством свежего выпускника колледжа с инициативой, которая будет нуждаться (как и все остальные в той же лодке) в значительном наставничестве и надзоре, чтобы убедиться, что они не совершают никаких огромных промахов (я говорю из опыта здесь, будучи одним из них много лет назад).

…Или они не знают, как проводить собеседования Они могут просто не знать, как проводить собеседования с тем типом кандидатов, который им нужен, и испортили свою сторону процесса собеседования.

В большинстве компаний ваши действия были бы восприняты положительно, даже если бы в конце концов имелись веские технические причины отклонить ваш запрос на вытаскивание:

• Это показывает ваш неподдельный интерес к этой позиции, в частности
• Это доказательство того, что у вас есть практический опыт с кодированием

• Это была возможность поговорить о реальном коде во время интервью, вместо вымышленных упражнений по кодированию

• То есть, если только код, который вы написали, не был полной чепухой, которая убедила их в том, что у вас нет того опыта, который они предполагали, что у вас есть с первых интервью, или вы каким-то образом сумели оскорбить их в комментарии.

Он сказал, что мне кажется, что я знаю больше, чем они, как свежий выпускник колледжа, и что я не задумывался о том, почему они зашифровали все так, как было. Я не получил работу.

Считайте, что вам повезло, что вы не получили работу, потому что лечение, которое вы получили для этого запроса тянуть, вероятно, вкус лечения вы бы получили, если бы вы работали в этой компании и предложил это (или любые другие) изменения.

Чтобы быть совершенно ясным: Да, я нахожу весьма вероятным, что ваш пиар не подошел им и что у них действительно есть веские причины, чтобы иметь свой код так, как они делают, а не так, как вы предложили. Другими словами, я очень верю, что ** Ваш код, вероятно, был проще, но хуже. ** Как бы то ни было** , если только вы не включили грубый комментарий в PR, предположение старшего о том, что простое предложение “неуместно”, что это высокомерный способ сказать “я знаю больше, чем вы”, и что кандидат с высшим образованием cannot, на самом деле, знает столько же, сколько и они или больше, ** является тройным красным флагом**, потому что:

• Это вызывает подозрения, что если вы работали там, ** даже ваши хорошие идеи будут уволены** полностью на том основании, что вы младший, просто со пожилые могут оправдать свою собственную роль и зарплату.
• Это демонстрирует, что они имеют некоторые серьезные небезопасности о своем собственном опыте - и я был бы склонен думать, что что эти небезопасности могут быть оправданы.
• Если это старший случайно не имеют формального образования в области программного обеспечения, есть дополнительный стимул для них, чтобы попытаться преуменьшить важность степени и опыт, который один получает из него, чтобы их собственные менеджеры в конечном счете заменить их на столь же опытных разработчиков, которые также имеют сертификаты.

Просто для того, чтобы дать вам некоторое представление, я как-то брал интервью у кого-то, и в процессе я сделал несколько радикальное предложение пожилым людям о системе, которую они находились в процессе создания. Они не только приветствовали и рассмотрели это, но и сделали мне предложение вскоре после этого.

Такие среды do существуют - не все компании используют модель одностороннего учителя/студента, где знания передаются строго от пожилых людей к юниорам. (И помните, если вы закончили школу, то вы not “студент”, и многие старшеклассники в этой отрасли на самом деле тоже не являются “инженерами”, независимо от того, как компания решает их называть).

Проблема в том, что ваше “улучшение” было наивным и искусственным, и я знаю, что из-за того, насколько короче вы смогли его сделать.

Это происходит постоянно со мной. Я создаю сложную систему, чтобы данные могли обслуживать многих пользователей. А потом кто-то приходит и говорит: “Нам не нужны все эти штуки! Ты делаешь простую проблему слишком сложной”. И они взламывают и прорезают, и сводят это к простой системе _ которая служит им хорошо_, и они дают себе золотую звезду.

При условии, что они не единственный пользователь. И модификации только что сломали его для всех других пользователей этих данных. Значит, должно быть что-то… встречи, перевоспитание, горечь, откаты, все это было лишним.

Кодирование - это простая часть. Самое сложное - это понимание и выражение проблемы. Вы замыкали сложную часть, чтобы облегчить легкую часть.

Если вас учили, что кодирование - это король, ну, не совсем. Другая сторона - там, где деньги: возможность написать спецификацию, которая кодируется и обрабатывает всех пользователей/потребности. (на другом конце шкалы также можно проектировать решения, которые поют/танцуют все, но не пишут, вот почему для проектирования нужно знать кодирование).

Это было ядром. Вы не до конца поняли проблему, которую пытался решить код.

И вы показали это им в эффектной манере.

В играх “новичок” - просто новичок. Новичок" - это новичок, высокомерие которого мешает ему учиться или уважать опыт других людей или их старших в целом. Похоже, что последний более применим к вам, потому что вы так легко смогли сделать этот код намного короче, _ и вам не пришло в голову, что это было чтобы легко , должна была быть причина, по которой они написали его таким сложным_.

…и что я не задумывался, почему они закодировали все так, как было.

Да, это правда. В некоторых случаях код пишется для поддержки определенной бизнес-функции или правила, которое программисты не могут контролировать.

Я посмотрел на него и нашел гораздо более простой и перспективный способ написания одной функции, и открыл PR с изменениями, не упомянув, что в настоящее время брал интервью.

Как молодой человек, нам нравится думать, что мы умные. Что мы все поняли. Правда в том, что если бы вы подумали об этом, то кто-то другой тоже мог бы это сделать, так как вы, очевидно, “нашли” лучший способ, погуглив то, что делали другие люди. Всякий раз, когда вы думаете о чем-то настолько очевидном, вы должны остановиться и сначала спросить об этом, чтобы убедиться, что происходит на данном этапе. Билл Гейтс не гуглить свой путь, чтобы построить Windows, он думал об этом и реализовал его. Если вы не в состоянии сделать то же самое, вы не нашли “лучший способ”. Вы просто google лучше, чем предыдущий человек.

Было ли это действительно неуместно для меня, чтобы сделать это?

Как пиар к их хозяину, да, это было немного неуместно. Возможно, это ваше собственное отделение, которым вы можете поделиться на собеседовании. Я видел, как вы сделали Икс, и после исследования я нашел Y, что позволяет в будущем доказать и легче модифицировать. Я знаю, что вы написали это не просто так, но мне было любопытно продемонстрировать концепцию, основанную на вашем коде: “Я знаю, что в git'е можно использовать символы @ и даже открывать цепочку обсуждений. Возможно, в следующий раз будет лучше прокомментировать раздел, который вы модифицировали с помощью,

@user Я заметил, что вы делаете здесь X, но я вставил Y. Хотел показать свою способность читать ваш код и делать модификации, и т.д.

Сделав пиар своему хозяину, это по сути то же самое, что и новость о человеке, который хотел быть сантехником, не смог найти работу, поэтому решил "исправить” утечку газа в своем районе. Можете представить себе конечный результат.

Чтобы добавить к другим ответам,

** Вы уверены, что Ваш код был действительно корректен и полезен в данной конкретной кодовой базе?**

Вы можете исправить, что может показаться намного проще и надежнее; однако, может быть легко, что старый код был написан так, как он был написан специально.

Вероятно, ваш запрос на вытаскивание изменил некоторые аспекты поведения (вы можете даже подумать, что исправили ошибку), но есть какой-то отдаленный код, который полагался на эту ошибку.

Вероятно, вы не учли тот способ использования кода, и поэтому ваш код хуже в этой конкретной ситуации. Например, вы можете не работать в многопоточной среде, или данные, с которыми работает код, могут иметь некоторые неочевидные свойства, которые делают старый код лучше и быстрее.

Насколько мы знаем, вы, возможно, упустили из виду какую-то глупую причину (ошибка в вашем коде, или тот факт, что ваш код работает медленнее и т.д.), которая должна быть очевидна для опытного разработчика.

Вы, возможно, упустили из виду что-то другое. В конце концов, они работают с этим кодом долгое время и, вероятно, должны знать гораздо лучше, как он работает. Тот факт, что они сказали “что [вы] не задумывались о том, почему они закодировали его так, как он был”, говорит об этом.

• *

Это говорит о том, что я согласен с другими людьми, которые говорят, что открытие 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) не сможет произвести совпадение, потому что предположительно не сможет найти намеренно wacko строку по умолчанию.

Это явно по замыслу. Но это также objectively плохая кодировка.

Ваше исправление кажется улучшением. Я сам бы заметил это в обзоре кода, не задумываясь. И я легко видел, что пишу то же самое 25-словное дружелюбное, неконфронтационное сообщение о коммите, которое вы написали.

Поэтому этот конкретный PR мне не кажется неуместным. И при условии, что это сделано профессионально, уважительно и добросовестно, пиар никогда не будет неуместен**, в том числе и при проведении интервью.