How to get into a junior position and keep it

You are fresh out of school looking for your first job, maybe you have done an internship or have some other first experience. The most impressive thing on your resume is still sitting in the Education section. You might be asking yourself: “How do I stand out?”

Be familiar with what you are selling

One thing people often do, is to pad their resume with every school project and tech they had a course on. This is understandable: what else should they be talking about, right? Not everybody has side projects that are in line with their career choices.

Although I disrelish sifting through pages of resumes, I don’t get too worked up about it. Unless the position you are applying to is massively coveted and the company will receive hundreds or applications, people responsible for picking candidates will sit through it. I know I did.

Now here is the principal thing:

Only mention projects and tech that you are confortable discussing at length, and in detail.

Reading a three page resume is a chore but can be done in a couple of minutes. A candidate in the room, however, deserves attention for at least half an hour. The job of the interviewer is to learn about the candidate and find out if they will fit the company and be productive. With nothing but the resume to grasp on, the conversation naturally gravitates towards the mentioned projects. So if I ask you what was your role during a particular project, what were the challenges, or what did you like or dislike when using a particular tech, you’d better have an answer ready.

Understand things before tearing them apart

There is a large chance you will be recruited as a part of a team. You may have read a lot about 10x developers but don’t pay too much attention to that. Most software is not written by superstars¹.

Personality is something that will be evaluated during the probation period. A good personality indicator for coders is the manner how they approach an existing code base. Usually the first (and second… probably the third too) impression is that the code sucks. This is for two reasons: First is because it was written by people. Second is for you to discover. And I mean this quite literally.

Before spewing expletives ask your colleagues to explain why the code works the way it does, why is it structured as it is and so on. Chances are there are reasons that may not make sense now but may have when the code was written.

Some examples:

• The code was written before a feature X in language even existed. Rewriting it is not a priority.
• The code originally depended on library X but it was refactored out.
• Implementing feature X was required to secure funding 10 years ago, it was never used since and there was no time to remove it.²

The first reflex is the urge to rewrite everything. I invite you to read this article by Joel Spolsky to find out why this is a really bad idea.

Only once you have understood the reasons, you can start fuming and lamenting what a pile of garbage you have inherited. But this will keep you from making mistakes that could lead to disaster and lost time down the road. Example: Refactoring a library that ends up breaking some client’s plugin they depend on. It will also avoid being the obnoxious winger during lunch.

A homework assignment

I challenge you to go through your resume and write notes about every project you chose to mention. Think about your role and contribution. Recall how you solved a particular problem, or at least how the final presentation went. I am sure you were not one of the freeloaders, so prove it.