Ask HN: Showing personal projects to potential employers | Hacker News Reader

Ask HN: Showing personal projects to potential employers

6 pointsBrewer7 comments

I've heard that when I go to look for an internship one of the most important things for a potential employer will be the projects that I've done in my free time.

This will vary from employer to employer, but what is it that you would be looking for when you see my projects? What would get me bonus points and what would make me lose points? What is important to you? Good documentation and commenting? Optimization? Apparent effort? What is a deal breaker?

View on HN

Fortunately I landed an internship in a good company because of my portfolio, not my grades. They saw that I was developing quite a lot of stuff that was not really related to my degree and they liked it.

I would look for something related to the thing that company does, but a range of different thingies created just for yourself shows that you're creative, learn quickly and actually like doing this stuff.

Coding your own projects it's better than sitting and doing nothing so I guess that it's hard to "loose points".

I'd like to get an internship with Mixpanel -- a web analytics company -- next summer so I've been reading up on data mining and I hope to get to work on a related project using Python in the next few weeks.

Speaking from my own internship experience:

1. The type of project you're doing: If you're applying to a game company, then your projects better be about AI, particle effects, or gameplay related

Bonus points if what you are doing fits the job description (in terms of the language you use or what your project is about)

2. Good coding practices (formatting, documentation, readability): Nobody wants to work with a guy who writes unreadable code

I definitely agree with meric. I look at code samples/projects to gauge how good the developer is. Most likely the code will be read, not executed. So, good design is a huge plus, but well thought out programs or clever but readable code is a great-to-have. Documentation and commenting I ignore unless they're necessary (hard to read logic). I wouldn't OVER-optimize these projects either, since they'll simply be read over.

If the company has an API, build something with it.

Sounds like brown nosing to me. :P

In my short experience, any project > no project and complete projects > incomplete projects.

Reply on news.ycombinator.com