I've been a JavaScript developer for a while now and in the last few years I had the opportunity to interview a lot of candidates of all levels, from students aspiring to an internship position to Senior Developers. Today I'll focus on the first category, the students and junior developers who wish to join the software developers world.
First Contact
For me, a well-made GitHub repository says a lot about a candidate, and when I say well-made I'm not talking about all those fancy graphs you add in the readme, or all the emoticons showing you :heart: programming. I consider that if you make a nice profile you make it for you, what interests me is your repository list.
When getting into your repositories, I'm looking through all projects and the first thing I am checking for is similarities. You don't know how many times I've seen the same project in different repositories with minor things changed between them like colors, hero images or some text. The best one I remember was a student mailing me their GitHub account with a message saying I should look over their biggest project, the one with 62 pages. I stopped working the second I read the email and went on GitHub just to realize that those 62 pages were the same HTML page copied and pasted 62 times with some text changed in each of them. You see, quantity doesn't matter, better have only one or two projects but make something special, something that will make the people looking over your projects remember you.
Tutorial Hell
If you don't already know why it's called tutorial hell, you finish one tutorial, think you learned something new, you forget parts of it a few days later so you think the tutorial sucked so you find a new one with a different instructor, follow it then repeat the process over and over and in the end, you are getting nowhere. How is the tutorial hell affecting your chance of getting an interview without even getting face-to-face with a technical interviewer? What I see a lot in students and junior developers is the list of tutorial projects they have. Don't get me wrong, having them is not a problem, not working on top of them is a problem. If I see a project called "React ToDo App" with just the basic functionality comprised in the App file and the code is neat and most of the times pushed all at once on GitHub, it's easy to see that's a tutorial so the question is, why do you think you're worth interviewing, just for following along some guy on YouTube? I recommend that every time you are doing a tutorial that has a project that you need to create, develop on top of it, add your own code, make it better. For example, if you have a to-do app, don't stop at the basics, add some animations to the tasks when they are marked as done, add a new input with autocomplete capabilities, add a due date field and move the tasks that pass that date to an "Overdue" list, show the recruiter you can do much more than following along a video.
Development Academies will take over the world
Right? But no, seriously, have you noticed how many software development academies were created in the last 2-3 years and how all promise really big salaries and tell you that you too can become a developer in as little as 3-4 months? Although some of their students will end up getting a dev job, the reality is that most students fail, and why is that? Unrealistic expectations set by these academies. How do these academies work? They sign you up, give you documentation to learn, help you develop some basic projects for your portfolio and give you a diploma. What is my issue with these projects? they are well groomed so in the end the academy looks good. I've met with students from a few different academies and upon looking over their projects I noticed how everything was perfect down to the last detail and it's easy to realize that this is not the code of a student or junior developer, heck..I've seen mid and senior developers that were writing code worse than that, so I started questioning them how come everything was so good-looking and the answer was almost the same every time: if I didn't make it right after 1-2 rounds of code review I would either get a snippet with the right way of doing it to add it to my code or get someone to do some pair-programming and get to the right way. This is one of those unrealistic expectations, most developers can relate to the fact that no one on your first job will have the code ready but still make you do it first before showing you the actual way to do it, you have to develop a new way of thinking, trying to solve the problem before pressing your first key, use pen and paper, make online diagrams, whatever helps you figure things out. Real-life programming is more than having someone constantly looking over you and showing you the right way after you fail, you can't rely in someone else always coming to help you out. In some companies, you'll get a manager who will constantly look over you and ask you about your task status every 15 minutes but that's called micro-managing and we'll probably talk about this some other time.
To all students of these academies, don't be discouraged if you don't pass a few interviews or if the offers you receive are under what the ads were saying you will be able to get after you finish a course, just like I was saying before, don't be happy with the few things you learn during a course, learn things on your own, allow yourself to make mistakes, comment code out saying "Hey, I've tried to add this new feature but it keeps crashing, I'll try again after I figure out how to better handle the data", make the code your own.
After all being said, the thing that you need to keep in mind is that you have to better yourself every day, learn something new, code something interesting and don't get let down by rejection. The software development market for junior devs got really big in the last few years thanks to the possibility of working remotely so to succeed you have to stand out of the crowd.
What was your journey into development? What stops you from getting a software development job? Let's meet up in the comments and talk about it.