¿Es razonable pedirle a un empleador potencial muestras de su código y/o información de contacto de los empleados para determinar si quiero trabajar allí?

He preguntado "¿podría explicarme algunos de sus mejores y peores códigos durante unos minutos?" las últimas dos veces fui a buscar trabajo, generalmente al final donde la gente pregunta "¿tiene alguna pregunta para nosotros?" Hasta ahora, esto ha sido universalmente recibido como positivo. Es posible que no todas las empresas estén dispuestas/capaces de hacer esto; mucho depende de la cultura, el tamaño, la industria, etc. de la empresa.

La razón por la que pido el mejor y el peor código es para poder tener una idea vaga de lo que consideran "buen código", y también tener una idea vaga de lo que consideran problemas en su base de código. Tenga en cuenta que esto no es una revisión del código, sino más bien una apertura para iniciar una discusión sobre el estado de su código, los planes futuros para mejorar la base del código y, lo que es más importante, su enfoque general para el desarrollo de software. Incluso si no pueden/no están dispuestos a mostrarle el código, esto puede ser un buen comienzo de conversación; por ejemplo, pueden describir verbalmente por qué consideran que su código bueno es bueno o que su código malo es malo.

Algunas organizaciones tienen ideas sorprendentemente divertidas sobre esto. Para dar un ejemplo, una organización me mostró lo que claramente era un gran lío de espaguetis, y los mayores problemas que señalaron fueron " publicy las privatepalabras clave a menudo no se agregan" y "los nombres de las variables no siempre son descriptivos". Si bien estas son preocupaciones legítimas, estaban lejos de ser las preocupaciones más apremiantes con ese código. Claramente no sabían lo que estaban haciendo. Terminé trabajando allí porque una amiga mía trabajaba allí y confiaba en ella, pero resultó ser un gran error y una experiencia desconcertante para ambas partes.

Anexo : OP regresó y publicó lo siguiente en los comentarios:

Aunque me pareció una buena idea y la probé varias veces, los resultados fueron bastante malos: las grandes empresas no pueden hacer eso, ya que necesitarían un proceso que no han implementado, pero está bien porque las grandes empresas generalmente no lo hacen. No te doy tareas en casa. Otras empresas, incluidas las que sí te dan tareas a domicilio, se niegan con mejores o peores excusas, prometen hacerlo y luego nunca lo envían, o no entienden por qué/qué quieres. Un par de ellos me enviaron sus repositorios completos con varios miles de líneas de código, lo que al menos era honesto porque sabría qué esperar. – antonro

Entonces parece que su millaje puede variar; Solo puedo hablar desde mi propia experiencia personal limitada. Me he entrevistado casi exclusivamente en empresas más pequeñas "no empresariales", y tal vez también dependa un poco de su localidad (estoy en Europa). Es importante recalcar que nunca le pedí a nadie que me enviara nada, sino que solo repasé un poco el código con ellos durante la entrevista durante unos minutos. Simplemente enviar código me parece bastante inútil porque no hay conversación: el valor está principalmente en la conversación, no necesariamente en el código como tal, que es principalmente de MacGuffin en este contexto.

En cuanto a pedir la información de contacto del empleado, esto me parece bastante extraño. Entiendo de dónde viene, pero aparte de las preocupaciones de privacidad, también puede poner a los empleados regulares en una situación bastante difícil.

Utilice sitios como Glassdoor en su lugar, donde los empleados actuales y anteriores pueden dejar comentarios, si así lo desean. Para empresas medianas y grandes, esto debería darle una indicación razonable, aunque recomendaría encarecidamente leer algunas de las reseñas en lugar de confiar ciegamente en la calificación de 4.4 (o lo que sea).

Soy empleador de varios desarrolladores.

Pruebas de selección: Pedimos a los candidatos que respondan una prueba de opción múltiple de 20 a 30 minutos que intenta seleccionar candidatos que nunca tendrían éxito en una entrevista de codificación. Esto beneficia tanto al candidato como al empleador, ya que reduce la cantidad de tiempo perdido por todas las partes.

Si su posible empleador le pide que haga varias horas de codificación antes incluso de tener una conversación con usted, NO son eficientes y no respetan su tiempo, y esa es una gran señal de advertencia . Sin embargo, la respuesta correcta es rechazar cortésmente y alejarse (si está en condiciones de hacerlo), no pedirle al empleador que dedique una gran cantidad de tiempo a usted antes de saber si es competente.

Entrevistas de codificación: lo que debe comprender es que la contratación tampoco es un proceso divertido para el empleador. Tienes que abrirte paso entre una plétora de candidatos que han solicitado un trabajo que son incapaces de hacer. Es por eso que las entrevistas de codificación son tan útiles.

Pido a los posibles empleados que codifiquen sus entrevistas para ver:

1. Cuál es su proceso de pensamiento y si son capaces de identificar un algoritmo para resolver un problema
2. La calidad de su código.
3. Su capacidad para depurar
4. Su capacidad para adaptarse a las críticas.

¿Es justo pedir ver parte de nuestro código base? Sí, y consideraría esta pregunta si ya tuviera confianza en la capacidad de codificación del posible empleado, y si el posible empleado tuviera suficiente experiencia para comprender lo que estaba viendo.

Comprobaciones inversas de referencias: no realizo comprobaciones de referencias en general. Creo que no tiene sentido, ya que personalmente he dado verificaciones de referencia positivas a ex empleados que no volvería a contratar. ¿Por qué? Porque puedo encontrar cosas positivas y veraces que decir sobre todos mis empleados, y no tengo piel en el juego. Solo hay un ex-empleado por el que no haría esto, y para esa persona, diría que va en contra de la política de la compañía dar verificaciones de referencia.

Sin embargo, si en la entrevista me pidieran los datos de contacto de varios ex empleados, respondería: "Gracias por su tiempo. Desafortunadamente, claramente no es el candidato adecuado para este puesto".

Si, por otro lado, ya estuviera en negociaciones para contratar a un empleado que realmente quisiera, sí , le preguntaría a los ex empleados si estarían dispuestos a darnos una verificación de referencia.

Ya hay algunas buenas respuestas aquí, pero para agregar mi propio pensamiento. ¿Se te ha ocurrido que su evaluación de ti es tu oportunidad de evaluarlos?

Déjame darte dos ejemplos diferentes, todos basados ​​en experiencias reales que he tenido:

1. Pasé más de 15 horas trabajando en casa en una asignación de programación para una empresa, su respuesta llegó a través de un reclutador, pero básicamente cayó en la categoría "no tenías que usar X para eso" y "no necesitabas hacer ese". Sin discusión, sin llamada telefónica.
2. Una segunda empresa me trajo para una entrevista y me dio una lista de instrucciones en una hoja de papel y una computadora portátil. Fue un desafío de programación TDD muy simple. Los dos entrevistadores se sentaron en la sala conmigo y conversaron mientras completaba el desafío, discutimos los pros y los contras de NUnit sobre MSTest y cómo puede superar la desventaja de una mala denominación de prueba usando la propiedad NUnit Name en el atributo.

¿Adivina en qué empresa quería trabajar?

Mientras estás en una entrevista es MUY importante impresionar a los entrevistadores, pero busca pistas. Escuche sus comentarios sobre estos desafíos, si es colaborativo y tiene una conversación amistosa, así es como opera la empresa. Si es un "no lo suficientemente bueno", entonces probablemente no encajes en su molde.

QUIEREN que seas el candidato (créeme, ya han visto suficientes malos). Pero la compañía a menudo olvida que usted quiere que ellos sean la compañía. ¡Busque pistas sobre cómo es la empresa a partir del proceso de entrevista en sí!

Para el lado de la muestra de código, si le piden que haga una tarea de programación, solicite ver sus estándares de codificación para que sepa cómo esperarían que se viera el código, y también brinde una indicación de lo que ven como buenas prácticas de codificación.

Esto no significa que su código será todo así. Algunos lugares pueden administrar aplicaciones o versiones heredadas, que tienen bases de código horribles. Cualquier lugar que no tenga estándares de codificación (o que no pueda señalar estándares generales como PSR-2) es un lugar que probablemente tenga problemas de calidad de código.

Una pequeña pieza de código puede no ser la mejor indicación, ya que podrían escribir una aplicación pequeña que sea extremadamente ordenada, pero que no represente su plataforma de código principal.

En cuanto al interrogatorio de los empleados, pregunte a las personas en la entrevista las mejores y peores partes de trabajar allí. Pueden discutirlo, y es algo que pone a mucha gente en un aprieto, por lo que no siempre se ensaya.

Entiendo tu frustración. Desea tener suficientes datos para tomar una decisión informada. Pero estás corriendo un gran riesgo.

A menos que esté muy por encima de los otros candidatos en términos de requisitos y la empresa haya pasado del modo de entrevista a tratar de convencerlo de que acepte su oferta, sus solicitudes probablemente harán que decidan que no vale la pena hacerle una oferta.

Enfrentado a un candidato que quiere que encuentre el código de exposición y quiere entrevistar a empleados actuales y anteriores; en comparación con otros 9 que no piden estas cosas, me centraría en el 9.

No importa en qué parte del proceso se encuentre su solicitud, creo que el riesgo es que su solicitud no pase al siguiente paso. Siempre que la empresa tenga más candidatos calificados que puestos vacantes, pueden decidir eliminar rápidamente las solicitudes.

Como empleado, no estoy seguro de querer ser entrevistado por un candidato, a menos que sea parte del proceso para todos los candidatos. Y como parte de ese proceso estaría evaluando candidatos..

Perdone una respuesta más en una larga serie de respuestas, pero mi sugerencia establece explícitamente algunas cosas que implican otras respuestas:

Al ser entrevistado, la empresa te preguntará sobre las cosas que les importan, y esto puede decirte mucho si prestas atención. Revisiones de código, pruebas unitarias/de integración, estándares de codificación: estas son las herramientas que ayudan a las empresas a escribir un buen código. Las empresas que se preocupan por un buen código utilizan estas herramientas y, como resultado, le preguntarán sobre su familiaridad con ellas. Si el proceso de la entrevista en sí no hace que sea extremadamente importante si están siguiendo o no las mejores prácticas, estos son los tipos de preguntas que haría como entrevistado para tratar de resolverlo:

1. ¿Cómo funciona su proceso de revisión de código?
2. ¿Cuál es su guía de estilo de código? ¿Sigue un estándar particular para su tecnología? (PEP8, PSR2, etc...)
3. ¿Qué herramientas utiliza para administrar su integración e implementación continuas?
4. ¿Qué herramientas utiliza para administrar la escritura/ejecución de pruebas unitarias y de integración?

Estas cosas te pueden decir mucho sobre una empresa sin necesidad de nada más. También puede redactarlos para que no suenen como un interrogatorio y atraigan al entrevistador: "En el pasado, trabajé en equipos que usan bitbucket para administrar las revisiones de código. ¿Qué herramientas usan ustedes para ayudar a administrarlas? " o "En el debate de 'pestañas vs espacios', nuestro equipo eligió X. ¡Es una locura cuánta controversia generó! ¿Dónde aterrizan ustedes en ese debate y, como equipo, cómo deciden qué estándares seguir?".

Preguntas como esta logran algunas cosas:

1. Dejan en claro que te preocupas por un buen código y que no eres nuevo en estos conceptos. Si el lugar al que se postula se preocupa por un buen código, se darán cuenta absolutamente del hecho de que usted pregunta estas cosas y lo verán de manera positiva.
2. No suena como si los estuviera interrogando y puede iniciar una conversación con ellos sobre un aspecto de su proceso de administración de código.
3. ¡Te enteras de sus estándares!

Si les preguntas sobre "pestañas versus espacios" y su respuesta es algo así como "No sé, lo que la gente quiera, supongo", entonces obviamente estás entrevistando a una empresa que no se toma las cosas en serio. Si inicias una conversación amistosa sobre la integración continua y no saben de qué estás hablando, obviamente estás en el lugar equivocado.

En esencia, las empresas que escriben buen código lo hacen porque los desarrolladores se preocupan por las buenas prácticas de codificación. Como resultado, debería poder tener una conversación coherente con quien lo esté entrevistando durante una entrevista técnica sobre las mejores prácticas de codificación. Por supuesto, cuando ingrese, puede encontrar algunas áreas en las que sus estándares no se practican tan bien como afirmaron durante la entrevista; después de todo, nadie es perfecto. Sin embargo, si los empleados se preocupan por los estándares, es muy probable que no tenga mucho de qué preocuparse en esta área.

Como ya ha visto, esta no es una gran técnica de entrevista. Si lo fuera, sería un lugar común.

Al solicitar ver muestras de código de su posible empleador, está convirtiendo la entrevista en una revisión de codificación en la que usted es el juez. También es propiedad intelectual y existe la posibilidad de exponer material confidencial de seguridad a un tercero (usted, el candidato).

Esto no va a pasar.

También está solicitando detalles de contacto confidenciales de empleados anteriores. Esto tampoco va a suceder (por razones obvias).

Puede evaluar mejor la idoneidad de la empresa investigando y haciendo preguntas, esto es lo que hacen todos los demás.

Por ejemplo, está perfectamente bien que pregunte qué desafíos han tenido en los lanzamientos o proyectos, y pregunte sobre sus procesos de desarrollo actuales. Pero tenga en cuenta que hacer este tipo de preguntas puede resultar en una reacción negativa (a nadie le gusta admitir que ellos (o su empresa) tienen la culpa).

Bueno, siento la necesidad de poner mis 2 centavos.

No firmaré un contrato hasta que yo:

1. Conoce a mis futuros compañeros de equipo
2. Discuta algo de código con esos compañeros de equipo.
3. Conoce a mi jefe.
4. Pase al menos un par de horas en la oficina mientras todo funciona con normalidad.

La mejor manera de lograr esto es programando en pareja con sus futuros colegas durante un par de horas.

Por lo general, informo a mis posibles empleadores sobre este requisito al principio del proceso de entrevista, generalmente cuando me preguntan si tengo alguna pregunta. Es en ese momento que digo algo como "Bueno, eso suena genial, y estoy interesado en seguir adelante con el proceso de contratación. Debo hacerle saber que quiero (completar el resumen de su proceso aquí) antes De hecho, firmé un contrato, pero estoy dispuesto a esperar hasta que estés seguro de que quieres contratarme.

Por lo general, menciono algo como "Creo que es lo mejor para los dos si nos aseguramos de que realmente encajemos bien el uno con el otro". La mayoría de las empresas están de acuerdo.

Cuando estoy del lado de la contratación de la cerca, lo encontraría razonable. Mi experiencia ha sido que mis entrevistadores tienden a apreciarlo. Los que no lo hacen probablemente estén trabajando en un entorno que quiero evitar. Dedicar algunas horas a permitir que un candidato que desea contratar se asegure de que se integre bien en su empresa antes de contratarlo es un alto retorno de la inversión , y no me gusta trabajar para empresas que no invertirán una cantidad tan pequeña en la creación de un buen equipo. .

No creo que los empleados que la empresa podría permitirle contactar serían de gran valor. Dado que no le darán todos los contactos de los empleados, habrán elegido un panel de empleados felices y amigables que le darán exactamente los mismos comentarios que recibió de los reclutadores. Será mejor que confíes en el reclutador en este caso, ya que es demasiado fácil "jugar" con esta pregunta.

Solicitar el proceso y algunas muestras no críticas de código producido o mantenido por la empresa, por otro lado, es una solicitud bastante razonable, siempre y cuando no solicite que se lo envíen o que se vaya con él. Puedo ver que esta pregunta se plantea al final de la entrevista cuando el reclutador le pregunta si tiene alguna pregunta.

Siempre he querido mirar el código antes de empezar. Pero en su lugar puede preguntar específicamente en qué estará trabajando, cómo está configurado el entorno de desarrollo y en qué módulo inmediato estará trabajando y qué dependencias, tecnologías y en qué parte del SDLC se encuentra el proyecto actual, así como si qué la arquitectura de n niveles es, qué módulos, pregunte a qué NO tiene acceso, dónde está la documentación, etc.

En cuanto a las referencias en el empleo, las he hecho gratis usando Linked In, puedes encontrar personas que trabajan en otro lugar pero que solían trabajar para la empresa en cuestión. En mi experiencia, mis comentarios sobre Linked In, la gente dijo que desearían haberlo hecho (pregunte a los antiguos empleadores en Linked In) y me dieron mucha información que no obtendría en Glassdoor o, de hecho.

Creo que en cada entrevista de trabajo es evidente quién está iniciando la transacción potencial. ¿Eres el bien escaso o estás siendo aspiracional? La capacidad de escribir código comercial es muy escasa, ya que requiere un nivel de concentración que muchos jóvenes aturdidos por los juegos no tienen. Por lo tanto, en la mayoría de los casos, la empresa debería venderse a usted. Modificaría su solicitud para que el entrevistador hiciera preguntas de sondeo para evaluar sus habilidades para codificar, en lugar de pedir ver parte del código de la empresa. Si solicita ver fragmentos, esto sugiere que podría estar buscando una guía para sus propias respuestas, mientras que pedirle al entrevistador que codifique por usted sugiere que no quiere trabajar para tontos, una actitud adecuada.

Las empresas que se especializan en producir software de código abierto suelen estar más abiertas a esto.

• En primer lugar, una gran parte de su código fuente está disponible en GitHub o para descargar.
• Muchos de ellos también abren muchas más cosas, por ejemplo, sus problemas, sus pruebas unitarias, sus experimentos, su hoja de ruta. La forma en que se manejan los problemas revela mucho. Si bien algunas empresas de código abierto solo envían el código al público después de una revisión interna, la mayoría trabaja desde el principio de manera abierta, con todo el trabajo de los desarrolladores directamente en las ramas visibles para todos en GitHub, lo que facilita tener una idea real de lo que es la codificación. parece el día.

Estas empresas centradas en el código abierto me han ofrecido tener una llamada con los miembros del equipo para discutir lo que piensan sobre el trabajo. Esta es mi experiencia limitada, pero parece que ser abierto es una cultura y, por lo general, significa que la empresa no tiene miedo de que sus empleados hablen con franqueza sobre el lugar de trabajo.

Como alguien que ha (durante koff-koff... varias décadas...) "entrevistado a un montón de 'programadores'", déjame decirte esto muy claramente:

"Me importa un carajo *sobre '¡tu código fuente!'"

Si realmente llegó a mi entrevista, entonces ya asumo que "usted es técnicamente competente". (Por lo tanto, espero que de alguna manera "aterrices cuatro patas hacia abajo"). Por lo tanto, ¿qué es lo que quiero? Una cosa:

"Cuando se le presentó un requisito técnico (que, por supuesto, hizo que su mente purista vomitara...) ¿qué hizo?"

Estoy muy centrado en las cosas sociales . ¿Se integrará bien en alguno de mis equipos existentes o simplemente causará problemas? ¿"Cavarás en las trincheras y nos ayudarás" sin quejarte (mucho...), o simplemente "cortarás y correrás"?

"¡Sí, tengo una necesidad comercial de contratarte!" Pero - "¿eres la persona que quiero contratar?" 🤷‍♂️