work samples for junior developers -- what does an employer want to see? [duplicate]

Question

I have a github which has a series of repositories.

• A photoshop-esque clone (java)
• A web application tutorial series, with branches for each tutorial (python/flask with a touch of javascript)
• A WebGL project (javascript and WebGL/Three.js)
• A 3D Game (Java/OpenGL)

My question is -- what do employers want to see and not want to see? Would there be things that are better to omit?

For example, I wrote the photoshop clone a fairly long time back and it doesn't seem to be up to date with my current level.

My web application may have 100% test coverage and follow all the best conventions with a tutorial for each branch, but is unfinished and remains at a pretty rudimentary level of functionality (log ins, profiles, logout, and the ability to edit profiles)

What would be best to include?

Answer 1

At the minimum, your prospective employers want to see from you clean, well organized code that makes sense. They would also be interested in seeing code from you that employs the frameworks that you claim you know. They might want to see how you go about testing your code and making sure that it does what it's supposed to do.

In terms of style, they want to see code from you that is solid enough to survive several rounds of maintenance. They want to be comforted that those great things that you've be saying about yourself as a software engineer actually check out and that your coding style is compatible with that of their development teams.

And they want to have some kind of estimate as to how your skill level fits in with the skill level of their existing staff.

Answer 2

I'd say they want to see:

• Whether your typical code conforms to their standards.

  Many / most people like to see clean, readable, maintainable code that conforms to some coding standard (which one isn't as important as consistency).

  Some will appreciate being able to quickly write working code - if the code was written for a programming competition or something with similarly tight time constraints, it being slightly slopping won't look too bad.

  Then there are also things like:

  • Do you favour efficiency above readability or vice versa?

  • Do you use design patterns too much or too little?

  • Do you always write modular code or do you mix it up a little when you think it would make the code more compact without sacrificing readability?

  These are just some questions that don't have 'right' answers - it will depend on their opinions on the matter.

• Where your abilities lie.

  If they're looking for a senior developer and your most recent code is just some messing around with basic linked-lists and binary search trees, that will give them a good idea that you're probably not a good fit. Similarly you could have too much experience for a role, although, ideally, that might lead to getting considered for a more senior role.

  If you have a lot of code that shows you have experience with tools they work with, that will be a good sign for them (while lack of such code might not necessarily be a bad sign).

• Whether you actually enjoy coding enough to spend free time doing it (and how much).

  This pretty much speaks for itself - a massive amount of code will likely show that you're quite fond of spending your free time coding.

• Where your interests lie.

  If you've written exclusively graphical applications, and a ton of them, and the role is for something with no graphics programming, that would probably be a bad sign for them, although not that bad, as it's possible that you couldn't be happier doing what you do in your job, while spending your free time doing something else.

---

If you have a large code base, it's a bit of a balancing act between abilities, interests and just amount of code.

Keep in mind that old bad code may or may not count in your favour - it might show how much you've learnt since then, it might seem like you're still proud of it or someone may just not be paying enough attention and think it's recent (a comment putting it in perspective could help).

Answer 3

This will vary from company to company and from hiring manager to hiring manager but in my personal experience I've found that typically when a hiring manager looks at something like a client's GitHub account what they are really interested in is what kind of technologies, techniques, ect you're familiar with. Might also be looking to see what kind of practices and standards you're following (if any) and what type of projects you like to work on when given a choice. For a junior level developer with minimal to no professional experience or prior relevant employment history they might also be looking to make sure you know actually know how to code. Most employers probably won't dive to deeply into any given project.

As far as what to include and what not to include it's ultimately up to your discretion but for the most part things will only raise a red flag if they blatantly illegal (ie: some sort of Pirate Bay esque application). However as far as unfinished and/or buggy projects go then you'll probably be fine but you should be prepared to talk about them if you expect it to come up in an interview. If that's the case then be prepared to answer questions like "how would you fix bug x or how were you planning on implementing feature y".

Answer 4

Unless you think one of the 4 you posted is not appropriate for a particular position (or you run out of room on your CV), you can leave them all.

The subject of coding may not come up in the job placement process until the 2nd or 3rd interview which tend to get more technical. If your online code doesn't get mentioned, you should bring is up as a follow-up question. Just ask what they would like to see and point them in that direction. This will save them time.

Otherwise, I think everyone wants to see something that: is good quality, matches the job description, and possibly has some level of complexity.