Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question is directed more toward employers and graduate student advisors/professors but all opinions are welcome.

What do you find is a common weakness of new hires and/or new grad students? Is it entirely variable dependent on the student and his or her university? Is there a particular skill or skillset that you wish new hires/researchers had expertise in and how can we remedey this deficiency?

I realize that this question is general and really encapsulates two questions, one more about the weaknesses of new software engineers and one about the weaknesses of new researchers. However, both types of people tend to come from similar courses of study so I'm wondering if there is any overlap.

Note: I am not a professor but I'm interested in how best to revise the undergraduate curriculum in CS.


migration rejected from May 10 '15 at 12:20

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by Ixrec, Snowman, MichaelT, durron597, GlenH7 May 10 '15 at 12:20

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

"Ah, yeah. These wise fools do not learn (insert my favorite antiquated technology here) in college these days. – Job Feb 17 '11 at 18:04
In order to properly revise the curriculum in CS, you'd have to define what the CS degree should be. Should it be the study of the science and mathematics involved, or should it be glorified job training? Science or professional? Universities teach both (Ph.D. vs. M.D. as top-level examples), but most disciplines are clear on which they are. – David Thornley Feb 17 '11 at 18:35
Great insight @David Thornley. However, I think for undergraduates, it may be difficult to make a decision early on about whether they'd rather go a more scientific or professional route. Shouldn't there be a way through the first few years of university to expose students to both and somehow illustrate would life is like on either side of the coin? – akobre01 Feb 17 '11 at 19:07
Sure, but in most cases that's a matter of specifying or changing majors. A student might take courses while trying to decide between a chemistry and chemical engineering major, for example. It has nothing to do with the goal of the major itself. – David Thornley Feb 17 '11 at 22:25
Also check out this…. However, the answers here and there seem to be radically different. – apoorv020 Feb 18 '11 at 5:17

27 Answers 27

This vastly depends on what school you get a degree from. Some schools are more skills-based, teaching things that can be put on a resume to get a job. Others are more knowledge-based, focusing more on abstract topics.

They both have their advantages. A degree from a more skills-based school will make you more comfortable coming into a new job, since you're more likely to know how to do some things, but knowledge-based degree programs will usually shine when it comes to overall computational understanding.

A lot of the top tech businesses focus on the knowledge based schools rather than the skills-based ones. From my experience, it's easy to train someone who has an excellent knowledge of computing. It's a lot harder to train someone who knows tons of Java or .Net, but doesn't understand what's going on behind the scenes. From my experience, people from skill-based programs often disappoint in their creative and cognitive abilities.


What do you find is a common weakness of new hires and/or new grad students?

In undergraduate students, a lack of mastery. They know a little bit about a lot of things, but in industry, that simply doesn't cut it. This lack of defined expertise is common to most undergraduate students, not just computer scientists.

In grad students, a lack of real-world experience. Some grad students do get internships, which helps them transition to the employer/employee world. But the majority of grad students are stuck from 1-5+ years doing research (or worse, doing class-related projects) and writing technical papers. This is great for when you develop a product or idea and want to document it, but it isn't always good for the process of interacting on a team or within a work environment. Also, more mathematical graduates may have a significant lack of programming experience, depending on their graduate focus. However, grad students tend to have a specific mastery, which is always helpful at the top tech companies.

Is it entirely variable dependent on the student and his or her university? Is there a particular skill or skillset that you wish new hires/researchers had expertise in and how can we remedey this deficiency?

Yes. But more to the point, this depends largely on the student. Where I did my undergraduate studies there were ample opportunities for both academic (research) pursuits as well as industry options. These had to be sought out, however, and most undergraduate students simply want to party (this is in the U.S.)

I realize that this question is general and really encapsulates two questions, one more about the weaknesses of new software engineers and one about the weaknesses of new researchers. However, both types of people tend to come from similar courses of study so I'm wondering if there is any overlap.

Carl Norum answered this one well. Computer scientists aren't necessarily software engineers, even though upon graduation that's exactly the position they apply for. Then they get to the company and everything is new, unfamiliar. Well what do you expect? They didn't spend four years learning software development.

I am a computer scientist, and engineer. I graduated from one of these programs and I've seen my fair share of how things are. A few of the answers given here trouble me, and I'll explain why.

IMHO, the main weakness is the lack of project management skills. Computer science students get many technical disciplines but few or none knowledge on management.

In my experience, you can't be taught management. Good management comes with experience. At both the undergraduate and graduate levels (at least where I went to school) students are often loaded with 3-4 projects each week and they have to complete these while balancing work, family, and friends. Some manage better than others, but to say CS students have no knowledge on management is a very general, very imprecise statement. Most undergraduates have poor decision making skills when it comes to management, it isn't something specific to computer science students. And if I had to take a position here, I'd argue that CS students tend to have better management skills than most other students, sometimes even better management than the engineering students (but only sometimes).

I would have to say one weakness is being able to pull requirements for a given task. In the academic world, your requirements are typically given to you in the form of a project that says it must do x,y,z. (This is geared more toward SW Engineers than Researchers)

Definitely a drawback to weak computer science programs. Most classes are fairly structured in a "spoon-fed" kind of manner. Unfortunately it is true that many many students fall into the trap of thinking that this is how things work all the time. However, there are classes that are not like that at all. They require taking initiative towards not only developing steps to a goal, but also defining the goal itself. Additionally, completion or lack of completion of these goals must be formally presented, as if to a working group, which is how industry tends to do things.

1 - Presentation/Communication skills totally absent.

2 - The woeful lack of teamwork experience. In that, they don't have a grasp on how important it is that their work has to fit in with the other team members work.

Only in some programs. The one I was at presentation and communication were very important (if not essential) in most classes. Also, we were almost forced to work in teams. Of course, this ties into management that many students simply couldn't work in teams (they did little to no work). This is more a generational/youth problem rather than a problem specific to the computer scientist world.

In summary I guess my point is that the OP question would have been better worded towards people who go for software engineering jobs. To generalize CS degrees in this manner is a gross simplification. On one hand what you're saying is true, but it's not specific to CS degrees. On the other hand people who go for SWE jobs (in my experience) do exhibit these sort of deficiencies.

Excellent post, particularly the bit about Software Engineering. I think that SE is woefully under represented academically, and yet that's what 80% of the "computer programmer" jobs really are and what most undergrads really want to do. Yet if they go the engineering route they're typically limited to Computer Engineering or Electrical Engineering, which are (typically) not focused on Software, or go into Computer Science, which isn't focused on Engineering. – Curtis Batt Feb 17 '11 at 19:25
+1 @c.batt (and @aqua!). That's exactly what I was trying to get at in my answer. The EE program I took had exactly one course in software (Fortran, nonetheless), and the CS program had exactly zero courses in hardware. Trying to get an education that would lead me towards embedded systems development was complicated, to say the least. In particular the lack of focus on the design/engineering process in the CS program was terrible, though maybe to be expected. – Carl Norum Feb 17 '11 at 19:46
"...and most undergraduate students simply want to party" true of the UK too. An excellent post. +1 – user10197 Feb 17 '11 at 21:16
"Also, we were almost forced to work in teams." -- One of my CS courses at university had assignments that had to be done in teams of up to 3 people. Team of 1 was an option and I took it... and then learned the hard way that they were team assignments for a reason. Best (if painful) teamwork lesson ever. – Adam Lear Feb 18 '11 at 2:03
@Anna: On the other hand, at least you probably had something to turn in. In a lot of my classes, I'd work on a "team", and the other team members would simply not participate. Therefore not only do I have to spend time doing more of the assignment than I should have to, I still end up with a poor grade. There's been more than one assignment my "group" has gotten better than 97% on that the other group members didn't touch. Fortunately for those who really don't care, there are enough of us who do care to get things done. Unfortunately, that means us caring people get shafted. – Billy ONeal Feb 18 '11 at 2:57

As a professor of CS in one of the largest public university systems in the nation, I find all this handwringing over course content rather sad. No Bachelor's degree in any major will prepare a student for advanced tasks in every work environment. I am constantly peppered with idiotic questions from industry locals like "why don't all your students know Visual Basic?" or "why doesn't your program focus on Drupal development?" or "why don't you purchase a computer game design suite" or "why don't all CS students have a business minor?" Everyone in the computer industry has a wish list, believes I'm Santa Claus, and my elves can manufacture 100 extra lecture hours with students with a little magic dust.

What we all teach is a core of the field that the graduate can build on--enough to be capable of doing both practical and theoretical work, depending on interest. We serve the students--not the industry--because they're the ones paying the bill. We emphasize different things in different CS programs, something advantageous to industry because a team with differing skills more quickly tackles complex problems.

Unfortunately due to meddling from outside interests things are getting much worse, not better. Industry attempts to force cookie-cutter curriculum and assembly-line processing on students with wildly differing needs. General education requirements continue to grow as a percentage of education, and hours devoted to the student's major are forced to decline as a consequence (we just cut CS major hours by another 18%). The public demands more and more paper shuffling to meet increasingly Byzantine regulations, which reduces contact time with students and faculty time necessary to generate internship and project opportunities for students. All outside interests cut funding to education and increase course class sizes. Administrators hire marginally competent instructors to teach more of the curriculum as a 'cost saving' measure (they are also starting to eliminate science majors, including CS, because they are more expensive than philosophy and history). Megacompanies like Microsoft and Cisco that squat on tens of billions in cash can't find it in their Grinch hearts to help starving CS programs with a little used hardware and software that could enhance the students' experiences, so students are forced to use open source compilers/IDE's on 10-year-old cheap desktop systems (and what yoyo thinks we can afford advanced version control environments, or the staff to install and maintain them??). If you think your Christmas stocking will be filled under the conditions you are creating, guess again.

Talented students regularly pass over CS as a degree and choose Biology or Physics or Economics--degrees where less than one in five can find a job in their major. Why? Because industry chooses to make the computing work environment unpleasant and unrewarding. I can't tell you how many times I've tried to recruit top notch talent into our CS major only to be told no thanks, they have a relative who used to be in the industry. That relative worked 60 hour weeks, slept in his cubicle, had no social life outside a tyrannical boss and terrified coworkers, was forced out due to downsizing after training an H1B replacement, and could only find temp jobs after that; the relative finally got wise and took a job in another industry where he's much happier.

The real problem the industry must face is that universities are only training 1/4 the number of people needed for industry growth over the next several years. In addition, millions of productive Baby Boomers are about to retire. Industry members, ask yourselves: why should someone work for you? Do you think the obesity, divorce, diabetes, stress, lack of sleep, and frustration are worth a few bucks? The students are saying no. This is not because they can't do the work, or they're from a 'selfish generation.' It is because they know what is on the other side and they want no part of it.

And that is for those who can still afford an education--rising tuition at our 23 campuses is forcing out tens of thousands of bright young minds, where they must choose between low-paying grunt labor and a high-paying life of crime (that's not an exaggeration--a recent economic analysis of our county showed that illicit drugs generated half a billion in export income for the county--half of the county's total GDP, and proof positive that talent will find a way to express itself).

Please do us all a favor and start talking to high school students about what they want out of life. Try convincing a few that a career in CS is worth doing. Perhaps you'll realize that whining about what isn't under this year's Christmas tree isn't helpful but just exemplifies to a young generation seeking work/life balance that you're unplugged from their reality.

I need to ask you one question, having to decide to stay in the industry or not, do you believe that generally speaking the situation will improve or what it will get worse for the IT workforce in the following years? I am very interested in your opinion thank you. – dimitris mistriotis Feb 18 '11 at 14:55
It is a very complicated problem. The students have two directly competing needs. The need for knowledge they can build on, and thereby become good members of society. Then, we've also got the need of the students to be able to enter the business world. The first half seems to be working well now, the second half is failing. Students who do practical application of knowledge on their own time make the transition fine. However, those that have the false belief that schooling will prepare them for the real world are always shocked to find out that they only have half of what they need... – Brian Knoblauch Feb 22 '11 at 15:16

I've not met any entry-level person in the computer science field who had the slightest idea of how to query a database. I've not seen any business-oriented project that didn't need to do this (granted there are some, but not in the typical business environment where most graduates will get jobs).

Lol, my databases textbook never mentioned an actual select statement. That would be too applied :) – Job Feb 17 '11 at 18:59
Statements like this answer scare me. Glad I majored in Application Development and not CS. – Ben L Feb 17 '11 at 19:36
When I taught databases, I had to basically throw out the book (I reviewed a lot of textbooks and all were terrible). You don't start with normalization, you start with queries (and query both good and bad structures) and then normalization makes more sense when you get to it. – HLGEM Feb 17 '11 at 20:40
SQL was one of my weakest areas coming out of college. All ERD diagrams and normalization...not once did I see how to acually use SQL in programming. – falclif Feb 17 '11 at 21:11
I remember my database class. It was a 400 level class. By the time we got done, I could write my own DBMS, structure data like a fiend, but I had no clue how to use any of the ones that were commercially available. :-) – Brian Knoblauch Feb 17 '11 at 21:23

I would like new graduates to come out with all of the following:

  1. A decent understanding of basic coding best practices. This would be covered by exposure to everything in Code Complete.
  2. Experience in using some form of source control, and an understanding of why it matters.
  3. Experience with unit testing.
  4. A decent understanding of algorithms, efficiency, big-O, etc.
  5. Enough exposure to enough languages to not be afraid of picking up whatever they need to.

My impression is that most students come out with 1 - 2 of these.

You've listed three things not relevant to Computer Science (as opposed to software engineering), one that is, and one that's borderline. Having 1-2 of those sounds correct. – David Thornley Feb 17 '11 at 18:28
#5 is borderline impossible as one would want someone to have depth in a language before gaining breadth – Woot4Moo Feb 17 '11 at 19:01
@david-thornley: The question was what weaknesses students come out with. Your explanation justifying those weaknesses notwithstanding, those are common weaknesses. Furthermore my personal belief is that teaching items 1-3 would pay off even within the context of the small projects that students do in CS courses. – btilly Feb 17 '11 at 19:08
@Woot4Moo, I don't think it's that unreasonable. If I could hire a new grad who was great at C, but also knew enough shell scripting/python/java/you-name-it to not be scared of them, it would be great! A combination of fepth in something and a reasonable amount of breadth doesn't seem like it would be impossible for a curriculum to provide. – Carl Norum Feb 17 '11 at 19:53
@Woot4Moo: Do you consider MIT to be top tier? Glancing at the courses in I easily found MIT courses using Scheme, Java, Python, C, C++, MATLAB and Python. I understand that they have dropped Scheme, but they still have a lot more than 2 languages. – btilly Feb 17 '11 at 21:32

Lack of business sense.

The biggest weakness I've seen (and in myself when I was a recent graduate), is that there's passion and drive to work on cool projects with little or no regard to how it will provide value and profit to the business.


I'm going to answer slightly off topic. I won't tell you what a fresh graduate lacks (because that varies depending on school and curriculum), but a great way to ensure that you minimize this lack of knowledge at the time of graduation is by working (internships). My school gives a standard 4year degree in 5 years, but incorporates three 6 month internships in the program so that at the time of graduation, we have 18months of work experience.

By the time we graduate, we have a fair idea of what to expect from the 'real world', so we don't have any illusions of what our work will consist of.

One of the greatest things I've learn from my internships that school wouldn't have taught me is writing good quality code. Countless times, I've thrown together crappy code that gets the job done for a class assignment and got a perfect grade, but there is no scope for bad code when you're working. You need to cater for expandability of the program, whether by you or someone else, and so its extremely important how you architect the program. Classes encourage writing crappy code because you're on extremely tight deadlines (agreed a work environment has these too), and code written for classes is rarely re-used once you're done with the class.

++ To me, it's a matter of quality control of what is taught, because there is flow of information between the practical world and academia. Without that, it seems schools have no guidance on what would be useful to teach in upper-division courses, because they get no feedback from reality. Other engineering disciplines have productive relationships with industry. – Mike Dunlavey Feb 18 '11 at 2:12

I think you hit the nail on the head with your comment about engineers vs. researchers (scientists). Science and engineering are different things and require different approaches to problems and problem-solving. Many universities' computer science programs are just that - science programs - but many students studying computer science actually want to be engineers. There's a big disconnection there to have to correct once a student becomes an employee.

Ok...why didn't they major in Computer engineering or software engineering then? – Pemdas Feb 17 '11 at 18:33
@Pemdas, maybe the school doesn't offer such a program? My university didn't. – Carl Norum Feb 17 '11 at 18:34 go to a different school. – Pemdas Feb 17 '11 at 18:36
@Pemdas, that's not practical or possible for a large number of people. It certainly wasn't a practical option for me - I managed to split the difference by getting bachelor's degrees in both EE and in CS, but explaining to students that's what they need to do is an education problem in and of itself. – Carl Norum Feb 17 '11 at 18:37
@Pemdas, they shouldn't - but they should explain to their students what they're going to teach, and especially explain to them that it's not an engineering program, so that students can make an informed decision. – Carl Norum Feb 17 '11 at 18:44

I would have to say one weakness is being able to pull requirements for a given task. In the academic world, your requirements are typically given to you in the form of a project that says it must do x,y,z. (This is geared more toward SW Engineers than Researchers)

No kidding. I'd love for universities to prepare students for the real world by giving vague or contradictory requirements on assignments and making them negotiate them out. – JohnFx Feb 17 '11 at 19:44
What do you mean by "pull requirements"? I.e. ask for clarification if the spec is unclear in a place, or formulation of a sensible spec in the first place? (The irony here is that the "requirements" -- for me as a student -- of this answer are unclear....) – Billy ONeal Feb 18 '11 at 3:18

My experience is that schools tend toward one of two extremes: either "practical" or "theoretical".

The practical programs seem to concentrate on teaching the syntax of one language (with some luck, maybe two) they've decided are important to industry. Most of what the students seem to have done is basically just take neat, simple, mostly meaningless descriptions of how to solve some particular problem, and translate the formula (or whatever) they've been given into the syntax of the target language.

The theoretical programs tend to go way too far to the opposite extreme. Many of the graduates can expound at length on the relationship between formal grammars and computability, or the precise difference between NP-hard and NP-complete -- but when it comes to writing code can't quite manage working code for a fizz-buzz program or (my usual test) a binary search.

Binary search... hmmm... isn't that the algorithm that's simple in concept but took almost 20 years before someone wrote a bug free version of it? :) +1 – Billy ONeal Feb 18 '11 at 3:05
@Billy ONeal: IMO, no -- that was just somebody trying generate a bit of blog traffic with a (mostly nonsensical) claim of "I'm right and Knuth was wrong!" :-) Truthfully, I don't demand anything close to perfection though -- but it would be nice if they could figure out a few pieces of it without my telling them... – Jerry Coffin Feb 18 '11 at 3:19
@Jerry: I don't mean that more recent case. I mean the time between the first conception of the algorithm and when Knuth published it -- that is, from the early 60s to mid 80s, not from mid 80s till that recent blog post (which I cannot seem to find right now). Anyway, my question really is, do you expect someone to rattle off a bug free implementation algorithm like that from memory? While I think everyone should at least understand how binary search works, I doubt many have ever implemented it seriously for any project simply because it comes with most every programming language (even C). – Billy ONeal Feb 18 '11 at 3:25
@Jerry: My previous comment was before I saw your comment was edited :) – Billy ONeal Feb 18 '11 at 3:29
Sorry for the triple comment -- found what I was looking for: -> "According to Knuth, the first binary search algorithm was published in 1946, but the first published binary search without bugs did not appear until 1962." – Billy ONeal Feb 18 '11 at 3:31

1 - Presentation/Communication skills totally absent.

2 - The woeful lack of teamwork experience. In that, they don't have a grasp on how important it is that their work has to fit in with the other team members work.

Agree with #2 completely, thankfully some professors (with real world experience) make you do team projects. Sadly I think #1 is more so the people that are attracted to CS than the actual degree itself. – Woot4Moo Feb 17 '11 at 18:59
@Woot4Moo: Speaking as a current student, I HATE that professors make you do team projects. I agree that programmers need to know how to work in teams. The difference is that in the working world, if a team member isn't doing any work, you can fire them. In the academic world, the only thing those who actually care about the assignment can do (and often that only person who actually cares is yours truly) is do the work of the group member(s) who don't participate. At work I work on teams all the time, and it's great. In class though, it's the pits. – Billy ONeal Feb 18 '11 at 3:39
@Billy ONeal: Agreed.... team projects at university were the pits, because most people were lazy and few spoke English properly. Apologies to anyone I might offend with that comment, but that was how I experienced it. – sevenseacat Feb 18 '11 at 4:17
@Billy Very true, the only time I have really seen it be an issue though is when everyone receives the same grade regardless of whom put in the work. – Woot4Moo Feb 18 '11 at 14:23
@Woot4Moo: What team projects have you ever worked on which were not that way? How does one grade team members separately if they're all working on a single product? – Billy ONeal Feb 18 '11 at 16:01

Actual experience working with other developer's code in realistic applications not just toy programs. They have to realize they can't always write everything from scratch and their code style is not the end all be all (Sadly, I thought this way coming out of college; egos are a double edged sword.)


Assignments and projects at most schools are limited to building new stuff from scratch (sometimes using an API).

As a result, most graduates come out with no idea of how to deal with a real-world messy codebase, and fine the locations to make changes without bringing the whole thing toppling down.

Unfortunately, most entry level folks are assigned to maintenance tasks that nobody else wants, and which depend exactly on this skill.

Maintenance is a unique skill. Some people will never be able to do it. It is not easy to understand someone else's thinking and put all the pieces together. OTOH, creating good designs is also a unique skill that many people will never be able to do. I can certainly see how a university class can attempt to teach software design. It is much harder to see how to teach code maintenance skills other than a few practical tips. – Dunk Feb 18 '11 at 17:37

The general consensus here is that CS should be a training ground for software engineering. I don't believe that is the direction that CS should take. What a lot of you are failing to realize is that academia is recognizing that there is disconnect between the goals of many student going into CS and what they want to do for careers. Software engineering programs are popping up all over the country they just don't quite have the necessary penetration to be as widely available as CS yet. It will get there. The real question is not how can we change CS. The real question is how do we increase the growth and availability of software engineering programs.

Speaking as someone in an almost completely computer science-y type of program, I think most of the computer science things I've learned have proven useful at my job, which is almost completely software engineering based. I think the only way you can really be decent at software engineering is to practice. A lot. And have your designs bite you a few times, until you can see how to make something flexible yet still applicable to your problem domain. – Billy ONeal Feb 18 '11 at 3:10
I agree, that the "engineering" in software engineering needs to be emphasized. What worries me in the SE I've seen is that it's just watered-down CS. Just learn some programming, how to use databases, write some web stuff, and maybe a little project management thrown in. What I don't see is careful problem solving, based on quantitative math analysis, considering alternative approaches, balancing pros and cons. Rather it's just one-size-fits-all technical skills, like how-to-weld-metal vs mechanical engineering. – Mike Dunlavey Feb 18 '11 at 14:10

IMHO, the main weakness is the lack of project management skills. Computer science students get many technical disciplines but few or none knowledge on management.

right...but this is covered in most software engineering programs. – Pemdas Feb 17 '11 at 18:34
@Pemdas: What are these "software engineering programs" of which you speak? ;) – Billy ONeal Feb 18 '11 at 3:46
@Billy ONeal: I can't tell if you're being fastidious or not so.... actual degrees in software engineering, instead of computer science. – sevenseacat Feb 18 '11 at 4:15
@Karpie: Yes, I was being sarcastic -- that's what the ;) was supposed to indicate. Seriously though, at least at the more "upper echelon" schools, I don't think software engineering is offered all that often. (Perhaps as a single class, like it is here at Case Western). – Billy ONeal Feb 18 '11 at 4:17
@Billy ONeal: Ah, see over here it's a whole separate culture - my CS course was three years with no work placements, a standard SE course is four years including work placements, and there were exactly two classes overlapping between the two (one on ethics, and one on requirements gathering that all the CS students pretty much ignored because it was just so very different than the rest of our classes.) – sevenseacat Feb 18 '11 at 4:19

I think most CS student come out of college thinking that they are going to sit down at some company and start writing massive amounts of code. In reality most entry level programming jobs are horribly tedious (writing reports, fixing bugs the other more senior guys don't feel like fixing), and doing grunt work. They also have little to no idea what it means to write software for a set of users that have specific needs. They are often bored to tears sitting in requirements meetings and spending time talking about what the system requirements are. I know when I came out of school I thought I was hot stuff and could do anything; my first job after college was writing basic database queries and doing data comparisons. The senior guys let me tag along to the requirements meetings and I eventually got more responsibility. I think that CS programs should have some sort of project creation class. The students should get a set of requirements and work in a team to figure out how to solve the problem at hand under a deadline. That's what the real world is like, not perfecting your Radix Sort.

We actually had that class. We submitted project ideas, voted for which ones we'd like to contribute to, and then implemented them and presented them at the end of the quarter. We did a browser-based text MMO role playing game, using an open source engine. – Ethel Evans Feb 17 '11 at 18:36
Hmm in my experience these things are more directed towards IS/IT degrees, which thankfully my university offered to help support CS – Woot4Moo Feb 17 '11 at 19:03
Yes, over here those sorts of things are more classified as software engineering, not computer science. – sevenseacat Feb 18 '11 at 4:13
Yeah, I feel like most programmers would probably benefit more from software engineering classes rather than the hardcore CS classes. – Nodey The Node Guy Feb 20 '11 at 20:57

What is the biggest weakness of students graduating with degrees in Computer Science?

  • Many (but not all, and not necessarily most) new hire CS majors graduate with the belief that they either have learned or can learn all that they need to know in the classroom.

  • Many (but not all) later learn that a successful practitioner must be a voracious autodidact.

You could've just putted "self-learner"? – Rook Feb 18 '11 at 2:03

Problem solving

Most new grads I have worked with don't really know how to go about figuring out the best way to actually solve the problem. They can run circles around some of us doing pattern and factory, but when they get to the bottom of that mess and try to actually write the code that does something useful they are often awkward at best.

+1 Problem solving. IMHO, that equals experience. – Rook Feb 18 '11 at 2:07
Valid point, but more what I had in mind was all the grads that you see that if you ask to do something like write a factorial function just have no idea where to begin – Bill Feb 18 '11 at 15:14

design patterns and other maintenance techniques.

Students have no reason to write code for reuse. They know anything they write only has to work for a semester at most (99% of my programs only had to work once at the end of the week).

The result is poorly documented, poorly designed code hacked together to work that one time the TA runs it.

+1 -- this is 100% true. I know a lot of the code I turn in for assignments is poor because I turn in the first prototype -- I have no reason to make the design maintainable because I'll never have to look at the code again. Of course, most code I write for PreEmptive and for myself I write much differently. – Billy ONeal Feb 18 '11 at 3:11

Just addressing this part of the question

... and one about the weaknesses of new researchers

My view is that a graduate (with a regular Bachelors degree) should not be expected to function as a researcher. The entry qualification for a researcher is a PhD ... or maybe a Masters by thesis / MPhil.

(Of course, it does depend on what is meant by "researcher". To some people, a researcher is someone who can do a Google search. I'm talking about someone who can do work that would be accepted for publication in a peer-reviewed academic publication.)

I agree, except as an on-again-off-again researcher myself, it seems to me that a lot of what gets published as research is just summarizing what other people have done, or navel-gazing, as if practicality were someone else's problem. (How many papers are titled "Toward XYZ"?) The job is to puff up the publication list, by cranking out me-too vacuous papers with lots of co-authors, because you can't get tenure without it. – Mike Dunlavey Feb 18 '11 at 2:20
Thank you for addressing the research side of the question. It seems everyone here is more concerned with the software engineering aspect... – akobre01 Feb 18 '11 at 5:40

I'm a professor of Computer Science at a reasonable place (top 40 PhD-granting institution, if US News and World Report rankings mean anything).

Your question is one that CS departments are constantly asking themselves. In fact, it's essential to the vitality of a department that we are constantly assessing ourselves. Departments that do not, risk becoming irrelevant.

Unfortunately, there's no one answer (as many respondents have already mentioned). Some students say we teach too much theory, others say it's not enough. Some students say they wanted to learn language X or skillset Y. We of course can't do it all, although sometimes we try (often with a poor outcome).

What should be taught (which indirectly answers your question about "what was left out") depends on what the student wants to do after graduation. If the student goes on to grad school, he/she needs a solid foundation in theoretical material (formal programming languages, algorithms, operating system models, automata). If instead he/she wants to become a production coder then it's better to do a lot of big software projects mixing a wide cross-section of technologies. Obviously, computer scientists who want to become managers, marketers, sales people, journalists, or entrepreneurs might wish they had had an entirely different set of skills.

Even within the relatively narrow job category of "production coder" sought after skillsets can vary: Google often doesn't care if you know any particular language... they just want to see top-level problem-solving skills and a solid understanding of data structures and algorithms. Other jobs often list particular technologies a candidate must have mastered ("looking for someone with 5 yrs experience in MIPS assembly, CSS, Erlang and NTL"... gah!)

The best we can do is to offer "tracks" that allows a student some degree of specialization within the major. My instituation has 5 tracks, ranging from mainstream (like "software engineering") to somewhat fringe ("health informatics"). We will continue to add to the list provided we have the resources and expertise, but the only guarantee is this: there will always be something missing.

@user17626: I think the best you can do in these cases is, rather than provide "tracks", teach those skills which aren't really tied to a problem domain. Yes, the average production coder might not be messing with automata every day, but when a solution like that is required, that production coder had better be able to come up with a solution (with the fact in mind that that production coder has Google available to look up theory on these things). Sure, a researcher needs more of this theory, but even researchers usually need to be highly advanced only in their specific problem domain. – Billy ONeal Feb 18 '11 at 3:46

Easy: they can't write. At least in US programs, most students earning technical degrees have never been asked to write more than a few sentences on any technical topic. By the time they graduate, what they may have learned from their humanities classes is long forgotten—and often doesn't transfer well to technical situations anyway.

As has been known since Dijkstra's days, writing is the forgotten skill for programmers.

I hadn't thought about this until you brought it up, but, now that I think about it, I believe you are absolutely right. In my undergraduate curriculum, I was never really asked to write anything serious and because of that, I have been totally unprepared for publishing my work or even writing detailed analyses/explanations of it. – akobre01 Feb 20 '11 at 3:46

This is more general, and not just about CS. Applies to engineering as well.

One of the biggest weaknesses I find in new graduates is that they have not sufficiently encountered "Murphy's law". They assume too many things (this includes the latest coding methodology fad) will work. Sometimes it all does... for the lucky ones.

The others need to learn the various ways to dig a project out the holes into which they fall. This requires broader, often interdisciplinary, problem solving skills often seen more in students who do a lot of side projects than in those who just ace theoretical coursework. Or in students who take courses similar to robotics contests, etc.


I probably interview 30 people for every one I hire. I find most people with "CS" degrees are sorely lacking in math skills. Basic calculus and statistics skills are notably absent. Most people are mystified by freshmen level math questions.

I was expecting some answers like this! Actually, I thought about this question coming out of an inference theory course. The class is extremely relevant to my work as a "computer scientist" (whatever that means) however a lot of the material is extremely difficult for me. I was wondering whether or not my undergraduate curriculum should have prepared me better or if it really wasn't in the scope of the CS major...(and yes with more math/proof/probability/statistics I would have been much better prepared for this course...) – akobre01 Feb 18 '11 at 4:43
@ראובן: Couple reasons for this. First, CS students see that Mathematica does everything they're ever going to learn in college math, and said students are quickly disillusioned with the math department. It's simply being pragmatic; if someone's already done it, and it's not associated with your intended problem domain, why spend the time learning all of it? Unfortunately, useful things for CS like sums and series are usually buried in the crufty corners of math departments and take a back seat to calculus related analysis, which I can say I've never used in programming whatsoever. – Billy ONeal Feb 18 '11 at 16:39
I can do calc just fine with wolframalpha. – Ape-inago Mar 23 '11 at 11:34

I interview a fair number of new CS graduates, mostly MSCS, from local UT branch campuses. I have just a few requirements for candidates:

  1. Knowledge of basic data structures. Sadly, most candidates are unable to tell me the difference between a tree and a map.

  2. Basic ability to program. They have to be able to write two nested loops at the whiteboard. Most are unable to do this, and consequently would be worse than useless on a development project.

  3. Ability to discuss some work they have done. If it's on the resume, I expect the candidate to be able to say something about it. Usually I'm disappointed. I interviewed a prospective PhD in Software Engineering who had nothing to say when I asked her "What is software quality?" A new MSCS listed work involving linear programming, but described a linear program as "it's when you have more equations than variables".

  4. Some opinion about the systems and languages they have used. Mostly I just get the most trivial responses, e.g. "Java is good because it has garbage collection."

I attribute this to these factors:

  1. An MSCS is the easiest ticket to a green card. Other engineering programs require calculus.

  2. Actually programming pays more than teaching CS at public universities.

  3. The universities are making money on the students. They have no reason to make the programs so rigorous that some students can't complete it. The students would take their money and get the degree from another school.

Java is good because it has minecraft. – Ape-inago Mar 23 '11 at 11:38

There are a couple of technical things that I think are generally lacking on most courses and they are very practical in nature. They are a lack of source control and delivering software.

In my experience and from talking to people who have done software engineering courses students tend not to get pushed to use source control (like svn, git or whatever). This is a massive fail because it ought to be something that is simply done from day 1 as part of the day to day admin of being a programmer. If it was taught at Uni from the start as a requirement the programmers coming out would already know the pro's and con's of what to store and how to handle their source code for releases by the time they come to business. Right now it's frustrating how much time you need to spend teaching each new graduate simply how to use source control, never mind the why's and the good practices. That's not to say universities don't mention source control. They just tend to leave it as a footnote on the course rather than treat it as a basic skill that needs to be used on a regular basis.

The other problem is that students don't tend to get rewarded enough for delivering software correctly. Installers and deployment may again be mentioned but they are likely to get even less attention than source control. Most software is provided to lecturers for testing is hard to deploy on a different machine. There is often not much priority placed on whether the software actually works. Delivering software so that it can be deployed quickly and simply and producing regular releases that work would make for much more useful practices. Right now most graduates come away with the standard practice of working on the features until the last minute and then assuming they'll have time to cobble it together again on the lecturers machine when it comes to demo it.

I personally think that a lot of universities do a good job in their general curriculum and that it's the more mundane stuff that they could do with getting the students to do, simply as part of the existing work they are doing.

Source control and deployment are specific to products. Teaching to a product would be more akin to teaching a trade. I don't believe universities should be teaching trade skills, they should teach concepts and theory. They should certainly talk about source control and deployment but why should they learn git or svn specifically. Odds are that specific knowledge will be pretty useless to them on their new job. Let's see you apply your git/svn knowledge to Clearcase or Synergy. What is the point of putting your homework assignment that you'll never need again into source control? – Dunk Feb 18 '11 at 18:03

Real life practice

I am a computer science student, with a lot of knowledge and practice the average student doesn't have (and probably never will during the study). I was actually programming long before getting into uni and I am additionally also working as a software developer.

Looking at my courses in uni, I notice one thing that is really missing: Real life practice. I mean the way you actually will work later when working in a team etc. We had a practical course last year (a software practical course) in which we were supposed to work with a group of 8 people on an actual software project; completely from zero to the final project. Within three weeks we were supposed to build up a small software starting with complete code-less planning in UML. So we had to start with creating use case diagrams then activity diagrams, then later class diagrams and sequence diagrams without having written a single line of code. Not only that but we were supposed to ignore any code- or language-related design decisions during that phase. So we had to create class diagrams with multiple inheritance for example just to completely rework that later when actually starting to program in Java.

While I don't disagree with the need of some planning before writing a software, I did have a problem with the way we were forced to do things in a simple waterfall model, and a time schedule that left us 5 days to actually write the code with only 3 of 8 people being able to program good enough to progress. From my personal experience, this is just not the way software development works these days; and I think it is sad that there is such a requirement to that old way of developing software.

That is just one example where the actual real life practice is missing. I have heard professors tell us that things are supposed to work like this and that later in “real business” with hundreds of developers on a single big projects, accompanied with a comment if that is actually possible and that he could never imagine to work in such a situation himself. If they don't know how things actually are, then they shouldn't try to teach us the things the way they believe it is, especially on practical topics like software development.

I know the Agile community is very vocal nowadays, but you'll find that the waterfall model (and variations) are still very prevalent in industry. The main reason being that it is the easiest approach to manage and for customer oversight. Also, if you can do waterfall well, which most people are woefully incapable, then you can do any methodology. The converse is absolutely not true. – Dunk Feb 18 '11 at 17:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.