Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-08-22T01:49:20.793Z
Answers.Text: All these good qualities are hard to evaluate during an interview.
Answers.UserDisplayName: Qiulang 邱朗
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:49:45.160Z
Answers.Text: 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.
Answers.UserDisplayName: Dunk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T16:02:35.813Z
Answers.Text: @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.
Answers.UserDisplayName: enderland
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T16:42:15.230Z
Answers.Text: 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.
Answers.UserDisplayName: Dunk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T17:11:11.290Z
Answers.Text: @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_.
Answers.UserDisplayName: enderland
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T21:19:16.403Z
Answers.Text: 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.
Answers.UserDisplayName: Oleg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T21:24:09.973Z
Answers.Text: @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.
Answers.UserDisplayName: Dunk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:12:29.803Z
Answers.LastActivityDate: 2017-09-11T18:06:51.917Z
Answers.LastEditDate: 2017-09-11T18:06:51.917Z
Answers.UserDisplayName: enderland
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T14:01:05.463Z
Answers.LastActivityDate: 2017-09-11T14:10:02.343Z
Answers.LastEditDate: 2017-09-11T14:10:02.343Z
Answers.UserDisplayName: techturbulence
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T18:43:24.403Z
Answers.Text: 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.
Answers.UserDisplayName: axwr
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T17:57:33.847Z
Answers.LastActivityDate: 2017-09-11T17:57:33.847Z
Answers.UserDisplayName: Kevin Workman
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:47:19.023Z
Answers.Text: 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?
Answers.UserDisplayName: Dunk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:52:21.547Z
Answers.Text: 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.
Answers.UserDisplayName: kingfrito_5005
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T13:22:13.923Z
Answers.LastActivityDate: 2017-09-11T13:22:13.923Z
Answers.LastEditDate: 2020-06-18T08:36:57.023Z
Answers.UserDisplayName: Robert Columbia
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-12T15:54:29.283Z
Answers.LastActivityDate: 2017-09-12T15:54:29.283Z
Answers.UserDisplayName: Jared Smith
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T20:35:58.833Z
Answers.LastActivityDate: 2017-09-10T21:45:03.363Z
Answers.LastEditDate: 2017-09-10T21:45:03.363Z
Answers.UserDisplayName: axwr
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T14:30:11.603Z
Answers.LastActivityDate: 2017-09-11T14:30:11.603Z
Answers.UserDisplayName: Robert Fisher
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T18:40:30.843Z
Answers.LastActivityDate: 2017-09-11T18:40:30.843Z
Answers.UserDisplayName: ChrisLively
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:50:58.123Z
Answers.LastActivityDate: 2017-09-11T15:50:58.123Z
Answers.UserDisplayName: kingfrito_5005
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T13:37:30.637Z
Answers.LastActivityDate: 2017-09-11T13:37:30.637Z
Answers.UserDisplayName: HaemEternal
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-12T14:58:24.733Z
Answers.LastActivityDate: 2017-09-12T14:58:24.733Z
Answers.UserDisplayName: Michael Platt
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T19:42:33.257Z
Answers.LastActivityDate: 2017-09-11T19:42:33.257Z
Answers.UserDisplayName: AnoE
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T00:42:02.133Z
Answers.Text: 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.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:26:56.233Z
Answers.Text: 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.
Answers.UserDisplayName: T.E.D.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T23:03:39.873Z
Answers.LastActivityDate: 2017-09-10T23:03:39.873Z
Answers.UserDisplayName: Michael Kay
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T16:13:13.367Z
Answers.Text: 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.
Answers.UserDisplayName: littleO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T17:20:50.010Z
Answers.Text: "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.
Answers.UserDisplayName: Voo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T17:55:53.960Z
Answers.Text: `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.
Answers.UserDisplayName: enderland
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T18:15:21.247Z
Answers.Text: 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.
Answers.UserDisplayName: E.D.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T18:19:14.467Z
Answers.Text: @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.
Answers.UserDisplayName: J...
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T21:28:10.817Z
Answers.Text: 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.
Answers.UserDisplayName: Oleg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T12:33:28.800Z
Answers.LastActivityDate: 2017-09-11T18:16:00.403Z
Answers.LastEditDate: 2017-09-11T18:16:00.403Z
Answers.UserDisplayName: J...
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T16:16:37.523Z
Answers.Text: 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).
Answers.UserDisplayName: Oleg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T17:36:29.417Z
Answers.Text: 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.
Answers.UserDisplayName: Oleg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T17:48:26.537Z
Answers.Text: @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!
Answers.UserDisplayName: alephzero
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T17:52:07.873Z
Answers.Text: 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!
Answers.UserDisplayName: alephzero
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T19:21:05.993Z
Answers.Text: @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.
Answers.UserDisplayName: Prime
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T08:11:14.437Z
Answers.Text: 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.
Answers.UserDisplayName: l0b0
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T08:14:15.423Z
Answers.Text: To comment on git see https://cseducators.stackexchange.com/questions/2897/how-to-make-git-easy-to-learn
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T08:14:47.517Z
Answers.Text: @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.
Answers.UserDisplayName: anaximander
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T10:47:13.040Z
Answers.Text: @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.
Answers.UserDisplayName: Oleg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T11:03:32.320Z
Answers.Text: @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.
Answers.UserDisplayName: anaximander
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T15:06:20.277Z
Answers.LastActivityDate: 2017-09-12T19:16:21.873Z
Answers.LastEditDate: 2020-06-18T08:36:57.023Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T17:33:26.387Z
Answers.Text: 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).
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T18:10:32.563Z
Answers.Text: 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."
Answers.UserDisplayName: EvSunWoodard
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T23:22:13.800Z
Answers.Text: "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).
Answers.UserDisplayName: Jules
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T18:01:21.330Z
Answers.LastActivityDate: 2017-09-10T20:10:15.477Z
Answers.LastEditDate: 2017-09-10T20:10:15.477Z
Answers.UserDisplayName: Dan Mills
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T08:13:41.603Z
Answers.Text: 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.
Answers.UserDisplayName: l0b0
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T10:16:03.920Z
Answers.Text: 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.
Answers.UserDisplayName: Sean Houlihane
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-11T15:34:48.883Z
Answers.Text: 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?
Answers.UserDisplayName: Dunk
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-12T22:28:20.990Z
Answers.Text: @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).
Answers.UserDisplayName: nova
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-10T15:18:49.580Z
Answers.LastActivityDate: 2017-09-10T15:18:49.580Z
Answers.UserDisplayName: Ben I.
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-10T20:45:42.263Z
Comments.Text: "Typical" in which country?
Comments.UserDisplayName: Andrea Lazzarotto
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-10T22:51:36.270Z
Comments.Text: I just addressed location, I hope.
Comments.UserDisplayName: Buffy
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-11T02:56:39.690Z
Comments.Text: Its too vague is what it is.
Comments.UserDisplayName: Jay
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-11T10:08:55.643Z
Comments.Text: 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'.
Comments.UserDisplayName: Sean Houlihane
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-11T15:49:13.683Z
Comments.Text: 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.
Comments.UserDisplayName: Džuris
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-11T15:52:55.837Z
Comments.Text: 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.
Comments.UserDisplayName: Džuris
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-11T23:16:03.390Z
Comments.Text: @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.
Comments.UserDisplayName: Jules
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-12T02:01:24.553Z
Comments.Text: @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.
Comments.UserDisplayName: Oleg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-12T02:06:27.223Z
Comments.Text: @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?
Comments.UserDisplayName: Oleg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-12T15:46:33.393Z
Comments.Text: 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.
Comments.UserDisplayName: stannius
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-12T15:58:36.110Z
Comments.Text: 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!
Comments.UserDisplayName: neminem
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-09-12T17:13:13.627Z
Comments.Text: 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).
Comments.UserDisplayName: thesecretmaster
Tags: <undergraduate><self-learning>
Title: What does a person with an undergraduate degree in CS still need to learn to be employable as a developer?
ThreadText: # 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**: @username_3 - 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-username_36-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.
  
  
  ---
  
  