3 ms·

What kinds of projects do you consider that look good on a resume? If you need more context, I just started learning web development and want to start building

by soneca 10y ago

What kinds of projects do you consider that look good on a resume? If you need more context, I just started learning web development and want to start building some interesting projects that could help me get a job.

fecak 10y ago
The biggest thing with projects is that they're 'finished'. Most young devs have 20 sloppy repos or apps/sites with incomplete functionality that sends the message that the person is not able to finish something. Of course you can go back and refactor old code (which you probably will if you keep repos public as your career advances), but have at least a few completed and fully functional projects to show.
nameless912 10y ago
As someone who does some technical recruiting, things that look good: 1) Work experience. Let's face it, this always looks good to everyone looking over your resume. We all know that people hiring for an office have a bias for work you do in an office. I'm as guilty of it as the next guy. 2) Side projects. For me at least, starting stuff from the ground up (no matter how silly or niche) shows me the kind of code you write in your free time, which is a much better measure of your ability (but possibly a less rigorous measure of your success) than what you do at work, where you're constrained by deadlines, code reviews, and "best practices". 3) Open source contributions. This one is trickier; usually when you contribute to Open Source projects, you're doing small pieces of the big work that needs doing, and there isn't much decision making/architecting going on. Speaking as someone who's currently trying (and failing....) to get into Linux kernel contributions, 90% of the issues you're going to come across that are within your abilities to fix are the kind of thing that a more experienced dev could do in 20 minutes, but doesn't have the patience to sit down and do it (due to being busy with more important/pressing work). So, the vast majority of the work you'll do (especially early in your career) is going to be bound in scope by your lack of experience, and won't be as impressive as engineering something from scratch. In general, WRITE CODE. WRITE LOTS OF CODE. And show off whatever you can. And try to follow best practices, e.g. using CI/CD, writing good tests, using proper style, designing and documenting your architecture, etc.
purple-again 10y ago
When I'm looking at candidates repos I don't care what the project is. Music app, twitter clone, whatever. I just want to see a live project with a series of commits from 'ember new' all the way to deployment. I look at their migrations, model files, etc just to get a feel for how the person architects real world concepts.
deleted 10y ago
[deleted]
ktRolster 10y ago
Generally it's not so much what you build, but how it's built. If I look at your project, I'll be asking myself these kinds of questions: 1) Do you understand databases, or did you choose an easy project that lets you avoid knowledge of databases? 2) Do you understand how to write code on the serverside (either PHP, or Node, or Java, or Django, or something like that)? 3) Do you understand CSS/HTML/Javascript, or did you choose a project that makes it easy to avoid these things? Bonus points for React or similar framework. 4) If you are looking for work as a frontend developer, I would also include things like, "is the website attractive? Is it easy to use/user friendly?" 5) Do you know processes......git, Jenkins, AWS deployment, etc? You don't have to be perfect in all those categories, of course, but the higher you score in each of them, the better.

by soneca 10y ago

fecak 10y ago

The biggest thing with projects is that they're 'finished'. Most young devs have 20 sloppy repos or apps/sites with incomplete functionality that sends the message that the person is not able to finish something. Of course you can go back and refactor old code (which you probably will if you keep repos public as your career advances), but have at least a few completed and fully functional projects to show.

nameless912 10y ago

As someone who does some technical recruiting, things that look good: 1) Work experience. Let's face it, this always looks good to everyone looking over your resume. We all know that people hiring for an office have a bias for work you do in an office. I'm as guilty of it as the next guy. 2) Side projects. For me at least, starting stuff from the ground up (no matter how silly or niche) shows me the kind of code you write in your free time, which is a much better measure of your ability (but possibly a less rigorous measure of your success) than what you do at work, where you're constrained by deadlines, code reviews, and "best practices". 3) Open source contributions. This one is trickier; usually when you contribute to Open Source projects, you're doing small pieces of the big work that needs doing, and there isn't much decision making/architecting going on. Speaking as someone who's currently trying (and failing....) to get into Linux kernel contributions, 90% of the issues you're going to come across that are within your abilities to fix are the kind of thing that a more experienced dev could do in 20 minutes, but doesn't have the patience to sit down and do it (due to being busy with more important/pressing work). So, the vast majority of the work you'll do (especially early in your career) is going to be bound in scope by your lack of experience, and won't be as impressive as engineering something from scratch. In general, WRITE CODE. WRITE LOTS OF CODE. And show off whatever you can. And try to follow best practices, e.g. using CI/CD, writing good tests, using proper style, designing and documenting your architecture, etc.

purple-again 10y ago

When I'm looking at candidates repos I don't care what the project is. Music app, twitter clone, whatever. I just want to see a live project with a series of commits from 'ember new' all the way to deployment. I look at their migrations, model files, etc just to get a feel for how the person architects real world concepts.

deleted 10y ago

[deleted]

ktRolster 10y ago

Generally it's not so much what you build, but how it's built. If I look at your project, I'll be asking myself these kinds of questions: 1) Do you understand databases, or did you choose an easy project that lets you avoid knowledge of databases? 2) Do you understand how to write code on the serverside (either PHP, or Node, or Java, or Django, or something like that)? 3) Do you understand CSS/HTML/Javascript, or did you choose a project that makes it easy to avoid these things? Bonus points for React or similar framework. 4) If you are looking for work as a frontend developer, I would also include things like, "is the website attractive? Is it easy to use/user friendly?" 5) Do you know processes......git, Jenkins, AWS deployment, etc? You don't have to be perfect in all those categories, of course, but the higher you score in each of them, the better.