How extensive should a GitHub portfolio be for a CS student with no "real world" experience looking to secure their first internship?

Question

I am a CS student that has reached the senior level of the degree program. As someone with absolutely no "real world" experience in terms of working a job related to computers, I feel that it has become absolutely critical for me to start applying to internships.

However I have become a little overwhelmed and confused about how robust my GitHub portfolio must be.

My understanding is that a GitHub portfolio where you can showcase your programming skills is essential when applying for work in the field of computer science.

My confusion is regarding how many and what types of programs should I place into my GitHub and how many different languages do I need to code in?

The programs I have written in various classes are kind of all over the place, some are pretty mediocre, like coding a simple calculator to learn how to code GUIs. Or very basic programs to learn simple data structures.

Others are a little more complex like code that I wrote in my algorithms class, however in the algorithms class each coding assignment required us to add to the previous assignment so that by the end of the course we essentially only had one giant program with a lot of different functionality. I worry that might make my GitHub portfolio look a little sparse.

Even worse, I have pretty much only coded in Java so it would be somewhat difficult for me to code programs in C or C++. In fact, I haven't even learned Python yet because I started my degree program before Python become popular when the preferred language was Java.

I worry that coding a robust detailed portfolio for GitHub could take weeks (maybe even months?) especially if I need to include code in more languages than just Java. I worry that this will take so much time and effort that it will greatly delay my ability to actually start applying to internships.

If anyone could give me a few suggestions as to how detailed a GitHub should be for students looking to find their first internship, I would greatly appreciate it.

Answer 1

I don't know about internships, but I wrote on a different question earlier today that for real jobs, employers almost never look at a prospective employee's personal GitHub portfolio. I would presume internships are mostly the same, although they might look at your GitHub a bit more closely because they are not expecting you to have a robust resume; while I would say it's 100% useless for a real job, I would say it's maybe only 80% useless for an internship.

As for what to put on it: Just put in whatever, just to show that you have something in there. You may want to put some descriptive names or short descriptions on your projects which are particularly unimpressive, like school-assignment-calculator so whoever reads it knows not to expect too much. That said, don't put code there that's too messy and make sure to showcase your best work, because this is what employers may be looking at and you want to show your best.

As for which or how many languages to feature, the answer is "feature what is comfortable". If you want to work in Java, then there is nothing wrong with featuring only Java applications. If you want to showcase your portfolio to a company which works in Python, then they probably won't be impressed with a portfolio in Java and you may need to showcase some Python. Likewise, if you only want to showcase your portfolio to companies which work in Java, then spending a bunch of time learning and writing Python is probably not productive. So it's really up to what you want/expect.

Answer 2

In my experience as a junior programmer, very VERY rarely does my portfolio on Github get checked out. To give you a concrete answer on how many projects you should have is perhaps more than 5. Have some silly projects on there like weather API app, calculator app, that sort of stuff. If anybody was going to check, give them something to look at. It proves that you know how git works.

Since you're a graduate, it's slightly more important to have some work on there, but even so, you don't have to. Once I got offered a React.js role. They asked me if I had any react apps on my github, I said I didn't have any yet still got hired.

The idea of a portfolio is much overrated. It's what recruiters and gurus will tell you to do on LinkedIn. What gets you jobs is simply how well you present yourself with your CV and your interviews. As long as that is good, you can for sure score jobs even without having a Github. Mate of mine doesn't even know how to use git yet he got hired. He simply promised he'd learn it

Answer 3

This depends on what the particular employer is looking for. The quality of your public GitHub portfolio (or the lack thereof) is one of many deciding factors and I have never seen it be a deal-breaker. If the hiring manager is on the fence about hiring you, a great GitHub portfolio might tip the scales in your favor. Or you might run into a hiring manager who doesn't care to take the time to view your portfolio and instead makes the decision based solely on the interview.

Take what you have already and fix it up as nice as you can. If you have time, add a feature/framework/pattern that you are interested in. If you have more time after that, start a fun new project in one of the technologies you listed that you aren't familiar with yet to show that you are willing to learn.

Answer 4

Coincidentally I just sent out an internship offer to a candidate earlier today. We hire straight from the Computer Science faculty at the university I work at, which means that almost nobody has the amount of work experience that can convince me to hire them outright, and it means that everybody has almost exactly the same programming experience.

So what we do is we turn it around. We don't focus on the programming experience. We focus on all the other things. Things that some people call soft skills, but I don't like that term, as they're so much more important than the ability to write code.

When we evaluate applications and conduct interviews, we focus on people's communication skills. The stories about whatever projects they've worked on, and what they've learned from them. How did they manage their time and project scope? Did they settle on a Minimum Viable Product and iteratively worked from there, ensuring they had a deliverable? What did they do to ensure technical quality and prevent regression? The answers to these questions have very little to do with code or specific tools.

These experiences often do come from practical projects. But even if you can't show the code, you can share what you've learnt. So take some time, make yourself a nice cup of tea, and sit down with a pen and paper. Then start writing down what you learnt from each of your projects, the good and the bad. With that, you do two things: you make your story (who am I and how have I grown), and you make yourself a 'to-do list' of things you've identified are important but haven't got around to. If you do have the ability to get around to these things and gain the experience, that's a wonderful privilege. But if you don't, you'll add it to the story and call it "reflection", which is as important a skill as any of the others.

Answer 5

Your portfolio should provide credible evidence that you have sufficient skill for the position you are applying to. Since you don't have work experience, your portfolio will provide the next best indicator of your ability to do real world software projects. So ideally you want your portfolio to be as close as possible to the job you would be doing. It's okay if it's not a perfect match but the closer you get the better.

• The project scope must be non-trivial. Toy programs, basic exercises and trivial things are not a good choice here because they do not demonstrate a high level of skill. For example, a simple calculator is something people code during interviews. It is not adding anything new to your application. A complex calculator, that has support for unit conversions, algebra, calculus or graphing is a different matter.
• The tech stack must be relevant. If you are applying to a Java shop, projects in Java are better. That said, a lot of CS is language/platform agnostic. So even if you only have C and C++ projects, and during the interview you do well at the Java challenge, it is not a leap to say that your C/C++ skill would transfer to Java. But that is if you get called in to the Java interview with your C/C++ portfolio.
• The domain must be relevant. If you are applying for a frontend position, by all means spend time on the GUI and make sure you do a good job. But don't expect a GUI-heavy project to do much for you in a backend heavy position. Not only does it fail to demonstrate as much skill in target areas, but it also creates a question of whether you would even be happy working on backend when in your own time you only ever do frontend projects and never backend. Similarly, if you are interested in networking then a peer-to-peer application is good, a purely single player text adventure game is not so good.
• It must be clearly explained. If people can't even tell what your project is or what it's for, it can't be strong evidence. It may even be taken as evidence that you would be difficult to work with because you can't explain your work well. So make sure your readme and docs are all there, your code is commented, your git history is tidy, etc. But also when starting the project, make sure it is solving a clear problem that will be easy for people to understand.

You don't have to ace all four categories, especially for an internship. The majority of your competition has no portfolio at all. But if you are looking for ways to strengthen your portfolio, you should see which category is weakest and work on that. Don't worry about doing a perfect job in any of them. For example, it's okay to have some trivial projects, you don't have to delete or hide them. Having just one non-trivial project already demonstrates your ability to accomplish a non-trivial things. But of course a relevant non-trivial project is better than an irrelevant non-trivial project, because it is more direct evidence that you can do non-trivial work in that particular area.

Lastly, the number of projects doesn't matter so long as they address these points. If you can accomplish all four goals in a single strong project, then it is fine to have a portfolio with only one project in it. In fact you are better off with one major project than many tiny projects.

Answer 6

My understanding is that a GitHub portfolio where you can showcase your programming skills is essential when applying for work in the field of computer science.

You can use your GitHub profile for that, but it's not essential. Many employers won't look at it -- they rely more on giving you technical tests to see if you can solve problems. And there are other ways to showcase your work.

As someone who has been involved in hiring developers, I would be much more impressed if your "portfolio" consisted of a running system that I could actually use and test out.

A selection of the code you've written shows me how you write code, but putting a running system in front of me, demonstrates to me that your code actually works and that you know how to deploy it.

The simplest way to give whoever's going to read your resume a running system, is probably to build a website. There are hosting providers that provide free tiers for things like this. Granted, this is biased towards web development; it's perhaps more difficult to show off your knowledge of OS-level concepts, in a web app. But there are a lot of other things you can show off -- database knowledge, for example. And for someone starting out with no "real world" experience at all, web development is not the worst place to start, even if it means picking up some basic web development skills.

EDIT

I wrote the above thinking mainly about regular positions, not internships. It doesn't apply very well to internships, because schools focus almost exclusively on having their students write code, even though almost all software jobs involve building systems, of which writing code is only one part.

As a person involved in hiring, I want to know about your relevant past experience. If you are fresh out of school, the only thing that is likely to count as this, is assignments you've done at school. So, it would be great if you could supply these. They stand in place of what would be, on a more mature resume, previous work experience.

GitHub is a convenient place to share things like this, but it doesn't have to be on GitHub of course. "Back in the day" applications sometimes consisted of cover letter, resume, and code sample, on 3 separate sheets of paper.

And it doesn't have to be extensive. The important thing is that it reflects that you understood the assignment. Include the mark that the instructor or TA gave you for the assignment. If the assignment was for a GUI, include a screenshot.

Again, this stands in the place of previous work experience that you don't have yet. Your evaluation will almost certainly be based primarily on how you answer the questions in the interview process, not by the quality of this code. But it's good to show that you have accomplished something, even if "something" is just doing well on a school assignment.