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

Question

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.

Answer 1

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.

Answer 2

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)).

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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...}

Answer 7

Know your tools

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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 :-)

Answer 17

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.