(Part 2) Best products from r/cscareerquestions

> I assume I ought to check it out after my discrete math class? Or does CLRS teach the proofs as if the reader has no background knowledge about proofs?

Sadly it does not teach proofs. You will need to substitute this on your own. You don't need deep proof knowledge, but just the ability to follow a proof, even if it means you have to sit there for 2-3 minutes on one sentence just to understand it (which becomes much easier as you do more of this).

> We didn't do proof by induction, though I have learned a small (very small) amount of it through reading a book called Essentials of Computer Programs by Haynes, Wand, and Friedman. But I don't really count that as "learning it," more so being exposed to the idea of it.

This is better than nothing, however I recommend you get very comfortable with it because it's a cornerstone of proofs. For example, can you prove that there are less than 2 ^ (h+1) nodes in any perfect binary tree of height h? Things like that.

> We did go over Delta Epsilon, but nothing in great detail (unless you count things like finding the delta or epsilon in a certain equation). If it helps give you a better understanding, the curriculum consisted of things like derivatives, integrals, optimization, related rates, rotating a graph around the x/y-axis or a line, linearization, Newton's Method, and a few others I'm forgetting right now. Though we never proved why any of it could work, we were just taught the material. Which I don't disagree with since, given the fact that it's a general Calc 1 course, so some if not most students aren't going to be using the proofs for such topics later in life.

That's okay, you will need to be able to do calculations too. There are people who spend all their time doing proofs and then for some odd reason can't even do basic integration. Being able to do both is important. Plus this knowledge will make dealing with other math concepts easier. It's good.

> I can completely understand that. I myself want to be as prepared as possible, even if it means going out and learning about proofs of Calc 1 topics if it helps me become a better computer scientist. I just hope that's a last resort, and my uni can at least provide foundation for such areas.

In my honest opinion, a lot of people put too much weight on calculus. Computer science is very much in line with discrete math. The areas where it gets more 'real numbery' is when you get into numerical methods, machine learning, graphics, etc. Anything related to theory of computation will probably be discrete math. If your goal is to get good at data structures and algorithms, most of your time will be spent on discrete topics. You don't need to be a discrete math genius to do this stuff, all you need is some discrete math, some calc (which you already have), induction, and the rest you can pick up as you go.

If you want to be the best you can be, I recommend trying that book I linked first to get your feet wet. After that, try CLRS. Then try TAOCP.

Do not however throw away the practical side of CS if you want to get into industry. Reading TAOCP would make you really good but it doesn't mean shit if you can't program. Even the author of TAOCP, Knuth, says being polarized completely one way (all theory, or all programming, and none of the other) is not good.

> From reading ahead in your post, is Skiena's Manual something worth investing to hone my skills in topics like proof skills? I'll probably pick it up eventually since I've heard nothing but good things about it, but still. Does Skiena's Manual teach proofing skills to those without them/are not good at them? Or is there a separate book for that?

You could, at worst you will get a deeper understanding of the data structure and how to implement them if the proof goes over your head... which is okay, no one on this planet starts off good at this stuff. After you do this for a year you will be able to probably sit down and casually read the proofs in these books (or that is how long it took me).

Overall his book is the best because it's the most fun to read (CLRS is sadly dry), and TAOCP may be overkill right now. There are probably other good books too.

> I guess going off of that, does one need a certain background to be able to do proofs correctly/successfully, such as having completed a certain level of math or having a certain mindset?

This is developed over time. You will struggle... trust me. There will be days where you feel like you're useless but it continues growing over a month. Try to do a proof a day and give yourself 20-30 minutes to think about things. Don't try insane stuff cause you'll only demoralize yourself. If you want a good start, this is a book a lot of myself and my classmates started on. If you've never done formal proofs before, you will experience exactly what I said about choking on these problems. Don't give up. I don't know anyone who had never done proofs before and didn't struggle like mad for the first and second chapter.

> I mean, I like the material I'm learning and doing programming, and I think I'd like to do at least be above average (as evident by the fact that I'm going out of my way to study ahead and read in my free time). But I have no clue if I'll like discrete math/proving things, or if TAOCP will be right for me.

Most people end up having to do proofs and are forced to because of their curriculum. They would struggle and quit otherwise, but because they have to know it they go ahead with it anyways. After their hard work they realize how important it is, but this is not something you can experience until you get there.

I would say if you have classes coming up that deal with proofs, let them teach you it and enjoy the vacation. If you really want to get a head start, learning proofs will put you on par with top university courses. For example at mine, you were doing proofs from the very beginning, and pretty much all the core courses are proofs. I realized you can tell the quality of a a university by how much proofs are in their curriculum. Any that is about programming or just doing number crunching is literally missing the whole point of Computer Science.

Because of all the proofs I have done, eventually you learn forever how a data structure works and why, and can use it to solve other problems. This is something that my non-CS programmers do not understand and I will always absolutely crush them on (novel thinking) because its what a proper CS degree teaches you how to do.

There is a lot I could talk about here, but maybe such discussions are better left for PM.

> Someone said I might be "destined for grad school" which is fine, but I'd rather know the ins and outs before I get my mind wrapped around the idea.

Depends what you want to do. If you want to work in some very focused area, the MS might help. If you just want one of the multitude of SWE jobs where you get paid big bucks to contribute to a really cool project, then just get a job after your BS. You can always get an MS later, without quitting your job even.

> From talking about it in passing, it has to do with turning it into bits and the usage of an assembly language?

More or less, but to be pedantic, everything is always bits, and it's more about machine language the assembly language (which is a human readable version of machine code). The NAND to Tetris course I mentioned will make this all extremely crystal clear to you, possibly moreso than any class you actually take at school.

> Based on what you say later on, is it safe to say that abstraction is just the idea of isolating a piece of code, presuming it works, and letting it do its thing while you work around it to produce something better?

Not just code, but any physical resource. When you connect to a website over the HTTP protocol, your entire interaction with that web server is defined by that protocol. All you know is that there are certain commands you can send it, and certain responses it will give you back (you personally don't send these commands, your web browser does it for you). That web server is a fairly complex system in itself, but for your purposes, it's just a thing that takes requests and returns responses. It's no different than a method in a piece of code. This is what abstraction is, and it allows extremely complex projects to be managed understandably, by individuals or by teams.

At the same time, to be a competent computer scientist, you should know how a web server works... roughly speaking. But as a programmer sending it requests, you don't have to burden yourself with thinking about it.

> If you could change one thing about the order that you learned things, would you first learn about how a computer works before you began programming? And if so, how far in-depth would you go before you would be satisfied?

Honestly, I'd like to have had a better bottom-to-top view of computers before getting into all the super focuses classes that each teach a single aspect, but require cursory knowledge of the others. In addition to the book I mentioned already, another great one is CODE by Charles Petzold. It's lighter reading, and has no projects/assignments. It reads more like a novel and is really written for anybody, but at the same time it can explain a lot to a new CS student or even to a CS grad who got no good "high level" view in his classes.

> I'd love to read "From NAND to Tetris" based on what you describe it as, provided it doesn't require a heavy foundation of computer architecture. I myself have always wanted to know how a computer is built, what parts make simple functions like moving the cursor and key input work, how memory is stored, etc. Would "From NAND to Tetris" teach me those types of things and beyond?

Yes. The author says there are no prerequisites except knowing a programming language. It's a 12 chapter book that starts off with boolean gates (the basic building block of a microcircuit) and ends with Tetris. Each chapter in between builds something on the results of the previous chapter. Essentially, by the end of the book, you've built a video game from boolean gates. But thanks to the abstractions at each level, you don't have to concern yourself with transistors when writing your game; you only have to think about how a Tetris shape can move. Each chapter has a project, and they're not easy. But I loved, loved, loved those projects. I did all of them in about 2 months, in a pretty addictive approach. Basically, you learn about things like compilers, operating systems, etc, and you build simple "toy" versions of each one, but seeing how all of these connect together, eve with toy versions, is IMO more useful than a course that teaches you how to build a real compiler, but without a good understanding of how that compiler works in a larger system. Here's the book: https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686

> Would it be safe to say that CLRS is meant for seasoned veterans or those who are fascinated by DS&A, rather than someone like me who just wants to understand how they work and when I could use them in a program?
> Would Skiena's book be something to read after my DS&A course, based on your description of it?

I don't know who CLRS is intended for. Probably beginners. I actually don't like the book that much and really haven't read the whole thing, but I've looked up certain algorithms in it just to see how they're presented. It's not bad by any means, just not my style.

And yeah, I'd read Skiena at some point in your progression. Whenever. I've actually read it twice... both times when preparing for really tough job interviews, based on this famous post... and it paid off.

The resource seems very extensive such that it should suffice you plenty to be a good software engineer. I hope you don't get exhausted from it. I understand that some people can "hack" the technical interview process by memorizing a plethora of computer science and software engineering knowledge, but I hope you pay great attention to the important theoretical topics.

If you want a list of books to read over the summer to build a strong computer science and software engineering foundation, then I recommend to read the following:

• Introduction to Algorithms, 3rd Edition: https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844. A lot of people do not like this classic book because it is very theoretical, very mathematical, and very abstract, but I think that is its greatest strength. I find a lot of algorithms books either focus too much about how to implement an algorithm in a certain language or it underplays the theoretical foundation of the algorithm such that their readers can only recite the algorithms to their interviewers. This book forced me to think algorithmically to be able to design my own algorithms from all the techniques and concepts learned to solve very diverse problems.
  
  
• Design Patterns: Elements of Reusable Object-Oriented Software, 1st Edition: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/. This is the original book on object-oriented design patterns. There are other more accessible books to read for this topic, but this is a classic. I don't mind if you replace this book with another.
  
  
• Clean Code: A Handbook of Agile Software Craftsmanship, 1st Edition: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. This book is the classic book that teaches software engineer how to write clean code. A lot of best practices in software engineering is derived from this book.
  
  
• Java Concurrency in Practice, 1st Edition: https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. As a software engineer, you need to understand concurrent programming. These days there are various great concurrency abstractions, but I believe everyone should know how to use low-level threads and locks.
  
  
• The Architecture of Open Source Applications: http://aosabook.org/en/index.html. This website features 4 volumes of books available to purchase or to read online for free. It's content focuses on over 75 case studies of widely used open-source projects often written by the creators of said project about the design decisions and the like that went into creating their popular projects. It is inspired by this statement: "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters."
  
  
• Patterns of Enterprise Application Architecture, 1st Edition: https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/. This is a good read to start learning how to architect large applications.
  
  The general theme of this list of books is to teach a hierarchy of abstract solutions, techniques, patterns, heuristics, and advice which can be applied to all fields in software engineering to solve a wide variety of problems. I believe a great software engineer should never be blocked by the availability of tools. Tools come and go, so I hope software engineers have strong problem solving skills, trained in computer science theory, to be the person who can create the next big tools to solve their problems. Nonetheless, a software engineer should not reinvent the wheel by recreating solutions to well-solved problems, but I think a great software engineer can be the person to invent the wheel when problems are not well-solved by the industry.
  
  P.S. It's also a lot of fun being able to create the tools everyone uses; I had a lot of fun by implementing Promises and Futures for a programming language or writing my own implementation of Cassandra, a distributed database.

Review your basic algorithms and data structures. Sorting, graph traversal, linked lists, structs, arrays, and multi-dimensional arrays.

Know about memory management, know about orders of magnitude in runtime, know about pointers, know about debugging and what to test.

You almost certainly won't be asked one of those wacky brainteasers you hear so much about -- we've found over time they do little else but tell us how good you are at brainteasers.

If you can do every problem in this book then you'll be more than prepared.

Also, give a quick read of our general interview tips.

General advice:

Pay close attention to providing thoughtful, reasoned approaches. Don't get so tied up in providing a clever solution that you forget the simple answer. Points are definitely awarded for really clever or innovative solutions, but that isn't the only way to get through.

Additionally, RELAX! This is definitely easier said than done, I realize, but understand that most interviewers really do want you to succeed. They aren't there to scare or intimidate you, and interviewing isn't even their day job! They're engineers who once sat exactly where you were, answering the same things they're now asking you.

Try and think of your conversation with your interviewer as being a chat with a really good friend of yours that you haven't seen in a really long time. You used to be best buddies, but moved away and you haven't seen them since. You know you've both changed in all that time, so you're being a little restrained, but there's still a foundation of mutual trust and respect -- one that puts you at ease.

Lastly, verbalize your answers. We aren't asking you to write an algorithm to sort a linked list because we're curious how it's done -- we're asking you because we want to know how you think. Verbalize your thought process. Verify all your assumptions. And, if you get stuck, don't be afraid of stating your thought process to your interviewer and asking for some feedback on where to take the solution (this is a heavily team-oriented company, after all).

Hope this helps! Best of luck!

Source: I do interviews at Microsoft, both general technical interviews as well as PM interviews.

My Story

Hey pal, I was in a similar boat about 8 months ago. It was my senior year as an Economics major, and after taking a programming class, I instantly fell in love with it. I crammed a few more programming classes in before graduating, but in the end, I sure as hell wasn't employable as a software engineer.

​

I had a choice: become a data analyst (the path I was currently on) or follow the software engineering dream. I chose the latter.

​

I decided to go to a (remote) coding bootcamp after college. The program was 6 months. It taught web development (Node, React) and some very basic CS fundamentals. I spent my free time outside the bootcamp inhaling all the computer science and industry information I could. I did this because I wanted to be a competent programmer. I found it fun.

​

This week I had my second onsite. I expect to receive a full-time software engineer offer (my second offer so far) later today, and I have 4 other onsites in the near future (a big 4 + a few startups). It has been a heck of a lot of work to get here, but if you want it badly enough, it's possible.

​

My Tips

• Try not to be intimidated by these tips. Software engineering is something that you take little bites out of. You cannot become an employable developer in one bite, and sometimes the field can be intimidating.
  
• Your options right now are self-teaching, a coding bootcamp, or a CS master's degree (might be hard to get into a good program without a bit more relevant experience, tbh.).
  
• It's going to be pretty difficult to break into anything other than web development for your first programming job without a CS degree. Titles like Front-end Engineer, Full Stack Engineer, Backend Engineer, and Software Engineer (at a web company) are within reach. More specialized titles probably aren't very realistic.
  
• Basic toy projects (i.e., simple HTML/CSS or similar) probably aren't enough to get significant attention. You need things more complex, like full-stack applications built from scratch. This means a working backend, a working database, a modern front-end (using a framework like React, etc.). Here's my portfolio if you're curious about the type of apps I mean.
  
• Other types of programming applications outside of web dev are also fine, as long as they are sufficiently complex and interesting.
  
• Put your projects on your GitHub no matter what. Learning how to commit code to GitHub is an important industry practice. Having a green GitHub history makes you look better.
  
• Try and build a portfolio once you get better at coding. Don't kill yourself making it look amazing, but do try and make it look good. Not everyone will care about your portfolio, but some people will. I got an interview just based on having a nice portfolio.
  
• Your university course sounds like a great primer, but you need to go deeper to be competent enough to pass interviews. I took similar courses at my university, but what really helped me was going through a few textbooks (1, 2, 3 -- some suggestions) and watching MIT 6.006 lectures. You will still have gaps in things like web security, scaling systems, networks, and operating systems, but I wouldn't spend a ton of time learning those topics as a new grad. Knowing the basics can be helpful though, because these things do definitely come up in interviews.
  
  ​
  
  Happy to answer any other questions you may have. I'm not an expert or an experienced software engineer yet, but I've walked the path you're considering, so hopefully my tips are helpful.

I'll address your #1 below, but I want to focus on #2 for a second.

The feedback you've gotten regarding your degree choice is correct -- all of it, even though it may seem contradictory. You'll have a tough time finding a job in Art - and artists probably won't appreciate a degree in CS very much. The reverse couldn't be further from the truth.

It is a very rare individual that has the logical and mathematical nature to code efficiently and with broad scope but then uses their artistic creativity to inspire cleverness. Code, or more generally put a system, is a piece of art just like any other. A wide array of pieces which need to cleverly and harmoniously co-exist. The creativity of an artist is essential in recognizing the potential of an application.

I want you to look at this role. Read the job description, and picture it applying to a product where you design the User Interface and the User Experience. Understand that you will work with graphics artists, but it's your vision that determines what the user experiences.

If that feels right, chase it.

----

As for your #1 question, another very good one.

When I'm interviewing SDEs, I want to see mastery of concepts and, to an extent, cleverness of a solution. There are a few things, though, which make me almost immediately discount a candidate:

Starting before you have all the information. Make sure that you have a very clear vision of what the problems is before you begin. Understand that any assumptions you make must be checked first. For example, if I say take a pointer to the head of a linked list and then do X on it, and you assume that the pointer will never be null, you will fail my test. Either code for the case where the ptr is null, or ask the interview "Is it a fair assumption that the pointer will never be null?"

Being satisfied with a naive solution. When solving a problem, it's perfectly fine to give the naive solution -- but don't stop there. Once done, talk with the interviewer. Say things like "Now this is the naive solution, because it finishes in O(n^2) time. We can make this more efficient by doing 'X'" and then press forward.

Internalizing your thoughts. This is weird to do for candidates, but it's critical for a team environment. When you're solving problems, think out loud. I'm not asking you to solve these problems because I'm bored and need a show, I want to know how you think.

There's so many of these I could write a book (and others have). I highly recommend reading Programming Interviews Exposed. It's an awesome resource with spot on practice problems.

TL;DR Improve yourself, invest in your future, don't worry about the mistakes...read the books listed at bottom, and practice!

Few months ago I royally fucked up an interview at Microsoft. A really simple question. But I had no experience doing coding on paper instead of a computer.

I spent a lot of time studying various books and paper coding to make sure it wouldn't happen again.

I then had an interview for another (in my mind at the time) dream job. I did fine for all the phone interviews and they flew me over to the west coast for an in person interview for the day. I did well for the first bit until they started pulling out dynamic programming and integer programming questions on me and expecting me. Once again something I didn't prepare for, and f'd up. Didn't get this job either. For the longest time I was really hard on myself at fucking up on both these interviews one after another. Especially this second one since a lot more was riding on it than just the job (another story).

But then I decided I didn't want to have this sort of experience again and expected better of myself. I made myself further improve and brush up on all those concepts as well. Did a few mock interviews with friends, spent some time working on interview type questions on both the computer and on paper. A month or two later I started interviewing again. By this point I was an interviewing machine - and I'm now able to do just about anything thrown at me. I've had my choice of employers and until just recently, was in the situation where I had so many offers I didn't know which one I wanted most. I'll be heading to silicon valley soon at one of the top tech companies in the world with a fantastic offer considering I just graduated.

The point is - learn from the mistakes and improve yourself. I realize you don't want to be that guy spending heaps of time coding outside of work or whatever... but this is an investment in yourself and your career. Do it once, and then just brush up on your skills from time to time. Get into the interviewing mindset and just rock them so you can have your choice of job - and then you can go about your thing once you have the job locked. The up front investment will be worth it!

Things that helped me:

• www.hackerrank.com - practiced a lot of questions on here
  
• www.careercup.com - another great site for questions
  
• Cracking the Coding Interview More help on questions, but also some great insights into the interview process for the larger tech companies and many hints and tips on how to go about solving the more complex problems
  
• Code Complete A great book for helping you to refresh or learn about software design
  
• Eternally Confuzzled Great resource to learn how to think about common data structures and algorithms
  
  Having trouble with Algorithm design/analysis? These are some of the go-to books for that:
  
  
• The Algorithm Design Manual Probably the defacto for learning about algorithm design and analysis
  
• Introduction to Algorithms A great book with many different algorithms and data structures to learn about
  
• Algorithm Design A great book if you want to dive deeper into more complex subjects like graph theory, dynamic programming, search algorithms, etc.. etc..

Quick note about number 6: Those terms are a lot more intimidating than they sound. Some of them take a little while to really grok what they are and why they are useful but once you understand them they are extremely useful (and huge selling points for yourself as a developer).

About the interview: From what I've heard the questions they ask are different based on different backgrounds. They are less likely to ask software development methodology questions to a new graduate since that's not really in the realm of computer science.

I did get asked some questions regarding data structures and algorithms. The ones that I was asked, and I feel I did really well on, were more related to problem solving and software architecture. Think of it this way, if they hire you, in your day to day job having memorized how to traverse a graph isn't going to come up that often. Your day to day is going to consist of coming up with solutions to problems presented with you.

So when they ask a question like how to traverse a graph, they aren't looking for you to be able to spit out Dijkstra's algorithm exactly. Instead, they are looking to see how your brain works and what kind of solution you can come to by logically breaking down the steps to solve the problem.

They are looking for how you take a problem, break it down in pieces, and what your solution would look like.

Example: Implement a scale, that has two sides and lets you know based on the objects on the two sides, which side is heavier and by how much?

My answer to this question would be something like:

• Create a WeighableInterface that requires the getWeight method.
  
• Create a few random classes that implement that interface. Maybe a horseShoe class.
  
• Create a scale class and scaleInterface that has the methods addToLeft(WeighableInterface $object) addToRight, getWeightDifference, getHeavierSide.
  
  How do you store the set of items on each side of the scale internally in the scale class? Do you need to be able to remove items from the scale, and why would this affect how you store the items internally? Should the scale have a weight limit?
  
  These are all great questions to ask. Think out loud, talk out loud. They want to see that when confronted with a problem you don't know the answer to, or don't know the best solution to that you don't freeze up but instead chunk it up and try to reason your way through it.
  
  "Should the scale have a weight limit?" Asking the interviewer this question is a huge win in your favor. It shows that not only are you trying to solve the problem, but you're constantly thinking about issues that might have been overlooked in the initial assessment.
  
  Back on number 6: I learned these by googling a fuckton. Watching a lot of videos, reading a lot of tutorials, and just asking a lot of questions.
  
  Here's some resources I still have bookmarked from the last year/18 months. Some of them are for targeted for php, but the concepts are universal. But if any of these don't do it for you, google a bunch.
  
  Solid: 1 2
  
  Inversion of Control & Dependency Injection: 1 2 3 4
  
  Domain Driven Design: This is actually a ton of concepts, and you don't necessarily need to learn them all at once. This book is the only software architecture book I've read cover to cover, its that good. If you can afford to, do buy it. Also another helpful link Intro to DDD.
  
  Test Driven Development and UnitTesting: 1 2
  
  Also I've found many of the top answers stackoverflow user tereško are great sources of wisdom regarding software development.

Search algorithms and data structures will be pretty important for the interview, but if you're a bit rusty, there's probably still time to brush up on stuff before the interview. Books like Cracking the Coding Interview or Programming Interviews Exposed really help.

One thing to be careful about on the interview though is to not get too hung up on finding the best possible answer to a question. Yes, coming up with an efficient solution is good (and if you give a less than optimal solution, your interviewer will probably ask you to improve it or add more constraints), but if you cannot come up with any solution, even a naive one, and aren't able to code it (or run out of time because you spent too long trying to find an efficient solution), you probably won't make it to the next round.

In general though, you shouldn't be asked too many questions that require memorization as long as you know the basics (and you should be able to discuss space and time complexity for any solutions you provide). If you have any more questions though, feel free to send me a PM (I work at Amazon).

I read your question as having two parts:

A) How do I get better at taking a project and breaking it down into smaller tasks?

B) When I encounter an error, how do I get better at finding the cause of it?

There are a few answers to this-- a toolbelt of techniques.

1. Writing stuff down in an organised way.
   
   Basic, but very powerful. Your brain can only hold so much at once. If you keep a notebook by your side or a text file open, you can dump your thoughts into it and give your brain an advantage in keeping track of the things you learn. Better yet, when you run into an error, approach it like the scientific method: Form a hypothesis and come up with ways to test that hypothesis.
   
   
2. Debugging tools like print() and import pdb;pdb.set_trace()
   
   These are ways to look at "what is my code currently doing?" and "what is the value of this variable right now?". They let you gather the information.
   
   Debugging: The 9 Indispensable Rules is a great book on how to use these tools effectively.
   
   
   
3. Automated Tests
   
   When you encounter an error, write a little program which reliably triggers the error. Here is a tutorial on how to use py.test, a tool for writing such programs. The Goat Book is a longer intro to writing Automated Tests.
   
   
4. Modular code design.
   
   You want to split your code up into parts which make it easy to understand. That way, when you see an error, you can more easily read the code where that error comes from. How do you do this? A great book to start with, once you've gotten the ability to write some short scripts, is A Philosophy of Software Design. Another great book is Clean Code. You'll notice that these books sometimes disagree with each other. That is because this technique is a big part of what makes up the craft. Welcome.
   
   
   
   ----
   
   Note: I'm found a bit hard to understand the last sentence. I think that it got mixed up with the sentence before it.
   
   I hope you don't take this as condescending--perhaps you had to dash off a response on your phone. But I'm willing to take the risk of condescension because this advice is far more important than the question of python-vs-java:
   
   Alongside learning to write in a program, it is also important to make a strong habit to write English with solid grammar. Why?
   
   
5. The skill of noticing when some written structure seems "off" and the compulsion to fix it will serve you well when writing and debugging code.
   
   
6. As you learn to program, you're going to need to ask questions of others. When you do this, you want to empower your answerer as much as possible so they can succeed in to helping you. Read this blog post by Julia Evans
   
   
7. As mentioned in #1, the skill of "read this code to find the structural problem" and "read this paragraph to find the structural problem" are very similar. So, if you ask a question without having taken the time to re-read and fix up your grammar, then readers are going to think you also haven't taken the time to carefully read the code you're asking about. So, you'll find it harder to get help.

For more foundational stuff, I'd look at:

• GitFlow - a successful Git branching model - This is pretty much the prototypical Git usage model. I have seen it used pretty much everywhere I've worked that used Git, and a lot of software supports the model by default (Atlassian Stash, SmartGit, Git Tower, and more).
  
  
  • Also take note of alternative Git usage models like GitLab Flow and GitHub Flow. They fit rather different use cases, and GitFlow is typically used for software that follows a more old-school release model where releases happen periodically, or you need to support multiple production releases at any given time. GitLab and GitHub flow are geared more toward software that only sees a single version in production at any given time, and very common release cycles (e.g. daily or even shorter).
    
    Getting familiar with these branching models will also expose you to many commonly-used Git features like branching, squash merging, rebasing, tagging, and history rewriting.
    
    
• How to write a commit message
  
  No one's really gonna ask you about this, but you should develop a habit of writing great, clear, and concise commit messages.
  
  
• Continuous Delivery and Continuous Integration
  
  All the rage right now - having real/near-real time building/unit-testing/packaging/deployment of your software once you've made a code commit. Read the articles I linked, play with services like CircleCI or Travis-CI or CodeShip and integrate them with your projects in GitLab.
  
  
• Test-Driven Development and Behavior-Driven Development
  
  Probably the two most commonly used overarching test-based software development processes. I'm a strong proponent of TDD (when done right), and many teams you work on will probably employ TDD or BDD.
  
  
• Stemming from the last point, know how to write good unit tests and how they differ from integration tests or acceptance tests.
  
  
• Code organization - a lot of this will likely be influenced by the language/toolset you're working in, but you'll be interested in learning about Layered Architecture and software packaging metrics.
  
  
• Generic software design - all sorts of acronyms to read about and absorb, like YAGNI, KISS, DRY, and SOLID. Also, the Unix philosophy, which guided a lot of development of software for Unix and Linux these days. There will also be patterns that apply to specific languages or types of software, but the stuff above is rather generically applicable.
  
  Beyond those links, some books that cover a lot of general material are:
  
  
• Clean Code
  
• Pragmatic Programmer
  
• Mythical Man-Month
  
• Software Estimation - Okay, software estimation is really gonna be complex and difficult until you get a lot of experience, and even experienced developers get it wrong. I don't think it's particularly necessary to read this book when you're starting out.
  
• Domain Driven Design - I love this book - it's about breaking down complex software designs.
  
• Release It! - Nygard is a pretty battle-tested developer, so this book is about approaching software design practically rather than in a vacuum separated from real-world application.

This has been my biggest focus for the last few months.

1st realization was "Networking events" weren't a place where you join the hive-mind, exchange emails and share secrets on openings in the job market. You're basically are making friends. Get them to think: "This would be a good person to work with. I better answer his message so they'll answer mine"

John Sonmez (Author of Soft Skills: The software developer's life manual): https://simpleprogrammer.com/

Toastmasters: https://www.toastmasters.org/ This is like a public speaking club for anyone to join. My place is filled with 8 nice sweet, old people who want to speak better at church. I feel pretty comfortable speaking there.

This has been my 3 step plan:

1. Practice your speaking out loud. Practice speed, flow and volume first. Then add emotion as you read. I read to my girlfriend David Foster Wallace's Essay: Shipping Out
   
2. Learn how to tell stories. John Truby’s 22 Steps notes
   
3. Give speeches and powerpoints.
   
   
   My youtube story telling playlist
   
   Books/Audiobooks:
   
   
4. "Brag! The Art of Tooting Your Own Horn Without Blowing It" by Peggy Klaus audible link The audible book is abridged because chapters 4 through 8 have little value.
   
5. The Anatomy of Story: 22 Steps to Becoming a Master Storyteller by John Truby
   
6. The audible Summary of "How to win friends and influence people" by Dale Carnegie
   
7. The audible Summary of The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Steven R. Covey
   
   
   

DevOps is a tough field to break in to. A lot of companies will expect you to come in and know what you're doing right away - especially from a security standpoint. Managing infrastructure for your organization is a really big deal, which is why there is so much emphasis on Linux administration and deep understanding of how to secure those resources.

Going from web development to devops is a pretty big change - really they are two separate career paths. Not that you couldn't do it, but it will be a difficult transition for someone that hasn't done that kind of work before.

I think you need to assess what it is in the technology sector that interests you before you make a decision on which path to go down. Doing Devops-style work is super fun and rewarding, but like I said - it is a completely different field than traditional SWE.

If you do look in to the devops path, I would highly suggest reading Google's SRE book (it's free on PDF -https://landing.google.com/sre/sre-book/toc/index.html). This will give you a really comprehensive breakdown on what aspects of the SRE/DevOps that you will want to focus on to be successful.



e: also - the Phoenix Project (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592). A must read for any DevOps hopefuls out there.

You'll see this one recommended a lot :
How to Win Friends and Influence People by Dale Carnegie. It's a classic and for good reason. I always find myself going back to it. In fact there are quite a few books I'd argue that build upon it

Another very good one is by Leil Lowndes called
How to Talk to Anyone. It gives a lot of useful tips on how to make conversations exciting and vibrant.

Also, John Sonmez's books are really good too because they focus on communication skills from a developers point of view. I really liked these because it also teaches how to develop your career and start your own brand:

• Soft Skills
  
  
• The Complete Software Developer's Career Guide
  
  
  
  These are just off the top of my head, I'm sure there are plenty more. Hope that helped!

I mean, you can say you can start immediately to see if they'll take it! But if I'm being perfectly honest (as someone who's worked for companies like that) most of those resumes and applications are never seen by real people. The BEST way to maximize your chances is to reach out to people who work at those companies and ask to learn more about what they do or even just for learning tool recommendations. The key is to build relationships with people who can help teach you what you need to know and help you get your foot in the door somewhere you want to be. But also there are tons of other (and probably better) places to work than the big four anyways. Either way, if you're starting your job search there's this one book you should definitely read--it was basically my networking bible out of college and helped me land a job at a big four consulting company, i'll link ya: https://www.amazon.com/dp/B07YL448KZ

Read The Phoenix Project. It's a very good high-level overview of all the things that live under the DevOps umbrella.

Also make sure to acquaint yourself intimately with either Linux or Windows, preferably both, from an ops point of view. Setting up systems, configuring them, deploying/installing things, all that stuff. This stuff is rarely if ever taught in traditional CS programs but is very relevant in the professional world.

For Linux, you can find some RHCSA/RHCE study materials on the high seas which should get you there. The certification is nice to have, but not required everywhere. The knowledge is the important bit.

For Windows, the Microsoft Virtual Academy is a pretty good place to start. Like this one for Powershell basics.

I like this EdX course for covering more of the "dev" side of DevOps with a sprinkle of "ops":

https://www.edx.org/course/devops-for-developers-how-to-get-started

If you have the time/resources, take a 2 year diploma program specializing in programming. It's what I did (BA in History - staring at the same future of awful administrative type jobs). The program I took through a local tech college focussed on how to code, the basics of the math behind it, and some extra courses for basic management, accounting and communication (i.e. tech writing), and project management - all key skills in software development. All in all, it was a great program and got me way further then I could have done on my own.

What it didn't do is give me a solid foundation for the underlying concepts in Computer Science - basically how exactly a CPU works, how a compiler works, some of the more abstracted mathematics behind computational logic. While you don't necessarily need this knowledge to have a career coding, I feel it holds me back - so I'm trying to bolt it on through self learning and am finding it a huge challenge.

But for basic computer science, if you're serious, check out this book: The Elements of Computing Systems - http://www.amazon.ca/Elements-Computing-Systems-Building-Principles/dp/0262640686/

The Learn X the Hard Way are great primers on coding - I use them to teach myself languages I don't use in work (Python, C).

Other books to read include Code Complete 2, Pragmatic Programming and Clean Code - while these texts are largely for people already familiar with software development, I do recommend them to all beginner (and experienced) coders as they contain extremely handily insights into the complicated beast that is software development, as a craft.

Finally, the most important thing you can do if you want to learn coding is to CODE. Practice is the best way to learn. Wanna figure out how something works? Don't read about it, do it. Make hundreds of throw away programs tinkering with concepts. Coding is a craft - only way you're going to get better is by actually doing it.

I'm telling you... you do not have to wait to become a web designer especially if you have any CS chops. It sounds like you need some kind of validation lol? In design you have to be an entrepreneur, design your own experience, find out some people who are doing design x software email them... surprise them, designers love surprises and something different... make your own luck.

As far as Amazon good books, you really want to aim for a whole view of design at this point. Think of it like you wouldn't learn run before you can walk, there is A LOT out there.

• https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557/ref=sr_1_1?ie=UTF8&qid=1466034268&sr=8-1&keywords=thinking+in+systems
  
• https://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672326140/ref=sr_1_3?ie=UTF8&qid=1466034307&sr=8-3&keywords=alan+cooper
  
• https://www.amazon.com/Understanding-Media-Extensions-Marshall-McLuhan/dp/0262631598/ref=sr_1_1?ie=UTF8&qid=1466034386&sr=8-1&keywords=marshall+mcluhan+understanding+media
  
• https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654/ref=sr_1_1?ie=UTF8&qid=1466034432&sr=8-1&keywords=don+norman

Design Patterns by the gang of four ( http://amzn.to/2fwfVo3 ), learning design patterns and remembering them will allow you to find better solutions to problems, and quickly understand how libraries are working, I believe one of the most important skills for a programmer, but not often taught.
Java Concurrency in Practice by Brian Goetz ( http://amzn.to/2ycSZ8B ) is very good as well, even if you're not going to use concurrency, it teaches some very good coding practices that create better quality code.

If you're 4 years into your career and you haven't been failing at it and getting fired, you probably don't need to go all the way back to the absolute basics. You just need to fill in holes and keep pace with change.

I like to read books/blogs on emerging technology and areas becoming relevant. Like I just read [Refactoring: Improving the Design of Existing Code] (http://www.amazon.com/gp/product/0201485672) because we were doing a huge refactoring project at my job. I read Ng-book and an .NET MVC right when I got my current job because I'd never worked with angular or MVC before. I'm currently looking at some stuff about .NET Core. It won't be relevant at most places for years, but it's nice to keep on the edge sometimes.

Blogs are also good things to read too. The Morning Brew is my favorite site right now for keeping up with .NET.

If you're worried about your fundamental skills I'd say work through something like codility. I think you'll find a lot of the problems trivial or easy to pick up and do with a little googling. Sites like this are usually the kind of questions you'll get asked in interviews, so if you can do them, then you're fine on that front.

If you plan on self teaching I find these materials to be quite sufficient:

Data Structures and Algorithm Analysis This book also has a C++ version and can be found online for free(legally, from the author). I prefer reading a real book over PDFs so I opt to buy it but your opinion may differ.

The Algorithm Design Manual. This is pretty much the 'go to' book for self learning DS/Algo since it covers a lot of material but does not go that deep into the details beyond a working knowledge.

Introduction to Algorithms. This is the standard text on Algorithms and is used in most undergrad/graduate level courses on the subject. It is very detailed and goes deep into the theory and mathematical proofs of algorithms. It's a much more academic text but still worth mentioning and being aware of.


Edit:
Out of the 3 I think the first is the easiest to read but the second is the best in covering relevant material quickly and sufficiently enough. The last one is only for those who want mastery of the topic or intend to use it for a course.

Good news! Very few people code well in interviews, from what I've heard. Boneheaded mistakes are practically expected. Ask lots of questions about the problem--it'll give you more time to think and it'll make it clear that you're trying to figure out exactly what they're asking.

Amazon interviews are just like most technical interviews, in my experience. A FANTASTIC book to prep for interviews with is Programming Interviews Exposed. It goes over a lot of the data structures and common types of problems you'll get in interviews. It's great for day-of refreshers, or for going through more in-depth. HIGHLY recommend it!

I think you're on the right path, practicing will definitely make your skills better.

I strongly suggest you to learn about common architectural patterns, like MVC, MVP, etc. and try to build to build something using them, as practice.

Testing and TDD specially would also improve your code design skills, so I recommend you spending some time practicing it.

Here's a list of books that I think will help you:

• Clean Code
  
• TDD by Example
  
• The Art of Unit Testing
  
• Refactoring
  
• Growing Object-Oriented Software, Guided by Tests
  
• Domain-Driven Design
  
• Patterns of Enterprise Application Architecture
  
  I'm thinking about creating a course on code practices, design/architecture and testing and looking if there's demand for it. Would you be interested?

Wow that's awesome! Are you interested in embedded and RTOS systems at all?

If so, I'd highly recommend this and this and picking up a TI TM4C123 board to do some development on.

I also recommend this book for learning more about the practical application of algorithms.

Some books that I've found interesting and helpful are:

• Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead
  
• The Alliance: Managing Talent in the Networked Age
  
• Multipliers: How the Best Leaders Make Everyone Smarter
  
• The Five Dysfunctions of a Team: A Leadership Fable
  
• Corporate Confidential: 50 Secrets Your Company Doesn't Want You to Know—and What to Do About Them
  
  Also, I think participating in this sub has helped me become a better leader at work.

\> "can't we just install Google Tag Manager" - it's just a block of code in the <head> tag

​

Things your dev will probably be thinking of:

​

What's the performance like for this? Will this block the page load? Is this important? What kind of info is going to collect? Is this complaint with our privacy policy and how we collect info on our users?

​

"Iit's just a block of code in the <head> tag" ... hosted where? From Google? Do we operate in China? Will we ever? Will their CDN work? Can we afford to be reliant on their CDN / resource? Does it work in all the browsers we support?

​

Depending on the scope and reach, this could have a lot of stuff.

​

​

\> "can't we install this countdown pixel on one of our servers? it's just a block of php code" link

​

Do the servers run PHP? Should they? If not, would we need to install it? Who is going to keep that server patched? If it does, where do we put it? What are you using it for, emails?

​

\> "can't we just have read only access to the database? just certain tables? such as a category data, so we can count/sum/group-by categories - what about a staging database - can't we use that?"

​

Maybe a replica. As you've been told, you can't just run random queries since you could hurt performance without proper scheduling and permissions. This takes time. Privacy issues might prevent you from handling it without lawyers involved.

​

Who now has to manage your access? How are the credentials issue? Are you machines secured enough to handle the data or is someone going to click a random link and now get backdoored and now some competitor has access to your info? Oops!

Aside from that...

\> To the marketing team, everything sounds easy "just copy paste this script"

​

Sometimes it is. Often times, it is not. That being said, a lot of stuff can be very simple especially if it's a one off. You should organize time with your teams to get this kind of stuff. Where I work, we do help out with these requests but they are put in queue. However, you have to prove it's really going to help the business. You can't be wasting expensive resources chasing things that not going to return some kind of value for the business.

​

If you REALLY want to understand, reach this cliche book: https://www.amazon.ca/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 Judging by how you are talking, I am sure it will resonate with you.

> but it often gets derailed because we have a fairly large team and everyone seems to feel the need to say something, even if it is only tangentially related to the topic of discussion.

Oh no. Any meeting with more than 5 people trying to have a dialogue is a terrible idea...

> It's funny you mention adding stories to the sprint for meeting attendance because that's exactly what we do. I don't even want to look at how many hours I've logged so far for this sprint. It's mind-boggling.

My god, it's worse than I thought! I was half joking when I said that...

> How would you justify refusing to attend these meetings?

Well, it kind of depends on a few things, like how much you like your manager, how good is your relationship with your 2nd line manager, how much do you care about the job, how much can you get away with, etc.

In your sprint retrospectives, have you considered making one of the "Stop" actions being "Stop spending so much time during sprints discussing issues that are more appropriate for sprint retrospectives?" or "Stop having so many meetings"? BTW, does your manager attend your retrospectives? I don't believe they're supposed to, but even if they do, it might be a good way for all of you to unite and express your feelings on the matter in a "safety in numbers" group environment.

Otherwise, it sounds like you've already tried the diplomatic approach of talking to your manager (I assume privately?) about the meetings, and expressing that you don't think they're a productive use of your time. If you're on good terms with your 2nd line manager, you might consider mentioning it to them. Or, I don't know what your work environment is like (small/big office?), but what would happen if you just didn't go to the meeting? Or, what would happen if you just got up and left when the discussion drifted into the sprint issues away from the agenda?

Also, not sure it'll help, but you might consider buying your manager a copy of Peopleware. Every dev manager should read this. Even developers should read it. Of course, then you'll be even more pissed about all the stuff your management is doing wrong...

This here is my patterns bible:

https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420

As for .Net and SQL Server, it really depends on what you want to get into. Both have such a huge field of applications. In general MS Press is really good for books on their own stuff and written well enough that you can actually read through it.

Edit: But yeah, just realized that the book from Fowler also already is 14 years old. I need to update that as well :)

I'm going to suggest a few books that aren't textbooks that'll teach you a specific topic but are certainly brilliant at passing on viewpoints that are beneficial to your overall understanding of computer science and software development.

• Dreaming in Code
  
  
• Godel, Escher, Bach
  
  
• The Mythical Man Month

Refactoring: Improving the design of existing code

Design Patterns

Working Effectively with legacy code

Clean Code

How to be a programmer

Then there are language specific books which are really good. I think if you read the above, slowly over time, you'll be in a great place. Don't think you need to read them all before you start.

I'm just about to graduate with my undergrad in CS with a specialization in HCI, and have had multiple UX internships. Read these two books, they'll provide a really good baseline of knowledge about user-centric design.

The Design of Everyday Things - Don Norman

Don't Make Me Think - Steve Krug

While the second one typically focuses more on web, they're both amazing books that should be in the library of any UX/HCI specialist.

The best way to start building a portfolio is to, well, just do. Find anything (not just a program/app, even) that you don't like the design of, and start from there. Try and redesign it to make things easier to figure out. Show it to others to gauge reactions and get feedback. Iterate and improve.

There are a bajillion different programs for UI prototyping, but the first tool I'd suggest is good ol' pencil and paper. Get yourself a sketchbook and keep it in your backpack (or with you in some other capacity) at all times. When you have a design idea, drop everything, make a quick sketch, and go back to what you were doing. Ideas are fleeting and temporary, so it's best to get it on paper before you forget. Once you've got time, try and improve on those designs and think of what would work and what wouldn't. After you're happy (and have shown it to others for feedback), take it into some prototyping app like Balsamiq, Indigo Studio, or Sketch. Render it in high quality and start seeing how users would react to it in its natural setting (put it on a phone, or on a computer, etc. for testing). It's all about getting user feedback because one person on one computer may not have all the right ideas.

tl;dr: Read books. Redesign crappy things. GET A SKETCHBOOK. Feedback, feedback, feedback.

You received A's in your math classes at a major public university, so I think you're in pretty good shape. That being said, have you done proof-based math? That may help tremendously in giving intuition because with proofs, you are giving rigor to all the logic/theorems/ formulas, etc that you've seen in your previous math classes.

Statistics will become very important in machine learning. So, a proof-based statistics book, that has been frequently recommended by /r/math and /r/statistics is Statistical Inference by Casella & Berger: https://www.amazon.com/Statistical-Inference-George-Casella/dp/0534243126

I've never read it myself, but skimming through some of the beginning chapters, it seems pretty solid. That being said, you should have an intro to proof-course if you haven't had that. A good book for starting proofs is How to Prove It: https://www.amazon.com/How-Prove-Structured-Approach-2nd/dp/0521675995

Ah Midwesterner! Ok Chicago is a great midwest market! Maybe the current market there needs enterprise web developers more so than PHP developers for example.

On learning the business side it sounds like you should pick up some books on the business side of software development Soft Skills is a good one!

Soft Skills: The software developer's life manual https://www.amazon.com/dp/1617292397/ref=cm_sw_r_cp_api_fLMdzbJG99MF3

Non-fiction:

• The Design of Everyday Things -- not about programming, but a great resource in general for viewing things from a design perspective, and it was required reading in my CS curriculum.
  
• Don't Make Me Think -- another design-oriented book about web usability. It's quite a quick read since it's mostly pictures.
  
  Fiction:
  
  
• Sourdough -- it's a fun whimsical story about Silicon Valley, programming, and baking bread. Very quick, light read.
  

I always thought there should have been a subreddit called r/CompSciSoftSkills. I recently read a couple books, Peopleware and then The Mythical Man Month .

Peopleware mentioned that software development was more a sociological process than a technological one and I found that fascinating. I always thought that having a subreddit dedicated to exploring the sociological side of software development would be very interesting and revealing.

... and by extension and exploration of the skills outside whiteboards and code that apply to software dev.

Along with /u/a_few_benjamins suggestion, I used this book: Data Structure & Algorithms in Java to learn DS and Algorithms ahead of learning them in my DS and Algo courses. It doesn't go nearly as deep, but I found it easy to digest and I enjoyed the writers style. I didn't use the applets that the author created and I'm not sure if they are still available so don't let that hold you up.

Maybe leave a copy of Peopleware: Productive Projects and Teams lying around prominently? It has a number of studies showing that a quiet, distraction-free workplace does pay off.

> What I'd give to just move my desk into a corner, or to face a wall, but I'm not sure that would go over well.

> My stuff is on a shelf, and there's no room to put anything on the desk.

The appropriate adage here is "It's easier to ask forgiveness than get permission". There's a clear business need for developers to not be distracted while working; reconfigure/move your area one evening—see if you can get someone else to do the same, there's strength in numbers—and see how it goes. (I take it you've already tried raising the issue through normal channels.) If asked, explain that you're easily distracted by conversations and people walking by (i.e., couch it as your weakness, not their lousy setup) and really need to make some process on the Frobnicator feature if it's to be done by next Tuesday.

If you need space for pictures or toys or other personalization, stack a couple boxes/crates on each other to extend your desk. Call it "startup chic". Maybe it'll shame them into giving you more space.

Listen to the people who work for you. For every one person under you it takes a few hours a week to manage as a rule of thumb. When I say manage, I talk about leadership, developing them, understanding them, understanding how they want to grow and stretch.


I highly recommend reading the following book too about teams. It's a great book and in my experience holds true with small teams and large global teams.


http://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756

Design of Everyday Things is a really good book. Understanding how someone uses the things you build is vital in creating good products.

Depending on how much project management you do vs. personnel management, there is Cracking the PM Interview by the same author (though possibly ghostwritten).

General personnel management probably involves more general management interview questions, for which I'm sure a million books have been written (though I don't know enough about them to recommend a specific one).

Edit: If you haven't already, though, read Peopleware. If more shops were run like they suggest, the world would be a better place.

Also I've heard a lot about your recommendation there - Code Complete. I'm wondering if that counts as "software engineer" stuff? Is there a book out there to turn a "programmer" into a "software engineer"? I'm really not sure what the heck the term means but I know it's something about managing large code between other programmers in an efficient manner. That's just a guess, but again, no idea if that's important to learn or if there are books for that without the title of "software engineering".

Also not sure the order in which to learn subjects. I'm guessing data structures is first, then code complete, then software engineering stuff? I am willing to read Code Complete alongside this book http://www.amazon.com/Data-Structures-Algorithms-Java-Edition/dp/0672324539

Which I'm only 40 pages in so far, but it's good. What do you think?

I just chose some books that looked good from this list and this one.

The one's I got:

Clean Code
(already read)
Cracking the Coding Interview
Code Complete
Peopleware
Don't Make Me Think
Code (currently reading)
Regular Expressions Cookbook
Head First Design Patterns
C++ Primer
Working Effectively with Legacy Code
Elements of Programming Interviews in Java
The Mythical Man-Month
The Design of Everyday Things
JavaScript and JQuery

I figure that's enough reading material to last me until I graduate.

"I'm also sure that due to my limited educational resources, self-directed study will be a huge part. Any suggestions on which books are must reads to gain competency in CS?"

Here are a few good choices for the more theoretical areas of computing:

http://www.amazon.com/Algorithms-4th-Edition-Robert-Sedgewick/dp/032157351X/ref=sr_1_1?ie=UTF8&qid=1408406629&sr=8-1&keywords=algorithms+4th+edition

http://www.amazon.com/How-Prove-It-Structured-Approach/dp/0521675995/ref=sr_1_1?ie=UTF8&qid=1408406673&sr=8-1&keywords=how+to+prove+it

You'll also want to look at a decent discrete mathematics book. Sadly the book I used as an undergrad was rubbish, so I don't have a good recommendation.

Some good general (not language-specific) book recommendations:

• Clean Code
  
• Code Complete
  
• The Pragmatic Programmer
  
• Refactoring
  
• Design Patterns
  
• Head First Design Patterns
  
• Working Effectively With Legacy Code
  
• Beyond Legacy Code
  
• The Mythical Man-Month
  
• Soft Skills
  
  Also: Free Programming Books

I personally think Beck's TDD serves as a good resource to learn about testing. Even if you don't plan to fully adhere to the TDD doctrine, it does a good job of showing you how to write testable code and test it.

While the examples are presented in java, you don't need to really know much java - you can take it as statically-typed pseudocode.

I can't believe noone has mentioned The Mythical Man Month yet. If nothing else, it will help you give better time estimates for your work.

http://www.amazon.com/How-Prove-It-Structured-Approach/dp/0521675995

helps with the first part of the class. the stuff after that I would suggest just having good google-fu.

There's a [book] (http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530/).

It's a "classic" but I personally found it on the slow/pedantic side. See if you can borrow it from someone or find a chapter online for free before you buy it.

edit - formatting

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

https://www.amazon.com/Data-Structures-Algorithms-Java-2nd/dp/0672324539

Probably one of the best books I've read for DS with Java.

If you've worked with Java before this is a great book

I have most of these books.

The Art of Computer Programming
The Art of Computer Programming is dense. It is deep. You can likely put off this one. It should be a goal to be able to get through it though.

Introduction to Algorithms
Introduction to Algorithms, I don't have it. All I know is that it does come highly recommended.

Code Complete
Code Complete is excellent. Well written, it feels a lot shorter than it is. It will get you thinking about every step of the software development process.

The Pragmatic Programmer
Another one I don't have but gets recommended time and time again.

The Mythical Man Month
The Mythical Man Month is less directly relevant. It will go over meta issues in software development.

Don't Make Me Think
Don't Make Me Think is also not about code itself, but about design. Because if no one uses your application, does it matter if you made it?

I wouldn't say it's the exact same, but I still lump it in a nice to read category:

The Phoenix Project

How to be part of a team and lead a team.

There's one book to read - The Five Dysfunctions of a Team.

I read this book, and it opened up my eyes. Working as part of a team is THE most valuable thing I've learned.

Fairly frequently while I was in college; I shopped up to about a shelf's worth then.

I find that I go to books far less frequently now. Part of it is that I'm much more invested in the current technologies I'm using. Another part is that many books are of the "learn X language!" type, and I know enough general programming that those aren't as useful.

The things I still buy are things like The Mythical Man-Month, Scalable Internet Architectures, and Design for Hackers - that is, less reference and more for reading to get ideas from.

This book https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 is really helpful.

I've heard good things about these books; Cracking the Coding Interview: 150 Programming Questions and Solutions and Programming Interviews Exposed: Secrets to Landing Your Next Job

Refactoring: Improving the Design of Existing Code

Peopleware - Gives interesting insights into the "soft" side of software development

How comfortable are you with proofs? If you are not yet comfortable, then read this: How to Prove It: A Structured Approach

Besides the Soft Skills book I also like the Soft Skills Engineering podcast

Please go and buy and read all of these this week, for the sake of you and your team:-


https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897


https://www.amazon.ca/Managing-Humans-Humorous-Software-Engineering/dp/1430243147


https://www.amazon.ca/Debugging-Teams-Productivity-through-Collaboration/dp/1491932058


https://www.amazon.ca/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756

Skiena's Algorithm Design Manual - It gives you an overview of what classes of problems exist and how real world problems can be expressed as instances of them. It doesn't always give you the step-by-step directions of how certain algorithms work, but it gives you enough of an overview to understand the problem and points you towards existing implementations.

It's certainly one of the most useful books I used when preparing for interviews (and comes in handy in the real world as well). As an anecdote, in one interview at a big-N company, I was presented with a problem, said "based on these factors I'd treat this as a network flow problem by doing X", and that was the only buzzword needed - rather than watch me try to write a solution to a known problem, we were able to move on to other questions. Without knowing that term, I probably would have spent the remainder of the interview trying to optimize a solution to the problem instead.

As others are bound to point out, read through Cracking the Coding Interview and/or Programming Interviews Exposed. Both books walk you through a large variety of common technical interview questions--with an emphasis on the reasoning to get to the correct answer.

Keep in mind that many of the problems you face aren't going to be in those books. The key is to be able to recognize the problem and then use something from your toolkit to solve it. Part of this is practicing these kinds of problems (the above books will help, as will puzzle sites like TopCoder, Google CodeJam, Project Euler, etc.) so that you know how to recognize the problem. The other half is just having a big tool box. You need to be pretty solid in fundamentals like sorting/search algorithms, data structures (trees tend to be especially popular), recursion, etc. During the interview, constantly communicate your reasoning and what you think the problem represents and why you're going to use a specific kind of solution.

Here are some other great resources to look through:

Topics you should be familiar with

Variety of problems that you may be asked

A lot more resources

If you think you know Java, then read Effective Java.

Once you're through reading that, and you think that now you really know Java, read Java Concurrency in Practice.

There may be something more than these that's worth reading, but I haven't found it yet.

No internships at any point in my college or post-college career. I had a modest amount of projects, mostly relating to my coursework in school. My senior year I designed and programmed a video game with a team of fellow classmates, which was my main project on my resume.

As far as independent study goes, mainly hunting down UC Berkeley / MIT comp sci lecture series videos on youtube and watching them, using resources like hacker rank to work through coding exercises. I also read through the Algorithm Design manual https://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1849967202

• How to Refactor existing code http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ref=sr_1_1?s=books&ie=UTF8&qid=1415515846&sr=1-1&keywords=refactoring
  
• How to work with Legacy Code - http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

[Mythical Man-month] (http://www.amazon.com/gp/aw/d/0201835959?pc_redir=1398129703&robot_redir=1)

Focus on other aspects. Reading and being able to talk architecture has gotten me a lot further than the “cracking the code”, leetCode type of stuff.

(None of these are affiliate links)

https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164

https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420

https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599

https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X

I think it's Domain Driven Design

Data Structures for Coding Interviews in Java: From Soup to Nuts
Data Structures and Algorithms in Java (2nd Edition)

A few books that I have been going through: Programming Interviews Exposed, The Algorithm Design Manual, and Designing Data-Intensive Applications.

If you know social skills are your problem area preventing you from getting a job, then why not work on them? Despite what you seem to think, social skills are not some innate ability, they're learned, just like any other skill.

Try putting yourself in more situations where you're forced to interact with people. Read some books on the subject. Find and join a ToastMasters group. If you need a job and at least some semi-relevant experience, try getting a low level help desk position.

In no particular order:

Structure and Interpretation of Computer Programs

Code Complete

C Programming Language(K&R)

The Pragmatic Programmer

The Mythical Man Month: Essays on Software Engineering

Introduction to Algorithms and/or Algorithms