What kind of projects make a junior candidate stand out from the rest?

In my opinion, it is not so much about the "type of projects" but more about the "understanding of your work" and ability to explain why/what you built.

I have interviewed candidates who supposedly had a great Github Repo of apps they built but couldn't answer simple questions like "Why POST, why not GET. Can you do GET instead of POST. If yes, why. If yes, Why not". They got mad at me and told me "haven't you looked at my Github". I replied "I did and that's why I am asking how you built that project".

If I am hiring entry level, I wouldn't care if you built a Game or a CRUD App. I would care how you built it and how far can you explain the process of building it. How much do you really understand of what you built. For example, let's say you built a "Contact Form". I want to understand do you really know the difference between GET vs POST requests (you will be surprised how many candidates fail at this). I couldn't care less if you can just memorize how to add a GET API. I am more interested in your understanding of it. I want to know how the form gets submitted to the server (lot of candidates don't know how an http Request is formed, header vs body etc). Lot of candidates truly don't know how an AJAX request works. For example, if you submit a Form using Ajax vs Regular action, whats the difference ?

So, build anything which you can explain and walk through the process of. I would at least hire you.

If you're not getting called back for interviews, you probably need to work on your resume / cover letter / personal site.

If I get an applicant that writes a competent cover letter they stand out significantly from others (who often don't even bother!).

On your resume try to minimize details that aren't relevant to software development - keep it focused on software-related education/experience, skills, and projects. If you have significant non-software related education or experience that's worth mentioning, keep it short, as a side note.

An applicant with a reasonable personal site also stands out (it doesn't have to be extraordinary, just something simple and aesthetic that serves up your resume, links to your projects, etc.)

As for the projects themselves, the best advice I can give is to demonstrate business value. Creating a game or some nifty 3D site is neat, but it could be hard for an employer to be confident that your portfolio can translate into what they are doing. So aim for "business-like" websites, with beautiful landing pages, and functionality like forms, buttons, modals, etc. If you can also brag about how fast you got your project(s) done, that might also catch an employer's eye.

With juniors, I'm looking at a few things:

1. Bullshit. Juniors are mostly blank slates and anyone who hires a junior can train. But you can't fix a liar.

2. Potential. The variance for a junior is a lot higher than a senior. It's sometimes a bit of lottery.

So I do indeed look for people who can be amazing over people who can get the job done. A chess game would be a hint of amazing. Many great devs started with a game.

I hired one junior because she made a crappy robot. It didn't matter that the robot was crappy. It mattered a lot more that robots aren't a software developer "thing". The first page of her resume was typical, but the crappy robots on the second page onwards were interesting. She turned out to be an excellent programmer and I paid her about 30% more than the usual, but alas we couldn't afford her for long.

What's interesting was that nobody else gave her an interview, so from a statistical view, she did poorly. But she got some above average jobs from it later so ultimately she succeeded.

There's a lot of dumb "rules" around applying for jobs, but I'd say it's a lot like dating. Don't dress for who you expect to meet. Dress for who you want to meet.

Companies probably aren't even looking at your projects, but I'd keep it simple if all you wanted to do was build projects for a portfolio. Simple website with login + database.

If you're not getting a call back for interviews you should probably improve your resume. Maybe list and describe your projects as well, stuff you've learned from it, books you've read, communities/meetups you've gone to.

> I'm not talking about "just follow your heart and build something you would want to use"

In my opinion I do just build what I want. Passion projects are more interesting imo. You can describe and talk about them better, your goals, what you've learned, how you would do it differently, etc.

Most resumes only get looked at for 6 seconds before they end up in the discard pile.

You want to fix your resume so that that quick glance is enough to make you look interesting.

That means: - Having a summary section at the top that highlights somethings special about you (which shows you'll be a valuable employee). Anything that shows initiative or curiosity is a big win here. - The work/project experience sections should call out projects that you've worked on. The online title describing what it does is what matters. No one will look at your code. No one will click on your links (unless they find you really intriguing). They'll make a judgement based on the text and what they assume you actually did on each project, so simple is fine.

So what does this mean for projects? Work on the stuff you find most interesting. Whatever scratches your itch

I want to know that a junior candidate:

* Can actually produce something

* Cares about the craft of software development (learning the why behind things instead of just copy-pasting examples until it works)

* Has the initiative to be self-directed (learning and growing and pushing through obstacles instead of just waiting for someone to tell them answers)

* Understands how to work with other humans

Everything else will come naturally if the above are true. What will make someone stand out is showing that they are outstanding in one of the above categories. Almost any side project will show the first category. A side project that involves some complexity under the hood that you can talk about and talk about the struggles of learning it is even better because it can show some of the others.

If a junior candidate made something that fulfills any of the following, I’d be really impressed:

* Generates real revenue (either subscription, or one-time)

* Regularly used (e.g. a few dozen people who log on every other day)

* Useful enough that its users would be sorely disappointed if you pulled it

* Recommended openly on the internet (e.g. Twitter, Reddit) from people who have no relation to you

If you’re not being called back, it might not be because of your portfolio projects or lack there of. You might just not be standing out during the 5 seconds in which someone’s glancing over your cv. Time to change the dynamic. Can you network into these companies? Do they host meetups? Perhaps you can find a mentor who works there. Can you get some feedback on your CV and resume?

I think the projects are important, but probably not at the initial stages. Projects also teach you things, so I’m certainly not telling you to stop. I just don’t think that’s the reason you’re not getting through the screen.

The highest value projects to employers are individual, custom, novel, contemporary, domain-specific, applied, potentially high-value business impact, and end-to-end.

Lower value projects are the inverse - group, generic, templated, uses outdated technologies, rehash of common examples, academic, and research-oriented.

You're whole premise is wrong, a similar mistake we often make as programmers is trying to optimize without profiling.

You can build homebrew but still be rejected at Google.

Accepted pull requests to open source projects run by someone else. If PRs look even decent that will almost guarantee an interview with me for a young dev. It will guarantee me a look at just about anyone.

Write something rubbish/terrible, use it as a talking point about your learning journey, what you did wrong and what you learned from it. Maybe throw in a suggestion around how you would do it now. Bonus points if you mention using a technology the current company is using.

as someone who is constantly hiring frontend engineers and who has a partner who is hiring frontend engineers, i can tell you that the industry is absolutely flooded with entry-level candidates from other industries who took a two week bootcamp and whose github profiles are full of the exact same projects.

my only advice: don't make a todo app, a weather app, or any other kind of simple productivity/display-results-of-single-api-call apps. everyone has those and they're a signal that the candidate does not have real-world experience or experience building applications on their own (i require at least one of these).

> Since my goal is to build things FOR OTHERS I thought it's wise for me to ask what would someone want to see in my portfolio.

In this instance, you need to stand out for yourself in order to (get a job and) build things for others, so your portfolio needs to show that you understand both the basic and the nuances of your projects, and the underlying issues. It would help your case / cultural fit the fact that you possibly have a preferred industry already and send applications to related businesses in a relatable domain. Other than that, keep pushing, keep networking, keep knocking on doors. Good luck!

Projects that show that you are able to work collaboratively in a larger context. Patches to bootstrap, Angular.JS, the Go language's runtime, etc, are much more impressive than, say, websites you coded by yourself.

I don't care if you even have "side projects"

I care that you care about your work - doing your best, taking constructive criticism (and knowing how to ignore non-constructive criticism), improving, etc

If you can show that to me with your "side projects" - cool

If you don't have any "side projects" - also: cool

You don't have to spend your entire professional and personal life in front of a screen to "stand out from the rest"

You have to be able to coherently communicate and tell me how you currently add value to your present position, or how you expect to add value to a position with my company

Personal, professional, alumni connections matter more than the specifics of a resume or portfolio.

Because someone has to look at the resume/portfolio for its content to matter.

If you want a job, look for a job.

That's hard because looking for a job is mostly experiencing the risks of rejection.

Building a project for your portfolio first is easy because it completely avoids the risks of rejection.

The reality is, that no matter what you build the odds are no one will call you back because that's the default.

In the world of work, what you know is a value from 0.00 to 1.00. Who you know is a factor from 0.00 to 1000000.

Good luck.

If you are not excited by what you are building then there's something missing. I'm not sure that "build things for others" means anything. But maybe you're just a really great person and want to help others, I don't know. There's nothing wrong with "yet another Genshin impact wishes simulator" (wtf is that?) if you are excited about it! But you don't sound excited about it.

I think most comments misses the perhaps non obvious point. You may have some other fatal flaw in your resume.

I think you should call up the recruitment people to whom you applied and ask for feedback on your CV and/or application.

They would know best.

Then ask for tactical tips on how to get called.

After exhausting these options, then maybe, it could be appropriate to ask about the significance of hobby projects.

As others have mentioned, fix your resume. Regarding projects, in your resume talk about your projects in terms of what value the learning would bring to the company you're applying to. People WILL care that you made a chess game if you can tell them the value that learning how to implement a chess engine could bring to their organization.

What job do you ideally want? Build something relevant to that. I’m an experienced dev but this helped me a ton during my recent career move into a different niche (where many jobs require experience in that niche which I did not have).

Put another way, build something targeting the skills you want/need.

The number one thing I look for in candidates is curiosity. A willingness to look stupid by not knowing an answer, but being more curious to learn the answer. People with this mindset tend to learn very quickly and it shows that you’re not a one-trick pony.

if you've never had a coding job before, the best thing you can do for your resume is work on a project that looks like a coding job

This could be a very professional open source project like mozilla, where you can help triage tickets and fix small bugs and get mentorship and tasks from other senior members

or the crypto space is a good area to do this, there are tons of daos, coins, and tokens that could use frontend help and you could basically treat it like a job, spend a ton of time on the project and end up with a great resume section + some recommendations probably or leads on getting a real job

If you can solve a real business problem you can prove yourself and learn a heap. Do you know any business owners that you might be able to produce some software for?

Any non-bullshit project is good. But if you can do some basic coding and communicate clearly, I will teach juniors the rest.

Most places use a screener that will automatically trash your resume is you don't have a degree.

they only care whether you can do leetcode BS and if you have the right keywords in your resume.

> As a self-taught I'm getting the impression that, while I'm learning the basics following tutorials, FreeCodeCamp, the Odin Project etc. there's no one calling me back for interviews, and the cause for that is the type of projects that I'm building.

What causes you to get that impression? That the issue is the projects you are building, not something else? Feedback from the hiring manager? A feeling? A word from someone on the inside? Or something else?

Because as a (former) hiring manager, I can tell you there are any number of reasons that you aren't getting the interview.

  * other folks are better
  * there was a typo on your resume
  * you weren't in the first 50 submitted and they trashed the rest
  * your resume didn't indicate you could meet the need
  * your projects were underwhelming
  * they decided to not hire (budget!)
  * they shifted the job reqs
  * an employee referred someone they knew for the position

I could go on. The point is there are many reasons that you might not get an interview.

So if you don't have explicit feedback that it is the projects, it may not be.

I don't have a magic hiring wand (oh, at times I wish I did), but I've seen a few newer developers get hired and the ones that did stood out in some way that was relevant to the job. They had background, projects, knowledge, connections, etc that was relevant to the position.

I know nothing about your situation other than what you shared, so take my advice with a grain of salt, but I'd start targeting companies where you have an edge.

What kind of edge?

   * Well, have you done any other kind of work? Look for companies doing that or consulting firms helping companies do that. This can be related (did you work in a restaurant as a host? Then you know customer service; look for companies that help folks automate customer service interactions).  
   * Do you have any hobbies that relate to work (other than coding)? Look for companies that such hobbies might apply to.

Look for that edge! You have one and all it takes is one yes.

Finally, to actually answer your question, I think that a friend's advice is best: helping on an open source (OSS) project is probably the best kind of project you can do. Not a project you build and slap the MIT license on, but a real OSS project. Why? Because that will illustrate a number of things:

  * you can work on a team
  * you can do things other than code (test, doc, customer support, etc)
  * you will work in public
  * you can work remotely
  * you can write (if you do writing)
  * you can code
  * you can take feedback

All of these are very valuable skills that are ancillary to coding, and with an OSS project you can demonstrate them.