How to get hired as junior developer
Doing the latest round of recruitments at Aller Media Finland got me thinking that it could be beneficial for the community to write down some of the things I am looking for when hiring for junior developers as I remember back in the day being now too aware when applying for my first developer role and I see similar mistakes repeating in the applications I am combing through.
Note that this article refers specifically to developers in a web environment though similar principles can be applied to any environment you aim to work in.
You are most likely to get hired by having few polished hobby projects using the most established technologies & tools and treating your code as your CV. It all seems obvious but you'd be suprised, I'm quite sure.
Traditionally web development work has been separated into the back- and front-end development, however, as new technologies are unifying the two sides, developers are getting more productive as they can work on the complete features instead of just one aspect of it. This means that full-stack is a growing requirement for web developers, especially looking into the future.
Focus on popular technologies
This will inevitably ruffle some feathers but as a team lead, when I'm looking for a potential junior developer, I am more likely to hire the one who knows most about the tech stack we use instead of someone who knows a little bit of everything. Different roles and companies have different needs and philosophies but as a rule of thumb, you maximize your chances to get hired as a junior developer by focusing on the most established technologies. Not only does this give you the the obvious benefit of math as those technologies also have the most work opportunities but it also ensures that the people on the other side of the table are most likely to be familiar with the tech stack you are using which makes reviewing your code more probable.
Don't give me things like your own scratch-built CMS solution that you have built since as a recruiter I can't spend the time to review how usable, maintainable, etc. the code is in the short timeframe that I have to review it. However, if you give me code that is written for a setup that I know, I can quickly evaluate how it is written, how closely best practices are followed, etc. And clean, reviewed code will land you a job - More of this in the next chapter.
Have development as a hobby
The most important part of getting hired is to have development as a hobby - To have personal development projects to show and to the experience of projects that you have had spend time on completing and polishing as prototyping is easy, products are hard.
The best way to do this is to have your projects running somewhere (For example AWS Lambda/S3) and have the code available to see in your Github account. This way any interested party can easily see what you have been working on, see the code, tools, and development practices behind it. And remember, this should be something you have had spent time and developed yourself as just using a ready-made template/tutorial will be quickly obvious to anyone who knows their stuff.
Having a personal project(s) will also show the recruiter that you are interested in development as a hobby as the fact of web development is that since the whole area moves so fast, to stay relevant, you need to do studying outside the work as well.
Treat the code as a job application
The personal projects you have available for people to see are your job application, thus they should be treated like so - They should be as clean as possible, with no bugs and no commented out code and with README that has screenshots and link to the running project, if possible.
And remember, quality over quantity - Anyone can crank out 10 tutorial repositories per week but one polished project with 100+ commits tells a lot more than all of the tutorials combined.
Screenshot of supermon development tool README
Don't re-invent the wheel with clever file structures and instead use the same structure the main tutorials tell you to do, this way it is again easier for the recruiter to evaluate your code as they will already be familiar with the common ways of working and don't have to hunt down logic - You don't scramble up the parts of your CV either, you present it so that it can be easily evaluated and moved forward, the same applies to your code. Completed code is experience and the easier you make it for the other party to understand your experience on the matter, the more likely you are to get hired.
Extra points: Don't forget the tooling
Some of the most important parts of teamwork are automated toolings that enforce coding styles, highlight/fix errors, and so forth. This unifies the code style, making it faster to read & understand for others in the team, which in turn increases the productivity of the whole team. So, if you can show that you are already familiar and working with the popular teamwork-related tools you make yourself easier to integrate into a new team.
So all in all, I believe that you are most likely to get hired by focusing on technologies, tools, and ways of working that cover the widest amount of companies in the area that you want to work in and polishing your showcase projects around those. Hope this helps some of you on landing your first junior developer job and if so, please, let me know.
Full disclosure: The exact stack mentioned here is the same that we use in Aller Media Finland, however, the same reasoning that is presented in this article was part of the stack selection, to make sure we have the best recruitment opportunities possible. So, if you are looking for a (junior) developer position in a fast-moving team, have full-stack experience with React.js, Node.js, Express (and possibly AWS) and have an appetite for learning & pushing yourself forwards head over to aller.dev to learn more.