¿Cómo puedo pedirle a un empleador potencial que muestre el código de producción?

En mi experiencia, los gerentes e incluso los empleados de un empleador potencial tienden a enfatizar el compromiso con la calidad en su empresa o su equipo durante las entrevistas. También me preguntan de forma rutinaria sobre mi competencia con herramientas y procesos para mejorar y mantener la calidad del código. También se acostumbra escribir algún código durante la entrevista o como tarea.

Al tener experiencia con varios proyectos de mantenimiento, tuve que aprender el valor de un buen código de la manera más difícil. Se ha vuelto muy importante para mí cuando escribo mi propio código. Y no quiero ser empleado de una empresa que no se comprometa a escribir un buen código, aparte de las definiciones de buen código.

Sin embargo, una vez que el código heredado está sobre la mesa, a menudo me siento decepcionado, ya que resulta que el compromiso con la calidad del código es más bien una forma de hablar. Tiende a estar repleto de errores simples que se introdujeron hace años, no tiene un formato consistente, no tiene expresiones idiomáticas consistentes y, a veces, muestra una grotesca falta de comprensión de las técnicas y principios básicos de codificación. Probablemente estoy predicando al coro aquí :)

¿Es una buena idea pedirle a un posible empleador que muestre primero el código fuente? Específicamente, me gustaría ver algunos ejemplos de código de producción.

¿Cómo puedo solicitarlo para que un posible empleador comprenda mis preocupaciones y me permita echar un vistazo?

¿Es probable que se nieguen por motivos distintos a la mala calidad del código (confidencialidad, etc.)?

Si se niegan, ¿cómo podemos llegar a un acuerdo que sea satisfactorio para ambas partes?

Por el bien del argumento, supongamos que podré determinar la calidad del código a partir de una muestra bastante pequeña: mi pregunta es realmente solo sobre si solicitarlo y cómo hacerlo. Advertirme sobre los rendimientos esperados bajos es agradable, pero no tiene nada que ver con el tema.

No soy un solicitante. Me han contactado debido a mis calificaciones y me gustaría evaluar si realmente estoy interesado. No tengo miedo de ser excluido de la carrera. Mi objetivo principal es saber si la comida es de mi agrado sin tener que comerme todo el plato.

comentarios eliminados: los comentarios están destinados a ayudar a mejorar una publicación o buscar aclaraciones. Por favor, no responda las preguntas en los comentarios. Estas no se pueden votar fácilmente como las mejores respuestas y, sin darse cuenta, pueden impedir que otros usuarios proporcionen respuestas reales. Consulte ¿Cómo debo publicar una no respuesta útil si no debería ser un comentario? para más orientación.
Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
@IanLewis, para las discusiones, usted y otros pueden usar The Workplace Chat . Sin embargo, los comentarios tienen un propósito muy específico en nuestro sitio . En concreto, consulta las secciones "Cuándo debo comentar" y "Cuándo no debo comentar" para obtener más detalles, o consulta ¿Qué comentarios no son? Espero que esto ayude a aclarar. Dicho esto, moví automáticamente estos comentarios a su propia sala de chat para que la discusión sobre esta pregunta pueda continuar sin cesar. Ver el comentario anterior para el enlace.
No es una respuesta a su pregunta, pero esté atento a los proyectos de consultoría a corto plazo relacionados, así como a las oportunidades de conversar con desarrolladores que trabajan o han trabajado con la empresa (por ejemplo, hackatones).

Respuestas (13)

Es muy poco probable que le proporcionen una muestra del código, por lo que realmente lo que necesita averiguar es cómo puede responder sus preguntas sin ver el código. Está tratando de asegurarse de que valoren las buenas prácticas de codificación, así que pregúnteles sobre eso .

Aquí hay algunas preguntas de ejemplo que deberían ayudarlo a comprender cuánto valor le da la empresa al mantenimiento del código de calidad a lo largo del tiempo. Hay muchas otras cosas que puede preguntar específicas para su situación y prioridades.

  • ¿Qué tipo de control de fuente usas?
  • ¿Cómo informa el equipo los errores?
  • ¿Realiza revisiones por pares sobre el código?
  • ¿Cómo se asegura de que el código escrito por un desarrollador sea fácil de leer y comprender para otro?
  • ¿Cómo se mantiene el código heredado a lo largo del tiempo?
  • ¿Cómo mantiene actualizados a los miembros de su equipo sobre las mejores prácticas y técnicas de codificación?
  • ¿Utiliza alguna herramienta de análisis estático, como Checkstyle, para hacer cumplir los estándares de codificación? (@Ryan)
  • ¿Cuánto tiempo se congela su código antes de un lanzamiento? (@SandraWalters)
  • ¿Cuál es su marco de prueba? (@m24p)
  • ¿En qué punto del desarrollo comenzaste a implementar buenas prácticas de codificación? (@dotancohen)

EDITAR:

Algunas personas señalan que el hecho de que el entrevistador te diga algo no significa que sea del todo cierto. Es posible que sus estándares para la revisión por pares no coincidan con los suyos, o tal vez el gerente no sabe tanto como cree sobre las prácticas de codificación de su equipo. Esto es cierto para todo lo que le dicen en una entrevista, en todos los temas, y debe confiar en la confianza en cierto punto. Si realmente se sentiría más cómodo viendo algún código, ¡pregunte por todos los medios! Simplemente no creo que puedas suponer que la respuesta será sí.

+1 Tiene mucho sentido. Creo que comenzaré haciendo las preguntas que ha propuesto y solo pediré el código si la reacción es evasiva/sobresaltada/murmurando.
Para agregar a la lista de preguntas para hacer, preguntaría sobre cualquier herramienta de análisis estático o cualquier herramienta que automatice el proceso de hacer cumplir un estándar de codificación. Sé que Java tiene Checkstyle.
Hmm, durante una entrevista real, pedí ver un código de partes no esenciales de la aplicación y me lo mostraron. Simplemente lo vi como parte de 'conocer a la empresa'. Sin embargo, esto ya estaba en el punto en que la compañía sabía que me querían, y era probable que aceptara.
+1. Una pequeña muestra de código no le dirá mucho fuera de contexto. Si el código base en su conjunto es bueno o no, estará muy influenciado por si todo el proceso de desarrollo conduce a la producción de un buen código.
También a esta lista agregaría la pregunta ¿Cuánto tiempo se congela su código antes de un lanzamiento? Si la respuesta es ninguna o es muy corta, entonces puede ser una tienda que está practicando la producción... y la consiguiente hilaridad de corregir errores con el producto lanzado recientemente.
Podrían estar haciendo todo eso, y luego puede encontrar una página llena de gotos en el núcleo de la aplicación C++. Realmente no hay una forma segura de evaluar las habilidades del equipo (o las de la empresa para escenarios más pequeños) sin trabajar en ellas.
Algo que pregunté cuando me entrevisté con posibles empleadores fue "¿cuál es su marco de prueba"? Si no escuché sobre pruebas unitarias automatizadas, etc., no fue una buena señal. Otra buena pregunta genérica son las que obligan al entrevistador a decir algo negativo sobre la empresa. Por lo general, encontrarás un patrón que te dice algo útil. Si el estado del código es un problema, alguien podría mencionarlo.
Creo que te perdiste una pregunta clave: ¿Cuáles son los pasos en el ciclo de compilación y prueba y cuánto tiempo lleva?
"¿Tiene algún proceso automatizado, como la creación y ejecución de pruebas?" Esencialmente, pregunte acerca de las prácticas de integración continua.
Una vez estuve en una entrevista en la que me mostraron el código en vivo sin siquiera preguntar. No fue gran cosa.
Además de estas preguntas, no olvide preguntar en qué punto del desarrollo comenzaron a implementar buenas prácticas de codificación . He visto a muchos desarrolladores y empresas mencionar prácticas de codificación, pero cuando el código es un desastre, responden: "¡Oh, eso ! Eso fue escrito antes, bla, bla, bla". Por supuesto, eso consiste en el 90% del código base.
"También a esta lista agregaría la pregunta ¿Cuánto tiempo se congela su código antes de un lanzamiento?". En mi opinión, la necesidad de congelar el código es una señal de alerta. No son necesarios si su código está bien probado y las implementaciones están totalmente automatizadas.

Si está manteniendo el código, también podría suponer que el código que está manteniendo será estructuralmente deficiente de alguna manera.

  1. Solicitar un código para revisar no es bueno porque ese código se considera confidencial y propietario a menos que haya sido de código abierto. Puede echar un vistazo al código de código abierto, pero si está bien escrito y bien estructurado, no hay garantía de que el código heredado esté tan bien escrito y estructurado.

  2. Incluso si se le permitió ver algún código propietario, no hay garantía de que este código no sea realmente su mejor paso adelante.

  3. Si estuvo en una entrevista conmigo y solicita ver parte de nuestro código propietario, asumiré la actitud de que no conoce el significado de las palabras "confidencial" y "propietario" y lo descartaré como candidato. ¿Por qué debería contratarlo de todos modos, si tengo que preocuparme por qué código heredado está dispuesto a mantener?

4. Además, si realmente le permiten ver una muestra de su código, no hay garantía de que el resto del código tenga la misma calidad/estructura.
@Vietnhi Gracias por su respuesta, Vietnhi. Estoy de acuerdo con sus puntos 1 y 2. No hay garantías, pero esto no es relevante para la pregunta. No tengo miedo de ser rechazado: la empresa expresó su interés con bastante claridad. Estoy pidiendo una manera de evaluar si yo también debería estar interesado. ¿Tienes algún consejo al respecto?
@kostja Al final del día, aceptar una oferta de trabajo se reduce a una tirada de dados en la que esperas lo mejor. Si lo contratan específicamente para trabajar en nuevos proyectos comenzando desde cero, entonces no se encontrará con un código heredado. Al menos al principio. Los programadores junior son contratados para mantener el código heredado para que los programadores senior puedan participar en los proyectos divertidos :) Durante la entrevista, puede preguntar si se espera que lo implementen en los nuevos proyectos comenzando desde cero o en los heredados. Un nuevo proyecto que incluye mucho código heredado no cuenta como un nuevo proyecto :)
1. no tiene sentido: si quieren, te lo pueden mostrar. Y mostrar un par de archivos de un proyecto completo no socavará nada, no es como si pudieras hacer uso de ellos.
Agregando a lo que escribió @Lohoris: y mucho menos en unos minutos de mirarlo, que es probablemente de lo que se trataría si preguntara al respecto en el sitio. Si pides que te lo envíen, eso obviamente cambia un poco las cosas, pero no tanto; la empresa ciertamente puede elegir una parte del código que sea menos crítica y/o no haga nada importante. Podría sacar algo de código de un sistema más grande que es trivial en muchos aspectos, pero aún así transmite el estilo general del código en ese sistema al lector. Supongo que eso es lo que busca el OP.
@ra_htial Su punto 4 es exactamente el mismo que el punto 2 de la respuesta.
Esa es una respuesta muy ilustrativa. Este tipo de reacción a una buena pregunta es un obstáculo claro para mí. Creo que abandonaría la entrevista justo después del tercer punto y te dejaría en paz con tu código de mierda.
"¿Por qué debería contratarte de todos modos, si tengo que preocuparme por qué código heredado estás dispuesto a mantener?" Bueno, ¿no es ese el punto? Si solo está dispuesto a contratar a alguien que esté feliz de mantener un código heredado de mierda, entonces eso presumiblemente significa que mantener un código heredado de mierda es parte de la descripción del trabajo, lo que significa que kostja no quiere trabajar para usted . ¡Ese es el punto de preguntar!
@BenAronson Hay un código de mierda en todas partes. Siéntete libre de salir del negocio.
La primera oración es terriblemente cierta: si lo contratan por razones de mantenimiento, no espere un gran código en primer lugar.
Esta respuesta de Vietnhi es negativa y no acepta que existen diversos grados de código, existen diversos grados de mantenimiento o ayuda al OP a determinar si es una situación "razonable" o "deficiente" en esta empresa.
@VietnhiPhuvan, y lea la respuesta de mhoran a continuación, Workplace.stackexchange.com/a/34137/25730 para ver cuál es la respuesta real a esta pregunta que ciertamente no es fácil.
@ThomasW Y dado que acaba de contradecir los puntos 1 y 2 de mi respuesta, debe trabajar en su comprensión de lectura. Me estoy tomando muy mal tu condescendencia.
El consejo de @ThomasW mhoran_psprep sobre la contratación es sensato en el sentido de que un contratista debe saber en qué va a trabajar antes de siquiera pensar en ofertar, pero ese es un buen consejo: el contratista no tiene forma de saber el código en el que trabajará. en dos semanas después del período de prueba, si ese código es bueno. La analogía con la contratación de mejoras para el hogar es falsa: un hogar y sus problemas son visibles para un contratista de mejoras para el hogar. No es así con el código heredado: el contratista del código está dando un salto de fe basado en el resto del código basado en el código que se le ha permitido ver.
Es responsabilidad del empleador reconocer que en realidad está contratando a alguien para refactorizar una montaña de mierda , no para mantener una base de código. El empleador debe ser sincero al respecto y buscar un candidato que esté dispuesto y sea capaz de hacer ese tipo de trabajo. La actitud expresada en esta respuesta sería contraproducente para el empleador, porque lo más probable es que terminaría con un empleado que renunciaría de inmediato al ver el código, un hombre de mala calidad que aceptaría su dinero a cambio de nada, o algún tipo de arras. novato que solo empeoraría las cosas.
La pregunta no se trataba de pedir acceso sin restricciones a todo el código base. Con solo unos minutos de acceso supervisado a una pequeña parte del código base, incluso alguien con una memoria fotográfica tendría dificultades para obtener algo que pudiera usar maliciosamente.

Solo pregunta. No dé un ultimátum de que si no ve el código, saldrá por la puerta. Puede haber razones legítimas por las que no pueden mostrarlo. Si cree que esto es un factor decisivo, simplemente rechace la próxima entrevista.

Aunque no vendían software comercial, vi código durante una entrevista y ni siquiera tuve que preguntar. Querían saber si lo entendía.

Limpiar el código siempre será parte del trabajo. Puede sentir que tiene estándares muy altos para sus prácticas de codificación actuales, pero en aproximadamente un año, es posible que no esté tan satisfecho con él.

No seas tan duro. Una imagen puede contener mil palabras, pero solo muestra un lado de la historia.

Editar: creo que una clave aquí es que lo pondrán en una posición para escribir un código deficiente. Esa podría ser la razón de que el código base actual sea de baja calidad o que los programadores anteriores no fueran tan hábiles. La limpieza no siempre es divertida, pero es tolerable si sabe que la compañía lo pondrá en una posición para hacer un trabajo exitoso y de calidad.

Es decir, cuando la empresa está dispuesta y comprometida con la limpieza. Ese puede ser el objetivo de estar dispuesto a echar un vistazo al código actual.

No pidas una copia de nada: eso suena espeluznante e imprudente. No pregunte a la gerencia: es posible que el código base no coincida con los objetivos aspiracionales de la gerencia actual. Ni siquiera preguntes sobre la prueba de Joel, ya que pueden reclamar cosas que realmente no tienen.

Pero pida sentarse con un desarrollador existente para un recorrido por la base de código y la cadena de herramientas y los desafíos actuales. Es una petición razonable, no excepcionalmente inusual. En ese momento puede preguntar sobre problemas de mantenimiento del código. Si el código base es malo, lo sabrá bastante rápido. Si es bueno, ha iniciado una buena relación con el equipo.

+1 Probablemente obtendría mucha más información que simplemente pedir que me muestre el código. Buen consejo.

Dices que no te consideras un candidato y que no temes ser rechazado, pero insistes en usar el término empleador potencial; necesitas cambiar tu enfoque.

Quiere funcionar como contratista. No son un empleador potencial; son un cliente potencial.

Ningún contratista de mejoras para el hogar dará un presupuesto sin ver el sitio de trabajo, las condiciones y comprender los riesgos involucrados. Usted, como contratista de mejora de código, debe seguir los mismos pasos.

Un enfoque es tomar una asignación de una o dos semanas para investigar la situación y hacer una estimación de lo que necesitan y lo que costará. Si no le gusta la situación, haga una oferta alta o rehúse aceptar el trabajo.

Por supuesto, firmará cualquier acuerdo de confidencialidad que requieran.

Nota: incluso si me acerco a usted para que se convierta en un empleado, lo descartaría si insistiera en tener acceso a mi base de código. Pero si estuviera buscando contratarlo como contratista para lograr un objetivo específico, esperaría que hiciera su debida diligencia.

+1 buen punto. Veo la situación más bien como una asociación potencial (mientras que en realidad estoy empleado). Comenzar con una asignación puede beneficiar a ambas partes. Gracias, morán.
simplemente no es así como generalmente funciona la contratación.

Intentaría hablar con futuros colegas . Preferiblemente más de uno.

Los programadores reales son más propensos que sus gerentes a decirle la verdad del día a día, en lugar de una visión de dónde se espera que la empresa esté en el futuro. También puede comparar las opiniones de varios colegas para separar aún más los hechos de las ilusiones.

Otro beneficio es que las personas con las que trabaja también son muy importantes para su satisfacción laboral, por lo que desea conocerlas de todos modos.

+1. En mi empresa, varios de los "futuros colegas" son los entrevistadores, pero ese no es el caso en todas partes.

Simplemente haga algunas preguntas tomadas de Joel Test :

Ejemplo de prueba de Joel

No creo que esto ayude en absoluto en la situación que describe el OP. Él dice: "... A menudo me siento decepcionado, ya que resulta que el compromiso con la calidad del código es más bien una forma de hablar". En mi experiencia, muchas personas responderían "sí" a las preguntas de Joel Test, pero cuando llega el momento, realmente no viven con esa respuesta afirmativa.
@ Carson63000: y parte de la razón por la que se salen con la suya es que, como con cualquier criterio conciso, hay buenas razones para cubrir algunos de los puntos de Joel de todos modos, y estos se convierten en malas razones. Para un ejemplo artificial de una buena razón, si "la mejor herramienta que el dinero puede comprar" alterna con frecuencia entre los diferentes paquetes de X e Y para lograr lo mismo, ya que cada uno supera al otro con cada nueva versión, entonces el 50% de los tiempo no, no usamos "la mejor herramienta que el dinero puede comprar", nos quedamos con una para evitar el costo de cambiar constantemente ;-)
... del mismo modo, no compro una nueva CPU cada vez que se lanza una más rápida. Así que casi el 100% del tiempo tampoco uso la mejor herramienta que el dinero puede comprar en esa categoría. Tengo uno que cumple con mis requisitos, pero si la interrupción para mí de obtener uno más rápido fuera cero, entonces probablemente lo tomaría, por lo que el que tengo no es el "mejor". Pero cualquiera de mis ejemplos puede convertirse en una empresa llena de personas que usan herramientas obsoletas si nunca evalúa seriamente las alternativas a sus herramientas actuales y si puede mejorar lo que tiene. Podrían creer que tienen lo mejor por ignorancia.
Tengo que estar de acuerdo con todos ustedes. Sin embargo, estaba pensando en adoptar un enfoque cualitativo, en lugar de cuantitativo. Algunas preguntas son más subjetivas que otras, por lo que preguntaría primero: "¿Usas control de fuente?", y si es así, pregunto qué herramienta usan, cómo usan día tras día, etc. De esta manera muestras interés con su pregunta, en lugar de sospecha.
Sólo puedo estar de acuerdo; Empecé a hacer las preguntas de la prueba en entrevistas recientemente, y siempre conducen a buenas discusiones con suficientes conocimientos para tener una idea de la calidad general/nivel heredado de la base de código.

Como han dicho otros, puede compararlos con algunas preguntas simples, pero realmente entiendo de dónde viene... Por experiencia personal.

La gente dice un montón de cosas en el acto que no saben con certeza o responden sin entender la pregunta. Algo así como la prueba de Joel es realmente genial, pero solo si entienden la pregunta y la tecnología (y si no están mintiendo).

Una afirmativa a "¿Utiliza el control de fuente?" en realidad podría ser tan horrible como "trabajamos desde FTP y hacemos una copia de seguridad en CVS a fin de mes". Si esto es importante para saber si va a trabajar o no con estas personas, o (quizás más importante) cuánto les va a cobrar para compensar su ineptitud, debe averiguarlo mediante la observación directa . Las personas que no están contratando desarrolladores de software probablemente no lo entiendan.

Pero los profesionales entienden la evaluación de riesgos . Eso es todo lo que estás haciendo aquí. Explíquelo, diga que está feliz de firmar un NDA [bueno, no ridículo], y si se niegan, haga que absorban el riesgo citando el peor de los casos (o un factor del mismo). Así es como cualquier otra industria maneja esto.

No estoy diciendo que no debas compararlos con pruebas como la prueba de Joel. Solo asegúrese de haber visto lo que es importante para usted antes de comprometerse con algo.

En mi experiencia, los gerentes e incluso los empleados de un empleador potencial tienden a enfatizar el compromiso con la calidad en su empresa o su equipo durante las entrevistas.

Todo empleador está supuestamente comprometido con la calidad. Sin embargo, hay toneladas de software de mala calidad y existen toneladas de brechas de seguridad.

En general, está confundiendo la jerga de los negocios porque decir "estamos comprometidos con la calidad" es, en última instancia, una declaración vaga. Cualidad de quien? ¿Cuál es el punto de referencia? Es solo basura de toro hecha para hacerte sentir genial.

En general, todo lo que escuchará durante el proceso de una entrevista será, a falta de un término mejor, una "mentira piadosa" diseñada para hacerle sentir que el empleador potencial es la mejor opción que tiene.

¿Mi consejo? Lo más probable es que nunca vea el código de producción hasta que esté en la propia empresa. Y si no cumple con tus estándares, sigue buscando un nuevo concierto.

La dura realidad es que muchas empresas tienen sistemas deficientes, software deficiente y prácticas deficientes. Y eso se debe al hecho de que este tipo de trabajo informático es "invisible" para la mayoría y la mayoría de las personas pueden salirse con la suya.

Sencillamente: ofrezca firmar un acuerdo de confidencialidad (NDA) . Esto impedirá legalmente (aunque no técnicamente) que uses su código en tus propios proyectos.

Además, asegúrese de que su solicitud suene lógica. Haga una solicitud solo para los fragmentos de código que necesita . Esto ayudará a guiar sus discusiones sobre el proyecto y hará que su solicitud suene sensata.

No me apresuraría a firmar un NDA, ya que eso podría no solo impedirle usar su código, sino también hacer algo similar por su cuenta en el futuro. Renunciar al derecho de pensar en ese mismo fragmento de código es un costo real.
Sí, la idea de firmar NDA ES para evitar que use su código ;-) Más importante aún, todos los desarrolladores YA corren un riesgo, pero de infracción de derechos de autor, no de NDA, cada vez que 'piensan en el mismo bit' de código. Firmar un NDA no es un problema por esa misma razón.
¿Y si el código fuera lo suficientemente obvio como para que lo hubieras pensado tú mismo si te encontraras con el mismo problema? Si encuentra el mismo problema en el futuro, no podrá resolverlo. Eso no es un problema si el código que te muestran realmente es único y especial, pero no sabes si lo es cuando te presentas a la entrevista. Lo que digo es que al ver el código y aceptar no usarlo, renuncias a algo en comparación con no verlo nunca.
Si vio algún código y no firmó un NDA, entonces, como dice Andrew, no puede usarlo de todos modos debido a los derechos de autor. Entonces, el problema aquí, si lo hay, es "mirar el código", no "firmar un NDA". El NDA podría decir cualquier cosa, podría decir "Nunca usaré el lenguaje de programación en el que se escribió el código", en cuyo caso, por supuesto, no lo firme. Pero un NDA incluso vagamente razonable no le impedirá usar (digamos) Quicksort solo porque hay un Quicksort en el código que ve en NDA. El algoritmo Quicksort no es lo que protege la NDA. Su implementación específica de la misma es.
... sin embargo, lo que hace la NDA (y lo que le importa a la persona cuyo código es) es prohibirle andar diciendo "la empresa X usa Quicksort". El simple derecho de autor, por supuesto, no le impide hacer eso, y esa es la razón principal por la que puede obtener acceso a cosas bajo NDA que no querrían dar a terceros simplemente con una licencia restrictiva que le impide adaptar el código usted mismo en sus proyectos futuros. .

Preguntar acerca de:

  • Cobertura de prueba
  • TDD - Desarrollo basado en pruebas
  • Cómo se realiza el análisis y diseño orientado a objetos
  • ¿Usan principios SÓLIDOS?
  • Uso de Sonar, Veracode u otras herramientas de análisis de código
  • Prácticas de CI/CD
  • La clase más grande en un proyecto.

Yo digo... "no pierdas el tiempo con las empresas que de alguna manera esperan que 'escribas código' extemporáneamente. Si realmente no creen que realmente puedes escribir código fuente en {insertar lenguaje de programación aquí}, ¿por qué- ¿Diablos te invitaron a una entrevista?

Ahora, habiendo dicho eso, también debo reconocer que "hay pretendientes por ahí". ¡Y también hay razones por las que las empresas han aprendido a realizar comprobaciones superficiales de antecedentes penales de cada candidato...! (Podría contarles historias ahora, pero no lo haré).

Entonces, depende de ti, supongo. "¿Cuánto quieres este trabajo?"

No puedes según las otras respuestas.

Sin embargo, es más probable que consiga que acepten decirle los ID de usuario de algunos de sus programadores que tienen cuentas en StackOverflow y Programmer.

Observar los problemas que tiene su personal le dará una idea de cómo es su código.

Horrible consejo. Nadie quiere que la gente los aceche en Stack Overflow. Y, créalo o no, muchos programadores excelentes no hacen preguntas sobre Stack Overflow. ¿Qué harías si te dijeran "no tenemos ningún programador representante con una cuenta?
¿Cómo puedo pedirle a un empleador potencial que muestre el código de producción?
RespuestasAquíPolítica de privacidad1y, 0v