How to Stand Out with Your Job Application as a Junior Software Developer
akoskm.com
akoskm.com
There are many popular developers whose libraries get used by large organizations, yet cannot get hired by them due to the brainteasers.
All you need is the callback so forget the reindeer games described in this article.
i have been offered tech interviews after showcasing my extensive portfolio and mentioning i have contributed 6+ years to open-source
wanna make me jump through hoops? f*ck you!
There are better and worse technical interviews, but a lot of orgs would consider them due diligence, if nothing else. I wouldn't want to be the hiring manager who skipped the technical interview for a candidate who seemed special, if that hire didn't work out.
but i have a visible track record of doing the job you're hiring for and on top of that, open-source contributions which you're happy to use to assess my skill
i'd rather lose a position than participate in cargocult
Its not about employee vs contractor, but the target can be looking for either or
The other thing that really makes you stand out is relevant experience. To get that you either need skill or luck, both of which are not simple to get.
So yeah, it's hard to get a first job, it really is. Young people legitimately complain about that prereq effect, that you need have experience to get experience.
That's the point!
If it was cheap, it isn't high value.
If it isn't high value, it isn't going to distinguish you.
In my opinion, as someone who has talked and interviewed new devs, it is better for the average junior dev to focus on 10 companies, learn about their business, research their team and tech, and apply, than to send 1000 resumes to companies at random.
> That's the point!
Neither of these is correct. High-value signaling is difficult to fake. If what you want to signal is wealth, then signaling is expensive. But if you're looking for a job, you probably aren't trying to signal wealth. Signaling competence doesn't have to be expensive.
For example, it takes more work to research a company, find the hiring manager, see what meetups the team members might attend, determine part of their tech stack, build an app in that tech stack using their product, volunteer to give a talk on that app, let the manager and team know about your talk and then ask about open positions, than it does to shoot a resume off.
But if I was at a company where a candidate did the former set of activities, it would knock my socks off and they'd definitely move to the front of the interview line.
Note, not everyone has time for this particular way to stand out (we all have different obligations), but in my opinion, every new developer should find some way to stand out.
This doesn't really accomplish anything worthwhile. Now you're hiring and you receive 50 applications each with their own unique way of standing out, so you're supposedly considering which of 50 points in a 50-dimensional space you like the best.
Obviously the only thing you can do is map each point onto a one-dimensional space and choose the highest value. To do this you need to know exactly how much you care about any given resume item.
It's more effective for you, and easier for everyone involved, if you just decide what you want and do an assessment based on that.
> Now you're hiring and you receive 50 applications each with their own unique way of standing out, so you're supposedly considering which of 50 points in a 50-dimensional space you like the best.
Just because people should do something doesn't mean they will.
> It's more effective for you, and easier for everyone involved, if you just decide what you want and do an assessment based on that.
This is a great approach and can pair nicely with the effort based filter I outline.
I don't know about you, but when I hired a new developer a few years ago for a remote position, no experience required, for a company that isn't nationally known, I got ~100 resumes in not very long. I also wanted to pay people for their time (at least a nominal sum!) if they did an assessment for us. That meant I had to have some way to distinguish folks. Of course, I did the quick 'nope' pass, but still had a lot of folks to weed through.
All I'm saying is that as a candidate, putting in effort will help you land a job, precisely because effort is expensive and most folks won't do it.
This can be true, but it doesn't support the idea that high-value signaling is expensive. Putting in effort is expensive. But putting in effort is not necessarily a high-value signal.
Filtering your job applications based on effort put into the application can easily lower the quality of the candidate you select, because the metric you're focusing has so little to do with performance.
What were you trying to say?
people who have a real passion have likely already committed to some project, either their own or open-source
as opposed to the ones who are only in for the money
Maybe they're passionate about the money!
I know some people on HN love to rag on those who go to university to become a dev, but I still think it is the most straightforward way to start your career. I also come from a country where university doesn’t cost a kidney so maybe my US peers would think going to university is too expensive for the benefits.
To have a better chance of getting a job, I guess. No everyone has the clout to be firm on work-life balance and everyone needs to eat. People do what they can.
because it's expected from a government contractor to blow budgets and extend deadlines
My rules for a portfolio project:
1. Solve a problem which can be explained in 15 seconds or so. For example, "This does 3d rotations"
2. Be difficult enough that the person you're talking to wouldn't be able to figure out all the tricks within a minute of thinking about it. In the above example, this means that while the interviewer may think "implement a bunch of math", they don't know that math and know you must have gone off and put some time in to accomplish it.
3. Be complete - for a programmer that means it runs, takes input, and provides output. In the above example, this means you have a function which takes a current orientation and rotates it. Probably also a main to that actually runs to demo this.
Bonus points for something which solves a developer's problem, even if it's not formalized to the point where it would be worth sharing. If it solves your problem, that's respectable already. A current example of this that I've wanted to write (or perhaps it exists already and I don't know about it), would be a logging system separate from the system logger, which will intentionally trip up some git hooks so that it can't be checked in. Maybe a script to purge those log lines and the package that includes it prior to check-ins.
I recently got rejected for a job because my API endpoint design wasn’t up to requirements. Mind you this was a fully frontend react position, I was told I would never need to touch the backend.
I lost out on some good money and they lost out on a solid frontend dev. Also, I have a feeling I could have been up to speed on whatever API design they wanted me to learn in a matter of a couple weeks..
they are probably not a good place to work at anyways, given you're given tasks beyond the scope they were hiring for
this is a total waste of time
search for real experience, freelance, do open-source, read books
you won't be more happy because you finally cracked FizzBuzz in brainfuck
> My rules for a portfolio project
why should my own personal project follow someone else's rules?
Here's my take:
1) Polish your resume. Get a friend who is good at editing to take a look at it. Better yet, pay someone to help you polish your resume. Once you have a good template, updating it is easier, so the few hundred dollars you spend on this will likely be a great investment. Even if you are a great writer, it's good to get another person's perspective. It's a one page document (at least at this stage in your career) and it's the single most important document you have, so make it good.
2) Keep your resume simple. One page, no graphics, or at least simple graphics. No typos. If you are careless about typos on a one page document, then what does that say about your ability to write bug free code? Maybe there's no connection between the two, but that doesn't mean a hiring manager will see it that way. You'd be surprised how few junior candidates have clean, simple and readable resumes, and having one sets you apart.
3) Interview a lot. It's a numbers game so just send out a lot of resumes. Try to send out resumes to places you don't care as much about first and then use those interviews as practice. The best way to practice for interviews is not to do online coding tests or read books. It is to actually interview.
4) Be persistent. You might go through periods with no responses from anyone followed by periods with lots of responses in a row. Don't get discouraged.
The thing that people don't mention that is really important is researching companies. By that I don't mean be prepared to praise a company. I mean it in the sense that you shouldn't just spam indeed/monster/etc and hope someone will call you with a job on a golden plate. Find local companies via unconventional channels. For example, one way to go about it is to google for local agencies and apply directly to them, even if they don't advertise positions. Another is to talk to friends' mom-and-pop businesses and try to convince them to let you make a website for them. Network w/ physical recruiting agencies, they sometimes have short term contracts that might pan out as a full time gig later. Look in non-tech industries. Do what other juniors aren't doing.
Resume 101 for new people: if you don't have work experience, don't fluff that section, we on the interviewer side can smell BS from a mile away. Highlight skills instead. And do extra work: study languages, do side projects, etc. You don't need to list cheesy projects in your resume, but anything that can up-level your skills (which you were highlighting, remember) will help you get through technical interviews.
That said I don't think I ever mentioned that to the candidates or to the team members that ended up joining. Nor did they ever get to skip the rest of the interview process.
- Does it have a README that explains the project?
- Does the code seem generally well-organized (not talking about linting)
- Is it just copied from somewhere else?
- Is it a cookie-cutter style project from one of your classes?
I don't expect a commit in the Linux kernel or TensorFlow, just a small project that confirms that the candidate is not just listing all the technologies he heard of on his resume with no actual exposure. I know it's hard to get good projects, but that's exactly the point, I want to see some code because I know what you'll be doing at work is write code.
Before I get pitchforked to death: this is not a make or break kind of signal, but if I have 20 new grads resume to pick from that's usually my approach.
Did you hack savefiles for a game? Did you write your own game? Did you write something to simulate statistics for a game or something? What are your major projects in your schooling? Did you automate something on your computer with scripting?
For a junior dev, these can show initiative, a willingness to learn, to experiment, and to produce something.
A JavaScript course with 2000+ students all "coding" the same portfolio app, to me, is a pretty big red flag.
You _could_ take electives with complicated freeform projects, or that mimicked actual software engineering, or that focused on the state of the art in various CS specializations, but you didn't need to.
On top of a full course load, of course, so they have a few like these in parallels. I don't think there's any bootcamp out there that has that.
[0] https://www.cs.cmu.edu/afs/cs/academic/class/15213-f10/www/l...
No signal is foolproof.
it does not guarantee you a job either
most people i work with today have either no degree or degree in some other unrelevant field
they're brilliant engineers, they bring lots of value to the table and i enjoy working with them
You are right, but it does show that you can stick to something and finish it, that you most likely have at least a baseline knowledge of the subject, and that you are committed to the field.
I'm not even saying that it has to be a CS degree, but having a CS degree is definitely bonus for an applicant.
IMO, CS degrees don't prove anything other than a) you had the means to attend a university, b) you learn best by having somebody else guide your learning, and c) you can survive the classes designed to "weed people out". Personally, I'm a lot more interested in interviewing people who may have come from more humble backgrounds, who learn really well on their own, and who don't entertain artificial barriers to entry.
Sure there are exceptions, but what about looking at the signal to noise ratio?
Having one candidate clearly not employable out of 20 from an engineering school/CS program is much better than interviewing 19 unemployable people from a bootcamp to finally get to the one that's actually a good hire.
I just need somebody who can do the job. New CS grads usually can’t - not without a ton of handholding. If I’m going to hire somebody and I’m going to have to provide a ton of guidance and mentoring up front, what difference does it make if I’m mentoring a CS grad or a self taught programmer?
A caveat: CS theory is useful. Given a choice between two otherwise equal bootcamp grads, I’m probably going to pick the one that has some deeper understanding of CS foundations (or potentially even better, an enthusiastic interest in learning that material). I truly do not care about the credential though.
That goes against my observations, but perhaps we're not hiring from the same bracket.
Idk. My conclusion is that hiring a software engineer is like hiring an artist: without a portfolio, the requisite skills are barely quantifiable and rely mostly on the word of the applicant. There’s really no way to determine the quality of an engineers work without actually seeing that work. Therefore, the most useful interview is to actually pay them to do something. I’ve had a lot of success with this approach and it eliminates the need to consider credentials at all.
Different hiring pipelines. I suppose the pool of CS grads has already been thinned.
Why? Are you exclusively looking for 10x developers or something?
One 10x engineer is what, 300K total comp?
I don't think I can get the equivalent of a 10x by splitting that 300K and hiring more coders at a lower price. That also means more employees to manage, more communication channels and more 1:1 time because they are less autonomous. Doesn't scale as well.
If you can find them, 10x are an incredible value.
>If you can find them, 10x are an incredible value.
Efficient market hypothesis implies that this arbitrage shouldn't exist, either because the 10x 300k total comp developers you found aren't actually 10x, or 10x developers cost much more than 300k (either because employers are clamoring for 10x developers and bid up their salary to 10x regular salary, or that they're so in demand that finding/recruiting them is expensive enough that it massively increases the cost).
> either because the 10x 300k total comp developers you found aren't actually 10x
That's a possibility. Honestly I've seen both approaches (going with prevailing wages, CoL or whatever metric) vs just matching what's happening in the Valley no matter where and the caliber of resumes you get with the second option is simply on an other level.
> or that they're so in demand that finding/recruiting them is expensive enough that it massively increases the cost
The trick is to adopt a different mindset.
You have to understand that these guys are never on the market. They'll get offers and interviews long before they publicly announce they are looking for a new job. Google has second year interns coming-in that won't work anywhere else but Mountain View for the next 7 years because they'll get an offer long before graduation.
It's all about finding a pipeline with a high signal to noise ratio and investing in it.