# What does a person with an undergraduate degree in CS still need to learn to be employable as a developer? [closed]

Some recent CS graduates feel unprepared to enter the job market. Some may actually be unprepared.

• What is missing from a typical undergraduate program, or not sufficiently emphasized, that a person needs to know for successful employment in a software development position? The gaps may be technical or not. What evidence do you have for the gaps you suggest? How can a person fill the gaps?

• What advice can you give to a recent graduate about what they should learn on their own and how they might go about learning it? Advice might be for developing hard skills or soft and both may be needed to be employable.

Many entry level positions are not very challenging or rewarding, unfortunately. This may be the fault of the educational process itself, leaving graduates unprepared for better positions.

I assume that no educational program can teach everything. Therefore some things are emphasized more than others and some necessary things may be omitted, especially in a changing world. I'm not making an indictment of the educational process, but wondering what important things the individual still needs to know, and what skills they need, beyond their formal education.

My personal context is the US, but the same is likely true, but with different details, elsewhere. Your answer may depend on your own context, of course, so you may want to mention it.

## closed as too broad by ItamarG3, Jay, Gypsy Spellweaver, thesecretmaster♦Sep 12 '17 at 17:10

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• "Typical" in which country? – Andrea Lazzarotto Sep 10 '17 at 20:45
• I just addressed location, I hope. – Buffy Sep 10 '17 at 22:51
• Its too vague is what it is. – Jay Sep 11 '17 at 2:56
• They general concepts are taught in every decent CS programme. The day-to-day things like certain tools and languages are usually not taught, at least not in entirity because those things become outdated every few years and can be picked up within days (if you have good background in the general concepts) when needed in a certain workplace. – Džuris Sep 11 '17 at 15:52
• I've voted to close this question because there are too many possible causes for a CS graduate feeling unprepared to enter the job market. I'd suggest that you ask a separate question about how to resolve a specific concern that graduates have (e.g. lacking in workplace skills, missing knowledge, etc). – thesecretmaster Sep 12 '17 at 17:13

Firstly, I think CS degrees vary widely in how "theoretical" they are. Some try to teach you about programming languages and even vendor-specific products that you are likely to encounter in the real world; others focus much more on teaching the fundamental principles. Personally (as someone who has always worked in industry) I would much rather have people who know the principles and the theory, because that knowledge will remain useful for much longer. But whether your background is theoretical or practical, on your first real project there are going to be a dozen technologies or tools you have to master that you have never seen before.

Secondly, I think CS (and even Software Engineering) courses find it very difficult to teach the things you will only encounter on large projects: how do you grapple with half-a-million lines of code, how do you work on a team with 40 developers?

Then there are the non-computing aspects of the job. How do you handle a boss who has made an incorrect decision? How do you handle customers who try to make design decisions for you, and do it badly? How do you handle an experienced and respected senior developer on the team whose knowledge has actually become rather rusty? How do you manage conflicting demands on your time?

One of the things that I think you can only learn with experience is to acquire a mature attitude to risk. Many of the decisions in programming are concerned with risk. Should we release now, or write more tests? Is it wise to use a new open-source library that has just become available? Should we move forward to the latest version of X? We know the customer's stated requirements, but how likely is it that they will change? How much should we invest in extra resilience or security? In the end, these are the judgements that make a project succeed or fail.

• This is an excellent answer that stems from a clear wealth of experience. Welcome to Computer Science Educators! I hope we hear more from you in the future. – Ben I. Sep 11 '17 at 0:42
• The second paragraph is both factually true, and completely missing the point. Almost nobody in the industry actively works with 40 other people daily. Teams that large are split into subteams. Plus, being able to work with any kind of team at all would be a huge improvement over the typical CS practice of training students to think that working alone is virtuous and working with others is for cheaters. – T.E.D. Sep 11 '17 at 15:26

# To know that you know nothing.

Recent graduates can be afflicted by arrogance or low self worth. These are two sides of the same problem.

It is important to know that you are at the beginning of a journey, that has no end. The sum of all knowledge that is known, is but a drop in an ocean, and your personal knowledge is but an atom.

However this has not stopped other such as Turing, Lovelace, Hopper, Ritchie, Liskov, Stallman, et al; It has not stopped you in the past; and it will not stop you in the future.

# Experience

I have heard many a new journeyman say “To get a job I need experience, but how do I get experience without a job?”.

So get experience: Find a good Free Software / Open Source project, that you are interested in, and contribute to the project.

# Software engineering tools

As well as testing (@BenI). Revision control: Learn how to use revision control tools, for example: mercurial (hg), git, subversion (svn).

Of these subversion is previous generation, but still has some use-cases that best suit it. It is still widely used.

Mercurial and git are more modern, distributed systems. git is the most popular, but is a git to use, and very hard to learn. Mercurial is similar in how it works, but much easier to use (it has a more intuitive command line interface, and a nice graphical interface(tortoise hg)).

• Good answer, a couple of nitpicks. 1. It actually starts on the "Experience" paragraph, this is a matter of style and not actually a problem. 2. Why mention mercurial? And before git?? It might be as good but git has won that war a long time ago. It's the de facto standard and they should concentrate on learning it (knowing subversion is also useful but not much to learn there). – Oleg Sep 10 '17 at 16:16
• Point 1 is not important no need to grok it. With a good GUI like SourceTree for example it's really not that hard, you can mostly just use its basic features as you would use subversion. I don't see git being replaced in the near future and if you want a swarm there is GitTorrent. None of this is relevant, people who want to work in the industry need to know git you said so yourself in your answer what I don't understand is why you also think they need to learn mercurial and by placing it before git it makes it look like you think it's more important. – Oleg Sep 10 '17 at 17:36
• @ctrl-alt-delor If a CS graduate can't learn how to use the basic functions git from the command line in a day, they should give up programming and go into management IMHO. (Don't complicate things by using a GUI that tries to make git look and feel the same as a different product, and just gives you all the bad features of both of them!) Also, I'm at a loss to see why you should have 200 students pulling anything of significant size during a lecture in any case. Lectures should be for learning new stuff, not practicing using it! – alephzero Sep 10 '17 at 17:48
• @Oleg In the spirit of the question, one thing I've learned since graduating is that any tool you can name will have somewhere where it's used. Mercurial is the VCS of choice for several sizeable institutions I know of, including at least one university. A good software developer keeps abreast of all tools, researches and develops their own opinions on which is the best for when they're able to choose which to use, but is prepared to work with anything for when they're not. – anaximander Sep 11 '17 at 8:14
• @Oleg A good developer prioritises what to learn, I agree with you there, and I agree that as it stands, git is a better call. I'm not saying you must know everything; it's just useful to have a general idea of what's out there. If I mention Mercurial to a candidate at interview, I'd want them to have heard of it, maybe have a rough idea of how it compares to other options, and if I said that they'll have to use Mercurial, I wouldn't mind them having an opinion on that, but I'd hope that they'd be open to the idea of using it, and learning what they need to learn to be comfortable with it. – anaximander Sep 11 '17 at 11:03

I suspect that the lions share of new CS grads seek jobs in what is actually software engineering, a related but different field.

Things I see missing when I interview these people:

• An ability to actually Program in the languages on that CV, if you claim C then know what volatile means and that i=i++ is broken, if you claim javascript then know the difference between == and === and the type system. No point bigging up your knowledge we can always tell.
• Testing, including the importance of automated regression testing.
• The fact that requirements change under you.
• Version control, I don't really care which one, but please have used something on a non toy project.
• Some appreciation for project management, at least in terms of what input they need.
• Some task domain knowledge is always nice, yes I know the specification is supposed to be fully detailed and internally consistent, have you ever seen one that really was?
• Code should be written for humans to read and only incidentally for the compiler (And remember your audience, just because you are a C/C++/Javascript/assembler/matlab god, does not make everyone on the team one).
• Build tools and an understanding of how they can be scripted.
• An appreciation of when big O likely matters and when a bogosort is the right choice.
• An appreciation that it is Worst Case that really matters, not average case (This one may be specific to my hard realtime industry).
• A huge amount of a junior engineers time will be spent maintenance programming on existing systems (Some of which are a right mess), some practice at this would be good (O.S. Projects are cool here).

My favourite interview question is "Yes, but what have you made?", open source is good here, but it does not have to be software, I will take a tree house as an answer as long as they can talk about the problems encountered and different approaches to solving them.

One other note: Low level is good, I can usually teach Javascript and the framework of the day (No point in teaching that in school they seem to have a half life of 12 months or so) to a C or assembly programmer a hell of a lot more easily then I can teach C and assembler for whatever core I am using today to a Javascript developer.

• Comments are not for extended discussion; this conversation has been moved to chat. – Ben I. Sep 11 '17 at 17:33
• Most of these points are not things that a College graduate would/should be expected to know. All of them are nice to knows. Regression testing? I mean, I'd love for applicants to have that experience, but realistically it may not happen, and that's okay. Almost all of these things can and will be taught on the job. Big O notation is the outlier, but it is most often taught in CS 201 - "Whatever name your algorithms class has." – EvSunWoodard Sep 11 '17 at 18:10
• "An appreciation that it is Worst Case that really matters, not average case (This one may be specific to my hard realtime industry)." -- I'd say it has good relevance to GUI design, too. A user interface that occasionally stutters and takes too long to complete an operation is a usability problem (and one that is, alas, all too common). – Jules Sep 11 '17 at 23:22

I once had the opportunity to sit down with a very high level Google engineer (who is also an alum of the institution at which I now teach.) I gave him an overview of our program, and then, since I knew that hundreds of engineers reported to him, I asked him what he would like to see more of from graduates. Without even a moment's hesitation, he said, "Test your code."

He explained that, even at a lauded place like Google, the majority of people coming in don't deeply understand how important it is to attempt to ensure that their code will always work.

In my program (which is at a high school), I have translated this statement of his into a lot of explicit practice in creating test cases. My program is really CS, not SE, but I am aware that many of my students intend to become software engineers, and creating strong test-cases seems like a core skill that needs to be developed within both worlds in any case.

• Testing is so hard to learn to do properly that I'd strongly recommend finding a mentor for this. Unfortunately many people who think they know how to test create slow, over-complicated test suites which are more for show than actually useful. – l0b0 Sep 11 '17 at 8:13
• We don't need grads who are good at testing. We need grads who know the value of testing, and when to ask for focused help. Also knowing that testing is about catching the failures, not demonstrating that 'correct' paths can be found. – Sean Houlihane Sep 11 '17 at 10:16
• Hmmm...when I was at uni almost all my programming assignments were automatically run against specific test cases created by the instructor. The test cases were unknown by the students so it forced the students to "test" their code as failing the instructor test cases pretty much guaranteed a failing grade on the assignment. I remember sometimes the instructors wouldn't even accept the assignment if it didn't pass all the test cases. That was a couple of decades ago and I know times have changed where telling someone they failed hurts their feelings, so do universities no longer do this? – Dunk Sep 11 '17 at 15:34
• @Dunk In my experience some universities do this, but a good number don't. I think you can count yourself lucky (I know I do in this regard). – nova Sep 12 '17 at 22:28

I've interviewed a ton of people fitting your criteria.

What is missing from a typical undergraduate program, or not sufficiently emphasized, that a person needs to know for successful employment in a software development position?

I don't want to hire programmers. I don't care if you can write beautiful code or ace a list of algorithms questions. You know how many programming jobs in the real world need someone who can do this? Nearly none.

I care if you can be a good engineer. Can you evaluate tradeoffs, make educated decisions, know when to write "good enough" code, when to reinvent the wheel (or not), how to contribute on a team, how to learn different skills, can you communicate your ideas effectively. Are you afraid to make mistakes, can you ask for help appropriately, do you understand why premature optimization is almost always a waste.

Can you dig into a complex system that is probably full of years of cruft, work with teammates who are opinionated and either talented or not. Can you work with teams of people, can you show up to work reliably and do the things you say you can do -- and communicate early if not. Are you able to deal with interpersonal issues (yes, these exist on a regular basis with a bunch of opinionated technical people) or do you just dig a hole and hide?

Do you take ownership for the code you write, knowing it may be in production for years or even decades? Do you understand that real users may be paying your company tens of thousands of dollars for the code you write - do you interact with your job appropriately? How do you do cost analysis, not only for your code but the system resources you will use.

I could go on and on. But regardless: these types of skills are simply not taught by and large.

this is assuming basic competency with programming principles, which isn't always the case, but the optimist in me is going to assume that anyone reading this is teaching those abilities well enough that I don't need to say that too...

• Exactly how are you going to know the answer to all your "wish-list" ideas from an interview? Also, IME, most computer science/engineering grads are introverts and it takes a few years experience before they even start to get better at those "social" skills you are looking for. But once they add those "social" skills to those technical skills they become quite good. Thus, I mainly look for someone that demonstrates they can learn, demonstrated that they are motivated to be a developer and someone that seems like they'll fit the personality of the team they'll be working with. – Dunk Sep 11 '17 at 15:49
• @Dunk it's actually pretty easy. Ask them to talk through how they solve a problem, how they resolve conflict with a team member (probably a group project), and a few questions about "what would you have done differently on a project?" and you get insight into most of those questions. – enderland Sep 11 '17 at 16:02
• pretty easy for someone with job experience. However, I can picture the terrified looks in the eyes of new-grads if I asked them the same kinds of questions as their mind becomes completely blank with the cache-swapping going on because I switch contexts and asked them non-computer questions. – Dunk Sep 11 '17 at 16:42
• Everything you described in your post applies to a good programmer. I don't understand the distinction you made between a programmer and an engineer. – Oleg Sep 11 '17 at 21:19
• @enderland - Your answer is fine, just IMO I don't see a whole lot a college can do to teach much on your list. At most they could have more group projects but I'm not alone in saying that those were the worst assignments ever and I don't think they are as good of learning experience as some people think. Finally, I'd be thrilled to death to find some new grad who could write beautiful code and come up with good algorithmic solutions on their own. I'd hire them in a second, with the exception being that it is obvious they are going to be a "people" problem. I'll teach the engineering skills. – Dunk Sep 11 '17 at 21:24

Students need to learn how to teach themselves. These are the only ones that succeed.

Programming, more than other fields, requires students to take responsibility for their own education because this is the only way they can survive as professionals. Students who expect that their courses and labwork will take care of making them employable professionals have essentially zero chance of succeeding. You can provide guidance, but if they're not already out there engaged in serious self-learning then there's really nothing you can do. A programmer who can't teach themselves is not much more than a liability on any real-world development team.

• But to be a successful programmer is not nearly as difficult as being a pro sports player, so I think this is overly pessimistic for people who want to get into programming later in life. – littleO Sep 11 '17 at 16:13
• "you're never going make it, or at least the chances are very very slim". There are obvious reasons why it's important to start early with physical activities, but I don't see why these would apply to intellectual activities. There are also many, many, many counter examples for CS (Don Knuth not programming in his teens doesn't seem to have hampered him that much). You just don't need 15 years of muscle memory to be a great engineer - yes the experience helps, but the experience you gain as a kid writing MUDs is going to be of limited use later on anyhow. – Voo Sep 11 '17 at 17:20
• I've seen a lot of CS kids where it's just too late already whaat? nearly my entire team is people who didn't program until after their undergraduate degrees. Are we all exceptions to this rule? I think not. – enderland Sep 11 '17 at 17:55
• I just graduated with a degree in CS in 4 years from a US college. Before starting college, I'd never programmed. By the end of my first CS course I was in the upper half of my class. I disagree that not programming in my teens was a huge disadvantage. I'd say the ability to teach yourself, to google, and experiment, and just not give up until you can do the task at hand, is more important then previous experience. – E.D. Sep 11 '17 at 18:15
• @all - Fair enough, and all good points. Most, if not all, good programmers I've known all started early on their own initiative and not because they were assigned classwork that required them to learn programming - maybe that's not always the case, as it would seem, but usually if you're interested in programming you're not waiting around for someone to give you an assignment before you start writing code; you dive in and learn because you want to. – J... Sep 11 '17 at 18:19

Test often using debugging tools. Clarity is key. Your IDE can save you hours of typing and testing over a month, so don't just hide the "tip of the day", and explore the menus.

Know your source control

Source control is your main input channel, it should be as familiar as your keyboard. Contribute to open source projects on github. Even fixing a typo shows you understood the code and can use git: great, one less thing to ask in the interview. Also, code reviews are based on diffs - keep it clean.

Make sure you know the solution you're planning is the right one

New developers can get over-eager and excitedly write a solution to a problem that wasn't the focus of the task - ask the ticket maker & other devs if you're on the right lines before starting to code. If you can solve other related issues, this can show initiative - just deal with the real issue first.

New graduates don't need to be an expert in anything, but they need to be able to get stuff done.

By that I mean, if you have Java listed on your resume, I should be able to hand you a laptop with a clean OS on it, and you should be able to write and run a basic hello world program. You should know how to download, install, and run Java, and you should know how to write, compile, and run a basic program. You should know how to look new stuff up in the documentation, Google, and Stack Overflow. That's how programmers get stuff done in the real world.

The best way to prove that you have this knowledge is by putting together something like an online portfolio. What were some interesting projects you did in school? Can I see them? What personal projects do you work on? Do you contribute to any open source projects?

tl;dr: Give me a link to a list of cool things you've done, and be able to setup your own workspace.

• I like the idea of an online portfolio i can read, especially for web developers. I would definitely consider a well made one to be a plus when hiring. – Scheme Sep 11 '17 at 18:43

What is missing from a typical undergraduate program, or not sufficiently emphasized, that a person needs to know for successful employment in a software development position?

To answer your question literally, I would say nothing. I don't necessarily think you need to be the best at TDD or GIT or whatever to be successful in an entry-level position. A willingness to learn, some enthusiasm, and a good team fit are (at least in my experience) huge factors in being successful in an entry-level role.

However, to better answer the question from an educator's perspective: I think dealing with mess is under emphasized. A lot, and I mean a lot of software development is horrendously messy. Seriously. I remember with vivid clarity the look of disgust on an intern's face when I told him there are about 60,000 files in the solution he would be working on (so sorry John). To me a good way to get that experience is as others have said: open source. (Bonus cool-guy points if you added a feature you needed to a tool you found lacking.) I think it would be great to see this (dealing with huge messy projects) added to more CS degrees. There is an art to it.

# Source Control

When I received my BS in Computer Science, I had never used source control and was vaguely, if at all, aware that it exists. Source control would have saved me from many struggles throughout my coursework and would have made the entire process much less painful.

• Copy and Paste into an archive directory as the CM tool is more than sufficient for BS degree course work. How exactly would having a source control tool have saved you from many struggles? IME, most companies that new employees go to are using different CM tools than what they already know. Thus, they simply use the cheat-sheet created by the CM person and are on their way in minutes. There isn't enough time to learn everything the students are supposed to be learning as it is in most CS programs. Why throw something as trivial as using source control instead of some more overarching concept? – Dunk Sep 11 '17 at 15:47
• I used source control extensively in college- if you have any projects shared with multiple people, its invaluable. Its also really good to be able to have GIT,TFS and SVN on your resume. – kingfrito_5005 Sep 11 '17 at 15:52

Hate to add yet another answer, but this needs to be said: there are three things that matter: how to communicate with people, how to communicate with people, and

### How to communicate with people.

Frameworks change. Testing practices change. Version control systems change. Languages change. Algorithms change (simpler but slower as the hardware gets faster). Hardware changes. At some point hopefully in my lifetime hardware architecture will change (away from Von Neumann to cellular automata et. al.).

Even a person can change. But people don't change. Peopleware, Mythical Man Month, etc. are every bit as relevant today as they were decades ago.

You will have to deal with bosses and coworkers. You may also have to deal with vendors, clients, customers, direct reports, and employees.

You will have to go on job interviews, pitch ideas, give presentations, write documentation, send email, and even write policy.

Software is a second career for me, I was already an adult when I went into the field. Before doing so I interviewed a bunch of people through my network who were in industry and I asked them what they wish they'd known going in. To a man/woman they said some variant of "people skills".

If you are sending your graduates out into the workforce without a solid grounding in this area then all the technical prowess in the world won't help them. They will be rated "hire, but not for my team" in interviews.

This is my observations, for whatever they’re worth, from having interviewed a lot of recent graduates over many years.

The first thing to understand is that you get out of an education what you put in. It is clear to me that it is possibly to graduate without having actually learned everything they were trying to teach you. You have to want to learn. You have to actively seize the opportunities. For just one example: Be the one person in your group projects that actually does the work and earns the grade.

In my experience, whatever you want to do in the field, you’re best served by knowledge of both computer science and software engineering. Most programs are naturally not going to fully cover both. You have to find opportunities beyond your courses to expand your knowledge and experience. If you’re studying CS, find or create open source projects to work on. If you’re studying software engineering, take time to read up on and understand the history and concepts behind the things you are learning.

Also note that even with theory, experience is invaluable. e.g. Spending some time with a Scheme interpreter playing with the concepts of the lambda calculus will help so much more than simply reading the literature. Build Peano numbers and their operators rather than just reading about them.

Finally, when you do interview for a job: I’ll hire someone who clearly wants to learn over one who knows more.

First off, employers expect entry level employees to be inexperienced. So most will not be looking for you to have a lot of hard skills. Some will want to know that you have the right aspirations and personality traits, since you will learn the skills you need on the job. Most will want to ensure that you have a minimum level of competency with one particular programming language. You should know what programming language you want to spend the rest of your life using, and get good with it. That will help you not just to land a job, but to land the right job for you. Other important things that may be neglected by your school are good Testing practices (including test driven development), and engineering principles. Experience writing code is one of the most valuable things that you can get, because it will be expected that as a new grad you will have virtually none. Make sure to take courses with lots of coding, not just theoretically knowledge. Those courses are fine too, but they shouldnt be the ONLY ones. Project based classes, open source or personal projects and internships are all critical.

And if you ignore all of that advice, at least try and get really really really good with SQL, because EVERY job you will look at is going to need it.

A fundamental part of understanding software architecture is to understand how your target platform will shape design decisions.

Regardless of the type of work you do, the code is going to be constrained by the hardware it runs on. Processor speed isn't necessarily that bottleneck. Often it is memory availability, disk transfer rates or even network transfer speeds.

For each of these constraints there are architectural designs to help alleviate them, but all designs have drawbacks. Understanding those along with your target platform will usually point the developer to the right solution.

By way of example, I've lost count of the number of times I've seen a new developer put out code that runs a 'select *' on a large table ... multiple times, then wonder why the computer grounds to a halt when that page loads. Only to come to the "conclusion" that locally caching all that data is the right answer.

TBH, I think they should spend their entire senior year working on a mid sized project. Something run how one would be in the real world. Replete with hardware, software and time constraints - as well as changing priorities and requirements. All of them would benefit from having experienced that before showing up at a new job.

If your "CS" is the same as what "Dipl.-Informatiker (Univ.)" is in Germany, then, frankly, I expect nothing from a fresh graduate that is really related to the job, since I work in a real world IT company that consults other companies (the "real world" type consulting, i.e., try to understand and solve their problems, not the golf-related consulting) and first and foremost creates software on every level. I understand and experience day to day that the universities, at least in my country, do not see teaching that as their task (rightly so, it is called science for a reason).

Now, don't get me wrong. I have studied those things myself (albeit before they changed the university system in my country - these days we have Master and Bachelor as well, and the university education is much more school-like than it was before). I, also, although I was very happy with my studies, learned almost nothing that I ever actually directly used in decades of work.

What I brought to the table back then, and what is a huge bonus for current applicants, is private, real-world related effort. Be it programming in the context of an open source project, your own software, digging deeper into programming languages than the curriculum would need of you, having a Linux box or three in the cellar, playing around with your own VPN, programing Arduinos or Raspberry Pis, configuring a small enterprise-level NAS involving XFS or whatever. And yes, be prepared to answer in-depth questions have a fascinating discussion about each of those topics if you bring it up, because although your interviewer may look like Dilbert-like "pointy haired boss", he just might be doing all these activities at home right now...

Of course, I also delight in just chatting about CS, so I might throw in a question about functional languages, lambda calculus, temporal logic or what have you, just to test the modern curriculum. ;)

I need to see a real self-motivated interest in the topic. If I find that, I know that you will pick up whatever you need on the job. A successful CS degree helps, of course, but I might rather pick a mathematician with all those attributes than a CS student who gave me the impression that he did study and finish CS but has zero interest in the topic.

Soooo many things can be said here and I could literally type an entire several hundred page book about my experiences coming out of college as an undergrad and what I've learned since then but I will try and keep it concise ;-)

### You learned how to learn, no program

The biggest point I can make here is that when I was in college I learned Java with Swing. Of course this was right at the cusp of everyone starting to want web sites because "the cloud" was an up and coming thing, so my Swing experience was completely irrelevant. What wasn't was my ability to figure out my problem, get online, search for solutions, and morph them into something I could use in my program. The information any developer needs is pretty much free and available through the internet, just gotta know what you are searching form.

### Debug, debug, and oh yeah...debug

When I was in college, I didn't know it at the time but I was doing myself a huge service by being someone people could come to when they had questions about the assignment. When a function wasn't working, or a unit test was failing, people would show me their code and we would walk through it. Sometimes the code was very cleanly written and other times it was worse than spaghetti. This equates to real world scenarios in a way recent grads needs to understand. Lots of companies will have one or more legacy projects where you'll need to debug someone else's old (and probably outdated) code. It's not feasible to simply say "scrap it and rewrite the whole thing" because it might be too costly. Be the go to person to help your friends in college when they need it.

### Work a little every night

I know this is silly to have to point this out but you should work on your projects for classes (or personal projects if you have them) every evening. Why?? Well, for one, it prevents pulling all nighters to meet deadlines, and two, because it gets you used to working in the real world. I can't just go in every day for a week saying I've done nothing and then work all weekend to meet a deadline. Building up your ability to stare at code for hours on end is a valuable tool that will keep you productive at work and not going for energy drinks every fifteen minutes.

### Work on personal projects

Have an idea for a website that does some functionality? Who cares if it already exists. Get your favorite tech stack and make that application. A company looks very highly on developers who do self improvement outside of work. Of course time doesn't always permit but if a recent grad goes to apply for a company and can link their Github where he/she has created a few applications that can showcase their coding standards and other items, it goes a long way. Like a graphics artist having a portfolio, a developer should have a portfolio too.

So I ended up not being as concise as I wanted to be but I think these are some of the main points I've taken away since I've started working post college :-)

In my experience (in the UK), a lot of current degree courses offer a breadth rather than depth of knowledge (a "flavor" of lots of different languages, rather than a decent length of time programming in one language)

This often means that graduates have only spent a few weeks developing in a language (possibly for one coursework for one module). So by the end of their first week or two on the job, they may have done more programming in a language than they ever needed to in order to pass their degree.

Developers who have spent any time at all on a home project or on an internship tend to have a real advantage in this area.