Sstrhsrtj

This happened to me last year while I was interviewing with a company for a position I didn't get. I'm currently employed elsewhere but I'd like to know for future applications.

I had an excellent phone screening, according to them - they said I was a strong candidate, and the first technical interview with one engineer went very well. Between that second interview and the final interview I found their software had an open-source aPI on Github, written in Python. I looked at it for a while and found a much simpler and future-proof way to write one function, and I opened a PR with the change without mentioning that I was currently interviewing.

When we started my third interview with two engineers one of them mentioned that he saw my pull request and it was inappropriate for me to open it. He said that it came across like I know more than them as a fresh college grad, and that I haven't considered why they coded it how it was. I didn't end up getting the job.

Was it really inappropriate for me to do this?

Clearly it wasn't a good tactical choice for this company, but it's pretty silly to go to the trouble of setting up a public repository and then disdain people for having the chutzpah to submit pull requests. Saying "No" to a pull request is hardly a burden. Heck, they could simply have ignored it.

If I'd been the interviewer, I would have given you bonus points for demonstrating real interest in the company and showing that you know how to work with an open source project in a public repository. That would be true even if the submitted code was naive about the problem being solved.

Since a job offer is on the line you should be sure that the code you submit is of high quality (get somebody else to look it over), and keep any comments in the code or in the pull request humble and polite.

"Inappropriate" might not be the best word, but "not strategic" would likely be accurate.

As what sounds like a perhaps still relatively new worker in a technical field, one of the first things you will need to learn is that decision making about how to do something, and when it is worth changing it, is not a simple matter. Given that you have an impetus to change something that already worked without being asked to, you are likely to find yourself often accused of "worshiping the new and shiny" without understanding the cost of change, complex reasons why something was done the way it was, or the full scope of new issues your idea would introduce.

Or maybe they're just small-minded people who found you annoying.

The thing is, to an extant, it doesn't matter what is objectively best, it mostly matters what is subjectively best for an organization at a given point in time. Change has a real cost in breaking existing awareness, so a new method needs to be substantially better in ways that matter and not just a little better in theory or a little more aligned to contemporary trends and thinking.

If you want to "volunteer" on something without being asked to, you'll likely get better reception for tackling real outstanding bugs that impact users, than in making bold re-writes of things which already worked. If you come to understand an unresolved issue, see if you can make a change that is as small and minimal a diff as possible, with a first class commit message. Make it obvious why this one change is the right way to solve the problem, and make it one that fits seamlessly into the current style and methodology of the code. Give them a pull request that is easy to approve and does not invoke any complex feelings of tradeoffs.

If you truly believe a section needs to be re-written, save that thought until you are being asked to contribute and are aware of priorities, history, and the nature of the codebase overall. And be prepared to understand why the change you want to make is not consistent with their priorities and plan. Somewhat counter-intuitively, the more you can demonstrate understanding of the current code by making fixes that fit seamlessly with its traditions, the more likely you are to gain trust to take things in new directions. You can also casually float drastic changes in a more informal way - "hey I was thinking we could make this part a lot better if we re-wrote it to use spindle folding" and gauge the reaction before actually doing it.