¿Cómo debería ser mi "muestra de código"? [cerrado]

Acabo de tener una entrevista telefónica bastante buena (para un puesto relacionado con CakePHP, no es que sea especialmente importante para la pregunta). El entrevistador parecía estar impresionado con mi currículum y mi personalidad. Al final, sin embargo, me pidió que le enviara un código de muestra de mi proyecto de trabajo existente, "para comprobar que no eres secretamente un programador terrible, ¡ja, ja!"

No me preocupa demasiado que mi código no pueda sostenerse por sí solo, pero soy más un programador intermedio que un experto. ¿En qué obstáculos obvios debo asegurarme de que mi muestra de código no caiga, en caso de que me descarten en el acto? En segundo lugar, y esta es probablemente la parte más difícil de la pregunta, ¿qué características de una muestra de código serían tan impresionantes que instantáneamente lo inclinarían mucho más favorablemente hacia el programador?

Todas las ideas o sugerencias son bienvenidas!

Me gustaría ver el código limpio :

Código limpio : código de software que está formateado correctamente y de manera organizada para que otro codificador pueda leerlo o modificarlo fácilmente.

Eso significa:

• Funcionalidad : algunos bits simples de funcionalidad que no son triviales (un montón de captadores / establecedores no mostrarían que sabes algo)
• , Estilo limpio Consistente - Popular o al menos común estilos carcasa, la sangría, el espaciamiento y soporte
• Buena denominación : nombres de calidad, no los use a imenos que sea el único valor de incremento. No use nombres de variables sin sentido.
• Otros atributos del código Clean : buenas prácticas en la verificación de errores, condiciones, bucles, métodos de conveniencia o métodos de utilidad, y una buena separación de preocupaciones (entre métodos). Y este es un buen momento para estar 100% SECO , ¡ sin repetición!

Desea enviarles algo que sea lo suficientemente complejo como para ser interesante pero lo suficientemente limpio como para que un buen desarrollador pueda entender casi de inmediato lo que está haciendo.

Algunos de los comentarios anteriores parecen preocupados por la facilidad con que esto podría ser falsificado. * Si desea protegerse contra esto, posiblemente envíe una descripción rápida del propósito y el historial del código en el correo electrónico.

^{* Por lo menos, si el entrevistador preguntó sobre proyectos pasados ​​por adelantado, luego le pidió una muestra de este proyecto y le preguntó qué requería que lo escribiera o cómo evolucionó, creo que el proceso sería bastante mentiroso. Creo que la mayoría de los candidatos que sería mentir van a mostrar problemas en otras áreas, de todos modos.}

Cuando buscaba trabajo, resolví un montón de preguntas del concurso de programación de ACM, en varios idiomas diferentes, y las utilicé para muestras de código desde entonces. Creo que hicieron buenos ejemplos de código porque:

• Resolvieron problemas desafiantes
• El problema no requirió una gran cantidad de contexto, además es fácil responder las preguntas
• El código escrito no tiene ningún riesgo de IP asociado.
• Cada problema puede existir razonablemente en un solo archivo, y a menudo no es extremadamente largo, por lo que debería ser fácil para cualquiera compilar y probar su solución, y puede usar los datos de prueba de las preguntas.
• Muestra que puedes dividir un problema complejo en partes más pequeñas.
• Si le preguntan cómo funciona algún aspecto de su solución, le brinda una gran oportunidad para demostrar que sabe de qué está hablando, especialmente si tiene muchos años pero puede descifrar rápidamente lo que está sucediendo.

Y luego, el código que cree debe ser claro, consistente, fácil de leer y fácil de entender.

Y por último:

• Vale la pena resolverlos solo por diversión, y es una buena práctica.

• Debe compilar / interpretar errores y advertencias libres al más alto nivel de rigor.
• No debe ser un código repetitivo que escriba todos los días. Hazlo único e interesante para que sea obvio que no lo copiaste / pegaste.
• Debe tener algunas decisiones de diseño interesantes con comentarios que expliquen cómo / por qué las hizo.
• Apunte a no más de 2-3 páginas impresas.
• Debe estar en el idioma que está solicitando.
• No debería hacer que me duela el cerebro cuando lo leo por primera vez. Haga que un amigo lo revise o publique en codereview.

Bueno, si te estuviera entrevistando, me gustaría ver tu código.

La limpieza es buena, la resolución de problemas es buena, pero el código verdadero es mejor. Un buen programador sabe cuándo fue estafado por otro programador, por lo que la confianza podría disminuir.

Leer el código de otra persona es como bailar teniendo sexo: sabes cuándo es real y si la otra persona lo está fingiendo, al final ocurrirá un desastre. (Acabo de darme cuenta de que los nerds reales no saben bailar)

Solo confía en ti mismo y en tus habilidades de codificación . A menos que realmente conozca a su entrevistador, no puede anticipar lo que espera de su estilo / habilidades de codificación.

También tenga mucho cuidado de que NO sea un código de su empleador actual (ellos son dueños de usted y no garantizo que no les guste que lo comparta). Tome algo de lo que esté orgulloso y reprocese por su cuenta para no ser específico del empleador (elimine las referencias a sus tablas de bases de datos o nombres de servidores, etc.). Haga lo que haga, no envíe código que tenga errores o sea una técnica pobre para el tipo de código que es (probablemente rechazaría a alguien que envió un cursor cuando una operación basada en conjuntos sería más simple y funcionaría mejor al revisar el código SQL. Existen técnicas similares para otros idiomas que están ahí para resolver un problema relativamente raro que puede usarse para otros problemas más comunes pero que no son la mejor opción para esos otros problemas. ¿Tiene sentido esa oración?)

Secundaría la publicación de Renesis sobre código limpio, pero agregaría a la lista que proporciona calidad y pruebas unitarias bien documentadas al código que envíe. Un buen programador debe escribir pruebas unitarias para su código.

Como una opinión de alguien que solicita muestras de código cuando evalúa candidatos, hay algunas características de alto nivel (contenido del código) y algunas características de bajo nivel (estructura del código). Características de alto nivel:

1. Identidad : el sabor del código. Si se está facturando como un codificador de UI / HCI, quiero ver un buen aspecto para algo visual cuando lo ejecuto. Si eres un constructor de bases de datos, quiero ver algo interesante con la representación o el análisis de datos. La muestra debe ser algo de lo que estés orgulloso . Si no tiene al menos uno de esos, no tiene identidad.
2. Madurez : ¿Cambias las estrategias para diferentes problemas? ¿Estás resolviendo problemas interesantes? ¿El código o enfoque sería fácil de extender a un problema similar? Por el contrario, ¿siento que estoy mirando a un miembro de una comuna de culto de carga?
3. Comunicación : ¿El código explica fácilmente lo que está haciendo y por qué? Esto no significa que el código deba ser simple. De hecho, es una ventaja hacer que el código complejo sea fácil de entender.

Los aspectos de bajo nivel son más simples:

1. Estilo : el código debe ser limpio, coherente (sigue algunas pautas establecidas) y bien documentado.
2. Empaquetado : debe haber como mínimo un archivo Léame breve, una versión ejecutable y pruebas ejecutables. El archivo Léame debería decirme cómo ejecutar los dos últimos, así como por qué está demostrando este ejemplo de código en particular.
3. Idioma (s) : por lo general, le pido a alguien una muestra en el idioma para el puesto, así como en el que se sienten más fuertes. Da una buena idea de los límites máximos actuales de una persona.

Para un buen candidato, espero que una muestra sea: A) Una pequeña muestra a prueba de balas o B) Una buena parte de un proyecto interesante más grande (por ejemplo, un módulo de un repositorio personal de Github). Espero que sean proyectos personales o proyectos académicos. Si envían uno de un proyecto pago, espero una nota de que se les dio permiso para usarlo. Si no recibo esa nota, los cortaré de los candidatos (candidato débil) o les preguntaré al respecto durante la entrevista (candidato fuerte). No tener permiso sería una gran bandera roja (probablemente insuperable). Para un candidato avanzado, espero un descargo de responsabilidad que indique que algunas de sus mejores muestras de origen no se pueden mostrar porque se hicieron como parte de su trabajo. Sin embargo, entonces espero un testimonio efusivo de por qué están orgullosos de ese diseño que no se puede mostrar y de cómo lo aman como a un niño.

Finalmente, por mucho que algunas personas repitan que "Oh, alguien podría obtener una muestra de código de Internet", el contraargumento es que la mayoría de las personas que no entienden el código de buena calidad de producción tampoco lo entienden cuando lo ven. . Además, siempre se puede buscar en Google una línea distintiva para verificar el código. Además, en el mejor de los casos, robar código llevará a un candidato a una entrevista donde se avergüencen ("Entonces, ¿por qué lo hiciste de esta manera ...?").

Como última nota sobre el código del empleo anterior: simplemente no lo hagas. Desde el punto de vista de RR. HH., Pedir un código de un empleo anterior es inapropiado y una señal de alerta sobre la empresa. Ambos tendrían responsabilidad legal (es decir, ambos podrían ser demandados) y esto demuestra que no tienen idea de lo que están haciendo. El código hecho para un empleador anterior nunca debe darse a menos que el código ya esté disponible públicamente o tenga permiso explícito de ese empleador. Peor aún, en una gran empresa, su jefe directo puede no tener el poder de otorgarle permiso, ¿se divierte con el departamento legal en ese caso? Estoy seguro de que estarán encantados de exponer su IP para un empleado existente.