What basic knowledge can I expect recent CS graduates to be competent in?

I have found myself in a team lead position having to manage/guide recent CS grads. I myself do not have a degree in Computer Science, rather I was working as a programmer to put myself through school while studying linguistics. I'm finding that using my own background to set expectations for junior developers quite problematic. I would like to guide them into developing as programmers, but I'm concerned that I can't quite connect because I have been mainly self-taught from a young age and a lot of things seem obvious to me.

I have been expecting new graduates to know:

• The general practice of using a source control / versioning system (not a specific one)
• Basic database theory - normalization vs. denormalization (pros and cons)
• The software life cycle
• Basic QA theory - blackbox testing, unit tests, builds systems
• Basic OOP principles
• Code formatting best practices (non-specific)
• A knowledge of a few design patterns
• Operating system knowledge - specifically Linux

I consider the above to be the bread and butter of our industry. However, everyone's list will vary.

When I got my start in the industry, I was thrown in the deep end and had to spend many nights studying above and beyond my college homework and my paid hours. Is it reasonable to expect the same level of effort from junior coworkers? Am I just full of it and venting frustration? I can't tell. I just notice a significant disconnect as an entirely self-taught developer. I keep telling myself - "I knew this at their age and I didn't have a degree in CS!" and I wonder if I have some sort of inferiority complex. I wish I had the benchmark of going through a CS degree program, so that I could set more reasonable expectations. Can anyone enlighten me on their experiences guiding juniors into productive members of their teams?

Another worthwhile thing to note is that I'm from the USA and that I'm not in the USA.

From stackoverflow

• The important thing to remember is that computer science isn't software engineering. Out of your list, I would classify these as computer science:

  • Database theory
  • OOP principals
  • Design patterns

  I'd classify these as software engineering:

  • Source control/versioning
  • QA
  • Code formatting
  • Software life cycle

  I'm not sure where "operating system knowledge" fits in - the core theoretical stuff is part of computer science, but sed/grep/awk/etc aren't really. I'd expect CS graduates to usually know them anyway, but probably not due to the course itself.

  It's hard to judge whether or not you're viewing your colleagues too harshly without knowing details, but it does seem that you're polarizing your view through a "with/without CS degree" lens, which may not be helpful in the long run. Where you see gaps in their knowledge and experience, try to mentor them, and in turn try to spot areas where you can benefit from their CS knowledge.

  User : I would clearly put Database theory, OOP principals and Design patterns into the software engineering bowl. Especially in the latter two there is not much "science" involved, these are rather "best practices".

  Jon Skeet : Possibly - possibly not. I think there's room for looking at design patterns and OO principles with a scientific eye. Database theory is *definitely* CS in my view.

  nickohrn : Agreed that database theory is CS, but I just graduated and most CS majors didn't know design patterns. (Neither did the SEs for that matter... lack of intellectual curiosity, I think).

  Jon Skeet : The whole of CS is too much to cover in a single degree :) I would still include some aspects of design patterns as CS, but it's definitely a grey area.

  dotnetdev : Unfortunately a comp sci degree teaches the basics of programming/computers (I know comp sci isn't just about programming). As a result, though, things like design patterns which are for when you are a little more experienced, are skipped. Just my 2p from when I was at uni.

  Jon Skeet : @GSS: It's *bound* to depend on the course/university.

• I'd say what you knew at a certain point in your life, is irrelevant. Why are you even comparing the juniors to yourself? What good/constructive conclusions can made from that? You'll end up feeling either inferior, or superior to them. Both of which are part of a bad attitude at a workplace IMO.

  I would just accept the team that I have, and try to make the best of it. Working out constructive ways on how to improve their weaker sides.

  The general practice of using a source control / versioning system, for example, shouldn't really take more than a couple of workshops to get everyone up to speed on.

  This also gives you more control, and assurance that everyone knows this stuff, instead of having to rely on them studying stuff on their own time, and getting disappointed when some fail to do so.

  Elijah : Thank you for your comment. I agree you with the attitude bit - I guess my question was in a way me seeing a need for change.

• Agree with Jon Skeet in difference between software engineering and CompSci

  Out of your list, I would classify these as computer science:
  
      * Database theory
      * OOP principals
      * Design patterns
  
  I'd classify these as software engineering:
  
      * Source control/versioning
      * QA
      * Code formatting
      * Software life cycle

  On to that I would add you can't hire grad's for there knowledge, you need to hire them for their ability to learn. My first job was in a langauge I had never herd of against a database I had never herd of, putting out web pages which I had never done. Yet I was a good hire and got a lot of good work done.

  So assume lots of intelligence and no knowledge, and your team will go places.

  Nifle : +1 for "can't hire grad's for there knowledge, you need to hire them for their ability to learn"

• I think you need to lower your expectations. In particular, I haven't run into many CS graduates who know anything about version control.

  Watch out for candidates who pass off class assignments as real projects. I remember, for example, someone who put on their resume that they had developed a hotel reservation system. Turns out it was some dinky homework assignment.

  I would assign a mentor to every new hire. I've heard that Microsoft does this. The new hire and the mentor read every line of code that each other write. Maybe even do some pair programming.

• I think that you are expecting competency at these described practices as opposed to just knowledge of them, which is what you gain at school. While at school you don’t work on massive programs that give the opportunity to really apply any of these techniques in enough great detail to master them. However, school does teach you enough to be able to grasp the concepts so that hopefully your learning curve in the real world is not too bad.

  School also teaches enough broad concepts so that you can more easily put all the pieces together which gives a better understanding of why. If you know the why's then you have a better chance of figuring solutions to problems that you never saw before.

  If you want someone to walk in right away and know all these things on day one then you needed to hire someone who worked as an intern/co-op while going to school. I don’t think that will give you a better developer 6 months from now, but on day one they will know more than someone who didn’t. This may meet your expectations better.

  The general practice of using a source control / versioning system (not a specific one)

  Source control is for keeping track of history. Not really needed in a school setting where the project is forever forgotten once it is turned in.

  Basic database theory - normalization vs. denormalization (pros and cons)

  You learn this if you take a database class. When I went to school this was an elective, not a requirement.

  The software life cycle

  They should generally know what this is, but each and every company puts this into practice different from each and every other company. Most companies prefer a blank slate anyways. That way they can teach their way. Besides, this is usually a single semester course. Thus, the size of project that is worked on in the course is fairly small. Thus, the real benefits of following the process are hard to grasp for the student. They’ll learn the benefits as they (or witness others) screw up on the job like everyone else did.

  Basic QA theory - blackbox testing, unit tests, builds systems

  Once again, this is very company specific. Teach it your company’s way. I suspect that you are expecting them to perform these tasks in more formalized ways. Not something that is done in school, but is trivial to teach on the job.

  Basic OOP principles

  While students may or may not learn OOP principles at school. Learning them well enough to apply them is a totally different discussion. That comes with experience and I know many people with years and years of programming experience in OO languages that still don’t quite get it.

  Code formatting best practices (non-specific)

  This is a religious argument. What looks good to one person does not to another. Teach them your way, that’s what you want anyways.

  A knowledge of a few design patterns

  Not having been to school in quite a while, I suspect this would be an elective course. Plus, learning to use them (or recognize them) in the real world is an acquired skill that takes many people years to learn.

  Operating system knowledge - specifically Linux

  Why should they know Linux? There are at least 100 predominant operating systems out there; you can’t possibly know them all.

  I’m not trying to make excuses for what may be lack of initiative, but if you expected these skills then you should have asked the questions at the interview prior to hiring. I personally think your expectations are not at all reasonable.

• You can expect recent CS grads to have heard of most of those things and to have some idea what they each mean. You should not expect recent grads to be highly trained in any of those areas - most CS degrees don't seem to think that those are things you'll pick up on the job. A good recent CS grad will be able to write code in some language (though not necessarily the one you use) to solve a problem (hopefully related to those you have).

  More than anything, expect them to be able, willing, and excited to learn. If they are, you can teach them anything. If not, don't expect them to provide much return on the investment of hiring them.

• I think that you can expect a CS graduate to have covered a lot of background theory as part of their degree, but probably not a lot of practical application of that theory.

  A CS course is likely to cover subjects such as:

  • Procedural programming and design
  • Object-oriented programming and design
  • Database design (e.g. ER analysis, data-flow, normalisation)
  • Software life-cycle
  • Usability and UI design
  • Software project management

  It might even cover things like:

  • Contract law
  • Ethics
  • Accounting
  • Web design
  • Electronics
  • Processor design

  It's unlikely however to cover the use of tools, operating systems or APIs that might be used in a commercial environment.

  A good CS course gives the graduate broad knowledge across a variety of computing topics. It is up to the company to mould, nurture and coach that employee into a software engineer with skills and experience specific to the industry and environment that the company is working in.

  Finally, a really good CS graduate will have already taken the knowledge their course has given them and begun to work it into specific skills - either through a challenging and interesting dissertation project or through projects they have done in their own time (or both). I always look for this in interviews - a good degree classification shows me the candidate is bright and can deal with a broad range of programming topics, a good dissertation project shows me they can apply that knowledge deeply to solve a real software engineering problem.

• I feel your pain man. I'm an Electrical Engineer but I have asked myself some of the same questions you have. The main issue is "Do you have a staff that is willing to get it done? Do THEY know what they need to get done?"

  As a manager of multiple teams, I remind my teams the things I learned along the way:

  1) Computer Science is just that ... Science. The day you stop learning is the last day your a scientist - Your a technician at that point and you shouldn't warrant such a salary.

  2) As a scientist, communication will be your hardest challenge. ((Most of your non-CS issues will be relate to that issue. The best geeks alive can also be the worst communicators))

  3) Projects are long, lessons are learned and forgot and relearned. We are not pro-athletes, we can't look at tape the next day and see what we did wrong. We have to look at the bug list 6 months - 1 year from now. (This communicates that this is a marathon not a sprint. Continually learning, forgetting, learning is the process - and that is okay)

  4) This IS a career you can not be in it for anything else then the pure enjoyment of it. No money or mission in the world will get you to continually learn this stuff to the level you must if this is truely your career path. (Hard to tell the staff but it wakes them up)

  I've always found that those that are given a mission they can get behind and well communicated expectations (project requirements, manager's expectations, self expectations) will come to work everyday and give it their all.. and isn't that all you can ask of anyone?

• I guess their knowledge of some given things is not as important as their intention to be good in what they know. Like they may not have experience with C++, but they wrote a distributed computation program in plain C as an assignment in the university and got practical knowledge of design and debugging. I would prefer such a hardcorer with little C++ experience to one who claims two years of C++ experience but can't explain why a memoty leak is bad.