Joe Letizia

For close to a year, I had been working to find, and being employed in, my first true '9-5' software development job. It was an incredible experience and one that I'll never forget. The process of landing my first job was one of the hardest things I've had to do. Actually working at the job has been even harder, but so incredibly rewarding that I wanted to share my experiences in order to help more people gain employment in software development.

It's not Personal : It's Business

Being a junior developer is hard. The profession is difficult on its own, but if you also consider that many software development shops have brutally honest performance feedback schemes, it can seem that no one is truly cut out to be a software developer. This is obviously not the case. Hearing where you need work and what you're lacking is tough on anybody. Learning how to embrace the feedback and not looking at it as a personal attack is essential, and a key sign that you are willing and able to grow personaly and professionaly.

You will receive tons of feeback as you begin to interview for your first position. Every offer and rejection you receive will help mold you into a better developer. Any and all feeback is important; remember it. A good tactic is to keep a record of all of your interviews. Use a google docs spreadsheet to record things like:

• Date
• Company name
• Interviewer names
• Interview format (white board, pairing, puzzles)
• Impressions on the company process both positive and negative
• Culture
• Offer details should it go well
• Feedback received from interviewers

Embrace your CS Fundamentals

The first key to becoming a developer is landing a job. For most, the route generally begins with your first job out of college. Thus begins the discussion on the dreaded programming interview. Some companies have ridiculous puzzles about finding a close approximation of how many grains of sand are on the Earth (you probably don't want to work here), other companies will ask you questions about data-structures and algorithms and have you sketch out solutions on a whiteboard, while others will sit you down next to a team member and work on a project out of their backlog. Regardless of how the interview is done, the one constant through all of them is that they will require fundamental Computer Scienece knowledge. Things like basic data structures and algorithms and object oriented design are essential in most interviews.

For a junior position, places outside of Google and Facebook aren't going to probe you for concepts that you didn't learn in school. However, you'll certainly want to be able to explain in what situations a certain data structure is more advantageous over another.

I've been shopping around for data structures books for a few months. It seems that there is almost a unanimous consensus for Introduction to Algorithms(also known as the CLRS after the authors) to be the de facto standard. To this point, I find myself to be in agreement with those that gave it such high praise. A general understanding of all the points in the text should be a great stepping stone for even seasoned developers.

Attitude is Everything

The attitude with which you approach your position is (at some companies) more important than the state of your current skill set. If you are difficult to work with, have an abrasive personality, or are in some other way incapable of being a part of a team, your skill set can be inconsequential. There are many well regarded engineers out there that are known as "The Brilliant Jerk." These engineers are obviously very highly touted for their ability. But working with them can be insufferable. Don't be a brilliant jerk.

Don't be affraid of not being the best developer on your team. The people I work with code circles around me on a daily basis. However, you can still be a contributing member of a team as long as you have a good attitude and are continually progressing.

Interviewing

On my current team, we use a somewhat unique approach to interviewing. It's strikingly simple… but the fact remains that it is unique none-the-less. We simply invite candidates that pass a phone screen to complete a simple pair programming exercise with one of our developers using test-driven-development. There are no tricks, no riddles, and no counting grains of sand. This gives us a few key points:

1. Whether or not they have enough of a background in data structures and algorithms.
2. Whether or not they personable enough to work in a team to accomplish a common task.
3. A small look into their thought process and how they vocalize their thoughts.

We tend to keep it to an hour in order to save the candidate time because the next round is a full day of pairing with 2-3 of our developers. The interview is tagging along with your partner and tackling real features out of our backlog. This process is as much a technical assessment as it is a deep dive into the candidates attitude. Having an inquisitive personality, a calm yet up beat demeanor, and even a sense of humor are all things that employers are looking for in their junior hires. If this sounds a bit like blind dating, you're not too far off. This doesn't mean that you shouldn't be assertive, however. One thing that may help people stand out is having a set of opinions on best practices that you've developed over the course of your experience. Being able to express these opinions in a way that is both assertive and well mannered is a great combination. By doing that, you've shown that you not only have good skills, but can be a great teammate.

Write Some Code

Most universities do a fine job teaching theoretical Computer Science. A good base in Computer Science is essential in your professional career. However, being introduced to the more practical problems you will see in your day-to-day professional career is also essential. A great way to do that is to have a side project. Apply what you are learning in your classes to something that you can get behind. If you are into finance, write a small application that does some analysis on several securities to find correlations. If you find you have an interest in gaming, create a few graphics programs in OpenGL. If you are passionate about web development, create a web application to handle your personal blog. There are many things that you can apply your course work to while at the same time learning the necessary tools that make up our trade as software developers.

In any non-trivial project you will want to set up a version control system which will allow you to track the changes you make to your code as you add more and more features to your project. Git + GitHub is a pefect choice for this. GitHub allows you to share your code with others if you desire, access your repository from many machines, and uses git under the hood which has become quite prevalent in the version control systems market.

Learn to Interview

Interviewing is like writing code, playing soccer, or riding a bicycle; they all take practice to become proficient. Once you have some experience under your belt, take a stab at applying to a few companies. Make sure to have your resume or other application material looked over by a friend. Remember that side project you did? List it! Put a link to your github on your resume! If you spent a significant amount of time on it and you can explain the strengths and weaknesses of the code you wrote eloquently, you are way ahead of the game.

Your first few interviews will most likely not go well. You will probably get flustered when asked to whiteboard code or pair program. This is fine, it takes some getting used to. After a while, you'll learn how to use the appropriate amount of space on the white board, how to elegantly state why you are using one algorithm or data structure over another, and how to present yourself as a overall well adjusted human being.

At many companies, writing some code on a white board is still the go to medium for interviews. I would definitely encourage an interviewee to practice before going into an interview that was certainly going to be on a white board. It is so different than being behind a keyboard.

• Make sure your writing is well spaced.
• Keep your handwriting size in check if it is too big.
• Don't drift up or down when writing long lines.
• Use a fine tip marker (bring your own).
• Rehearse.

Post-interview: Success!

Congratulations! You made it! It only gets harder, but much more rewarding from here. There are several key points to succeeding as a developer that you should pay extra attention to.

You Will Fail Often

For many, this is the first time others will see the code you write on a frequent basis. It is undoubtedly not going to be up to the standard of a professional software engineer. It's very rare to see someone straight out of college or in the their first job writing elegant code. However, do not let that break your will. If you are on a good team that knows how to mold someone they've seen potential in, you should break those bad habits quite quickly. Keep your mind open to the opinions of your more senior peers. They are bound to have been through the problems you've been through. Your senior peers will most likely have great feedback on how to structure your code and how to be more succinct and elegant in the particular languages and frameworks your project employs.

Process Before Domain

Software Engineering isn't much different from other disciplines of engineering in the fact that they all employ a standard operating procedure that is crafted over a long period of time, and generally not deviated from. Creating and iterating on that process is as important as the code you're writing. Therefore, I advise junior people to focus on learning your team's process before trying to become versed in a particular section of the code base or the business domain at large. It may seem tempting to be able to answer questions about a particular bug that your teammate is investigating, or know some obscure detail of the business domaain, but a deep rooted knowledge of the engineering process is much more valuable at this stage in your development. Know your process, and the rest will fall into place.

A team's process might include some of the things below.

• Version control
  • What VCS does your team use?
  • How does your team handle feature branching?
  • How do you integrate changes into the main line?
• Deployment
  • Is deployment automated?
  • What scripts need to be run to push a build to an external environment?
  • How do the stakeholders approve a build?
• Code review / pair rotation
  • How do I approach my peers for feedback?
  • How often should I ask for help on an assignment?
  • How can I improve my soft skills for working with teammates?
• Iteration planning with the stakeholders
  • How does the team estimate a body of work?
  • How does that effect the stakeholders' prioritization of certain features?
  • How do I know when to push back on implementing a feature?
  • How do I advise other teams of what is feasible for the engineering team?
• Continuous integration strategy and how it relates to deployment
  • Does a build that passes the test suite automatically get pushed to an environment?
  • How does your CI system work? (Location, typical settings)
• How to test
  • Unit testing
    • Mocking and stubbing.
    • How to notice smelly code via a test.
    • How to write a valuable test.
    • How to isolate your code from external dependencies.
  • Integration testing
    • What framework does the project use?
    • Should I create database records in every test (factories) or do we use fixtures?
    • How do I stub external dependencies and third party services?

All of these facets of your team's process are what make up the majority of what will be your area of expertise. I never really understood that until a few months into my first real engineering job. The best way it was illustrated to me was by one of our senior consultants. He knew I happened to enjoy martial arts. My friend explained to me that this knowledge was the basis of your repetoire, and you should fall back to it when you find yourself struggling; do your katas. In martial arts, katas are forms or drills that exemplify the basic mechanics of your art. It's typical to focus on these katas whenever you find yourself struggling or moving into non-trivial or improvisational aspects of your craft. Software is no different. Relying on your fundamentals is what will allow you to succeed.

Embrace Feedback

In order to succeed in your new team, you have to learn to trust it's members. Try to strike a relationship with one of the more senior people on your team. If you can, grab a coffee with them periodically to see if there's anything you may need to work on. If you have questions about a part of the code, a new pattern, or something else you don't understand, ask! One of the greatest aspects of surrounding yourself with a good team is that you will receive feedback on where you need work. This will increase the rate at which you improve your skills exponentially.

Embracing feedback also includes knowing where you went wrong. If you do find yourself not understanding a concept or if you made a mistake on a project, accept that fact, admit it to yourself and your colleagues, and improve on that weakness. This shows your dedication to the project and team, as well as your ability to improve. If I could sum up what it meant to be a junior developer in one sentence, it would be "A developer who improves everyday." In that respect, all developers could be considered junior in some aspect, but beginners gain distinction via the velocity at which they improve. If you can show an ability to pick concepts up quickly and consistently, you are ahead of the game.