I'm going to graduate soon and I've been thinking. I have a few really small projects/scripts (~100-200 LOC) that I made on my free time and I have them on Github. I was wondering if they are "worthy" enough to be presented to future employers? Or should I only include those that are big (~1000 LOC)?
When we interview, we ask for this on the final interview. I will start by saying that size doesn't matter and then qualify a little (isn't that always the way).
If I ask someone to submit a piece of code they feel proud of and want to stamp their name to and they send me a single file then I'm going to lose confidence. In one case, I received a long ASCX code-behind file and there is nothing I can read into that except "boy does he like his code in the UI layer".
In other cases, I've received entire sizable projects. On one hand, that makes me more confident, but it also gives me a lot to pick holes in without digging very deep.
But here's the secret: the code itself doesn't matter that much. I can pick holes in anything you give me. What matters is how you react. Don't be argumentative for the sake of it, but also don't agree with me for the sake of it. I may not actually believe what I'm saying, and even if I do I will respect you for backing your code in a constructive way.
I think the question depends on how and when you are planning to present them to a future employer. Are they going to a line item on your resume or are employers asking you to give short descriptions of something you have done during an interview?
For a line item on the resume, I would lean toward just bigger projects. On the other hand, a smaller script is something you could describe to an interviewer in not much time and the full content could be grasped.
In the end, it depends more on how interesting the thing you are mentioning is. If the script does something that novel and happened to not take much code to do, there is weight to that.
"Judge me by my size, do you?" - Yoda
What completely matters is the quality. An impressive project is determined by the amount of things it can do, and the complexity of the things it can do, and that's all that matters as far as the end results are concerned.
If your project has 1,000 lines, of which the same 100 lines of code feature has been copied 10 times with slight modifications each time, then you're going to look like a bad programmer. You're going to look like a bad programmer because you would have failed to create something well. You'd have failed to keep your project maintainable, readable, manageable and scalable.
Just create things really great things well. There's no need to even consider length.
I personally do not thing the #LOC should be the determining factor. Instead I think it should be the creativity, complexity, and problem the project solves that should determine the code samples you submit. Most employers do not want to pour through lines of code just to find a snippet that proves to them that you understand complex algorithms and the like. If you are able to produce projects that display your skills without much to sift through I think that ultimately is a more impressive quality than sheer amount of code lines. That being said, having the link to a large project is useful if they were able to just compile the project and make sure that it is working. However all this really shows is your ability to write a program that appropriately separates concerns.
Size doesn't matter (as in LOC) really. It is (almost) in direct correlation with the language (more vs less lines for the same thing), so it would be unfair to judge anything on that basis.
I would more rate project as big or small, based on their number of features, personal interest to me, and the number of users it helped solve a problem (this should've been the first in the list).
Coding is like sculpting - it's not about writing more, it's about taking away what's not necessary.
A programmer's job is not to produce lines of code; the job is, instead, to figure out, from all the masses of junk code that could possibly be written, what's the smallest, cleanest set that will solve a particular problem.
If one of your projects shows the smallest possible, simplest, cleanest solution to a problem, use it as a reference. If it doesn't, don't.
I was never asked to provide code samples to an interviewer. Usually companies who want to make sure you know how to think and code give you an exam then in the technical interview you may be asked to write a little algorithm but most of the technical interviews I made for developers or made for me where discussions.