<p>I've interviewed a ton of people fitting your criteria.</p>

<blockquote>
  <p>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? </p>
</blockquote>

<p>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. </p>

<p>I care if you can be a good <em>engineer</em>. 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. </p>

<p>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?</p>

<p>Do you take ownership for the code you write, knowing it may be in production for <em>years</em> or even <em>decades</em>? 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. </p>

<p>I could go on and on. But regardless: <strong>these</strong> types of skills are simply not taught by and large. </p>

<p><sub>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 <em>that</em> too...</sub></p>

CC BY-SA 4.0
2022-08-22T01:49:20.793Z
All these good qualities are hard to evaluate during an interview.
Qiulang 邱朗
CC BY-SA 3.0
2017-09-11T15:49:45.160Z
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
CC BY-SA 3.0
2017-09-11T16:02:35.813Z
@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
CC BY-SA 3.0
2017-09-11T16:42:15.230Z
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
CC BY-SA 3.0
2017-09-11T17:11:11.290Z
@Dunk why do you think I answered a question `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` with this list of questions then? What you just said _is entirely the point_.
enderland
CC BY-SA 3.0
2017-09-11T21:19:16.403Z
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
CC BY-SA 3.0
2017-09-11T21:24:09.973Z
@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
CC BY-SA 3.0
2017-09-11T15:12:29.803Z
2017-09-11T18:06:51.917Z
2017-09-11T18:06:51.917Z
enderland
<p><strong>Know your tools</strong></p>

<p>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.</p>

<p><strong>Know your source control</strong></p>

<p>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.</p>

<p><strong>Make sure you know the solution you're planning is the right one</strong></p>

<p>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 &amp; 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.</p>

CC BY-SA 3.0
2017-09-11T14:01:05.463Z
2017-09-11T14:10:02.343Z
2017-09-11T14:10:02.343Z
techturbulence
<p>New graduates don't need to be an expert in anything, but they need to be able to <strong>get stuff done</strong>.</p>

<p>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.</p>

<p>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? </p>

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

CC BY-SA 3.0
2017-09-11T18:43:24.403Z
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.
axwr
CC BY-SA 3.0
2017-09-11T17:57:33.847Z
2017-09-11T17:57:33.847Z
Kevin Workman
<h1>Source Control</h1>
<p>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.</p>

CC BY-SA 3.0
2017-09-11T15:47:19.023Z
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
CC BY-SA 3.0
2017-09-11T15:52:21.547Z
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
CC BY-SA 3.0
2017-09-11T13:22:13.923Z
2017-09-11T13:22:13.923Z
2020-06-18T08:36:57.023Z
Robert Columbia
<p>Hate to add yet another answer, but this <em>needs</em> to be said: there are three things that matter: how to communicate with people, how to communicate with people, and</p>

<h3>How to communicate with people.</h3>

<p>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 <em>hardware architecture</em> will change (away from Von Neumann to cellular automata et. al.).</p>

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

<p>You <em>will</em> have to deal with bosses and coworkers. You <em>may</em> also have to deal with vendors, clients, customers, direct reports, and employees.</p>

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

<p>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".</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-12T15:54:29.283Z
2017-09-12T15:54:29.283Z
Jared Smith
<blockquote>
  <p>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?</p>
</blockquote>

<p>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.</p>

<p>However, to better answer the question from an educator's perspective: I think dealing with <em>mess</em> is under emphasized. A lot, and I mean <strong>a lot</strong> 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.</p>

CC BY-SA 3.0
2017-09-10T20:35:58.833Z
2017-09-10T21:45:03.363Z
2017-09-10T21:45:03.363Z
axwr
<p>This is my observations, for whatever they’re worth, from having interviewed a lot of recent graduates over many years.</p>

<p>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 <em>want</em> 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 <em>earns</em> the grade.</p>

<p>In my experience, whatever you want to do in the field, you’re best served by knowledge of <em>both</em> 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.</p>

<p>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.</p>

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

CC BY-SA 3.0
2017-09-11T14:30:11.603Z
2017-09-11T14:30:11.603Z
Robert Fisher
<p>A fundamental part of understanding software architecture is to understand how your target platform will shape design decisions.</p>

<p>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.  </p>

<p>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.  </p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T18:40:30.843Z
2017-09-11T18:40:30.843Z
ChrisLively
<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T15:50:58.123Z
2017-09-11T15:50:58.123Z
kingfrito_5005
<p>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)</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T13:37:30.637Z
2017-09-11T13:37:30.637Z
HaemEternal
<p>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 ;-)</p>

<h3>You learned how to learn, no program</h3>

<p>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.</p>

<h3>Debug, debug, and oh yeah...debug</h3>

<p>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.</p>

<h3>Work a little every night</h3>

<p>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.</p>

<h3>Work on personal projects</h3>

<p>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.</p>

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

CC BY-SA 3.0
2017-09-12T14:58:24.733Z
2017-09-12T14:58:24.733Z
Michael Platt
<p>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 <em>not</em> see teaching that as their task (rightly so, it is called <em>science</em> for a reason).</p>

<p>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.</p>

<p>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 <strike>answer in-depth questions</strike> 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...</p>

<p>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. ;)</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T19:42:33.257Z
2017-09-11T19:42:33.257Z
AnoE
<p>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.</p>

<p>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?</p>

<p>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?</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T00:42:02.133Z
This is an excellent answer that stems from a clear wealth of experience. Welcome to [cseducators.se]!  I hope we hear more from you in the future.
Ben I.
CC BY-SA 3.0
2017-09-11T15:26:56.233Z
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.
CC BY-SA 3.0
2017-09-10T23:03:39.873Z
2017-09-10T23:03:39.873Z
Michael Kay
<p>Students need to learn how to teach themselves.  These are the only ones that succeed.</p>

<p>Programming, more than other fields, requires students to <em>take responsibility for their own education</em> 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.</p>

CC BY-SA 3.0
2017-09-11T16:13:13.367Z
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
CC BY-SA 3.0
2017-09-11T17:20:50.010Z
"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
CC BY-SA 3.0
2017-09-11T17:55:53.960Z
`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
CC BY-SA 3.0
2017-09-11T18:15:21.247Z
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.
CC BY-SA 3.0
2017-09-11T18:19:14.467Z
@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...
CC BY-SA 3.0
2017-09-11T21:28:10.817Z
Your post applies to what somebody needs to do to become a *good* programmer. With the current supply and demand for programmers lots and lots of bad ones manage to find jobs and stay employed.
Oleg
CC BY-SA 3.0
2017-09-11T12:33:28.800Z
2017-09-11T18:16:00.403Z
2017-09-11T18:16:00.403Z
J...
<h1>To know that you know nothing.</h1>
<p>Recent graduates can be afflicted by arrogance or low self worth. These are two sides of the same problem.</p>
<p>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.</p>
<p>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.</p>
<h1>Experience</h1>
<p>I have heard many a new journeyman say “To get a job I need experience, but how do I get experience without a job?”.</p>
<p>So get experience: Find a good <a href="https://www.gnu.org/philosophy/free-sw.en.html" rel="noreferrer">Free Software</a> / <a href="https://opensource.org/osd-annotated" rel="noreferrer">Open Source</a> project, that you are interested in, and contribute to the project.</p>
<h1>Software engineering tools</h1>
<p>As well as testing (@BenI). Revision control: Learn how to use revision control tools, for example: mercurial (<code>hg</code>), <code>git</code>, subversion (<code>svn</code>).</p>
<p>Of these subversion is previous generation, but still has some use-cases that best suit it. It is still widely used.</p>
<p>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)).</p>

CC BY-SA 3.0
2017-09-10T16:16:37.523Z
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
CC BY-SA 3.0
2017-09-10T17:36:29.417Z
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](https://github.com/cjb/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
CC BY-SA 3.0
2017-09-10T17:48:26.537Z
@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
CC BY-SA 3.0
2017-09-10T17:52:07.873Z
The "low self worth" issue is usually curable, unless it's so severe the person is incapable of attempting to do anything at all. Unfortunately, "arrogance" usually isn't a treatable condition IMO - just filter it out in the recruitment procedure!
alephzero
CC BY-SA 3.0
2017-09-10T19:21:05.993Z
@alephzero I strongly agree regarding using git from the command line.  Regardless of if someone actually interacts with git regularly through the CLI knowing how your tools work under the hood is crucial to being an engineer.
Prime
CC BY-SA 3.0
2017-09-11T08:11:14.437Z
As someone who has used CVS, Subversion and Git I'd say **Git is only hard to learn if you already learned either of the other two.** Things with the same name mean different things, and Git contains concepts not found in the others because it embraces the inherent distributed nature of DVCS.
l0b0
CC BY-SA 3.0
2017-09-11T08:14:15.423Z
To comment on git see https://cseducators.stackexchange.com/questions/2897/how-to-make-git-easy-to-learn
ctrl-alt-delor
CC BY-SA 3.0
2017-09-11T08:14:47.517Z
@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
CC BY-SA 3.0
2017-09-11T10:47:13.040Z
@anaximander I strongly disagree, the question is about what graduates need to learn, with the current state of the industry knowing git is necessary mercurial much less so. The rest of your comment about "all tools" is preposterous ***nobody*** knows all the tools from [here](https://en.wikipedia.org/wiki/Comparison_of_version_control_software) and this is not a comprehensive list. By your definition "good software developers" don't exist and you will need an infinite(probably with higher cardinality than the people making those tools) amount of time to become one.
Oleg
CC BY-SA 3.0
2017-09-11T11:03:32.320Z
@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
CC BY-SA 3.0
2017-09-10T15:06:20.277Z
2017-09-12T19:16:21.873Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>I suspect that the lions share of new CS grads seek jobs in what is actually software engineering, a related but different field. </p>

<p>Things I see missing when I interview these people:</p>

<ul>
<li><strong>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.</strong> No point bigging up your knowledge we can always tell.</li>
<li>Testing, including the importance of automated regression testing. </li>
<li>The fact that requirements change under you.</li>
<li>Version control, I don't really care which one, but please have used something on a non toy project.</li>
<li>Some appreciation for project management, at least in terms of what input they need.</li>
<li>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? </li>
<li>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).</li>
<li>Build tools and an understanding of how they can be scripted. </li>
<li>An appreciation of when big O likely matters and when a bogosort is the right choice.    </li>
<li>An appreciation that it is <strong>Worst Case</strong> that really matters, not average case (This one may be specific to my hard realtime industry).</li>
<li>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). </li>
</ul>

<p>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. </p>

<p>One other note: <strong>Low level is good</strong>, 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.</p>

CC BY-SA 3.0
2017-09-11T17:33:26.387Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/65432/discussion-on-answer-by-dan-mills-what-does-a-person-with-an-undergraduate-degre).
Ben I.
CC BY-SA 3.0
2017-09-11T18:10:32.563Z
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
CC BY-SA 3.0
2017-09-11T23:22:13.800Z
"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
CC BY-SA 3.0
2017-09-10T18:01:21.330Z
2017-09-10T20:10:15.477Z
2017-09-10T20:10:15.477Z
Dan Mills
<p>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, <strong><em>"Test your code."</em></strong></p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T08:13:41.603Z
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
CC BY-SA 3.0
2017-09-11T10:16:03.920Z
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
CC BY-SA 3.0
2017-09-11T15:34:48.883Z
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
CC BY-SA 3.0
2017-09-12T22:28:20.990Z
@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
CC BY-SA 3.0
2017-09-10T15:18:49.580Z
2017-09-10T15:18:49.580Z
Ben I.
<p>Some recent CS graduates feel unprepared to enter the job market. Some may actually <em>be</em> unprepared. </p>

<ul>
<li><p>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? </p></li>
<li><p>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. </p></li>
</ul>

<p>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. </p>

<hr>

<p>I assume that no educational program can teach <em>everything</em>. 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. </p>

<hr>

<p>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. </p>

CC BY-SA 3.0
2017-09-10T20:45:42.263Z
"Typical" in which country?
Andrea Lazzarotto
CC BY-SA 3.0
2017-09-10T22:51:36.270Z
I just addressed location, I hope.
Buffy
CC BY-SA 3.0
2017-09-11T02:56:39.690Z
Its too vague is what it is.
Jay
CC BY-SA 3.0
2017-09-11T10:08:55.643Z
Not sure I really like the question as-is, but it may be relevant that post-degree employment in the UK seems spectacularly poor in CS (ref some research data from maybe 6 months ago). Supports the 'feeling unprepared'.
Sean Houlihane
CC BY-SA 3.0
2017-09-11T15:49:13.683Z
Some answers point out that programs might miss out on testing or source control. But even if the program includes these topics, some people (including some answerers here) will find the graduate unprepared. It's mostly because they don't understand that the education gives overview and general understanding but can't and won't teach every pecularity and nuance in the languages, development processes etc.
Džuris
CC BY-SA 3.0
2017-09-11T15:52:55.837Z
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
CC BY-SA 3.0
2017-09-11T23:16:03.390Z
@SeanHoulihane - indeed, I've often wondered about those statistics.  It seems very odd that a career-oriented degree in a field that is very much in-demand should have such a high graduate unemployment rate, particularly when you consider that in the US graduates in the same field have among the *lowest* unemployment rates.  There's something odd going on there, and I'm at a loss to explain it.
Jules
CC BY-SA 3.0
2017-09-12T02:01:24.553Z
@Džuris It's not that they don't understand what education supposedly gives, they are looking for people who genuinely love and are interested in programming. Asking them about nuances in languages is one way to find them.
Oleg
CC BY-SA 3.0
2017-09-12T02:06:27.223Z
@Jules It's the same thing in Israel. Graduates from top universities are recruited immediately because of their high potential, all the others struggle finding their first job. Seems very reasonable to me, nobody wants to invest a year until they will see anything resembling productivity from them. If anything it's odd that it's different in US maybe it's because of internship practices?
Oleg
CC BY-SA 3.0
2017-09-12T15:46:33.393Z
I can't speak to other countries, but here in the US it's assumed that a new CS grad isn't going to produce much for as much as the first year, and will require a lot of supervision to do so. I guess businesses just consider it a good way to get an employee relatively cheap - assuming they stay long enough for the investment to pay off.
stannius
CC BY-SA 3.0
2017-09-12T15:58:36.110Z
The biggest thing I didn't learn was how to *not* write it yourself. The biggest, most embarrassing thing I ever did my first week at work after graduating was writing a search algorithm from scratch, because I was treating the assignment like homework. We have a whole framework for that sort of thing, that does it way better than I would do myself, way quicker!
neminem
CC BY-SA 3.0
2017-09-12T17:13:13.627Z
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
<undergraduate><self-learning>
What does a person with an undergraduate degree in CS still need to learn to be employable as a developer?
# What does a person with an undergraduate degree in CS still need to learn to be employable as a developer?

(Asked by: username_0 on 2017-09-10)

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.

**Tags:** undergraduate, self-learning

> **Comments:**
> **username_1**: "Typical" in which country?  
> **username_0**: I just addressed location, I hope.  
> **username_2**: Its too vague is what it is.  
> **username_3**: Not sure I really like the question as-is, but it may be relevant that post-degree employment in the UK seems spectacularly poor in CS (ref some research data from maybe 6 months ago). Supports the 'feeling unprepared'.  
> **username_4**: Some answers point out that programs might miss out on testing or source control. But even if the program includes these topics, some people (including some answerers here) will find the graduate unprepared. It's mostly because they don't understand that the education gives overview and general understanding but can't and won't teach every pecularity and nuance in the languages, development processes etc.  
> **username_4**: 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.  
> **username_5**: @SeanHoulihane - indeed, I've often wondered about those statistics.  It seems very odd that a career-oriented degree in a field that is very much in-demand should have such a high graduate unemployment rate, particularly when you consider that in the US graduates in the same field have among the *lowest* unemployment rates.  There's something odd going on there, and I'm at a loss to explain it.  
> **username_6**: @username_4 It's not that they don't understand what education supposedly gives, they are looking for people who genuinely love and are interested in programming. Asking them about nuances in languages is one way to find them.  
> **username_6**: @username_5 It's the same thing in Israel. Graduates from top universities are recruited immediately because of their high potential, all the others struggle finding their first job. Seems very reasonable to me, nobody wants to invest a year until they will see anything resembling productivity from them. If anything it's odd that it's different in US maybe it's because of internship practices?  
> **username_7**: I can't speak to other countries, but here in the US it's assumed that a new CS grad isn't going to produce much for as much as the first year, and will require a lot of supervision to do so. I guess businesses just consider it a good way to get an employee relatively cheap - assuming they stay long enough for the investment to pay off.  
> **username_8**: The biggest thing I didn't learn was how to *not* write it yourself. The biggest, most embarrassing thing I ever did my first week at work after graduating was writing a search algorithm from scratch, because I was treating the assignment like homework. We have a whole framework for that sort of thing, that does it way better than I would do myself, way quicker!  
> **username_9**: 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).  

---

## 17 answers

### Answer by username_24 on 2017-09-10. Score: 17 | Accepted answer

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.

> **Comments:**
> **username_25**: This is an excellent answer that stems from a clear wealth of experience. Welcome to [cseducators.se]!  I hope we hear more from you in the future.  
> **username_26**: 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.  

---

### Answer by username_31 on 2017-09-10. Score: 35

# 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](https://www.gnu.org/philosophy/free-sw.en.html) / [Open Source](https://opensource.org/osd-annotated) 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)).

> **Comments:**
> **username_6**: 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).  
> **username_6**: 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](https://github.com/cjb/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.  
> **username_32**: @username_31 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!  
> **username_32**: The "low self worth" issue is usually curable, unless it's so severe the person is incapable of attempting to do anything at all. Unfortunately, "arrogance" usually isn't a treatable condition IMO - just filter it out in the recruitment procedure!  
> **username_33**: @username_32 I strongly agree regarding using git from the command line.  Regardless of if someone actually interacts with git regularly through the CLI knowing how your tools work under the hood is crucial to being an engineer.  
> **username_34**: As someone who has used CVS, Subversion and Git I'd say **Git is only hard to learn if you already learned either of the other two.** Things with the same name mean different things, and Git contains concepts not found in the others because it embraces the inherent distributed nature of DVCS.  
> **username_31**: To comment on git see https://cseducators.stackexchange.com/questions/2897/how-to-make-git-easy-to-learn  
> **username_35**: @username_6 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.  
> **username_6**: @username_35 I strongly disagree, the question is about what graduates need to learn, with the current state of the industry knowing git is necessary mercurial much less so. The rest of your comment about "all tools" is preposterous ***nobody*** knows all the tools from [here](https://en.wikipedia.org/wiki/Comparison_of_version_control_software) and this is not a comprehensive list. By your definition "good software developers" don't exist and you will need an infinite(probably with higher cardinality than the people making those tools) amount of time to become one.  
> **username_35**: @username_6 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.  

---

### Answer by username_36 on 2017-09-10. Score: 31

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:**
> **username_25**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/65432/discussion-on-answer-by-dan-mills-what-does-a-person-with-an-undergraduate-degre).  
> **username_37**: 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."  
> **username_5**: "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).  

---

### Answer by username_25 on 2017-09-10. Score: 14

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.

> **Comments:**
> **username_34**: 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.  
> **username_3**: 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.  
> **username_12**: 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?  
> **username_38**: @username_12 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).  

---

### Answer by username_27 on 2017-09-11. Score: 9

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.

> **Comments:**
> **username_28**: 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.  
> **username_29**: "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.  
> **username_10**: `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.  
> **username_30**: 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.  
> **username_27**: @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.  
> **username_6**: Your post applies to what somebody needs to do to become a *good* programmer. With the current supply and demand for programmers lots and lots of bad ones manage to find jobs and stay employed.  

---

### Answer by username_10 on 2017-09-11. Score: 8

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

> **Comments:**
> **username_12**: 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.  
> **username_10**: @username_12 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.  
> **username_12**: 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.  
> **username_10**: @username_12 why do you think I answered a question `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` with this list of questions then? What you just said _is entirely the point_.  
> **username_6**: 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.  
> **username_12**: @username_10 - 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.  
> **username_11**: All these good qualities are hard to evaluate during an interview.  

---

### Answer by username_13 on 2017-09-11. Score: 4

**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 by username_14 on 2017-09-11. Score: 4

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.

> **Comments:**
> **username_15**: 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.  

---

### Answer by username_16 on 2017-09-11. Score: 2

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

> **Comments:**
> **username_12**: 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?  
> **username_17**: 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.  

---

### Answer by username_18 on 2017-09-12. Score: 2

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 by username_15 on 2017-09-10. Score: 2

> 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 by username_19 on 2017-09-11. Score: 1

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 by username_20 on 2017-09-11. Score: 1

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 by username_17 on 2017-09-11. Score: 1

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 by username_22 on 2017-09-12. Score: 1

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 by username_23 on 2017-09-11. Score: 1

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 by username_21 on 2017-09-11. Score: 0

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.


---

