Adventures of a Junior Developer

I had never had any real problems in starting a new summer job regardless of the field. I have been building elements for buildings, assembling phones, guiding kids in sport camps, selling home electronics and video recording sport events to name a few. But when it started to be a time to turn my education into a developer job in a real company, I had these weird feelings of fear and anxiety. It seemed that there were many processes and practices that everybody else just knew about and I had no idea.

So I took a freelancer route and kept hacking things for customers either all by myself or with some friends. And in January I joined Chartio as an engineering intern to start my adventure as a junior dev in a real company.

Getting experience before you get experience

Getting the first job is usually the hardest part. With no experience, it is difficult to even get interviews. The best solution to help out in that is side projects. Develop something that you have always needed but never found or take an existing thing and try to mimic it. Then put your code on Github, add good readme and you have something to show to potential employers.

Often people are quite shy about their own projects but employers are not looking for perfectly written and structured code from someone with no experience so it’s more important to have something to show, even if it is bit fraqile. To make your Github repository useful, use time to make a good readme – just reading code doesn’t really tell what your code is supposed to do.

Interview

The entire job hunt process is an art. You write dozens of cover letters and applications trying to sell yourself to people who have no idea who you are. But once you get an interview, you may be horrified. Tech job interviews often have a part where you are interviewed about your past and your skills and a technical part where you are given some puzzles or mundane tasks to code in an hour or two.

If you have been in that situation and have completely frozen and failed, do not worry. I have failed too, many times and in absolute basic stuff. In one interview, my task was to parse a simple HTML and printing the results in wanted form – something I do all the time in my own hobby projects. It took me over 20 minutes to even get a good start because I was so nervous and I was barely able to finish that in 60 minutes. Or getting easy freshmen class beginner puzzles and forgetting everything I knew about programming that moment.

source: devopsreactions.tumblr.com

But over time, you will get better and you will gain confidence. Just remember to think out loud and don’t be afraid to ask for help if you get really stuck. There are books and websites to help practice for programming interviews, if you feel you need some help in that. Even if you fail to get a correct solution, thinking out loud may help you land your job since the interviewer knows you can think right.

Code Review

For the first few months, code reviews can feel like you are back in school again and performing badly, just waiting for the principal to call you into his office. Because you have probably spent last 15 years or so in school where every review means telling you just how good or bad you were and giving you a grade to remind you of that.

So what are code reviews? Like I said in the beginning, I had no idea about any processes or things to do in a software company so let’s start from the basics. You write code: a bug fix, new feature or some refactoring and you before pushing your code to production, you submit it to code review. We do development in different branches and then use pull requests for review phase but there are also different approaches. Then somebody (usually your fellow developers or a QA team) go through your code and comment on things that need fixing: code style changes, logical mistakes or simple improvements to do the same thing better. Then you fix them, get approved and your code is ready to go into production.

For me, code reviews have been essential in becoming a better developer. After getting over the fear of comments, I have really learned how to take all the improvement suggestions and not only fix that part of the code but to also remember that in the future. And the courage to be able to defend your choices when you know you made a better call than the senior developer commenting. It’s not teacher-student exam-relationship with right and wrong answers, it’s two collegues discussing the best way to code.