Timeline for Was it really inappropriate to write a pull request for the company I interviewed with?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 11, 2019 at 13:41 | comment | added | rkeet | @ChrisStratton You could employ a third party tool, such as No Pull Requests to automatically decline & close PR's. Or just make it private. Or create private repo's to start with. If you don't value another dev's input, keep it private. Could also make the repo "read only", but that would also prevent one's own devs from committing. | |
| Mar 10, 2019 at 17:53 | comment | added | kapex | @Wowfunhappy yes, for Github that's true. My point was more that other Git hosting services possibly don't allow it explicitly. | |
| Mar 10, 2019 at 0:26 | comment | added | Wowfunhappy | @kapex That's kind of the fault of the repository owner, no? If cloning the repo isn't allowed, the repo shouldn't be on public github. | |
| Mar 8, 2019 at 9:54 | comment | added | br3w5 | I think if I was interviewing, a PR would be a useful talking point. As an interviewer you could ask the interviewee to explain the reasoning behind the PR and challenge that, and then see how the interviewee responds. If that person is able to communicate their reasoning and understand how they might have got it wrong and discuss different approaches then that is a good sign. | |
| Mar 7, 2019 at 10:32 | comment | added | kapex | @A.I.Breveleri In addition to what @ ChrisStratton said, thinking that a public repo means you can submit pull request could be dangerous. The license may not permit derivative work (which a pull request essentially is). Even cloning the repo - which afaik you have to do for PRs - could be considered unlicensed redistribution (Github's TOS explicitly allows this, but similar services might do not). | |
| Mar 7, 2019 at 3:17 | comment | added | Chris Stratton | If it looks like poor judgement on the applicant's part, it looks like poor judgement... subjective as that assessment may be, no one wants to work with someone who exercises what they feel to be poor judgement by doing something without considering if it is useful, but merely on the justification that there are no technical mechanisms blocking them from attempting it. | |
| Mar 7, 2019 at 2:49 | comment | added | Wowfunhappy | @ChrisStratton Sure, it makes sense for a company to look through an applicant's history and take any public pull request—especially on a company's own project—as a way to evaluate the applicant's skill. However that's a different thing from saying there's something wrong with the act of opening the request. | |
| Mar 6, 2019 at 17:38 | comment | added | Chris Stratton | @CharlesE.Grant - a potential submitter can easily examine a project's pull request and commit author history. While an interview is a mutual evaluation, it's fairly incumbent on the new party to put some effort into understanding the existing situation. Someone who impulsively issues changes without thinking to first familiarize themselves with the apparent norms of the thing they want to change may come across as a potentially annoying co-worker who needs a lot of guidance rather than a person who can quickly fit in and solve real problems in a way that can be easily incorporated. | |
| Mar 6, 2019 at 17:24 | comment | added | Charles E. Grant | @ChrisStratton but the same logic applies to the submitter too. Unless there is some dire warning printed in bold in the README for the project, or in a contribution policy, submitting a pull request may be pointless but it's hardly inappropriate. | |
| Mar 6, 2019 at 16:05 | comment | added | Chris Stratton | @A.I.Breveleri - the fact that a repository is public does not mean that it is intended to accept unsolicited contributions. Many github repos especially from companies are effectively publish-only, others are convenience mirrors of projects where the actual development flow and change submission occurs elsewhere - and since github does not have any feature to disable pull requests the fact that one can submit one there implies nothing about the repository's purpose or the project's policies. | |
| Mar 6, 2019 at 14:30 | comment | added | PeteCon | "keep any comments in the code or in the pull request humble and polite." add Professional, and that sentence is a good rule to always work by. | |
| Mar 6, 2019 at 9:30 | comment | added | SZCZERZO KŁY | Not to mention I would treat such repository exactly as an "extra points" stage where you can show a)you are interested in the company b) you can read the code c)you can evaluate it d)you can make it better. | |
| Mar 6, 2019 at 5:15 | comment | added | A. I. Breveleri | Remember, when a prospective employer is evaluating you, you should also be evaluating that prospective employer. You have successfully avoided working with a supposedly senior developer who doesn't even know what a public repository is for. | |
| Mar 6, 2019 at 4:11 | history | answered | Charles E. Grant | CC BY-SA 4.0 |