È stato davvero inopportuno scrivere una richiesta di pull per la società con cui ho fatto il colloquio?

Chiaramente non è stata una buona scelta tattica per questa azienda, ma è piuttosto stupido prendersi la briga di creare un deposito pubblico e poi disprezzare la gente per avere la sfrontatezza di presentare richieste di pull. Dire “No” a una richiesta di pull non è certo un peso. Diamine, avrebbero potuto semplicemente ignorarla.

Se fossi stato io l'intervistatore, vi avrei dato dei punti bonus per aver dimostrato un reale interesse per l'azienda e per aver dimostrato che sapete come lavorare con un progetto open source in un repository pubblico. Questo sarebbe stato vero anche se il codice presentato fosse stato ingenuo riguardo al problema da risolvere.

Poiché un'offerta di lavoro è in linea, dovreste essere sicuri che il codice che presentate sia di alta qualità (fatelo controllare da qualcun altro), e tenere qualsiasi commento nel codice o nella richiesta di pull umile ed educato.

A parte que me dá mais pausa aqui é “uma forma muito mais simples e à prova de futuro de escrever uma função”. Eu não vi o seu código e não tenho conhecimento do contexto da sua mudança, mas não me parece que tenha corrigido um bug, adicionado uma funcionalidade, melhorado a performance, ou que tenha feito algo que os mantenedores do projecto consideraram significativo. Posso ver como submeter um pedido para uma alteração não solicitada desta natureza pode não ter deixado a melhor impressão.

Muitos projectos de código aberto (e frequentemente projectos de desenvolvimento de código fechado também) não são executados como os artigos da Wikipedia onde todos são encorajados a fazer pequenas alterações a toda a hora. Há um custo não zero que vem com qualquer mudança: o tempo para rever, testar e aprovar, o risco de quebrar algo (mesmo com uma suite de testes robusta), criar algo que menos membros da equipe entendem, etc… Como resultado, muitos projectos não são particularmente grandes em mudar as coisas só porque; há um número infinito de maneiras de escrever qualquer função, e nada seria feito se todos mudassem regularmente o código de trabalho existente para satisfazer a sua definição pessoal de “melhor”. Quando é altura de refactor, é mais provável que isso envolva um responsável pelo projecto, em vez de um primeiro contribuinte, e normalmente tem alguma espécie de justificação associada. Estas são normas, e como todas as normas, elas variam e são geralmente coisas que se espera que você pegue através de osmose, em vez de ser ensinado. Se foi recentemente formado, é provável que nada disto fosse particularmente evidente na altura.

A maioria dos pedidos de puxar aborda uma necessidade mais óbvia: corrigir um bug ou adicionar uma funcionalidade. E mesmo nesses casos, é muitas vezes melhor discutir a tarefa com o responsável primeiro, uma vez que podem ter contexto e preferências que você não conhece.

Por isso não acho que seja intrinsecamente inapropriado alguma vez submeter um pedido de puxar durante o processo de entrevista (certamente que mostra interesse e entusiasmo), mas da sua perspectiva, podem tê-lo visto como alguém que provavelmente reescreve o código de trabalho sem muita justificação e depois, infelizmente, reagiram de forma negativa e condescendente para consigo. O que, de forma útil, lhe diz muito sobre eles e como teria sido trabalhar com eles.

Hai frainteso il feedback che ti è stato dato e ti sei concentrato sulla parte sbagliata

Ha detto che mi è venuto fuori come se ne sapessi più di loro, come se fossi un laureato fresco di laurea, e che non ho considerato perché l'hanno codificato così com'era.

Il problema non è che hai emesso una richiesta di pull, ma che l'hai fatto per qualcosa che ti ha fatto apparire arrogante, ignorante e inconsapevole dei tuoi stessi limiti. Descrivete il vostro cambiamento come se aveste reso il loro codice “molto più semplice e a prova di futuro”; sembra ovvio, dalla sezione citata sopra, che non siano d'accordo. Inoltre, dato che hanno più esperienza di te e conoscono il loro codice, è molto probabile che siano corretti e che tu ti sbagli.

È comune che i laureati escano dai loro diplomi sopravvalutando fortemente la propria competenza. Non sono stati infastiditi perché avete emesso una richiesta di pull, ma perché sembravate dimostrare una mancanza di comprensione dei vostri limiti e una mancanza di rispetto per le loro competenze nella presentazione che avete fatto. Probabilmente, avete aggravato questa impressione durante il colloquio.

Infine, non leggete troppo in una particolare parte di un particolare colloquio: può darsi che questo non abbia niente a che fare con il fatto che non abbiate ottenuto il lavoro e che abbiano semplicemente avuto un candidato migliore. Non lo sapete. Non ossessionatevi da questa battuta d'arresto e concentratevi invece sulla prossima candidatura. Buona fortuna per la ricerca del lavoro!

“Inappropriato” potrebbe non essere la parola migliore, ma “non strategico” sarebbe probabilmente accurato.

Poiché quello che suona come un lavoratore forse ancora relativamente nuovo in un campo tecnico, una delle prime cose che dovrete imparare è che il processo decisionale su come fare qualcosa, e quando vale la pena cambiarla, non è una cosa semplice. Dato che hai uno stimolo a cambiare qualcosa che già ha funzionato senza che ti sia stato chiesto di farlo, è probabile che ti trovi spesso accusato di “adorare il nuovo e brillante” senza capire il costo del cambiamento, le ragioni complesse _perché qualcosa è stato fatto così com'era, o l'intera portata di nuove questioni che la tua idea introdurrebbe.

O forse sono solo persone dalla mentalità ristretta che ti trovano fastidioso.

Il fatto è che, in un certo senso, non importa cosa sia obiettivo migliore, ma soprattutto cosa sia soggettivamente migliore per un'organizzazione in un determinato momento. Il cambiamento ha un costo reale nel rompere la consapevolezza esistente, quindi un nuovo metodo deve essere sostanzialmente migliore in modalità che contano e non solo un po’ migliore in teoria o un po’ più allineato alle tendenze e al pensiero contemporaneo.

Se vuoi “fare volontariato” su qualcosa senza che ti venga chiesto di farlo, probabilmente otterrai una migliore accoglienza per affrontare i bug veramente eccezionali che hanno un impatto sugli utenti, piuttosto che nel fare riscritture audaci di cose che hanno già funzionato. Se arrivate a capire un problema irrisolto, vedete se potete fare un cambiamento che sia il più piccolo e minimo possibile, con un messaggio di commit di prima classe. Rendete evidente il motivo per cui questo cambiamento è il modo giusto per risolvere il problema, e rendetelo un cambiamento che si inserisce perfettamente nello stile e nella metodologia attuale del codice. Date loro una richiesta di pull che sia facile da approvare e non invochi alcun complesso sentimento di compromesso.

Se credete veramente che una sezione debba essere riscritta, risparmiate questo pensiero fino a quando non vi viene chiesto di contribuire e siete consapevoli delle priorità, della storia e della natura del codice in generale. E siate pronti a capire perché il cambiamento che volete fare non è coerente con le loro priorità e con il loro piano. In qualche modo contro-intuitivamente, più si può dimostrare la comprensione del codice attuale facendo delle correzioni che si adattano perfettamente alle sue tradizioni, più è probabile che si acquisisca fiducia per prendere nuove direzioni. Si possono anche apportare cambiamenti drastici in modo più informale - “Ehi, stavo pensando che potremmo rendere questa parte molto migliore se la riscrivessimo per usare la piegatura del mandrino” e valutare la reazione prima di farlo.

Parlando dall'altro lato della scrivania - a livello personale, sono abbastanza contento quando un richiedente ha anche dei repo Github o qualche altro tipo di portafoglio, e ha fatto qualche ricerca di base su quello che fa l'azienda. Questo è come il 3-5% di tutti i candidati.

Un candidato che potenzialmente dimostra _e di quelli molto direttamente, fissando / migliorando il nostro codice? Probabilmente si sono persi una grande assunzione, e voi avete certamente evitato di entrare a far parte di una cultura terribile.

Non hai fatto niente di male. Se una Pull Request che rifattorizza una funzione del codice ha scosso la loro barca, questo non lascia molto spazio a interazioni più complesse.

Il ruolo del project maintainer (o Reviewer) è quello di districarsi da qualsiasi politica (arroganza percepita, incompetenza) dal codice stesso, e rivedere il codice in modo oggettivo. Se un revisore riceve una Pull Request e solo si concentra sulla politica (“Come osi sollevare questo argomento?”) e non rivede nemmeno il codice, si sta rivelando molto inefficace nel suo ruolo.

Ad essere onesti, non sembra che stia cercando qualcuno del tuo calibro, sii felice che presto entrerai a far parte di una società migliore.

Come ha detto @Kyralessa, potrebbe essere stato il suo commento non il suo PR Cosa ha inserito come commento alla sua richiesta di pull? Questo è il pezzo mancante chiave qui. Potresti aver involontariamente comunicato nel tuo commento che gli sviluppatori originali erano idioti e che tu eri di gran lunga superiore. La parola chiave qui è “inavvertitamente”. Come sviluppatore è molto facile da fare. Non sto dicendo che l'hai fatto, ma è una possibilità concreta.

**… Un'altra possibilità, come altri hanno detto, è che sono iperprotettivi nei confronti del loro codice, e forse non vogliono avere a che fare con il tutoraggio di un laureato fresco di laurea con l'iniziativa, che avrà bisogno (come tutti gli altri nella stessa barca) di un significativo tutoraggio e di una supervisione per assicurarsi di non commettere enormi errori (parlo per esperienza, essendo stato uno di loro anni fa).

…Oppure non sanno come fare un colloquio Forse non sanno come fare un colloquio per il tipo di candidato che vogliono e hanno fatto un pasticcio nella loro parte del processo di colloquio.

Nella maggior parte delle aziende, le vostre azioni sarebbero viste positivamente anche se alla fine ci fosse una buona ragione tecnica per rifiutare la vostra richiesta di pull:

• Dimostra il tuo genuino interesse per quella posizione in particolare
• È una prova che hai esperienza pratica con la codifica
• È stata un'opportunità per parlare di codice reale durante il colloquio, invece di esercizi di codifica inventati

Ovvero, a meno che il codice che hai scritto non fosse una sciocchezza completa che li ha convinti che non avevi l'esperienza che pensavano tu avessi fin dalle prime interviste, o sei riuscito in qualche modo a insultarli nel commento.

Ha detto che mi è venuto fuori come se ne sapessi più di loro, come se fossi un laureato fresco di laurea, e che non ho considerato il motivo per cui l'hanno codificato così com'era. Alla fine non ho ottenuto il lavoro.

** Considerati fortunato per non aver ottenuto il lavoro** , perché il trattamento che hai ottenuto per questa richiesta di pull è probabilmente un assaggio del trattamento che avresti ottenuto se avessi lavorato in quella società e proposto questo (o qualsiasi altro) cambiamento.

Per essere perfettamente chiaro: Sì, trovo molto probabile che la sua PR non sia stata una buona idea per loro e che abbiano davvero una buona ragione per avere il loro codice nel modo in cui lo hanno fatto, invece di quello che lei ha proposto. In altre parole, credo fermamente che *il vostro codice era probabilmente più semplice, ma peggiore. *

Tuttavia , a meno che tu non abbia incluso un commento scortese nelle PR, il presupposto dell'anziano che un semplice suggerimento sia “inappropriato”, che sia un modo arrogante di dire “ne so più di te”, e che un candidato laureato non possa, in realtà, saperne quanto loro o più, è una tripla bandiera rossa perché:

• Fa sorgere il sospetto che se tu lavorassi lì, anche le tue buone idee verrebbero respinte interamente sulla base del fatto che sei un junior, solo in modo che i senior possano giustificare il proprio ruolo e la propria retribuzione.
• Dimostra che hanno alcune gravi insicurezze riguardo alla propria competenza - e sarei incline a pensare che quelle insicurezze potrebbero essere giustificate.
• Se a quell'anziano capita di non avere un'istruzione formale nel software, c'è aggiunto un incentivo per loro a cercare di minimizzare l'importanza di una laurea e la competenza che se ne ricava, per evitare che i loro manager alla fine li sostituiscano con sviluppatori altrettanto esperti che hanno anche certificazioni.

Tanto per darvi un'idea, una volta ho fatto un colloquio da qualche parte e nel corso del processo ho dato un suggerimento un po’ radicale ai senior su un sistema che stavano costruendo. Non solo l'hanno accolto con favore e lo hanno preso in considerazione, ma mi hanno anche fatto un'offerta poco dopo.

Tali ambienti do esistono - non tutte le aziende utilizzano un modello a senso unico per insegnanti/studenti in cui la conoscenza fluisce rigorosamente dai senior ai junior. (E ricordate, se vi siete laureati allora non siete non uno “studente”, e molti senior in questo settore non sono nemmeno “ingegneri”, indipendentemente da come un'azienda decide di chiamarli).

Il problema è che il tuo “miglioramento” è stato ingenuo e artificiale, e so che a causa di quanto più breve sei riuscito a farlo.

Questo mi succede sempre. Costruisco un sistema complesso per permettere ai dati di servire molti utenti. E poi arriva qualcuno e dice: “Non abbiamo bisogno di tutta questa robaccia! Stai rendendo troppo complesso un problema semplice”. E loro hackerano e tagliano, e lo riducono a un sistema semplice che serve loro bene, e si danno una stella d'oro.

A parte il fatto che non sono l'unico utente. E le modifiche l'hanno appena rotto per tutti gli altri_ utenti di quei dati. Quindi ci deve essere qualcosa… riunioni, rieducazione, amarezza, rollback, tutto questo non era necessario.

La codifica è la parte facile. La parte difficile è capire ed esprimere il problema. Hai mandato in corto circuito la parte difficile, per rendere più facile la parte facile.

Se ti hanno insegnato che la codifica è il re, beh, non proprio. L'altro lato è dove sta il denaro: essere in grado di scrivere una specifica che sia codificabile e che gestisca tutti gli utenti/esigenze. (all'altro capo della scala è anche possibile progettare soluzioni che sono tutte cantabili/tutte danzanti, ma non scrivibili, ecco perché è necessario conoscere la codifica per progettare).

Questo era il nucleo di tutto ciò. Non capivate appieno il problema che il codice cercava di risolvere.

E glielo avete mostrato in modo spettacolare.

Nel gioco, un “principiante” è un semplice novizio. Un “noob” è un novizio la cui arroganza gli impedisce di imparare, o di rispettare l'esperienza degli altri o dei loro anziani in generale. Sembra che quest'ultimo sia più applicabile a voi, perché siete stati così facilmente in grado di rendere quel codice molto più breve, e non vi è venuto in mente che questo fosse troppo facile , ci doveva essere una ragione per cui l'avevano scritto così complesso.

e che non ho considerato il motivo per cui l'hanno codificato così com'era.

Sì, è vero. In alcuni casi, il codice viene scritto per supportare una particolare funzione o regola aziendale che i programmatori non possono controllare.

L'ho guardato per un po’ e ho trovato un modo molto più semplice e a prova di futuro per scrivere una funzione, e ho aperto una PR con il cambiamento senza menzionare che stavo intervistando.

Da giovane, ci piace pensare di essere intelligenti. Che abbiamo capito tutto. La verità è che se ci hai pensato tu, potrebbe averlo fatto anche qualcun altro, visto che ovviamente hai “trovato” un modo migliore cercando su Google quello che hanno fatto gli altri. Ogni volta che si pensa a qualcosa di così palesemente ovvio, ci si dovrebbe fermare e chiedere prima di tutto cosa si sta realizzando nel modo attuale. Bill Gates non ha cercato su Google il suo modo di costruire Windows, ci ha pensato e lo ha implementato. A meno che non si riesca a fare lo stesso, non si è trovato un “modo migliore”. Semplicemente google’d better than the last person.

È stato davvero inappropriato per me fare questo?

Come PR al loro padrone, sì, è stato leggermente inappropriato. Forse un tuo ramo che puoi condividere durante il colloquio. Ho visto come hai fatto X e, dopo aver fatto delle ricerche, ho trovato Y che permette una prova futura e una modifica più semplice. So che l'avete scritto per un motivo, ma ero curioso di dimostrare un concetto basato sul vostro codice" _“So che in git potete usare i simboli @ e persino aprire una catena di discussione. Forse la prossima volta sarebbe meglio commentare la sezione che avete modificato con un,

@utente Ho notato che voi ragazzi state facendo X qui, ma ho messo una Y. Volevo dimostrare la mia capacità di leggere il vostro codice e fare modifiche,etc

Facendo una PR al loro padrone, è essenzialmente la stessa storia di notizie dell'uomo che voleva fare l'idraulico, non riusciva a trovare un lavoro, così ha deciso di "aggiustare” una perdita di gas nel suo quartiere. Potete immaginare il risultato finale che è successo.

Per aggiungere ad altre risposte,

sei sicuro che il tuo codice sia stato effettivamente corretto e utile in quella particolare base di codice?

Puoi correggere può sembrare molto più semplice e robusto; tuttavia può essere facilmente che il vecchio codice sia stato scritto nel modo in cui è stato scritto di proposito.

Probabilmente la vostra richiesta di pull ha cambiato alcuni aspetti del comportamento (potreste anche pensare di aver risolto un bug), ma c'è del codice distante che si basava su quel bug.

Probabilmente non avete tenuto conto di quel modo in cui il codice è stato usato, e quindi il vostro codice è peggiore in quella particolare situazione. Per esempio, il vostro codice potrebbe non funzionare in ambiente multithreaded, o i dati che il codice tratta potrebbero avere alcune proprietà non ovvie che rendono il vecchio codice migliore e più veloce.

Per quanto ne sappiamo, potreste aver trascurato qualche stupida ragione (un bug nel vostro codice, o il fatto che il vostro codice gira più lentamente, ecc.

Potreste aver trascurato qualcos'altro. Dopo tutto, stanno lavorando con questo codice per molto tempo, e probabilmente dovrebbero sapere molto meglio come funziona. Il fatto che abbiano detto “che [voi] non avete considerato il motivo per cui l'hanno codificato così com'era” suggerisce questo.

Detto questo, sono d'accordo con altre persone che dicono che aprire una PR non è niente di male. Tuttavia, come per ogni nuovo codice, spesso è meglio discuterne con i manutentori. Dato che all'epoca lei era in fase di intervista, avrebbe potuto semplicemente sollevare la questione durante l'intervista.

È difficile capire come possa essere intrinsecamente inopportuno scrivere una PR per un progetto open-source di chiunque.

Pertanto deve scendere nei dettagli, di cui sappiamo molto poco. È stato ingenuo o arrogante nel codice o nell'atteggiamento? È stato utile e amichevole? Senza saperne di più è difficile valutarne l'adeguatezza.

La curiosità ha avuto la meglio su di me. Ho trovato il tuo PR. E mi ha fatto così tanta impressione che ho deciso di condividerla qui. Non è stata una decisione leggera perché non voglio tradire la riservatezza né di te né dell'azienda, ma ho pensato che avrebbe portato un contesto sostanziale alla discussione in modo accettabile. La mancanza di dettagli concreti ha sicuramente portato a molte speculazioni infondate

Ho completamente reso anonime e offuscate le PR cambiando tutte le variabili personalizzate, le stringhe, i metodi e i commenti. Eccolo, nella sua interezza:

# 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 


Il codice inizializzerà `target` in una stringa casuale codificata con un hardcoded random. (Nota, ho solo _sottotitolato_ i caratteri della stringa per offuscare quella parte). Se non viene fornito un argomento, allora `some_lookup(target)` non riuscirà a produrre una corrispondenza perché presumibilmente non può cercare la stringa predefinita intenzionalmente stravagante. 


Questo è chiaramente per progettazione. Ma è anche _obiettivamente_ una cattiva codifica. 

Il vostro fix sembra un miglioramento. Io stesso lo commenterei in una revisione del codice, senza esitazione. E potrei facilmente vedermi scrivere lo stesso identico messaggio di impegno amichevole e non conflittuale di 25 parole che lei ha scritto. 


Pertanto questa particolare PR non mi sembra inappropriata. E a condizione che sia fatto in modo professionale, rispettoso e in buona fede, **una PR non sarebbe mai inappropriata** anche durante un colloquio.