Here at Shutterstock, we’ve increased our efforts to reach out to college students and new grads. After participating in outreach throughout my career as a software engineer, I’m amazed at how unprepared most college grads are when entering the software industry. Most companies care less about your degree, major, or GPA and more about your raw talent. The process of obtaining a Bachelor’s Degree exposes you to new ideas and most importantly, you learn how to learn.
To gain real development skills, you must either find time outside of class or take control of your curriculum. Here are some things to take advantage of that you won’t learn in school:
Work on projects outside of class
When interviewing new grads for junior developer roles, we want to know how a potential candidate will function outside of a structured academic environment. While it’s great if you did a bunch of school projects and passed all of your exams, we’re more interested in what you did on your own, from start to finish. We’re less interested in projects that came with the class and more interested in projects where you came up with the idea yourself. If your school offers independent study, there’s a good chance you could wrangle some credit for working on your own project. That’s fine too, the point being that it should be something you owned from beginning to end.
Get real life software development experience
There are so many things you simply are not taught in school. You don’t learn how to package, distribute, and deploy a project. You don’t really learn the best practices for writing unit tests and integration tests or load tests for that matter. You get limited exposure to team work with a source management tool or a continuous deployment environment.
Most internships are either too structured or not structured enough. Meaning, either you get told what to do at a very granular level and don’t really get to think for yourself, or you aren’t given any guidance at all and left completely to your own devices. This also happens in jobs in real life and having sufficient experience to deal with it is very important. Also, most of your work is proprietary so there is no way to show future employers the nature or quality of your experience.
The easiest way to get experience is to get involved with Open Source projects. The advantage is you get experience working with teams, especially remote teams, and all of your work is public, so you can share code samples with future employers. You can even continue working on your open source projects once you’ve found work and it can also help to fill any employment gaps you might experience.
This is a talk I’ve done about getting started with Open Source, and while it’s been more targeted at the Perl community, there are tips there that are universal. In addition, I do a short tutorial on making a pull request in Github.
Here are some great projects to get started on that offer a bit more structure and guidance:
As a woman in this industry, when starting out, I found myself especially isolated and often wishing for more female peers. These groups offer the opportunity to connect with other women engineers and special programs focused on getting more women involved in Open Source.
Use Git and Github for EVERYTHING you do
Whether it’s a coding project for a college class or homework for a free class online, always use source control with your code. Find a place to host your repositories. Github happens to be one of the most popular and it’s pretty easy to use. I have plenty of colleagues that don’t even have a resume, they just send hiring managers a link to their Github profile. In the end, we really don’t care where you’ve worked, we care about what you’ve done and how you did it.
Write tests and understand what coverage means
Some college courses might introduce the notion of testing but it’s up to you to apply it. Get in the habit of writing tests every time you write code. When you have a homework assignment, first write unit tests to run the code you’ll write to prove whether you got the answers correct. Then write the code. Get in the habit of doing this early and your life as an engineer will be much easier. For whatever language you’re using, learn the test framework. Want to impress the interviewer? When they propose a problem for you to whiteboard a solution to, first write out (or at least talk about) how you’d test it. I guarantee it’s one of the few times they’ve seen any candidate do that, and very likely the first time they’ve seen a new college grad do it.
Learn to profile your code
You’ve learned about big O notation in your classes, but in the real world you rarely work on code such that you have full access to evaluate every method being called by all the libraries you’re using. A code profiler is a software tool that runs your application and identifies “hot spots” of areas that took some proportion longer to run than other parts of your program. These are only relative to total running times within the profile results so something highlighted doesn’t necessarily mean it took a long time. Many languages offer tools for code profiling. SQL queries can be analyzed using “explain” or query analyzer tools depending on your database. There are also end-to-end load testing tools. Whatever you are using, learn how to run and evaluate the results of a profiler or some type of analyzer. Start learning how to find the bottlenecks, I guarantee that’s going to be what you spend a good amount of your time as an engineer doing.
Explore engineering flavors
When someone asks you what kind of role you’re looking for when you graduate, just saying “software engineer” or “programmer” isn’t good enough. All that shows is you don’t really know anything about the industry and it doesn’t help the interviewer to get to know you. The field of software engineering is huge and there are a lot of areas you can focus on. My advice is to explore the different roles that are out there so you can see what you like best. For starters, there are Front-End Engineers that work mainly with User Interfaces, there are Back-End Engineers that work with data stores and API’s that the User Interfaces consume, and there are Full Stack Engineers that work with both. In addition, there are Big Data Engineers, Search Engineers, Algorithm Engineers, DevOps Engineers, Release Engineers, and even Software Engineers in Test (QA Engineers).
You don’t have to pick one necessarily, but at least talk about your knowledge of the different types of roles that you think might be interesting to you and explain how they line up with your interests. You’ve spent the past however many years studying the subject of computer science, there’s got to be an area that particularly interests you. Don’t try to tell the interviewer something you think they want to hear. If you’re looking at a backend software engineer role for a financial institution, saying the class you took on Embedded Systems programming was your favorite won’t take you out of the running. It opens up a conversation about “what did you like about that subject” and lets the interviewer get a better idea of what your own professional interests are.
In fact, the fact that you have interests is a good start. Let the interviewer decide if your interests are a good fit for things the company is doing. There might be a team that’s doing work in your area of interest that simply hasn’t considered hiring a junior candidate. It also tells the company up front that if they start you on a certain role, they should also have a growth path for you in the area you’re interested in (and you should look for this as well).
Get comfortable with ambiguity
Answers aren’t always easy or straightforward. Most of the time, you’re faced with a problem and there isn’t a professor sitting at the end of the journey ready to grade you on whether your solution matched theirs. Most of the time, there is no solution except for the ones you can come up with.
One of my favorite categories of questions to ask in interviews is things I call “troubleshooting questions”. These are vague, open-ended questions that are meant to show me how a person really thinks on the spot. When I was in college, I worked for my university’s housing internet department. My job was to hook students’ computers up to the school’s network. This job didn’t have a lot of structure or supervision. We needed resourceful people that could solve problems on their own.
When we interviewed candidates, the question that really told us how the potential candidates would do was this: “You’ve just hooked a computer up to the network. It’s not connecting to the Internet. What do you do?”
There is no right answer but with every answer the candidate gave, we responded with “that didn’t work, the computer isn’t online”. If they asked clarifying questions, we made something up based on the most common case and also to keep the focus on troubleshooting the main issue. Sometimes, you try everything you know and you still can’t get it to work. That’s life. Being able to deal with uncertainty is one of the most important skills you need as an engineer.
Think in terms of the problem, not the answer
A common mistake, even among veteran engineers, is to decide on a solution and make the problem fit into that solution. Never do that. Always start with the problem. Always ask “What is the problem we’re trying to solve?” and then determine how you will consider the problem solved. This is called defining your criteria for success.
Even in class as you’re learning new computer science concepts, always ask yourself, “what problem is this solving?”. Being able to explain your solution in terms of the problem is a skill that will not only earn you the respect of your mentors but also endear you to your non-technical peers (and your professors!).
One way to do this is to start thinking in terms of metrics. I’ve had many an issue come my way that consisted of “The website is slow, we need to make it faster”. First we need details. What specifically is slow? What are the conditions to reproduce the exact scenario being reported? What are our current metrics (ie, how long does it take page x to load)? So our problem actually is, the user’s profile page takes 3 seconds to load on average. Our criteria for success should then be something like, the user profile page should take 1 second to load on average. Now that you are thinking in terms of the problem and in terms of metrics, solving the problem (and preventing it in the future) is much more straightforward.
Click here to find additional tips you may find helpful.
Don’t think you need to learn all of these things in order to be marketable. As I said earlier, just knowing a little bit about one or two of these things (or even knowing that they exist) is a good step in the right direction. A career in software engineering is a life long learning process. Make learning more about these areas in depth a goal for yourself as you progress in your career. Your goal isn’t to have a list of buzzwords on your resume that you can rate yourself a 10 on. Your goal is to have a strong foundation and a broad toolset to help you adapt as technologies, languages, and the industry change.