Me voy a graduar pronto y he estado pensando. Tengo algunos proyectos / scripts realmente pequeños (~ 100-200 LOC) que hice en mi tiempo libre y los tengo en Github. Me preguntaba si son lo suficientemente "dignos" para ser presentados a futuros empleadores. ¿O debería incluir solo aquellos que son grandes (~ 1000 LOC)?
8
Respuestas:
Cuando entrevistamos, pedimos esto en la entrevista final. Comenzaré diciendo que el tamaño no importa y luego califico un poco (no siempre es así).
Si le pido a alguien que envíe un fragmento de código del que se sienta orgulloso y quiera estampar su nombre y me envíe un solo archivo, perderé la confianza. En un caso, recibí un largo archivo de código ASCX y no hay nada que pueda leer en eso, excepto "chico le gusta su código en la capa de interfaz de usuario".
En otros casos, he recibido proyectos enteros de gran tamaño. Por un lado, eso me da más confianza, pero también me da mucho para hacer agujeros sin cavar muy profundo.
Pero aquí está el secreto: el código en sí no importa que mucho. Puedo hacer agujeros en cualquier cosa que me des. Lo que importa es cómo reaccionas. No discutas por el bien de esto, pero tampoco estés de acuerdo conmigo por eso. Puede que en realidad no crea lo que digo, e incluso si lo hago te respetaré por respaldar tu código de una manera constructiva.
fuente
No es el tamaño del proyecto. Es la calidad. Tómese el tiempo para hacerlo bien para que sea digno de ser una pieza de cartera. Mientras el proyecto sea lo suficientemente grande como para demostrar el conocimiento que desea transmitir, solo importará la calidad.
fuente
Creo que la pregunta depende de cómo y cuándo planea presentarlos a un futuro empleador. ¿Van a una línea de pedido en su currículum o los empleadores le piden que haga descripciones breves de algo que hizo durante una entrevista?
Para una línea de pedido en el currículum, me inclinaría hacia proyectos más grandes. Por otro lado, un guión más pequeño es algo que podría describir a un entrevistador en poco tiempo y se podría captar todo el contenido.
Al final, depende más de lo interesante que sea lo que estás mencionando. Si el guión hace algo tan novedoso y resulta que no requiere mucho código, eso tiene peso.
fuente
Lo que importa por completo es la calidad. Un proyecto impresionante está determinado por la cantidad de cosas que puede hacer y la complejidad de las cosas que puede hacer, y eso es todo lo que importa en lo que respecta a los resultados finales.
Si su proyecto tiene 1,000 líneas, de las cuales la misma característica de 100 líneas de código se ha copiado 10 veces con ligeras modificaciones cada vez, entonces se verá como un mal programador. Te verás como un mal programador porque habrías fallado en crear algo bien . Habría fallado en mantener su proyecto mantenible, legible, manejable y escalable.
Simplemente crea cosas realmente geniales bien . No hay necesidad de considerar siquiera la longitud.
fuente
Personalmente, no creo que el #LOC deba ser el factor determinante. En cambio, creo que debería ser la creatividad, la complejidad y el problema que resuelve el proyecto lo que debería determinar los ejemplos de código que envía. La mayoría de los empleadores no quieren pasar por líneas de código solo para encontrar un fragmento que les demuestre que entienden algoritmos complejos y similares. Si puede producir proyectos que muestren sus habilidades sin mucho que examinar, creo que en última instancia es una calidad más impresionante que la gran cantidad de líneas de código. Dicho esto, tener el enlace a un proyecto grande es útil si solo pudieron compilar el proyecto y asegurarse de que funciona. Sin embargo, todo lo que realmente muestra es su capacidad para escribir un programa que separe adecuadamente las preocupaciones.
fuente
El tamaño no importa (como en LOC) realmente. Está (casi) en correlación directa con el lenguaje (más vs menos líneas para la misma cosa), por lo que sería injusto juzgar cualquier cosa sobre esa base.
Calificaría más el proyecto como grande o pequeño, según su número de características, interés personal para mí y el número de usuarios que ayudó a resolver un problema (este debería haber sido el primero en la lista).
fuente
La codificación es como esculpir: no se trata de escribir más, se trata de quitar lo que no es necesario.
El trabajo de un programador no es producir líneas de código; el trabajo es, en cambio, descubrir, a partir de todas las masas de código basura que posiblemente podrían escribirse, cuál es el conjunto más pequeño y limpio que resolverá un problema en particular.
Si uno de sus proyectos muestra la solución más pequeña, simple y limpia posible a un problema, utilícelo como referencia. Si no es así, no lo hagas.
fuente
Nunca me pidieron que proporcionara muestras de código a un entrevistador. Por lo general, las empresas que desean asegurarse de que sepa cómo pensar y codificar le hacen un examen y luego, en la entrevista técnica, se le puede pedir que escriba un pequeño algoritmo, pero la mayoría de las entrevistas técnicas que hice para desarrolladores o para mí fueron discusiones.
fuente