¿Fue realmente inapropiado escribir una solicitud de retiro para la compañía con la que me entrevisté?

Claramente no fue una buena elección táctica para esta compañía, pero es bastante tonto tomarse la molestia de crear un depósito público y luego desdeñar a la gente por tener el descaro de presentar solicitudes de extracción. Decir “No” a una solicitud de extracción no es una carga. Diablos, simplemente podrían haberlo ignorado.

Si yo hubiera sido el entrevistador, te habría dado puntos extra por demostrar interés real en la compañía y mostrar que sabes cómo trabajar con un proyecto de código abierto en un repositorio público. Eso sería cierto incluso si el código presentado fuera ingenuo sobre el problema que se está resolviendo.

Como una oferta de trabajo está en la línea, deberías estar seguro de que el código que presentas es de alta calidad (haz que alguien más lo revise), y mantén cualquier comentario en el código o en la solicitud de extracción humilde y cortés.

La parte que me da más pausa aquí es “una manera mucho más simple y a prueba de futuro de escribir una función”. No he visto tu código y no entiendo el contexto de tu cambio, pero no suena como que hayas arreglado un error, añadido una característica, mejorado el rendimiento, o hecho algo que los mantenedores del proyecto consideraran significativo. Puedo ver cómo el hecho de presentar una solicitud de cambio no solicitado de esta naturaleza puede no haber dejado la mejor impresión.

Muchos proyectos de código abierto (y con frecuencia también proyectos de desarrollo de código cerrado) no se ejecutan como los artículos de Wikipedia, donde se anima a todo el mundo a hacer pequeños cambios todo el tiempo. Hay un costo no nulo que viene con cualquier cambio: el tiempo para revisarlo y probarlo y aprobarlo, el riesgo de romper algo (incluso con un robusto conjunto de pruebas), crear algo que menos miembros del equipo entiendan, etc… Como resultado, muchos proyectos no son particularmente grandes en cambiar las cosas sólo porque sí; hay un número infinito de maneras de escribir cualquier función, y nada se haría si todo el mundo cambiara regularmente el código de trabajo existente para cumplir con su definición personal de “mejor”. Cuando es el momento de refactorizar, es más probable que eso implique a un mantenedor del proyecto, más que a un colaborador primerizo, y normalmente tiene algún tipo de justificación adjunta. Estas son normas, y como todas las normas, varían y son generalmente cosas que se espera que recojas a través de la ósmosis en lugar de ser enseñadas. Si eres un recién graduado, es probable que nada de esto fuera particularmente aparente en ese momento.

La mayoría de las solicitudes de extracción se dirigen a una necesidad más obvia: arreglar un error o añadir una característica. E incluso en esos casos, a menudo es mejor discutir la tarea con el responsable primero, ya que pueden tener un contexto y preferencias de las que no eres consciente.

Por lo tanto, no creo que sea inherentemente inapropiado presentar una solicitud de extracción durante el proceso de entrevista (ciertamente muestra interés y entusiasmo), pero desde su perspectiva, pueden haberte visto como alguien que probablemente reescriba el código de trabajo sin mucha justificación, y entonces, desafortunadamente, reaccionaron negativa y condescendientemente hacia ti. Lo cual, con gran ayuda, te dice mucho sobre ellos y lo que hubiera sido trabajar con ellos.

Usted ha malinterpretado la retroalimentación que se le dio y se enfocó en la parte equivocada

Él dijo que me pareció que yo sé más que ellos como un recién graduado universitario, y que no he considerado por qué lo codificaron como era.

El problema no es que usted emitió una solicitud de retiro, sino que lo hizo por algo que lo hizo parecer arrogante, ignorante e inconsciente de sus propias limitaciones. Usted describe su cambio como hacer su código “mucho más simple y a prueba de futuro”; parece obvio por la sección citada arriba que ellos no están de acuerdo. Lo que es más, como ellos tienen más experiencia que usted y están familiarizados con su propio código, es muy probable que ellos estén en lo cierto y usted se equivoque.

Es común que los graduados emerjan de sus títulos sobrestimando fuertemente su propia competencia. No se molestaron porque usted emitió una petición de retirada, sino porque parecía demostrar una falta de comprensión de sus propios límites y una falta de respeto por sus habilidades en la presentación que hizo. Probablemente, usted agravó esta impresión durante la entrevista.

Finalmente, no lea demasiado en ninguna parte de una entrevista en particular: puede ser que esto no tuviera nada que ver con que usted no consiguiera el trabajo y que ellos simplemente tuvieran un mejor candidato. No lo sabes. No se obsesione con este contratiempo y concéntrese en la próxima solicitud. ¡Buena suerte en tu búsqueda de trabajo!

“Inapropiado” puede no ser la mejor palabra, pero “no estratégico” probablemente sería exacto.

Como lo que suena como un trabajador quizás todavía relativamente nuevo en un campo técnico, una de las primeras cosas que tendrá que aprender es que la toma de decisiones sobre cómo hacer algo, y cuándo vale la pena cambiarlo, no es una cuestión sencilla. Dado que tienes el impulso de cambiar algo que ya funcionaba sin que te lo pidieran, es probable que te encuentres a menudo con que se te acuse de “adorar lo nuevo y brillante” sin entender el costo del cambio, complejas razones por las que algo se hizo de la manera en que se hizo, o el alcance completo de nuevos temas que tu idea introduciría.

O tal vez son sólo personas de mente pequeña que te encontraron molesto.

La cosa es que, hasta cierto punto, no importa lo que es objetivamente mejor, mayormente importa lo que es subjetivamente mejor para una organización en un momento dado. El cambio tiene un costo real en la ruptura de la conciencia existente, por lo que un nuevo método tiene que ser sustancialmente mejor en materias que importan y no sólo un poco mejor en la teoría o un poco más alineado con las tendencias y el pensamiento contemporáneo.

Si quieres “ser voluntario” en algo sin que te lo pidan, es probable que tengas mejor acogida para hacer frente a los verdaderos errores pendientes que impactan a los usuarios, que en hacer reescrituras audaces de cosas que ya han funcionado. Si llegas a entender un problema no resuelto, mira si puedes hacer un cambio que sea lo más pequeño y mínimo posible, con un mensaje de confirmación de primera clase. Haz obvio por qué este único cambio es la forma correcta de resolver el problema, y hazlo de forma que encaje perfectamente en el estilo y la metodología actuales del código. Déles una petición pull que sea fácil de aprobar y que no invoque ningún sentimiento complejo de compensaciones.

Si realmente cree que una sección necesita ser reescrita, guarde ese pensamiento hasta que se le pida que contribuya y sea consciente de las prioridades, la historia y la naturaleza del código en general. Y prepárese para entender por qué el cambio que quiere hacer no es consistente con sus prioridades y su plan. De manera algo contraintuitiva, cuanto más pueda demostrar su comprensión del código actual haciendo arreglos que encajen perfectamente con sus tradiciones, más probable será que gane confianza para llevar las cosas en nuevas direcciones. También puedes hacer cambios drásticos de una manera más informal - “hey estaba pensando que podríamos hacer esta parte mucho mejor si la reescribimos para usar el plegado de huso” y medir la reacción antes de hacerlo realmente.

Hablando desde el otro lado del escritorio - a nivel personal, estoy bastante contento cuando un solicitante incluso _tiene _ Github repos o algún otro tipo de cartera, y ha hecho alguna investigación de fondo sobre lo que hace la empresa. Esto es como el 3-5% de todos los solicitantes.

Un solicitante que potencialmente demuestra ambos de esos muy directamente, arreglando / mejorando nuestro código? Probablemente se perdieron una gran contratación, y ciertamente evitaron unirse a una cultura terrible.

No hiciste nada malo. Si una petición de tirar que refina una función del código sacudió su barco, eso no deja mucho espacio para interacciones más complejas.

El papel del mantenedor del proyecto (o revisor) es desenredar cualquier política (arrogancia percibida, incompetencia) del propio código, y revisar el código objetivamente. Si un revisor recibe una solicitud de extracción y sólo se centra en la política (“¿Cómo te atreves a aumentar este PR?”) y ni siquiera revisa el código, están siendo muy ineficaces en su papel.

Para ser honesto, no parece que estén buscando a alguien de tu calibre, alégrate de que pronto te unirás a una compañía mejor.

Como @Kyralessa dijo, puede haber sido su comentario no su PR ¿Qué introdujo como comentario en su solicitud de extracción? Esa es la pieza clave que falta aquí. Puede que hayas comunicado sin querer en tu comentario que los desarrolladores originales eran idiotas y que tú eras muy superior. La palabra clave aquí es “sin querer”. Como desarrollador es muy fácil de hacer. No estoy diciendo que usted hizo esto, pero es una posibilidad definitiva.

**… Otra posibilidad que otros han mencionado es que son sobreprotectores con su código, y tal vez no quieran lidiar con la tutoría de un recién graduado universitario con iniciativa que va a necesitar (como todos los demás en el mismo barco) una importante tutoría y supervisión para asegurarse de que no cometen ningún error garrafal (hablo por experiencia aquí habiendo sido uno de ellos hace años).

…O no saben cómo entrevistar Puede que no sepan cómo entrevistar al tipo de candidato que quieren y que hayan estropeado su lado del proceso de entrevista.

En la mayoría de las empresas, sus acciones se verían positivamente aunque hubiera una buena razón técnica para rechazar su solicitud de extracción al final:

• Muestra tu interés genuino en esa posición en particular
• Es una evidencia de que tienes experiencia práctica con la codificación
• Fue una oportunidad para hablar de código real durante la entrevista, en lugar de ejercicios de codificación inventados

Es decir, a menos que el código que escribiste fuera una completa tontería que los convenció de que no tenías la experiencia que ellos asumieron que tenías desde las primeras entrevistas, o de alguna manera te las arreglaste para insultarlos en el comentario.

Dijo que parecía que yo sabía más que ellos como un recién graduado de la universidad, y que no he considerado por qué lo codificaron como era. No terminé consiguiendo el trabajo.

Considérate afortunado por no conseguir el trabajo , porque el tratamiento que recibiste por esta petición de atracción es probablemente una muestra del tratamiento que habrías recibido si hubieras trabajado en esa compañía y propusieras este (o cualquier otro) cambio.

Para ser perfectamente claro: Sí, creo que es muy probable que tus relaciones públicas no fueran buenas para ellos y que realmente tienen una buena razón para tener su código de la manera en que lo hacen, en lugar de la manera en que tú lo propusiste. En otras palabras, creo que tu código era probablemente más simple, pero peor. **

Sin embargo , a menos que incluyas un comentario grosero en las relaciones públicas, la suposición de los mayores que una simple sugerencia es “inapropiada”, que es una forma arrogante de decir “sé más que tú”, y que un candidato educado en la universidad no puede, de hecho, saber tanto como ellos o más, es una triple bandera roja porque: y 002 y 002 - Se sospecha que si trabajas allí, incluso tus buenas ideas serían descartadas totalmente en base a que eres un junior, sólo para que los mayores puedan justificar su propio papel y su sueldo. - Demuestra que tienen algunas serias inseguridades sobre su propia experiencia - y me inclinaría a pensar que esas inseguridades podrían estar justificadas. - Si ese senior resulta carecer de educación formal en software, hay un incentivo añadido para que traten de restar importancia a un título y a la experiencia que uno obtiene de él, no sea que sus propios gerentes eventualmente los reemplacen con desarrolladores igualmente experimentados que también tengan certificaciones.

Sólo para darte una perspectiva, una vez me entrevisté en algún lugar y en el proceso hice una sugerencia un tanto radical a los mayores sobre un sistema que estaban construyendo. No sólo lo acogieron y consideraron, sino que me hicieron una oferta poco después.

Tales entornos existen - no todas las empresas emplean un modelo unidireccional profesor/alumno donde el conocimiento fluye estrictamente de los mayores a los menores. (Y recuerda, si te has graduado entonces eres _no un “estudiante”, y muchos seniors en esta industria tampoco son realmente “ingenieros”, sin importar cómo una compañía decida llamarlos).

El problema es que tu “mejora” fue ingenua y artificial, y sé que por lo mucho que te quedaste corto.

Esto me pasa todo el tiempo. Construyo un sistema complejo para permitir que los datos sirvan a muchos usuarios. Y entonces alguien llega y dice: “¡No necesitamos todas estas cosas! Estás haciendo un problema simple demasiado complejo.” Y ellos hackean y cortan, y lo reducen a un sistema simple que les sirve bien, y se dan una estrella dorada.

Excepto que ellos no son el único usuario. Y las modificaciones sólo lo rompieron para todos los otros usuarios de esos datos. Así que tiene que haber una cosa… reuniones, reeducación, amargura, retrocesos, todo lo cual era innecesario.

La codificación es la parte fácil. La parte difícil es entender y expresar el problema. Hiciste un cortocircuito en la parte difícil, para hacer la parte fácil más fácil.

Si te enseñaron que la codificación es el rey, bueno, no realmente. El otro lado es donde está el dinero: ser capaz de escribir una especificación que sea codificable y que maneje todos los usuarios/necesidades. (en el otro extremo de la escala también es posible diseñar soluciones que son todo canto/todo baile, pero no escritas, por eso necesitas saber codificar para diseñar).

Ese fue el núcleo de esto. No entendiste completamente el problema que el código estaba tratando de resolver.

Y se lo mostraste de manera espectacular.

En los juegos, un “novato” es un mero novato. Un “novato” es un novato cuya arrogancia le impide aprender, o respetar la experiencia de los demás o de sus mayores en general. Parece que esto último es más aplicable a ti, porque fuiste capaz de hacer ese código mucho más corto, y no se te ocurrió que esto era demasiado fácil, tenía que haber una razón por la que lo habían escrito tan complejo.

y que no he considerado por qué lo codificaron como era.

Sí, es cierto. En algunos casos, el código se escribe para soportar una función o regla empresarial particular que los programadores no pueden controlar.

Lo he mirado durante un tiempo y he encontrado una manera mucho más simple y a prueba de futuro de escribir una función, y he abierto un PR con el cambio sin mencionar que estaba entrevistando actualmente.

Como una persona joven, nos gusta pensar que somos inteligentes. Que lo hemos descubierto todo. La verdad es que si lo pensaste, alguien más podría haberlo hecho también, ya que obviamente “encontraste” una mejor manera de buscar en Google lo que otras personas hicieron. Siempre que pienses en algo tan descaradamente obvio, deberías detenerte y preguntar primero sobre ello para asegurarte de lo que se está logrando de la manera actual. Bill Gates no buscó en Google su forma de construir Windows, lo pensó y lo implementó. A menos que seas capaz de hacer lo mismo, no has encontrado una “mejor manera”. […] Tal vez una rama propia que puedas compartir en la entrevista. Vi como hiciste X y al investigar encontré Y que permite una prueba futura y una modificación más fácil. […] Quizás sea mejor la próxima vez comentar la sección que habéis modificado con un,

@user Me doy cuenta de que estáis haciendo X aquí, pero he puesto una Y. Quería mostrar mi habilidad para leer vuestro código y hacer modificaciones,etc

Haciendo un PR a su maestro, es esencialmente lo mismo que la noticia del hombre que quería ser fontanero, no podía encontrar un trabajo, así que decidió “arreglar” una fuga de gas en su vecindario. Pueden imaginar el resultado final que ocurrió.

Para añadir a otras respuestas,

¿Estás seguro de que tu código era realmente correcto y útil en esa base de código en particular?

Puedes arreglar puede parecer mucho más simple y más robusto; sin embargo puede ser fácilmente que el viejo código fue escrito de la manera en que fue escrito a propósito.

Probablemente su petición de extracción cambió algunos aspectos del comportamiento (incluso podría pensar que arregló un error), pero hay algún código distante que dependía de ese error.

Probablemente no tuvo en cuenta esa forma en que se usó el código, y por lo tanto su código es peor en esa situación particular. Por ejemplo, tu código puede no funcionar en un entorno multi-hilo, o los datos que el código trata pueden tener algunas propiedades no obvias que hacen que el viejo código funcione mejor y más rápido.

Por lo que sabemos, puede que hayas pasado por alto alguna razón tonta (un error en tu código, o el hecho de que tu código se ejecuta más lentamente, etc.) que debería ser obvia para un desarrollador experimentado.

Puede que hayas pasado por alto algo más. Después de todo, están trabajando con este código durante mucho tiempo, y probablemente deberían saber mucho mejor cómo funciona. El hecho de que hayan dicho “que [usted] no ha considerado por qué lo codificaron como era” sugiere esto.

Dicho esto, estoy de acuerdo con otras personas que dicen que abrir un PR no es nada malo. Sin embargo, como con cualquier nueva base de código, a menudo es mejor discutirlo con los mantenedores. Dado que estabas en el proceso de entrevistas en ese momento, podrías simplemente haber planteado esa pregunta en la entrevista.

Es difícil ver cómo podría ser intrínsecamente inapropiado escribir un PR para el proyecto de código abierto de alguien.

Por lo tanto, debe reducirse a los detalles, de los que sabemos muy poco. ¿Fue ingenuo o arrogante en el código o en la actitud? ¿Fue útil y amigable? Sin saber más, es difícil medir lo apropiado.

La curiosidad sacó lo mejor de mí. Encontré tus relaciones públicas. Y me impresionó tanto que decidí compartirla aquí. No fue una decisión fácil porque no quiero traicionar la confidencialidad de usted ni de la empresa, pero sentí que aportaría un contexto sustancial a la discusión de una manera aceptable. La falta de detalles concretos seguramente ha llevado a muchas especulaciones no fundamentadas

He anonimizado y ofuscado completamente las relaciones públicas cambiando todas las variables personalizadas, cadenas, métodos y comentarios. Aquí está, en su totalidad:

# 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 "..."

El código inicializará target a una cadena aleatoria de código duro. (Nota, yo sólo controlé los caracteres de la cadena para ofuscar esa parte). Si no se proporciona un argumento, entonces some_lookup(target) no producirá una coincidencia porque presumiblemente no puede buscar la cadena por defecto de wacko intencionalmente.

Esto es claramente por diseño. Pero también es objetivamente una mala codificación.

Tu arreglo parece una mejora. Yo mismo lo comentaría en una revisión de código, sin dudarlo. Y podría verme fácilmente escribiendo exactamente el mismo mensaje de compromiso amistoso y no conflictivo de 25 palabras que usted escribió.

Por lo tanto, estas relaciones públicas en particular no me parecen inapropiadas. Y siempre que se haga de manera profesional, respetuosa y de buena fe, un PR nunca sería inapropiado incluyendo en las entrevistas.