I spent most of my software engineering internship not programming. Will that hurt me in interviews for full-time roles?
I'm a CS major in college and I am about to finish up an internship in backend software engineering at a division of a very large tech company. Most of my time was spent reading code, reading documentation, learning to use internal tools, writing configs, writing test cases, minor bug fixes, and spending a lot of time communicating or coordinating with coworkers, and there was not an emphasis on just writing code. Most of my tasks were not coding intensive, and looking at the rest of the team it looks like at least half of the team is more involved in testing/analysis than coding. This is very different from what I'm used to in my CS coursework at my University -- where our focus is almost entirely on writing code that solves assigned problems.
My question is, will this hurt me in interviews for full-time roles as a software engineer? If so, then what can I do to address that gap?
There's no reason it has to.
First of all, this is the job. You need to know how to code to do your job and if you are not a good coder it's very hard to do your job well, but most of your day will not be spent coding at most jobs. You have to solve problems and often the new code that is written is a very small part (in terms of total effort) of the solution.
Second, let's talk about interviewing. When interviewing for full time roles you can break these interviews into three types -
Behavioral interviews - these will ask you to talk about things you've done. When done well, it will give you an opportunity to talk about real problems that you had a role in solving. I hope the lack of writing code at your internship did not mean you were unable to contribute in a meaningful way to solving the company's problems. The internship you had sounds like it would give you a good leg up on these kinds of questions.
Technical screening interviews - these will usually focus on basic knowledge, or reading your resume and trying to ask questions to get at what YOU actually did.
- An example of basic knowledge question would be to ask you to explain garbage collection. For this one, your school or self-study is probably as valuable as the small amount of practical experience you got from an internship - including if you spent that time coding.
- An example of the second kind would be, if you said on your resume that you "automated the release process and saved the company x hours per year" you'll have to be able to explain what parts were automated, what technology was used, and most importantly, what was your role in it. For this one, just don't oversell on your resume so that you feel like you're caught in a lie if you get pressed on it. Instead think of your actual contribution - I bet you contributed to real progress on something important while you were there.
Coding interviews - You might feel like you are at a particular disadvantage here, but really, these are often theoretical in scope - things you would never tackle in real life on the job. You should be prepared for these by having a thorough understanding of analysis of algorithms and basic data structures. But I've been at this a long time and I have never been asked to solve a problem in one of these that I have actually had to also solve as part of my job.
So, in short, the kind of more broad experience you got on your internship may give you a leg up in some kinds of interviews and should be no great penalty for other types of interviews.
Jason recommends the following next steps:
There are a lot of things that an employer looks for, but those are typically things that are actually under your control. There are plenty of resources for software engineering interview prep, including the posts above.
Since most software companies require you to code in a highly specific domain, coding experience in previous companies is not of much value to them. Of course, you need to be proficient in programming languages, what they really look for is how well you know the coding best practises, how you devise a solution to a problem statement and your ability to collaborate with others.
It will not hurt you. Like Jason said, engineers don't spend most of their time writing code. A big chunk of their time is spent in breaking problems down, in solution design. and they will spend time writing tests.
Finding out how to solve problems well is actually the most difficult part. It is difficult because you need to understand many constraints (time constraints, resource constraints, performance constraints, maintenance constraints etc).
That said, to pass interviews and to do the job well, you need to brush up your CS knowledge (data structure, algorithms, etc). Leetcode is a good online resource and Elements of Programming Interviews is a very good book to practice.
Don't worry, you can do this!