Solicitando empleo, la nueva empresa quiere ver el código fuente al que ya no tengo acceso

En entrevistas de trabajo recientes, las empresas quieren ver el código fuente que he escrito en mis proyectos anteriores, para comprobar mis habilidades. Me encantaría hacer esto, pero en la mayoría de los casos, ¡no puedo! O no tengo permitido hacerlo legalmente o ya no tengo acceso al código.

En un entorno corporativo, en la mayoría de los casos es impensable pedir tal permiso. Copiar el código fuente, tomarlo para su cartera y mostrárselo más tarde a otras empresas, va en contra de cualquier estándar de seguridad de cualquier empresa de TI.

Posiblemente podría funcionar si hiciera que la nueva empresa firmara un NDA sólido antes de revisar mi cartera. Pero en una gran empresa es prácticamente inimaginable organizar eso, no es un proceso estándar. (Nunca lo pregunté, simplemente nunca consideré siquiera preguntar si era posible tomar un software de ejemplo de mi empleador).

Asi que:

  • Teniendo en cuenta los NDA y demás, ¿podemos considerar apropiado pedirle a un candidato que muestre el código fuente que se creó para una empresa diferente?
  • ¿Es apropiado reprocharle al candidato si no puede mostrar el código fuente (o solo un mínimo) de un empleador anterior?
  • ¿Debería pedir permiso para tomar ejemplos de mi código fuente para usarlos más tarde como referencia de cartera?
  • Si lo hago, ¿cómo se reflejará en mi reputación?
  • ¿Cómo manejan los demás la desmoralización y la frustración, que después de muchos años de trabajo no puedes mostrar una sola línea de código que has escrito?
  • ¿Cómo manejar la situación en la que necesito escribir cosas una y otra vez, a menudo varias veces, porque no puedo copiar y pegar de mi proyecto anterior?

Extensión: Es Alemania. Las empresas objetivo son en su mayoría empresas asociadas de multinacionales alemanas.

¿En qué país es esto? Esto suena bastante extraño: en la mayoría de los países, es una práctica estándar que el código fuente que escribe como empleado sea propiedad del empleador. Los nuevos empleadores sabrán esto y sabrán que un posible empleado no puede mostrarles el código fuente de trabajos anteriores.
Cuando una empresa le solicita un código fuente, no se refiere al código de producción de su empleador anterior. Lo que significan es todo lo que TÚ pensaste, planeaste, hiciste y terminaste. Dales algo de tu trabajo de tiempo libre, proyectos paralelos, contribuciones de código abierto, etc.
Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
@Kevin Sí, esto es lo que hago, pero estos proyectos se construyen en entornos completamente diferentes, para requisitos completamente diferentes.
@MorningStar La capacidad de analizar un problema y encontrar una solución elegante no está ligada al medio ambiente. Puede demostrar que puede escribir código limpio que funciona y no hace más de lo que debería, eso es realmente todo lo que quieren de usted.

Respuestas (10)

Este es un problema común, y hay una solución común:

Escribe algo.

Inventa una empresa falsa en tu cabeza. Encuentre un problema empresarial que necesite resolver con software y resuélvalo. Muéstrales ese código.

Explique su NDA y la información confidencial.

Nadie está buscando secretos de empresa. Están buscando para ver cómo organizas tus pensamientos en arquitectura, tus prácticas de código, arneses de prueba, comentarios, etc.

Sí, pero hacer que algo se perfeccione como un proyecto pagado de tiempo completo es una tarea que requiere casi tantos recursos como un proyecto de tiempo completo. Y tendré que reproducir esto para cada proyecto (o, para cada tecnología) ¿qué puedo hacer?
Si necesita una excusa, busque un proyecto de código abierto que necesite una función no trivial escrita....?
"hacer que algo se perfeccione como un proyecto pagado a tiempo completo es una tarea que requiere casi tantos recursos como un proyecto a tiempo completo". No, en un proyecto real, hay clientes, informes de errores, código heredado, pruebas de regresión, sistemas de compilación, convenciones de la empresa, soluciones extrañas para situaciones inusuales, etc. En una muestra de código propia, elimine todo eso y solo concéntrese en entregar el código mínimo requerido para demostrar que tiene las habilidades. Elija una tarea simple y bien definida y luego muestre cómo la resuelve un profesional.
Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
@Brandin y el tipo que mira ese código pensarán que fue descuidado y que no hizo el TDD adecuado, etc.

Haga un pequeño proyecto de algún tipo y muéstreles ese código. Nadie espera que muestre un código que es propiedad de sus empleadores anteriores, de hecho, me preocuparía mucho si lo hiciera y lo estuviera entrevistando. Algunas personas trabajan en pequeños proyectos de código abierto por esta misma razón.

Les interesa menos el código en sí que la forma en que lo escribes.

No soy un desarrollador profesional, pero no tendría ningún problema para encontrar un par de cientos de líneas de código que he hecho fuera de cualquier compromiso laboral.

Si quieres el trabajo, saltas los aros. Si te pidiera que trajeras algo de código a la entrevista y no lo hicieras, pero lo hizo otra persona con habilidades más o menos equivalentes, ¿adivina a quién contrataría? Te estás vendiendo a un empleador en los términos del empleador, no en lo que te apetezca... cuestionar sus motivaciones para preguntar no es constructivo. Es una competencia, date todas las ventajas que puedas.

Ayude a un proyecto de código abierto y haga que el mundo sea un poco más grande y que usted sea más valioso al mismo tiempo. ganar-ganar-ganar-ganar (...)
En realidad, cuanto más pequeño sea el proyecto, mejor para las muestras de código para las entrevistas. Nadie quiere leer 500 000 líneas de código, especialmente si nadie les paga para hacerlo.
A veces guardo fragmentos que me gustan, principalmente para poder encontrarlos y usarlos nuevamente. Podrías encontrar algún código del que estés orgulloso y cambiar el nombre de cualquier cosa sensible. Por supuesto, eso no te ayudará ahora que ya no tienes acceso...
Para mí esta solución no es válida. Digamos que si usted es un profesional de 10 años, necesitaría al menos un año completo trabajando a tiempo completo en un proyecto de código abierto para tenerlo en funcionamiento y poder mostrar un poco de sus habilidades.

Preguntar es ético. Esperar que infrinja un NDA no lo es. Quejarse de que no incumple un NDA es una idiotez y una buena señal de que este no es un lugar donde quiere trabajar.

Preguntarle a tu antiguo jefe si hay cosas que puedes copiar está absolutamente bien. Él entenderá por qué lo preguntas. También entenderá las reglas de su empresa y dirá "sí" o "no". Probablemente "no". Tal vez le dé permiso para copiar cierto código que ha escrito, tal vez no.

Y lo más obvio es escribir algo de código. Escriba la especificación para una pequeña tarea que se pueda resolver en 100 líneas de código y escriba un código realmente pulido que coincida con esa especificación. Así que tienes algo que mostrar.

Esas otras empresas no quieren ver el código fuente de todos sus proyectos anteriores. En realidad, quieren ver el código fuente de sus proyectos personales anteriores o proyectos de los que aún posee los derechos.

Si no tiene al menos un proyecto personal propio, ya sea de un Hackathon o de otra cosa, entonces eso podría ser una señal de alerta para algunos de los empleadores más exigentes.

Presionar a su antiguo empleador para obtener el código es en realidad un enfoque incorrecto. Esto puede reforzar el hecho de que el nuevo empleador no tiene un proyecto personal para mostrarle y/o que no es capaz de escribir uno por su cuenta.

Actualización: No tome esto como que estoy de acuerdo con esa opinión. También odio ese mismo aro por el que algunos empleadores potenciales quieren que pase. Tengo ejemplos de código que escribí y de los que todavía tengo los derechos, pero esos proyectos a menudo son proyectos a medio terminar/a medias que ni siquiera se acercan al tipo de proyectos que hago como empleado de tiempo completo.

"Si no tienes al menos un proyecto personal propio [...] bandera roja" Una opinión común que encuentro totalmente falsa. Hacer un trabajo X horas al día, luego ir a casa a hacer el mismo trabajo por otras Y horas sin que te paguen no debería ser un requisito para ningún puesto.
En todo caso, prefiero que mis empleados tengan otros intereses fuera del horario laboral. Ayuda a eliminar a algunos bichos raros de inmediato.
Estoy de acuerdo con Celos. Como desarrollador y alguien que está involucrado en el proceso de contratación en mi empresa actual, no me importa si el candidato no tiene un código para mostrarme. Siempre preguntamos, y nos gusta verlo. Pero nunca lo reprochamos al candidato si no tiene un código para mostrarnos porque todo es propiedad de empleadores anteriores.
@Celos: ¿Seguramente como mínimo deberías tener el código que escribiste en la universidad para tu último año? Si no está al nivel de calidad que te gusta, refactorízalo un poco.
La sugerencia de @slebetman de que alguien rehaga algunos proyectos universitarios en lugar de tener algún proyecto personal hecho en su propio tiempo... plantea la pregunta, por decir lo menos.
@slebetman: No tendría suerte allí, mi título no es en una materia de informática. E incluso si lo hubiera sido, lo terminé hace 15 años y es difícil creer que reflejaría mis prácticas de codificación actuales, o que podría hacerlo con "un poco" de refactorización. Equivaldría a escribir un proyecto con el propósito de mostrarlo, lo cual supongo que es algo que tienes que hacer si eso es realmente lo que se necesita para conseguir un trabajo. Pero muchas personas se las arreglan sin eso: por ejemplo, los entrevistadores pueden pedirle que escriba un poco de código para la entrevista y no preocuparse por los proyectos completos.
Tengo mucho. Lo que no tengo: ese proyecto en el que trabajé meses o incluso años, a tiempo completo, y donde tenía que cumplir con las expectativas de un entorno corporativo.

Lo importante para un posible empleador es demostrar la capacidad para realizar el trabajo para el que está contratando.

Como han dicho otros, podría entregar un código fuente abierto. El problema con eso es que nadie quedará impresionado con un proyecto trivial que tomó solo unas pocas horas/días para escribir y que resuelve un problema falso. El otro problema con esto es que el empleador potencial realmente no evaluará su proyecto hasta el nivel del código fuente. Eso sería mucho tiempo para invertir. Solo darles un enlace a su repositorio de git no es muy efectivo a menos que sea un proyecto realmente sorprendente y bien documentado.

Si desea demostrar su habilidad, cree algunas diapositivas que brinden una descripción general de una solución que haya creado. No tienes que mostrar líneas de código.

Comienza explicando el problema que resolviste y da una idea de su alcance. Continúe con diagramas arquitectónicos de alto nivel que esbozan su solución. Finalmente, brinde una idea de las decisiones y desafíos técnicos clave de la implementación y detalle las herramientas/bibliotecas particulares que utilizó. Si corresponde, algunas capturas de pantalla que muestran el trabajo en acción también son agradables. Estas diapositivas serán suficientes para demostrar su nivel de sofisticación y generarán preguntas que podrá responder con gran nivel de detalle.

Por supuesto, sería ideal hacer lo anterior con un proyecto de código abierto, PERO si está de acuerdo con el pequeño riesgo, TAMBIÉN puede hacerlo para el trabajo de su empleador anterior. Si crea diapositivas que describen el trabajo de su empleador anterior, simplemente no las distribuya. Debe mantenerlos en su computadora portátil y solo usarlos en vivo. La clave es que no estás entregando el código fuente y solo estás demostrando lo que has hecho. Nunca he tenido un problema con esto y ha sido una excelente presentación que me ha contratado más de un par de veces.

Como desarrollador actual y alguien involucrado en el proceso de contratación (de desarrolladores) en mi trabajo actual, permítanme ofrecer algunos consejos...

En primer lugar, puede esperar que casi cualquier posible empleador le pregunte y le gustaría ver su código. De hecho, no deberías querer trabajar para nadie que no quiera ver esto. Hay una diferencia entre un candidato que puede responder algunas preguntas de informática y un candidato que realmente puede escribir un buen código.

En segundo lugar, la mayoría de las personas que contratan desarrolladores también mantienen a sus propios desarrolladores bajo NDA. No querrían que sus empleados compartan el código fuente que escribieron pero que no poseen con otras empresas, por lo que deben ser comprensivos cuando los nuevos empleados potenciales se encuentren en el mismo aprieto. Si el empleador potencial no comprende su incapacidad para proporcionarles un código protegido por NDA, no querrá trabajar para ellos de todos modos. Ni siquiera eres su empleado todavía y te piden que rompas un contrato con un empleador anterior que te mete en una gran cantidad de problemas personales y profesionales. Piensa en cómo sería trabajar para esa empresa.

En tercer lugar, aliente a su empleador actual a que contribuya, como empresa, a la comunidad de código abierto, o permita que los empleados pasen una cantidad de tiempo contribuyendo a proyectos de código abierto que sean relevantes para el trabajo que realiza. Por ejemplo, aunque mi lugar de trabajo actual tiene montones y montones de proyectos protegidos por NDA en nuestra cuenta de Bitbucket, también tenemos un GitHub público y animamos a nuestros desarrolladores a que contribuyan a eso (y muchas de las bibliotecas alojadas en ellos se utilizan en nuestros proyectos protegidos por NDA). Mientras tanto, para un empleador anterior, tuve que desarrollar esta biblioteca y lo hice con el acuerdo de ese empleador de que sería una biblioteca de código abierto.

Cuarto, cuando estés jugando, hazlo en GitHub. Cuando Apple lanzó un nuevo lenguaje y algunas funciones geniales relacionadas con la interfaz de usuario para Xcode, hice este proyecto como una forma de explorar muchas de estas cosas nuevas. Era un proyecto de aprendizaje, pero es mejor que nada. Pero tampoco espero necesariamente que los candidatos coman, duerman y respiren código, por lo que no tener el tiempo o el interés en trabajar en este tipo de proyectos no me molesta particularmente. Pero dicho esto, si está buscando trabajo, probablemente no sea una mala idea tomarse unos fines de semana para trabajar en este tipo de proyectos y crear una cartera.

... porque eso es justo lo que es esto, una cartera. Cuando los artistas ingresan para conseguir un trabajo en algún lugar, se espera que traigan un portafolio de su trabajo anterior para que el empleador tenga una idea de qué tipo de trabajo puede traer el artista a la mesa. Será muy ventajoso para su carrera como desarrollador si tiene una cartera disponible gratuitamente de su mejor trabajo disponible para que los empleadores potenciales la vean.

¿Es malo poner el código fuente en GITHub.com que haces para tu empresa que te paga muy bien?
Es malo poner el código fuente que está cubierto por NDA, y es malo ser astuto con las cosas. No está mal insistirle a su empleador que la empresa y sus empleados contribuyan a la comunidad de código abierto.
Mi empleador actual no tiene ningún interés en poner nuestro código a disposición de nadie más. No beneficia a la empresa en lo más mínimo. Ni siquiera intentes argumentar lo contrario. Y como sé eso, dudarían de mi capacidad mental si les propusiera esto. Insistir probablemente significaría que me pedirían que trabajara en una empresa que estuviera más de acuerdo con mis deseos .
Si esa es tu forma de pensar, te aconsejo que lo aclares. Si esa es la mentalidad de su empresa, le recomiendo que trabaje en un lugar más inteligente.
@PratikCJoshi nhgrif tiene razón y me preocupa que no entiendas la diferencia entre el código de "publicación" y el código de "liberación". Incluso si su empresa estuviera muy involucrada en el código abierto, habría participación legal entre otras partes interesadas, y tendría que seguir el proceso de lanzamiento de la empresa. No estarán encantados si se los hace responsables del código que usted robó y publicó y que causó daños materiales.
Dicho esto, no estoy de acuerdo en que una empresa sin código abierto no sea "un lugar más inteligente", y siento que eso cae bajo "tratar de argumentar lo contrario" según el comentario anterior. La participación en el código abierto es una motivación perfectamente razonable para querer trabajar para una empresa o no trabajar para una empresa, parece que usted (el OP) tiene una preferencia aquí, por lo que tal vez quiera considerar eso cuando busque su próximo trabajo.
Gracias, tengo una cuenta de github. Pero, mi problema es que en la mayoría de los casos no tengo los mismos recursos (tiempo y compromiso) para proyectos de hobby, que para mis tareas profesionales en una empresa. Por lo tanto, en la mayoría de los casos no están al nivel de calidad de mi trabajo profesional. Si se las muestran al posible empleador, tal vez piense, que yo le daré esta cualidad también en mi trabajo profesional para él.

Configure una cuenta de github y comience a escribir algo. Casi no importa lo que sea, solo asegúrate de que sea tu mejor esfuerzo. Cuando recibo CV a través de la puerta para trabajos, lo primero que verifico es si tienen una cuenta de GitHub, ¡lo segundo es lo que contribuyeron a ella!

Si no sabe qué escribir (y ese es un problema común), escriba código para resolver los problemas del Proyecto Euler . Demostrará su enfoque para la resolución de problemas, diseño, documentación, etc.

¿También revisas bitbucket?
No. Realmente no aparece en mi radar. GitHub es donde está la acción.
Hablando como ingeniero - 2/10, no aplicaría.

No necesita escribir y mostrarles el código, al menos no para las ofertas de trabajo más respetables. Tienes tu currículum y tus logros, y te recomiendo seguir la "prueba de Joel" y entrevistarte solo en empresas en las que tengas que escribir código en la entrevista . Ahí es donde verificarán tus habilidades de codificación.

Fuente: trabajos que conseguí.

Creo que depende mucho de la industria. Pude ver compañías más nuevas y amigables con las redes sociales sorprendidas de que no tuvieras una cuenta de github. Podría ver que las industrias más antiguas y tradicionales se desanimaran si incluyeras algo así en tu currículum y es más probable que te hagan una prueba.
@TechnicalEmployee tecnología financiera, puesta en marcha de 5 personas, alta tecnología.
Estoy de acuerdo en que una empresa realice una prueba es mucho más útil que pedirles que presenten un código que ni siquiera sabe que escribieron, por lo que estoy de acuerdo en que su enfoque es mejor. Pero para el OP, tal vez estén tratando de descartar candidatos antes de una prueba. Sin embargo, creo que su consejo se aplicaría a una industria tradicional y podría ver que poner github en su currículum en realidad sería una señal de alerta en algunas industrias más antiguas que protegen más sus datos.
@TechnicalEmployee No veo por qué sería una señal de alerta... el hecho de que haya puesto mi propio código en github no significa que vaya por la vida al azar poniendo todo lo que veo y escucho en github, y las empresas no No veo eso. No entiendo lo que quiere decir con "industria tradicional" v. Supongo que el tipo más nuevo. Como he dicho, trabajé en una empresa fintech, una startup de 5 personas que existía durante unos meses en el momento en que me uní, y una empresa de alta tecnología tradicional pero joven de Silicon Valley. Todos querían código en el proceso de entrevista en algún momento.
Supongo que estoy pensando en una empresa donde las autorizaciones de seguridad son una preocupación. En esos casos, tener un empleado que esté muy a favor de las redes sociales y del código abierto no sería el "tipo" de empleado que querrían contratar. No estoy sugiriendo en absoluto que la gente en github carezca de ética y no entienda los acuerdos de confidencialidad. Estoy sugiriendo que los dinosaurios que contratan en ciertos tipos de empresas estarían 'asustados' de un empleado que se presentara en un currículum como muy involucrado en tales comunidades.
@TechnicalEmployee, según mi leal saber y entender, ninguna empresa de tecnología ve la publicación de código en github como algo negativo.

Si has trabajado durante décadas y no tienes nada que mostrar, entenderás el trato que estás recibiendo como creador en nuestra sociedad. Tus creaciones han cambiado de manos por dinero. Ya no tienes derechos (al menos ninguno que te sea útil) sobre ellos.

Si realmente desea que se muestre una cartera, debe tener cuidado de no cambiar todo lo que crea por dinero. Participe en algunos proyectos de software libre (naturalmente, obtenga el permiso de su empleador si sus contratos laborales lo prohíben). Devuelva algo a una gran comunidad de la que probablemente haya obtenido algún beneficio para usted y posiblemente para las empresas para las que trabajó.

Si haces eso, habrá confirmaciones que puedes mostrar. Cosas que mejoraste, cosas que escribiste, encajando en contextos más amplios. Cosas escritas por usted, disponibles públicamente y probablemente suyas, y cumpliendo un propósito, y siendo aceptadas por un gran equipo que probablemente las revise más a fondo que la mayoría de las empresas.

He dicho algunos años (divididos en mi carrera), no décadas. Las "décadas" vienen de tu mente, no de mi pregunta.

No puedo creer que todos los demás se hayan perdido esto, PERO:

Esta es una PRUEBA de tu carácter. Mira, si compartes las cosas de tu antigua empresa que no deberías, entonces también eres capaz de dar la vuelta y hacerlo con la empresa a la que te postulas.

Esta prueba se utiliza para descartar a las personas con baja integridad. Simplemente recházalo con gracia. Es así de simple.

¿Qué pasa si tengo el permiso de la empresa? ¿Qué pasa si el jefe de mi empresa antes de 10 años si ahora mi amigo y yo simplemente lo llamamos para pedirle permiso y me lo dio verbalmente? Pero también creo que puede ser una prueba. Pero si no lo fuera, también sería demasiado arriesgado hacer algo desagradable y, de hecho, no hay ningún dilema, porque tengo perfectamente legalmente mucho código fuente para mostrar. Pero de todos modos, ¡gracias la sugerencia!
Prefacio mi declaración con "que no deberías". Si todo está en orden, no se preocupe.
Solicitando empleo, la nueva empresa quiere ver el código fuente al que ya no tengo acceso
RespuestasAquíPolítica de privacidad1y, 0v