Ask HN: What kind of projects make a junior candidate stand out from the rest?
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.
So, what kind of projects are they worth building? I'm not talking about "just follow your heart and build something you would want to use" because I'm sure no one would care if I made yet another Genshin Impact wishes simulator, or a character planner for an RPG/MMORPG, or even a chess game.
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. My goal is to start with frontend and pivot to backend after a few years (or sooner, depending on the company). I only do that because I read pretty much everywhere that the frontend world is more open to self-taughts than the backend world, so I'd hate climbing the metaphorical wrong wall.
69 comments
[ 4.0 ms ] story [ 146 ms ] threadIf 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.
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.
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.
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 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.
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.
Put another way, build something targeting the skills you want/need.
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
Whether in time or money
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 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.
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.
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.
Now if I hired a firmware engineer, sure they might not know about GET vs POST.
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.
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.
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 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 :)
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"?
Guess you just outright reject 98% of all possible applicants?
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.
You can build homebrew but still be rejected at Google.
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.
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).
* 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.
* 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 mean, any CS101 class, at least at good schools, will have bitwise ops.
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'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.
* 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
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.
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.
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.
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!
Lower value projects are the inverse - group, generic, templated, uses outdated technologies, rehash of common examples, academic, and research-oriented.
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