(Part 2) Top 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.

I'm a software dev with 9 years experience, and even I have difficulty finding work. I live in Colorado as well. My qualifications are impeccable. But I still get "no's" for absolutely no technical reason.

My best advice? Work on your resume wording, and your interview people skills. Use active words on your resume, like "initiated", "spear-headed", "lead", "started", "identified". Words that scream out "I'm a leader". It doesn't matter if you have no desire to go into management. The more your resume reads as "I'm a self-starter, I'm a leader, and I'm ALWAYS learning", the better your chances.

Sadly skills alone are becoming more and more ubiquitous. There are scores of self-taught developers out there that dilute the market for people with actual degrees. Budgets being what they are, if a company needs JUST a code monkey, they're going to hire the cheap one. Your degree actually puts you at a slight disadvantage in that arena.

However, if they're looking for a long-term (i.e. quality) person, they're going to hire someone who has NOT ONLY the technical qualifications, but also fits the "perfect employee" model that they have envisioned. This means: pleasant to be around, good customer / people skills, confident (but not cocky), positive attitude. You know, the stuff an HR person would care about. Sit up straight. Make eye contact. Smile. Firm handshakes. Dress well (not too nice though, developers get a bit edgy around folks in suits). Address people by their name. Do not curse. Do not be overly familiar. Do not volunteer too much information (especially things like health conditions and personal quirks). You're interviewing with human beings, who are vulnerable to "gut feelings", "first impressions", and other vague means of evaluating a candidate. Give them every reason to have a good "gut feeling" about you.

This is important: do research about the company before you come in. If you come in, sit down, and act confused about what their business even does, they're going to think you don't care. Find out what the company does, find out what products they make, what their business model is, etc. Find out (if you can) what the employee atmosphere is like. Do everything you can to show that you actually really WANT to work there. This also means attaching a custom cover to your resume, and showing a similar amount of attention to detail that screams, "hey I did this JUST FOR YOU".

As for the technical qualifications, your degree just says "I can be taught". Nothing more. A company who sees a candidate with a degree and a small amount of experience WILL expect you to work for a rather modest paycheck. You CAN scare them off by throwing out a number that's too big. Research the company you're looking at. Use sites like glass-door to find out what level 1 (or similar) engineers are paid. If you can't find information on the company's pay, find a similar-sized company in the same industry. Try to get a realistic idea of what to expect, salary-wise. You can PM me and ask what I made at my very first "real" job after getting a degree.

Also make sure you have a LinkedIn profile. It's surprising how many recruiters hang out on there, just doing searches for keywords, contacting everyone who pops up.

I know you're having a hard time right now, and I know it can be VERY discouraging hearing "no" after "no" (or the classic, "we've decided to proceed with another candidate" line). ALL IT TAKES IS ONE YES. You might be one interview away, but you won't know unless you keep trying. YOU CAN DO THIS. I know it's a lot to keep track of. I know it's a ton of stuff to remember. And I know putting on a brave face especially in the face of financial uncertainty is all but impossible.

I'm not a big believer in positive thinking. But neither am I a big believer in negative thinking. Your post comes across as being incredibly pessimistic and defeatist. While I understand that this is your reality (and please know that this IS a safe place to vent), you need to make absolutely CERTAIN that you leave that attitude at the door when you're interviewing. You're interviewing with people who can and will pick up on that if you're not careful. And like I said, sometimes all it takes is that "unpleasant gut feeling" to cost you the job. Don't give them ammo.

One more word about technical qualifications. Smaller companies put a big emphasis on experience. But larger companies know that experience is cheap, and that what really matters is that you understand the fundamentals. Make sure you understand the fundamentals. This means data structures and algorithms mostly. If it's in your budget to do so, pick up a copy of The Algorithm Design Manual. Once you have a good grasp on the concepts in that book, most white-board coding exercises become much easier. Also, make sure there's (at least) one language you understand REALLY well. Whether that's javascript, or Python, or C, or Perl, or PHP, or Java, or... doesn't matter. Just make sure you have one language that you can actually code competently in.

I know you said you can't move. I live in Colorado Springs. Not sure if that's considered a "move" for you. I work at a DoD company that currently has a number of openings for Java developers, and Javascript frontend developers. It's a modest-sized company (600 people, ish). Your Asthma won't phase them at all (though frankly you really shouldn't ever bring up health issues in an interview). If you're interested, PM me and I'll give you the company name and a few tips about what they're looking for.

If you're interested I can also take a look at your resume and let you know if I see anything that could use some improvement / modification. I know it's really hard to get feedback about resumes. I'm not a hiring manager, but I've spent years perfecting my own, so I like to think I know a thing or two on that subject.

Best of luck.

TL;DR: Just read it. Sorry.

EDIT

I just want to also throw in that I agree with /u/akhbhaat about the gap on your resume. That's not an insurmountable problem, and some companies would still hire you. But, in the words of Ricky Ricardo: "you got some 'splainin' to do". It's not a deal breaker, but it does raise eyebrows. Unemployment can become self-perpetuating because companies assume you're not good enough to be employed. It's bullshit, of course, but it IS now up to you to either take corrective action (go back to school), or come up with a really good excuse as mentioned.

EDIT 2

I also agree with all of the comments about side-projects. Side-projects are a way of showing a company, "I may not have been employed, but I was still actively developing my skills". It also kinda gives them the idea that you're passionate about the field, which is an extremely good impression to give.

Sites like Project Euler and Topcoder might provide a good starting ground to just get you warmed up a bit. Also you may want to consider registering on Stackoverflow and answer some of the questions you know the answers to (don't worry about reputation on there, no one cares). But if you really want to impress them, go start or contribute to an open source project. Doesn't matter what. Doesn't matter what language. As long as it's challenging to YOU and actually teaches you something.

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 have some advice for you. I'm speaking more from the position of someone who didn't do a lot of these things and regrets it than someone who can say for sure what you need to do, but I still think I have some helpful advice:

First and foremost, take a little time to enjoy your last summer before going off to university. I'm not saying you shouldn't also learn some CS, but honestly if you're the type of person who knows how to study and is willing to go to class and put in the work you already have a "head-start" on a good percentage of your classmates. And frankly, life gets a lot more stressful after high school. Enjoy yourself. You're right that AP courses aren't representative of the college experience, but your first year's coursework isn't going to be too scary. If you can handle AP, you can handle your freshman level coursework. Go to class, take good notes, and be an active participant in your courses, and then study afterwards. That's 90% of college success in the classroom. Doing well in the classroom isn't the only thing you need to worry about though (more below).

If you'd like a little summer reading, I personally found this book really enjoyable. Picked it up during my freshman year IIRC: https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_1?ie=UTF8&qid=1541924346&sr=8-1&keywords=code

It is both very informative and a fun read.

If you've taken AP Comp. Sci. then I'm assuming you can code a bit. If you want to do some programming I'd recommend sticking to what you know and deepening your understanding of it or trying out the language that your university starts you off with. They might even be the same language. Don't worry about learning multiple languages yet. You will likely be introduced to several languages in undergrad. Focus on the fundamentals.

Get connected at your university. Universities have a lot of resources for people interested in research. For example, my university had an undergraduate research program. They also had a student success center with people equipped to help you develop a plan (which is what you're trying to do now) to get to where you want to be, including graduate school and beyond. Be an active participant in your CS classes. You're going to have some shitty professors but you'll likely meet some really cool people too, who are passionate about what they do and who have the connections to help you if you show some initiative. If it's a larger school there will also be plenty of student organizations for you to check out, both explicitly CS-related and basically anything you can imagine. Don't be afraid to check out non-CS stuff. See what your university has to offer. If you don't know where to start, check out the website and once you get on campus seek out the equivalent of what I called the student success center. They will be familiar with all of the programs and services that your university offers at a broad level. Should be pretty similarly named. Also, ask your professors! At my university student organizations had faculty advisors and even if your professor isn't that person they will probably know who is.

Final note: while you should be active, have a plan, and get involved, don't try to do too much at once. You will burn out. You need to be honest about your limits. It's healthy to push yourself, but only if you are mindful of what you can handle. And if you find yourself struggling, do not be afraid to seek out academic coaching. If you have trouble adjusting to the university experience (very common and nothing to be ashamed of) your university might also offer access to therapists. Finally, if you have a diagnosed disability, make sure to register with disability services to receive accommodations!

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

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.

The best way I know how is by solving problems yourself and looking at good solutions of others.

You could consider going back to "fundamentals".

Most programming courses, IMO, don't have nearly as many exercises I think they should have. Some books are particularly good on their exercises list, for example K&R2, SICP, and TC++PL. Deitel's has long exercises lists, but I don't think they're particularly challenging.

There are some algorithms/DS books which focus on the sort of problem solving which is about finding solutions to problems in context (not always a "realistic" one). Like the "Programming Challenges" book. In a book like that, a problem won't be presented in a simple abstract form, like "write an algorithm to sort numbers". It'll be inside some context, like a word problem. And to solve that "word problem", you'll have to find out which traditional CS problems you could solve/combine to get the solution. Sometimes, you'll just have to roll something on your own. Like a new algorithm for the problem at hand. In general, this helps you work out your reduction skills, for once. It also helps you spotting applications to those classical CS problems, like graph traversal, finding shortest plath, and so forth.

Most algorithms/DS books though will present problems in a pretty abstract context. Like Cormen's.

I think, however, people don't give enough credit to the potential of doing the exercises on the books I've mentioned in the beginning.

Some books I think are worth reading which also have good exercises:

• http://www.amazon.com/The-Programming-Language-2nd-Edition/dp/0131103628 - K&R2
  
• http://www.amazon.com/Elements-Programming-ML97-Edition-2nd/dp/0137903871
  
• http://www.amazon.com/Database-Systems-Complete-Book-Edition/dp/0131873253
  
• http://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871 - SICP
  
• http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840 - TC++PL
  
  I imagine the other Stroustrupp programming book also has good exercises, but I've never read it. Brian Kernighan is not only the author of K&R2, but of many other books. You could look at his stuff.
  
  Depending on what you mean by good code, though, you could look at other books.
  
  There are also the math books. I'd not discard those. And also, there are other programming books as well. Some I've never read, but want to, like Programming Pearls:
  
  
• http://www.amazon.com/Programming-Pearls-2nd-Edition-Bentley/dp/0201657880
  
• http://www.amazon.com/More-Programming-Pearls-Confessions-Coder/dp/0201118890
  
  Not only those, but, anyway... The point is that you can look at those books to find examples of good code, good exercises, challenges and so forth.
  
  Here are some books I've mentioned previously:
  
  
• http://www.amazon.com/Programming-Challenges-Contest-Training-Computer/dp/0387001638 - Programming Challenges book;
  
• http://www.amazon.com/Introduction-Algorithms-Edition-Thomas-Cormen/dp/0262033844 - Cormen's (and other 3 authors) book.
  
  By the way, there are websites with programming challenges for you to look at too. Like https://projecteuler.net/ and others. Just start looking this up and you'll find plenty. They all tend to start dumb easy and move up the difficulty to pretty damn difficult stuff from what I've heard.
  
  Edit: SICP is available for free (http://mitpress.mit.edu/sicp/) together with videos from the course taught at MIT in 85 (http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/).

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
   
   
   

These are books I actually own and would recommend. Of course there are other great/better books out there, but I'm going to stick with what I've actually bought and read or "read".

I say "read" because several books are NOT meant to be read cover-to-cover. These typically have about 1/3 that you should read like normal, and then skim the rest and know what's in the rest so that you can quickly reference it. These books are no less important, and often even more important. I've marked these kind of books as #ref for "read for reference". Normal books that should be read cover-to-cover are marked #read


For learning your first language: This is really the hardest part and unfortunately I don't have any books here I can vouch for. I started with "C++ for Dummies" and am not including a link because it's bad. Your best bet is probably "Learning <language>" by Oreily. I also love the Oreily pocket books because you can carry them and skim while on the bus or the john, but you can just do the same with your smartphone. Pocket Python, Pocket Java, Pocket C++

Top Recommendations:

Accelerated C++ #read Made for people who already know another language and want to pickup C++. Also great for people who need a refresher on C++. I really like how it doesn't start with OOP but gets you familiar with the imperative parts of C++ before diving into OOP.

The Algorithm Design Manual #ref This is my new favorite book and the first I would send back in time to myself if I could. Each algorithm & data structure is given a mathematical breakdown, pseudocode, implementation in very readable C, a picture (very helpful), and an interesting war story of how it Saved The Day.


Cracking the Coding Interview #read I originally avoided this book like the plague because it represented everything I hate about coding interviews, but many interviewers pull questions straight from this book so this book can equal getting a job. Put that way, it's ROI is insane.

The Pragmatic Programmer #read Must-have for any profressional software engineer that covers best-practices for code and your growth. You can also find the raw tips list here

Head First Design Patterns #read Many prefer the "GoF/Gang of Four" Design Patterns which is more iconic, but Head First is a modern-version using Java to cover actual design patterns used day-to-day by programmers.

For Intermediates:

Effective Java or Effective C++ and Effective Modern C++ #read When you're ready to go deep into one language, these books will give you a huge boost to writing good Java and C++.

Design Patterns #ref You'll want to get this at some point, but early on it's too much for a beginner and many of the patterns are obsolete.

The Art of Computer Programming #ref The programming "bible" but like Design Patterns you should hold off on this iconic book until you've got your basics covered. It would make for a great purchase with your first paycheck or first promotion :)

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!

> Structure and Interpretation of Computer Programs

I haven't read that book, so I just looked it up. And hey, the top review on Amazon is by Peter Norvig! Cool. It sounds like an interesting book, but definitely no replacement for a dedicated algorithms text. So, you do what I did in my schooling when faced with profs who assign the wrong books: you get the right books and read them on your own. :-) I did this in addition to reading the assigned garbage. Eventually after reading enough books on your own you realize that you can get any college education (minus the magic piece of paper) by just reading (to the point of true understanding) books.

I've read a handful of algorithms textbooks. The thing about this field is that a lot of concepts won't click the first time. So relearning is never a bad idea, even as a seasoned pro. When you interview for jobs eventually you'll probably go back and read an algorithms textbook again, assuming interview practices are still the same at that time, and you want a top company. The first algorithms book I read was this one which I think is much better for a beginner than CLRS. But if you don't know Java, you might have to learn it, which will require serious effort if you're learning Scheme at the same time too. And really, Scheme??? At least teach the kids something they can use in their career. Although, I admittedly learned a lot of really cool algorithms in Prolog, which I learned just for that class and promptly forgot how to use afterwards, and never used again. But the algorithms stuck with me. My favorite algorithms book is The Algorithm Design Manual by Skiena, but it's also not good for beginners. If you read Lafore, CLRS, and Skiena, you'll be an algo pro by the end of all that. :-)

I will suggest start with Head first design pattern. That will gradually build your intuition about good software design. And it’s more fun to read compared to GoF imo. On top of that, there are Youtube videos by a guy named Christopher Okhravi on design patterns. Since I understand much better with videos (along with text book) because of my attention deficiency, they really helped me.

Apart from that, follow tech blogs of Netflix, Google, AWS, Uber etc. They are treasure troves.

Also, as /u/ibsulon mentined, Clean Code for writing good quality code, Programming Pearls and Pragmatic Programmer etc. Effective java and Doug Lea's book on concurrent programming - really helpful.

Ah those are both excellent suggestions!

Code is a great book - If a programmer newcomer reads Code and doesn't find it interesting, that's a no a good sign, as all the concepts in the book are vital, and presented very well Link: Code by Charles Petzold

And medical science background is a great lead-in to bioinformatics - in that area OP would have a lead on other straight-CS programmers. And bioinformatics uses a lot of Python, which is pretty easy to learn.

Congrats! I'm on such a programme at the University of Bath in the UK right now. Bath's programme teaches C and Java, with a little Python in some elective modules. There are also theory of computation modules with a bunch of discrete maths in.


If you let me know which specific course you're attending, what your undergrad was, and how technical a career you might want I can give more tailored advice.


I did the following for prep, after researching what modules I'd be taking:

• MITx's Intro to CS MOOC (amazing)
  
• Read and did all exercises from several relevant chapters from a "Discrete Maths for Computing" textbook I got second hand for a fiver (helped a lot in a maths-heavy module)
  
• read the oft-recommended book Code (useful for awareness, but not essential, especially since we do no Comp Arch at Bath)
  
• did some algorithm challenges at places like leetcode.com and firecode.io once I had done the Intro to CS MOOC
  
  
  Conversion masters are generally very intense so doing prep now and over summer is a great idea. The stuff I listed helped immensely and I would do the same again - perhaps I would switch the MITx MOOC to Harvard's CS50 instead since CS50 has a bigger spread of languages. If I had had more time on my hands, proceeding from here to do a Java MOOC would have been really useful also.
  
  Working on the Leetcode/Firecode challenges helped a lot for general programming practice, and will also be helpful prep for job hunting later.

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!

There's good advice here. Did you master JavaScript on the way to CoffeeScript? If not, pick up Crockford's Javascript: The Good Parts - actually, either way, read that book if you haven't already.

If you know JS well, you should do a couple of side-projects in Meteor. It's an interesting framework that embraces "Reactive Programming".

Here's a few other things:

• Node.JS
  
• MongoDB
  
• Redis
  
• Memcache
  
• Ruby (if you like CoffeeScript, this shouldn't be a massive leap)
  
• jQuery/Backbone or Angular/SASS/Susy/Yeoman (if you want to do front-end stuff)
  
  Good luck!

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.

• Aduni algorithms course - i plan to review that course soon.
  
• For my class, we were assigned Algorithm Design - Kleinberg, Tardos. It's readable but from what I heard, CLRS is the undisputed recommended text, best read that one first.
  
• Algorithms: A Creative Approach - some say this one is a good alternative if you're after a less mathsy version

I wouldn't try to read programming tutorials during commutes, as programming is best learned by trying out exercises in a real text editor / terminal as you follow along in the book. Only something like Microsoft's Code would make for light, commuter reading.

As for podcasts, The Verge is a fun tech podcast.

I've started listening to Welcome to Night Vale, a fun, nontech podcast.

Closures are actually a somewhat important concept in Javascript. If you don't understand them then one day you'll probably get some weird this bug working with callbacks and you'll waste more time than you need to trying to figure out what's going on.

This is just my personal experience, but I felt that when I had a Javascript interview coming up I would always take some time to review this book:
https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=sr_1_1?ie=UTF8&qid=1501136583&sr=8-1&keywords=javascript+the+good+parts

It's worth it to read in my opinion, it covers pretty much everything you would probably be asked in a Javascript interview, and it's very short.

It helps me a lot with Javascript stuff. The other stuff, like the Java stuff, you could probably just google it. There's a standard set of OOP questions that interviews just like to ask all the time.
http://java-questions.com/oops-interview-questions.html

The most recommended books usually are on this list:

• The /g/ Reading List
  
  Also, I just heard about these two books and they are supposed to be good as well:
  
  
• The Complete Software Developer's Career Guide
  
• The Passionate Programmer
  
  If you're interested in the world of startups, I would also highly recommend this book:
  
  
• Hello, Startup
  

I just saw your edit. Since you are not looking for books just like Grokking Algorithms, I will suggest another amazing book on algorithms.

https://www.amazon.co.uk/Algorithm-Design-Jon-Kleinberg/dp/0321295358

Algorithm Design by Kleinberg and Tardos. I thoroughly enjoyed it and I highly recommend it to anyone interested in algorithms. One of my favourites.

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

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

It's time complexity of algorithms. It's asking for big O, which is worst possible time your algorithm would take given a data input, usually n being the size of the array/list or whatever.

Hash tables are 0(1) because true hash tables uses a function to map 1:1 for all given inputs. For fun(y) => x, every x is generated by a unique y. If it's not a true hash table (ie not a 1:1 map), then you use chaining or bucketing. Chaining is guaranteed 0(n) time and uses no extra space and bucketing is guaranteed 0(n+t) where t is the largest bucket but requires extra space (tradeoffs!).

It's important because it's efficiency. You can program things 1000 ways. Given an input of 10 items, algorithm A (lets say runs in O(n)) and algorithm b (runs in O(n!)) may perform in nearly the same time and produce the same output. But given a list of 100000 items, algorithm B would take years to complete the task, when algorithm A would do it in ms.

Although I'm just about to graduate and don't have a real job yet, I recommend picking up something like this. You can find a pdf with minimal effort. The first few chapters really nail into it well.

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.
  

If I was to make a guess, it is that your problem is not your technical skills. You can be the best programmer in the world, but if there are behavioral or cultural red flags you can have huge problems finding a job. What does a Google search for you turn up? How do you act in interviews? How are you to interact with? Those kind of things. A good starting point for addressing these issues is Land the Tech Job You Love. For general career development I have enjoyed The Passionate Programmer personally.

If you're relatively new to OOD and OOP, I'd look into the Head First books. They do a great job cutting ones teeth on the topics. If that's too rudimentary for you then the GO4 book on reusable design patterns. This is the bible on design patterns for Software Engineers. As for SOLID There is a smattering of information. Basically this consists of five principles:

• Single Responsibility classes
  
• Objects are open to extension but not modification
  
• Liskov substitution principle, In a nutshell objects that inherit from other objects should not have less functionality than the objects from which they inherit.
  
• Implementation of interfaces
  
• Dependency Injection.
  
  There's a smattering of information around the web. That should be enough to get you started.
  
  As for implementation. One thing I've done in the past is to take a simple programming exercise, e.g. FizzBuzz and see if you can't write a solution that implements SOLID. so you can create different rules via extension. Things like that.

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.

It does look like spam. Sorry.

I did not buy the course, but I've watched a few of his videos on YouTube. His thesis is to think of your career as a business, and to learn how to market yourself so that work comes to you, not the other way around. Pretty insightful stuff.

Irregardless, $299 is way overpriced. You can find the same advice in Chad Fowler's The Passionate Programmer.

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

Always be learning.

Carry a notebook around with you. I usually use the cheap ones with metal spiral binding. At the end of the "back to school" sales, they can be like 25 cents each, so I stock up for the year. In this journal keep notes of what you do each day. Also things like server names/configurations, bugs, tips on using tools like bug tracking, other workers, conference calls. I'd write dates on the front cover (start & end date so you can go through a pile of them real fast). This way you can look back at something you did a couple weeks ago and find it easily. In college, I'd keep one of things I read (books, journals, blogs). You might want to keep your research one separate from your work one.

One book I recommend is Passionate Programmer. The title for the first edition was "my job went to India". The 2nd edition covers lots of things you should know about working in companies. Most folks will learn them eventually. Reading lets you save lots of time and pain for education. Despite what we want to believe, America is not a meritocracy, some amount of politics is essential to survive in any job. Some companies need more than others.

In some companies, being on IM or skype is seen as screwing off. In others it will be seen as an essential work tool. Pick the hills you are willing to die on.

Find blogs and podcasts/videos for your frameworks. When you have some decent expertise there, expand to other frameworks/languages. Don't get pigeonholed into one tech. If that tech dies, you're unemployed.

Stay physically active. Gym, walking, running, biking. Something. It helps fight off depression and keeps you mentally fit as well.

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.

Steve Yegge's 5 Essential Areas

When I was preparing to interview I broke up the studying into the 5 areas mentioned in Steve's post. From my experience, the two most critical things are:

• Writing reasonable code on demand (like on the whiteboard)
  
• Knowing the core data structures (including time and space complexity)
  
  If you have never written code on a whiteboard, you need to practice -- it isn't natural and will almost certainly trip you up. For the data structures, try explaining something like a heap or a map a friend who has no background in CS. It will get you comfortable talking about that kind of stuff and also help cement your knowledge. This book is excellent as a resource.

One book that helped me a lot while starting out and which I highly recommend to any new student of computer science is Code: The Hidden Language of Computer Hardware by Charles Petzold, which starts out as a general interest book about the history of computing and then very quickly ratchets up into how modern computers, compilers, operating systems, and hardware drivers are built. You basically have to learn some discrete math and assembly language just to follow along, and by the end you have a really good idea of what happens under the hood when you run your programs and why.

Check out Structure and Interpretation of Computer Programs.

https://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871

I'm pretty sure you can find a PDF for free, if that's too much.

If you want to understand how a computer works from the ground up, this book is pretty great: https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

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.

Thank you! I'm actually realizing that I learn more from my textbook than I do from the lectures for my intro class, so after my midterm tomorrow I think I'm going to focus on reading ahead for the next couple weeks and spending the second half of summer getting a handle on data structures and algorithms.

Aaand I just looked it up, the data structures course just has a C reference book and the algorithms course doesn't have a required textbook. I'll have to look into which textbooks are commonly used for those classes elsewhere.

I'm also planning to read MIT's Structure and Interpretation of Computer Programs at some point, cause I heard it was a really good intro book. Should I try to get through that first and then hit up data structures and algorithms?

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.

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

It's going to be hard, make no mistake about it. Most places won't want to interview you just based on the fact that you haven't worked for 10 years after graduating. There's going to be some level of disappointment and you'll need to be ready for it.

If your knowledge of C++ comes from school, it's likely at a basic level. Improving on C++ is generally harder than just learning .Net, Java or python.

But if you do feel comfortable with C++, I would suggest getting a more advanced level book rather than relying on online tutorials. My favorite one is Effective C++ from Scott Meyers. Try finding a used version to save money.

You will also need to meet recruiters and be confident but open with them. This is a trial and error with a low hit rate but I would suggest doing it anyway.

You could also sign up for a coursera or udemy course on web development and start creating a project. Make sure you get a github account to showcase your web development skills to any potential employer.

Read Effective C++ and Effective modern C++. In my opinion, theses books are miles away from any online guides. There's some pdf of those books on some (not legal) webite, but they are a very good purchase.

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

Books:

The Pragmatic Programmer ($30)

Clean Code ($40)

Structure and Interpretation of Computer Programs ($40)

T Shirts ($20-30):

Works on my machine

Hello world

Other:

A nice coffee mug or teapot for the office

Nerdy desk top calendar

Introduction to Algorithms

Structure and Interpretation of Computer Programs

I linked to Amazon but obviously these can be easily found as .pdfs.

http://www.amazon.com/Passionate-Programmer-Remarkable-Development-Pragmatic/dp/1934356344/ref=sr_1_1?ie=UTF8&qid=1422574454&sr=8-1&keywords=A+passionate+programmer&pebp=1422574452299&peasin=1934356344

Read that. Seriously. I am half way through it and it is amazing

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

For the first two I think OP means:

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8

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

I'd also recommend:

https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073


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

I'd read through this book:

http://www.amazon.com/Algorithm-Design-Manual-Steve-Skiena/dp/0387948600

(I've noticed pdfs of that books on some .edu's in .cn, but I'm not going to link those here.) Be prepared for tree traversal type questions.

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

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

This could keep you busy : )

http://codeidol.com/csharp/learncsharp2/Object-Oriented-Programming/The-Three-Pillars-of-Object-Oriented-Programming/

http://en.wikipedia.org/wiki/SOLID

http://en.wikipedia.org/wiki/SOLID

http://en.wikipedia.org/wiki/SOLID

http://msdn.microsoft.com/en-us/library/ms379570%28v=vs.80%29.aspx

http://msdn.microsoft.com/en-us/library/ms379570%28v=vs.80%29.aspx

http://msdn.microsoft.com/en-us/library/ms379570%28v=vs.80%29.aspx

http://www.amazon.com/Introduction-Algorithms-Thomas-H-Cormen/dp/0262033844

http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read

http://en.wikipedia.org/wiki/Dependency_injection

http://www.engineering.cornell.edu/academics/undergraduate/curriculum/handbook/

http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=IntroToDatabases

(Or the equivalent for your stack) http://www.target.com/p/querying-microsoft-sql-server-2012-mixed-media-product/-/A-14259758?ref=tgt_adv_XSG10001&AFID=Google_PLA_df&LNM|14259758&CPNG=NoCPNG&ci_src=14110944&ci_sku=14259758&kpid=14259758&LID=PA&ci_src=17588969&ci_sku=14259758

Git

Pick One: Java / c# / [C++](http://en.wikipedia.org/wiki/C%2B%2B

Pick One: C / JS

Pick One: Ruby / Python / Lisp

Contribute to open source.

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742

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

Code: The Hidden Language of Computer Hardware and Software

This book starts with flashlights and Morse code and Braille, goes to telegraphs and electricity, works it way up to Boolean logic gate circuits (still using the components from telegraphs!) and then goes all the way to programming languages and computer graphics.

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

Most of the design patterns introduce by GOF (gang of four) is still applicable today. Buy and read this book

design patterns are language agnostic, so it shouldn't matter which language a book opts to teach in. this book is generally regarded as a paramount resource in learning design patterns

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.

You're missing concurrent programming, alternative paradigms and algorithms.

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