A Software Engineering survival guide

Resources that will help you at the beginning of your career

The first few years of my career were a time of intense learning.

I encountered the realities of being a software engineer and had to acquire many skills that I didn’t know I needed. Looking back, it would sure have been nice to know the things I know now.

So, I wrote this guide to help others based on the experiences of developers I mentored in their first few years as professionals, and those of myself and some of my colleagues.

I will cover:

• How to make the best out of interviews,
• How to survive (and thrive) in your work as a software engineer,
• And what resources to look into when considering continuous improvement.

Interviews

As you start your career in Software Engineering, you’ll have to face one indisputable fact. Interviews suck.

They can be awful for everybody involved. Having been both an interviewer and an interviewee, I can attest that interviews are a big time sink, extremely stressful and a really bad indicator of future job performance. Nevertheless, they are a necessary evil that you and your résumé better be prepared for.

Preparing for Battle

If you’re considering a career in Software Engineering, make sure to learn some of the most commonly asked programming interview questions, such as ‘FizzBuzz’:

“Write a program that prints the numbers from 1 to 100. But for multiples of three print ‘Fizz’ instead of the number and for the multiples of five print ‘Buzz’. For numbers which are multiples of both three and five print ‘FizzBuzz’.”

(Coding Horror)

Sounds simple enough, right?

Well, the vast majority of interviewees fail this simple test, let alone its more complex variants.

I’ve personally seen many candidates for senior positions fail this test while having full internet access. So make sure that if a programming language is listed on your résumé, you know how to do at least FizzBuzz in it. Otherwise, you’re just wasting everybody’s time, including yours.

Of course, you’ll need to know more than just FizzBuzz to survive your interviews. You also need to make sure that you know:

• Basic data structures and algorithms: such as linked lists, arrays, trees and sorts.
• Common “gotchas” in your language of choice, such as whether strings are immutable, and how memory is managed.
• Object Oriented Programming concepts like class versus object, and inheritance.

At the beginning of your career, you’ll need to shine on these sorts of questions, since you don’t have the experiences to prove that you will be good at the job. There are two resources that I always recommend when preparing for interviews:

• “Cracking the Coding Interview”, a fantastic book that includes a lot of coding problems and their solutions, as well as summaries of what you need to know to solve them
• CodeWars, a website that has a large collection of coding problems that you can solve in the browser using a wide selection of languages. The most useful part is seeing how other users solved the same problem. You’ll get to see different approaches to the same problem and learn new tools in the language of your choice.

Give yourself that extra edge

There are several things you can do that will give you that little something extra.

First, learn to communicate your experiences. You should have an elevator pitch that summarizes your resume into a coherent and engaging narrative.

In addition, know your own résumé! It sounds silly, but I’ve seen a lot of interviewees struggle to explain a particular item on their résumé. You should be able to answer questions about any experience that you list on your résumé and explain how it’s made you a better candidate for the job.

Next, have code samples to show on GitHub (or another public repository).

Seeing is believing, and interviewers being able to see your code will do wonders. Plus, it shows you have an understanding of version control systems.

The code samples don’t have to be anything too complex, but they do need to be clean and show good coding practices. This is your chance to show how you code without the time-pressure of a coding interview.

Once you’ve done all of the above, it’s time to consider participating in an open source project. It will show you can work in an existing code base and collaborate with other programmers.

This will be the closest you can get to programming in an industry environment without actually being in an industry environment. This is by far the hardest and time-consuming item so far, so reserve it until you’ve completed the lower hanging fruit I’ve discussed above.

Interviewing your interviewer

In the rush and stress of the job hunt, many candidates forget that interviewing is a two-way street. As the company is trying to figure out whether you’re the right person for the job, you should be figuring out if the company is the right fit for you.

Make sure that you get to ask some of the questions below, even if it’s in a follow-up email. Be aware that often times, companies might try to spin not following best engineering practices as a perk, so read between the lines.

Here are some example questions you could ask:

“What would a typical workday look like for me?”

It’s important to know what to expect from a particular position because Software Engineering jobs vary quite a bit. You might be expected to upkeep servers or talk to clients directly, for example.

Red flag: “I’m not sure.” → Means that the people interviewing you won’t be on your team, or they don’t have a clear idea why they’re hiring you.

“How do you test your software?”

Ideally, a combination of unit testing, manual testing, and automated testing should be used to verify the quality of the code.

Red flag: “We just don’t write bugs, haha.” → Those people are exactly the ones writing bugs.

“What version control system do you use?”

Version control systems are extremely useful for collaboration and there are zero reasons to not use one in a professional setting.

Red flag #1: “Uh, version control system?” → Run far, far away.

Red flag #2: “<insert obscure or custom VCS>” → Indicates they’re most likely not keeping up with the times and haven’t updated their infrastructure in a long time.

“Do you do peer reviews?”

Peer reviews, or having someone else look at your code before it goes into the code base, is a fantastic way to spot silly mistakes and is a vital training opportunity when starting your career.

Red flag: “We just trust each other!” → Very likely that the senior developers are very protective of their code and not great at receiving feedback.

“What programs do you have for continuous education?”

Being a software engineer means constantly learning as technologies appear, mature and become out-dated at a dizzying rate. As such, many companies have a training budget that they use to pay for university and online classes, conferences, or in-house talks.

Red flag: “You mean reading stuff online in your free time?” → The company is either strapped for cash or sees developers as replaceable and not as long-term investments.

“What’s the software development process that you use?”

Process is vital to software engineering, regardless of the actual details. The particulars of what constitutes optimal process are subject to intense debate, but the mere existence of an agreed upon way of working on a project minimizes chaos and ensures everybody is on the same page.

Red flag: “Our process is inspired by free-form jazz.” → Most likely the entire department is in fire-fighting mode, jumping from emergency to emergency without any clear goal.

“How do you tackle technical debt?”

Technical debt is an accumulation of outdated technologies and quick-but-dirty solutions in the code base. Addressing it is important to the long-term health of the code and should be done on a continuous basis.

Red flag: “We’re exclusively focused on new features.” → Their code base is a mess or it will be soon.

“What’s your company culture like?”

Company culture might be a very vague concept, but even small things like an open office versus cubicles will change your day-to-day interaction with colleagues in significant ways. There are no general red flags, but make sure their answer is something you can live with for 40+ hours a week for years.

Working as a Software Engineer

At this stage, if you performed well in your interviews and liked how the interviewers answered your questions, you’ll likely be hired.

Congrats, You’re Officially an Engineer!

Now what? Well, it’s time to relearn a lot of things about coding and working. And since we’re programmers, let’s start by discussing code.

Good Industry Code

Good industry code has the following properties, in that order:

• Readable, because code is read and maintained more often than it is written. The intent of the code must be clear to other developers years after you’ve written it.
• Defensive, as in following best practices of defensive coding. Defensive coding is a topic all on its own, but the gist of it is: You have to ensure that improper use of classes and methods you’ve written won’t lead to your code crashing the software.
• Optimized, which is last on this list because most of the time, you won’t really need to worry about it. That doesn’t mean you should write bad code that does something in O(n³) when a linear solution exists. But developers are generally eager to try and over-optimize when there’s no need for it, often at the detriment of the readability and defensibility of the code. You should always be able to prove that a certain optimization that sacrifices those properties is actually needed.

Now that you know how to write good industry code:

You Won’t be Doing Much Coding

It may come as a surprise, but most of the time you won’t be writing new code, but instead, you’ll be:

• Debugging
• Reading existing code
• In meetings or writing emails
• Researching what to do so you don’t write code

Therefore skills other than coding will be just as vital for your career.

Debugging and Reading Code

• You’ll need a lot more than debugging using print statements. All widely-used languages and tech stacks have a variety of powerful tools. Learn to use them as they’ll make debugging a breeze and save you countless hours.
• Understand the code base. Most tech stacks have some sort of code graph generation tools that will help you understand the structure of the code base. Enterprise IDEs generally have that functionality built in. You can also explore the code using tools such as ReSharper, grep or Sourcegraph.
• Understand the product. You’ll be surprised how many developers don’t know how the software is supposed to work before they try to “fix” it. Just read the documentation.

Organize Your Thoughts

Since a lot of your time will be spent in communication, research and multi-tasking, you need some tools to help keep everything in order.

• TODO lists / Tasking: Your company should already have tasking software of some kind, but it helps to have a personal system as well. Use post-it notes or software like Trello or Todoist.
• Notes: Always take notes in meetings, work to improve existing documentation and create a personal knowledge base. Use Evernote, OneNote, or a notebook, like in the olden days. It might seem like overkill, but you’ll be thanking yourself a year later when you’re revisiting that obscure build process which took you 3 days to figure out the first time. I’ve never met a good Software Engineer who didn’t take extensive notes.
• Charts/Visualizations: Humans are visual creatures and creating charts of processes and architectures will help you and others understand complex topics. Diagrams are particularly useful when communicating with non-technical colleagues. Use Lucidchart, Visio or a plain whiteboard.

Know When to Use Libraries

Short answer: Almost all the time.

Long answer: 99% of the time, you shouldn’t reinvent the wheel. In most Software Engineering positions, implementing a particular kind of sort is a complete waste of time. That doesn’t mean you shouldn’t know how the algorithms and data structures you use work, since that will help you decide what to use and when.

In order to be an efficient Software Engineer, you need to understand the libraries that you have at your disposal. The standard libraries of most popular languages are extremely useful and are larger than what you’d expect. In addition, the code base might also utilize additional, specialized libraries. Read their documentation and know when to use them.

You should also not be afraid to suggest additional libraries if they will save time. However, you need to ensure that you pick a good library for industry use. A good library is:

• Open source, so you can verify the quality of code yourself and potentially fix bugs that are critical to your application.
• Licensed under a permissive license such as MIT and BSD, so your company doesn’t run into any issues by using it. Be careful with GPL, lest you open source your entire code base by accident.
• Mature, i.e. it has been out for some time and has a rich set of features.
• Maintained, with new releases coming out often.
• Used by other companies or projects, which acts as a stamp of approval and ensures it has industry support for continued maintenance.

Continuous Improvement

In addition to learning the skills that will make you better at your day-to-day job, you’ll also need to continuously improve your skills and learn new ones, in order to create new career opportunities for yourself.

The opportunities to learn are many and a lot of them are quite affordable:

• Online Courses: The opportunity to learn from the best professors in the field in a flexible format shouldn’t be missed. Check out Coursera, Udacity, and edX (among many) for courses that can supplement your existing skills.
• Online Master’s Degrees: A recent trend among top-ranked universities, online Master’s Degrees are a flexible way to continue your formal education. They are also generally less expensive thank on-campus degrees, with most programs costing ~$10,000 for the entire degree. Georgia Tech, UT, and UC San Diego are some of the universities offering such degrees. I personally recommend Georgia Tech’s Online Master’s which I graduated from this year.
• Blogs: Blogs are an important part of the developer community (no surprise here, as you’re reading one right now). Blogs such as Coding Horror, Joel on Software, or even more humorous websites such as The Daily WTF can give you a good idea of what and what not to do as a Software Engineer. Browsing Medium, r/programming, HackerNews or other feeds will also lead you to good articles and blogs.
• Conferences: Last, but not least, conferences are an amazing learning opportunity and you should definitely take advantage of your company’s training budget by going to them. A very incomplete list of good conferences to check out (alongside their topic): GOTO; (General), Strange Loop (General), PyCon (Python), CPPCon (C++), DEF CON(Security), Fluent (Web dev). All of these also have videos of (most) talks on YouTube so you will be able to learn something even if you can’t attend!

Hopefully, this article has armed you with the knowledge of what to expect from the beginning of your career as a Software Engineer and given you the tools to perform well on this exciting journey! Thanks for reading! If you have any questions or suggestions, please leave a comment or tweet @AlexievValeri.

 

Source: https://medium.freecodecamp.org/a-software-engineering-survival-guide-fe3eafb47166

Written by