CS degrees aren't designed to prepare students for roles as software engineers.
This is not news. And sure, a few skills overlap, but the perspectives are fundamentally different. One is academic in the service of theoretical computer science, the other is the application of code to real world problems in the context of teams — sometimes pretty big ones.
This, of course, is why software engineering internships are a heck of a leg-up for CS students. But what about the students who aren't lucky enough to get an internship? Or what about those who want to get ahead and arrive a bit more job-ready on day one of the internship they were able to snag?
Here are a few things CS students can do while still in school – mostly independently – to better prepare them for their first real-world software engineering gig.
Use git for everything
When you're first learning CS and coding fundamentals, adding another layer of complexity like git version control can seem like a massive pain that can just wait until later. That's how I felt. Nobody else was using it (except my one friend who was TA-ing half the CS intro classes), and it was nowhere to be found in any syllabus.
So I didn't touch it until my first professional role. I just wasn't interested in making my life even the slightest bit more complicated while I was already struggling to wrap my head around things like recursion and Dijkstra's algorithm!
But boy was I wrong.
Turns out learning and using git in school would have made my life orders of magnitude easier, completely aside from preparing me for what's to come after.
Hear me out.
When you're completing an assignment, there's often a lot of experimentation before you arrive at an acceptable solution. Sometimes you'll take the chance and go down a rabbit hole, only to hit a wall and wish you were back where you were three hours ago!
Without git, you're in the worst possible situation. Not only do you still need to solve the problem (and maybe it's 2am by this point given #StudentLife), but now you also need to remember what you changed so you can manually backtrack.
But once you make version control a habit, stuff like this is child's play. With a few quick commands, you're back on your original branch with no consequences of having made a mistake in manually backtracking. In fact, you can simultaneously experiment with multiple branches that have no impact on one another.
And you get all that for what is not really a very steep learning code to begin with at all.
There's a reason the industry uses git. Because life is a nightmare without it. Why not embrace this as soon as you possibly can? There's never an ideal time. Better when your time is flexible as a student than in your first full time gig anyway.
Chunk your logic as much as possible
Another thing academia completely fails to prioritize is clean code, which not only sucks for the teams you'll be joining, but also for your own ability to make sense of your code once you've written it.
Now, there's a million techniques for writing clean code (not to mention a million books explaining them), but if you do nothing else, at least attempt to do this:
Reasonably chunk your logic whenever you can. In other words, break your code down into copious functions/methods that represent sensibly grouped chunks of logic, and name them appropriately.
When you write papers you don't submit one giant paragraph, right? The same goes for your code.
You see, when I was a CS student, I just desperately wanted to get my code to work as soon as possible. I would write functions that spanned the length of the screen, which would allow me to indulge all sorts of other bad habits like nesting loops upon loops which themselves were the size of the whole file.
This basically made my code unreadable, even to me. I'd spend several hours on one part, then dive into another chunk of logic and forget how the whole thing came together. And that would then require me to go back and read through everything multiple times until my brain broke because nobody can hold that much information in their heads at once.
As soon as you can, experiment with taking a piece of independent functionality and putting it into it's own function. Do this for at least two or three items per assignment to begin with and watch how it simplified your entire coding process. Eventually, you will start to develop an intuition for this and you'll arrive at exactly the right number of functions per task, which will both have you completing assignments faster, but also finding bugs easier as well.
Pursue project-based work
Some CS curricula (maybe a lot) allow you to get away with an almost negligible amount of group project work as part of your requirements. And it's easy to shy away from project-based classes, especially when you're type-A and want full control over the grade you ultimately get.
Here's the thing. When you start working at a company, pretty much all projects are group projects in one form or another. And it's a real shock to the system when you go from 95% individual assignments to suddenly being dropped into a sprawling system that you now need to contribute to.
Fortunately, a lot of CS programs offer project-based classes as electives. If I were to do it all over again, I would use these as practice to really get myself acquainted with the asynchronous nature of group work. You'll still need to get up to speed once you join a professional team, but you'll get there at least twice as fast and with a lot less angst with adequate exposure to teamwork in general.
Even better, there's boatloads of open source projects on Github that accept pull requests from anyone so long as they meet their standards. That is, finding open-source projects that interest you is a great way to start to wrap your head around what it's like to contribute to something way bigger than you could ever do yourself. And in some cases, when you submit code to these projects, you'll get some really great actionable feedback that will foreshadow code review in a full time role.
Map the abstract to the real world
Academic CS is all about abstraction. And as a student, you are slammed with one abstraction after the other, often with little explanation of why you might care to know about it in any sort of practical way. So you learn what you need to learn, hopefully pass the exams, and move on without ever really getting a sense of how you'll ever use it again.
But it doesn’t have to be that way.
Abstract knowledge is what you make of it. And the more you link it to concrete, real-world applications and products, the more useful and interesting it becomes.
Ever wonder how Google is able to sort through the literal whole internet at lightning speed to deliver your search results? Or how map applications are able to find the best route to your destination?
Sure, both examples are orders of magnitude more complicated than anything you learn as an undergrad. To say it’s just hashmaps for search or Dijkstra's for maps would be exceedingly naive. Obviously.
But the fact is that these simpler concepts are the actual building blocks for these world changing solutions. They take these simpler concepts, make more sophisticated derivative versions of them, and string them together to create the masterpieces we use every day.
Likewise, the efficiency of your own database searches in web apps does the same thing, all the way down to the data structures provided by your programming languages that impact a small chunk of code that plugs into the products you’ll be contributing to.
And sure, if you need certain performance, you can always check the docs of anything you use and make your choices based on a lookup. But that’s not going to help you when you’ve run into an edge case bug that requires at least some vague sense of what’s happening under the hood.
The point is, understanding the fundamentals reduces magical thinking. And seeing how those fundamentals actually map to real things you will use as a pro brings them to life and subtly helps you make better, more nuanced choices. And a strong grasp of those fundamentals might just set you aside as the kind of engineer who can be thrown into the belly of Google search and make meaningful improvements, because all the more advanced techniques you learn on the job are being held together by a solid foundation.
So take some time for every abstraction you encounter in school, and do some Googling. Find out where it's being applied and take notice of the specific, derivative concept that's actually being used. I'm not telling you to learn how Google search works in depth, simply to make a light connection that may be surprise your future self.
Reach out for community
It's easy to remain in a bubble when you're in a CS program at a university. And it wasn't until a couple years later than I realized there's a world of both online and in person communities full of experienced people ready and willing to share their expertise in the right context.
Seek out online communities and Slack channels and consume the conversations. Check out meetup.com to see if there are any meetups you can attend (virtually until the pandemic is at bay at least). Ask folks about their experiences. Give people a chance to talk about themselves. Get a sense of the job market and whether anyone's hiring. You'll start to get a lay of the land in no time.
And if you belong to traditionally underrepresented groups in tech, you're in a better situation than ever before. Groups are popping up all over that are ready to help you succeed from Out In Tech and ColorStack to Triplebyte's own Slack channels like The Women Loop, BiTboard, and Latinx Declared.
Triplebyte helps engineers find great jobs by assessing their abilities, not by relying on the prestige of their resume credentials. Take our 30 minute multiple-choice coding quiz to connect with your next big opportunity and join our community of 200,000+ engineers.