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.

I've seen this pattern from BootCamp/self-taught candidates.

If you end-up interviewing candidates from the same bootcamp "batch" they'll all have the exact same portfolio project (and if you diff them there's going to be little to no difference between the different ones!) because they all followed the same tutorial to do it.

So yeah, unsurprisingly, none of them could answer why use a POST vs GET operation.

You are probably going to be downvoted, but this is the sad reality of the time when GitHub projects have become a measure.

I have seen lot of people making exact same project from seeing some tutorial and putting it on GitHub. And that was a college, not a bootcamp.

You must have lots of qualified candidates to choose from if a game or a CRUD app isn't a shoe-in for an entry-level position. Many developers who call themselves senior would struggle with writing such programs.

People have holes in their knowledge. Some people don't know how the difference between GET and POST, others can't explain hash tables, why merge sort is preferable over quick sort for disk-based storage, or the difference between a lambda and a closure, and so on.

I have fortunately not yet had to work with a senior web developer who would struggle with such a basic question about how the web works.

Now if I hired a firmware engineer, sure they might not know about GET vs POST.

Are you looking for something as simple as GET is for fetching data and POST is for inserts? Or something beyond that (state, idempotency,...)?

I am curious. What is the difference between an ajax and form post

Form post always causes a page load. An AJAX request is done asynchronously without changing the page until the request either succeeds or fails, at which point what happens depends on the code on the page.

You can submit a form without JavaScript

so once they answer your questions, are you going to have them do the leetcode BS? let me guess…

I personally don't :). We are not FAANG and unless I have that level of demand from candidates, I wouldnt do it

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.

I do tend to keep my software resume focused on software things and it's good advice for someone with software experience to show, but I think it's probably a big miss to ignore the value of skills developed in most other industries. Even a barista job has arguably more relevant skills to a software job than programming does. People would like to think programming is the core competency of a software developer, but probably it's the things that your manager defines as your job that actually keep you in it. Things like showing up on time, communication, being subordinate, writing skills, ability to do mindless repetitive assembly line bullshit work for extended periods, working with idiots, working for ladder chasers/idiots, etc..

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

I'm really sorry to say this but you are an exception to the norm when it comes to cover letters. Most hiring managers really don't give a shit and from an applicant's perspective it becomes a waste of time, hence why you get some 'fuck it I'll submit it without a letter anyway' types.

Many places don't even have the decency to send out a nice rejection email, which feels all the more antagonistic when you get ghosted after spending significant (non-transferable) effort drafting the letter.

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.

i suspect i got discarded as an entry level developer because somebody thought i was lying about some web design work done for a now-defunct web business in a tiny town. i made a website as a freelancer for the business, and the sites had vanished whenever somebody with hiring power asked to see them. he ghosted me.

in retrospect, i'm glad it didn't work out because he invited me for coffee but it was really a job interview, just unstated. talk about not being honest.

but it sucked, because later i had another "coffee" with the CTO for company who was friends with that guy. i mentioned to the CTO that i had met with his friend. later, after the meeting, he basically backtracked on the potential for working for them. i've always wondered if the two dudes talked and i got passed on because of my presumed dishonesty.

i'm doing fine without them, though. both of those dudes are pretty gate keeper-y in this small city tech scene, but i’ve made a network with some co-workers from my first job as a developer, since those are the ones who really know what’s up anyway.

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.

The first filter (HR/recruiting) may not look at your projects. By the time they get to me (an engineer), I'm going to spend 15 mins digging through this candidate before the first interview.

I will check whether your projects do CDN or whether you write functions with more than 4 arguments. There was a guy who put a project in a certain framework on his resume to prove he knew how to work with that framework. That project had one commit and it was titled something like "fris commit". That made me go "hmmmmm".

I don't judge too harshly because I know not everyone puts their code open source. But I do pay a lot of attention to what someone puts out there. I have interviewers who say "Hey I loved your Medium posts" or "Hey I saw your screenshots on AI on Facebook", so I doubt I'm the only one.

> I will check whether your projects do CDN

Assuming you mean Content Delivery Network by CDN - why would you look at at that when it's just a project? For private use projects, I can't see a need for any sort of CDN, at all.

They don't need to, but sometimes some people do (especially juniors). That's the idea, appreciate the trivial things that people do on their projects.

I would say the opposite.

Whenever I have started a serious side project it changed my life in 18 months or so. It goes from "not getting called back" to recruiters (not from Amazon) contacting me.

Usually my side projects involve finding some use of a new technology that other people aren't doing that doesn't seem that hard. Some examples are

* In the late 1990s I made a Java applet that knocked off Apple's Quicktime VR

* I built a web site that had an XML-based back end the week XML 1.0 was finalized and got a deal to write a chapter in a book

* I made a web site of animal pictures, went on to make sites about cars and New York City, then made a list of topics from DBpedia and attached over a million images with near perfect accuracy

* I made a workflow system for handling job applications and classifying job listings with machine learning that got me the first job I applied for

Right now I have three side projects that form a series

* a system for making "three-sided cards" that have a photo or art reproduction on the front, a description and QR code on the back, an associated web site as well as installations of the cards that have "digital twins" like

https://gen5.info/$/XQ*42RXF-TLY:$B.8/

that one is nearly wrapped up.

* a persistence-of-vision display that mounts on the passenger side of my car (I need to have it perfectly debugged before I drive with it so I invented an error-correcting communication protocol to send graphical data back to my computer)

* I want to do a sketch comedy act with a video game character projected like

https://en.wikipedia.org/wiki/Pepper%27s_ghost

which is a "moon shot" for me because it involves software, hardware, being funny, finding a venue, etc.

If I were looking for a new web-based project I'd use WebGL to give people a videogame-like experience. You can't make an AAA game but maybe you can make something like the trailer for an AAA game. In general I am seeing videogame interfaces (say the Pokédex or other "guides" you find in a game) as an inspiration for mobile interfaces.

I think that addresses my opinion to build passion projects.

I sometimes ask in interviews if they've checked out my repositories. I have a bunch, some skeletons, most unfinished, some doing an interesting thing whether large or small.

The answer is usually "no." This is fellow devs, not HR. Which is why I think one should create projects for fun, and learning.

As a person that sometimes does interviews, I make it a point to look at other's repositories, and I'm sure we'd have a great conversation about yours :)

Given that in my experience projects aren't looked at I think your post describes a really good _projects_ section on a resume.

I'm curious, what exactly do you mean by "persistence-of-vision"?

See

https://www.youtube.com/watch?v=2hASOre63Nk

That device has a single line of LEDs but they cover the space by spinning to make a 2-d image.

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

In addition to "curiosity" or "initiative", I want to see how you measurably saved money/time with something you did - like "implemented and maintained Ansible environment to cut system build times from 4 days to 10 minutes" or "implemented and maintained XYZ product, cutting intrusion response time from 'never' to under 1 hour"

Honestly, if there aren't at least 5-6 (non-leading) zeros after your "saved the company $" bullet point, I stop looking at your resume. Always be able to quantify exactly how much value you and your code is bringing to your employers!

I'm good with any measurable indicator of "savings" or "productivity improvement"

Whether in time or money

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.

Also:

* Doesn't have any obvious gaps in education

... which will be the concern with someone self-taught.

We hired a very bright and enthusiastic guy who dropped out of college after a year to work on his own sales/marketing funnel tool. It all was going well until out of the blue he pointed at a screen and asked what "a |= b" did. Pulled on the thread and not only he had no idea what bitwise ops were, he also didn't know quite a few of other basics. That's the kind of uncertainty that formal education usually removes and the reason why self-taught people having much harder time getting to the interviews.

I imagine it was important for the specific job you're referring to, but there are plenty of dev jobs that don't require an understanding of bitwise ops.

What it was exactly is secondary. The trouble was that there were gaping holes where it should've been solid and this complicated things in more ways than one.

> but there are plenty of dev jobs that don't require an understanding of bitwise ops.

I mean, any CS101 class, at least at good schools, will have bitwise ops.

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

I agree that would be very impressive. I think it’s important to also acknowledge that to be a fantastic junior engineer, you don’t have to be an entrepreneur. A lot of the factors you’re bringing up touch on (tremendously valuable) ancillary skills.

My advice: don’t boil the ocean, show you can have really high quality craft. Be playful and engaging. Show the meta work. Have good git hygiene. Write a blog post about why you refactored something and ask for public code review. Show from afar that you’d be great to work with.

I guess my intention is to recommend building something that people would actually use, rather than a toy project or a hello world (e.g., React tic-tac-toe). To actually deploy something to production shows you have "real-world" experience.

One example is a Chrome extension I made when I was in college that enhanced my alma mater's course registration page. I didn't have any entrepreneurial skills at all, but quite a few people were disappointed when it was later shut down.

Totally. Build something real, for sure!

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.

This is probably the only thing a young, self-taught dev could do to impress me.

If you put some projects on your Github profile, I am going to assume that they are either crap or copy-pasted from somewhere else.

If you are self-taught and have no experience, I am going to assume you will struggle with even the most basic things.

But if you write on your resume "I've had two pull requests accepted to Syncthing" I'm definitely going to have a look!

Of course, making a contribution that is meaningful and will be accepted in an open source project is pretty difficult, but at least you'll learn a lot in the process.

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

If I meet a candidate and they haven't used back channels to find out what challenges my team is facing, it's an auto-reject for me. You should at least care enough to do some sleuthing behind the scenes.

I'm interested why you expect that. I suppose you expect that of anyone and not just juniors? I suspect that you don't work at $BIG_CO and rather something more startup-y?

If a company expects me to spend my free time doing investigative social engineering work to cut through layers of indirection from a job advert to the interviewer, it's an auto-reject for me. The company should at least care enough about hiring someone to understand that they're selling their team and company "culture" (for lack of a better word) to me as much as I am selling my labour to them.

I guess I would totally not have been hired by you :)

So a candidate has to know someone who's already in the company? Which means they probably went to the same school/uni. Rough for anyone outside your bubble.

Or they cold-call people at the company, hoping to get the goss. Staff knowing about the candidacy should not respond. Others would hopefully be suspicious - how can you trust staff who tell company problems to any old "candidate"?

And for folks who don't have the connections to "back channel" the issues you have?

Guess you just outright reject 98% of all possible applicants?

how many people have you interviewed that met this requirement?

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.

A lot of junior job candidates are too afraid of rejection coming out of school these days. I guess it's the culture of helicopter parenting making them believe that they must succeed at everything they try. They walk into my office believing that they "deserve" the job! I will often reject a candidate just because I believe that resilience is a very important skill for a young person to learn. They are obviously welcome to apply again!

There are lots of places where the no asshole rule is absent from workplace culture.

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?

This is spot-on! We love candidates who make usable contributions! Even when we don't end up hiring someone, it's great to be able to use something they built for us as part of the interview!

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.