Top products from r/cscareerquestions

Hahaha, you're right, my post sounds totally creepy, sorry about that.

What I got from you is that you're basically dealing with 2 issues:

Lack of knowledge, skills and experience: it's like you have 4 times 1 year experience instead of 4 years of experience. Seems that you miss being exposed to different challenges and solutions to those challenges.

Imposter syndrome - fed by the previous one

First, it's important to acknowledge that both these problems will follow you throughout your whole career. The very nature of our industry, whit new tools, languages, frameworks and techniques appearing litterally everyday, makes it impossible for someone to know everything. Given this scenario, we have to be smart about what and how to learn things and, at the same time, be confortable being unconfortable.

I think those are a whole new discussion (we can talk about it if you want) but I'd like to suggest some tactics that might help you on a shorter term:

Join a community

This was what made THE big difference for me years ago. I didn't know anything other than what I did at my job; the community showed me different ways of doing my work that I didn't know even existed. It's a perfect space to learn, share experiences and network. Try to join a local community that has in person meetings. I still get a lot of energy from interacting with people from outside my job.

Pair programming

I don't know if your team does pair programming, but I'd recommend it. Even if you team doesn't do it, ask people if could pair with them for an hour or so on their tasks. Learn their style, how they use their tools, their shortcuts. Ask what they're thinking as they code. Discuss the solution being implemented, talk about alternatives.

I think pairing is one the best ways to learn.

Good article about techniques for pair programming by colleagues of mine

Start a pet project

Assuming you lack experience on backend development, I'd suggest you start building a complete web application on your free time. Build something that you care about and would actually do something, so you stay motivated. You can start with something very simple and add features as you go.

I don't know if you're interested in some specific language/technology and I don't know what your team uses on your current job (it would be nice to practice on something that would be immediately useful on your job), so I'd recommend something like Rails. Rails can be simple enough for a beginner to see progress quickly and has a huge community for support.

This app can be your platform to learn and practice a complete software development lifecycle for a typical web app - stuff like OO design, HTTP and REST, MVC pattern, unit testing/TDD, integration and functional testing, version control and how to deploy and operate a system in production.

You can share your code in GitHub and ask for reviews and feedback.

Teach

There's always someone that knows less than you do about a subject. Offer help on the communities you're part of, answer questions on reddit or stackoverflow, coach a new teammate... there are tons of opportunities. Teaching will make you feel good about yourself and will help you to reflect and understand more deeply the subjects you're teaching. Confidence + knowledge.

Host a lunch & learn or brown bag session for your team/company. You could share interesting stuff you're working on, cool technologies for your team to try or any other tech related subject. This can make you be perceived as the "go to" person on some subject and as someone who's making an effort to learn and share with coworkers, bringing lots of value to the team/company.

Books

I strongly recommend you check out Clean Code and The Pragmatic Programmer. There are many other great books I could recommend but those two were the ones that changed the way I see my profession.

I can think of a bunch other tactics to help you improve your skills and confidence, but I think this is enough to start a conversation.

Ideally, our jobs should provide all the opportunities to practice and accomplish all the things I suggested you do by yourself. But to get one of those jobs, we need to take the firsts steps. My point is that we should be in control of our career, not your manager/team/company. If we want to learn something, or use some tool or technology, we shouldn't wait for the opportunity to come.

Does this make sense to you? Is this helpful?

PS: I'm curious about a couple of points:

When you say "I've always struggled to build big features", what kind of features you're talking about? Can you be more specific?

When you say "I have to spend a really long time just thinking about some problem", what kind of problem is this?

I might have some insight about those issues.

> I just realized it's 900+ pages, sheesh. Is it still an easy book to pick up to learn the language?

It's still useful for learning it. If you want something more brisk, try Accelerated C++ which clocks in at under 300 pages.

> I just had a semester using Scheme and I really had a fun time using functional programming. It just feels more structured, but I don't know if that's a misplaced opinion.

> How easy would it be to transition from Scheme to Scala or Clojure? And can interesting projects be made in those languages? I only ask because I've tried to figure out what I could make with Scheme and came up empty-handed, so I'd love to find a functional programming language I can make something cool out of.

Functional programming is a great paradigm, makes a lot of things simpler. The languages also tend to have really awesome features.

Once you know one functional language, a lot of the core concepts carry over to other languages. Scheme and Clojure are also Lisp dialects so they will look very similar. Scala can be used in a very OO way because it was designed to be a Java replacement and to be easier to transition to.

There are certainly a lot of cool things out there written in functional languages. The Haxe framework is written in Ocaml. Netflix wrote their open source telemetry system in Scala. Clojure is used for web services and web applications, and there are some cool open source projects written in Clojure like the Light Table IDE.

> Is there a reason people want to use Haskell?

It's one of the biggest names in functional programming and is known for being a major source of research. It's older than a lot of the newer functional languages like Clojure or Scala, plus promises things like speed, easy concurrency, and doesn't require additional stuff like a Java runtime (like Scala or Clojure do).

> Speaking of FP languages, what're your thoughts on OCaml? I know Jane Street uses it, but that's about it, haha.

The ML family of languages is probably my favorite functional programming family. I learned standard ML in college and have also used F# a lot, which is derived from OCaml. I haven't used a lot of OCaml directly but I imagine it's awesome since I love f# and standard ML.

> Damn, never heard of NIST, it sounds like a fantastic resource! I haven't even seen it linked on the sub before (which, given how often people ask for resources for DS&A, you'd think it'd come up.

It's really more of a basic cheat sheet without a lot of information. Years back when I did more DSA type interviews, it did help as a simple refresher.

> Do you by chance know anything about C and learning it via books? If so, do you think The C Programming Language is a good starting point?

I love C (but it and C++ have been replaced by Rust in my life now). That book (the K&R) is the de facto book for C and one of the best technical books I've ever read, it's very concise. However, it was also written thirty years ago so while it's still mostly useful, it serves more purpose as reference than as a "learn C" book. Though I also learned C from the book and then used additional resources to learn about the newer language features that came out with C99 and beyond.

I'd say give K&R a try - if you don't like learning from it then try Zed Shaw's Learn C the Hard Way which is a free eBook/website.

> Languages generally speaking have a documentation which specifies itself. That's the spec for the language. Someone interested in creating a compiler, interpreter, or some sort of analyzer, and so forth for the language needs to know how the language is supposed to work. The spec is the document which talks about that in detail. It's like the official documentation if you will.

Okay, that makes sense; so the spec is a document explaining the nuances and how the language works?

> "Minimalist" is not very exact terminology. It means the language has a small set of concepts and things that you can use. The nice thing about scheme is that from this small set of features, you can do tons of stuff. It usually implies a small set of keywords, but that's not just it. Generally speaking, it has a small features set, which isn't very exact terminology either.

That makes sense; so Scheme is minimalist in one sense that it might not have a ton of built in keywords, but with what it does have you can create a lot from it?

> These weren't courses per se. I did this before getting into college. The C programming I was talking about came from K&R2 (https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/) and looking things on the web. I think it helped. Not sure how much. I don't think the PHP web dev helped.

That book looks very interesting, I might take a look at it later on!

I only ask if the experience helped because I mainly want to see how ready I can before I go into SICP without spoiling myself, as I believe SICP is a great place to teach people concepts for the first time (even if they're not totally understandable, like in my case).

> I have no clue what is the better choice in here. Try both at the same time? I think MIT 6.00 even uses "how to think like a computer scientist" (the book I mentioned before).

Duly noted, might look into the lectures before I start SICP.

> Both. It's meant as an introduction to programming and computational problem solving. In one of the lectures I think the professor talks about how people do better in SICP if they take this course before.

If you don't know this answer it's totally fine, but does the lecture prepare for the content in SICP and how to solve the accompanying exercises?

> That is true, but there is more to it than that. Each language has its ways of doing things. When people are making new languages, they're highly influenced by other languages. To the point that most languages I've seen have nothing new but a few pieces, and most of everything else is just a "rehash" of ideas from other languages. Generally speaking, you'll see a lot of commonalities among several languages.

Can these commonalities be seen amongst different paradigm languages as well? Like are there commonalities between, say, Python and Scheme? I only ask because for example, I never saw the use of car and cdr as ways of accessing elements of a list before, let alone the heavy usage of recursion in a language. But perhaps that's because it's my first functional programming language

> It is true that each language has its style, but that style shares plenty in common with other styles from other languages. There will be things in common, and very rarely stuff you learn in one language won't help you in another language.

So even though there's different paradigms amongst languages, there's still quite a lot of shared aspects between them?

> In the end, you'll have a bag of cohesive programming techniques. That's not really language dependent as much as some people will tell you. Languages aren't that important as far as I can tell. I remember, back when I was starting to learn how to program, giving real importance to programming languages. Maybe they are really important, but it doesn't seem to me like they are anymore. The programming techniques and ideas behind them are though. The language is just a "conduit" by which you apply those techniques to solve problems, which has its importance but it's greatly exaggerated by most programmers if you ask me.

So it's more so the ideas that are developed through the languages that are important rather than the languages themselves?

> In fact, in SICP, you'll end up learning that a way to make problem solving more approachable is to make a language that is a better means to apply the programming techniques that you think help in solving the kind of problem that you want to solve.

That sounds incredibly interesting. I know I'll learn more once I read it for myself, but do they suggest that the way of approaching a problem is to define techniques or functions within the language itself that would help better solve it, or do they imply to switch languages entirely to solve it better?

> Nowadays, some languages are nice enough that you'll be able to do that by just cleverly designing a new library or framework. Making new languages is still valuable though, and in my opinion, underrated.

When you mean you can design a new library or framework, do you mean creating a whole new sub-language so to speak to deal with the problem, or do you mean just creating new functions that meet the solver's needs and isn't readily available (i.e. the goal the user had in mind isn't implemented in the language, so the user instead creates it themselves)?

In what ways are creating new languages underrated? Do you mean the experiences one has and take away from creating one that are underrated?

> I didn't see it emerging either. I started to study programming and CS in 2006 (I think). All I've said is based on "stories" and reads that came up while I was reading books, reading blog posts, talking to people, etc.

Yep, that's pretty much how my background about the older days of CS is built. Although I suppose it's the only way to learn about a time before ours in which CS was emerging.

Another standalone question, if you don't me asking for your opinion: I currently have a book on data structures and algorithms (aptly called Data Structures and Algorithms in Java by Robert Lafore) that I plan on reading. Would it be in any way detrimental to read that book, or at least begin it, before delving into SICP, and once I've completed my next CS course (taught in Scheme), then begin working on SICP? Again, I only ask because you're more experienced and I'd like to hear your thoughts on this matter.

I am going to give my perspective, but as always, your milage may vary.

>When and how did you start?

I didn't start programming until I started in college. I knew I was good at Math, and good at Science, and that I was interested in Computers. I pursued a CE degree (I was 18 at the time), and am now pursuing a Ph.D. in CS. My wife started her CS degree 1 year ago (she's now 25), after being dissatisfied with (and subsequently abandoning) a degree in Marketing. For the sake of mentioning it, we both started with Java.

My real point is: I don't think it's ever too late to start. If you're sincerely interested, your passion will take you far.

> What are some daily things you do that drove/drive you to your goals?

I consider programming a type of carpentry, and so, I strive (and don't always succeed) to program as much as I can, in as many languages as I find interesting. So far, I've programmed in Java, Python, Javascript, C#, C, Objective-C, and Lisp. It can be daunting to learn new programming languages, but I wouldn't worry. I got around to playing with each one because I found they were good tools for things I wanted to do. In academic circles, I believe that's called "project-based learning," where you learn as much as you need in order to complete some project or task.

> What books do you recommend, ones that have had a huge positive impact in your professional career?

I absolutely love the Head First series, and it made me value my own unique learning style (which in turn led me to discover that I learn better through projects). I own 6 Head First books, and I absolutely love each and every one of them.

My wife recently discovered (and I also really enjoyed) the book Cracking the Coding Interview, which is a concise review of the fundamentals of programming, as well as very good guidelines for doing well in your coding interview.

> What advice do you give to junior programmers that want to plunge into open-source community but are just overwhelmed by the amount of complexity in most of this projects?

If you're just starting out, I would start your own project to do something you want to do. The chances are that, in doing so, you will leverage someone else's tools, and in turn, you may discover that a tool you're using...
...has an obscure bug, or
...would be really great if it had this one other feature

You then contact the project lead (or project board of directors), and state your case, and then...BAM. You're an Open Source contributor.

> Which work-related fields are you most interested in?

I am a fan of artificial intelligence, and I think it's the bees knees. I also do game development, which I enjoy very much.

> What was your first big investment after your degree?

I bought a car, mostly because I needed it. Bear in mind, I am on a graduate student salary, which isn't necessarily the most financially rewarding position out there.

If you have any other questions, or if you would like me to go more in-depth into some of the previous questions, do let me know. :)

Yes! Also, quite honestly I don't know that many CS majors who took linear algebra at my school for whatever reason.

Where do you get started?

• If you're the type of person who likes an organized class to learn concepts, consider checking out coursera or other similar websites which offer free online learning courses! Check out their CS offerings and start from the intro.
  
  
• I must be known for spamming this SR with this, but check out CLRS, it pretty much contains most of the "CS math" you need to know for algorithms. As well as pretty much all you need to know about Algorithms and Data Structures for any basic job.
  
  
• REALLY make sure you understand your Algorithms and Data Structures, nearly every interview for a basic position centers around these topics. As well as some others, depending on the company: Bit manipulation, multi-threading, TCP/IP, etc.
  
  
• You want to learn some mainstream language as a lot of other people mentioned: C++, Java, C#, Python are a few that come to mind (though there are more like Ruby!). Side Note: Some people have differing opinions on whether C++ is good to learn as a first language. I don't know C# (but from its apparent similarity to Java) I would say C++ is probably the most difficult language to learn of the four I listed, but I feel that it also provides the most flexibility, because once you understand C++ it's easier to trainsition from C++ to Java, than say Java to C++ (similar for the other languages).
  
  
• Practice! Start working on some Project Euler problems, or other practice problems. Bonus: Someone in another thread mentioned that they made a blog post for each problem they solved and explained every one of their design decisions. This seemed like a bit over the top, but it really is a good practice for an interview and a job! You can even put a link to this on your resume to share.
  
  
• Find an Open Source to contribute to, come up with your own projects and post them on your github! This can show off your skills to a potential employer!
  
  Bonus for programming:
  
  
• When coding alone it's easy to get lost and start "hashing" together code. When you get to big projects, you'll find that this causes a lot of problems (and when working with other people it can cause even more). Some things to keep in mind when coding:
  
  
• Make sure your code is maintainable.
  
  
• Make sure your code is scalable.
  
  
• Test, test, test!
  
  Maintainable kinda means that your code is easy to test, easy to comprehend (by others) and easy to modify. Read up on different design patterns to learn more about this.
  
  Scalable is something you'll learn more about later, but basically it's kind of thinking about whether your code will be "good" enough to handle a lot of users (how fast is it how much memory will it take up)
  
  Testing is very important when coding. You want to try to write small pieces of code then test it (i.e.: make sure it works).
  
  All three of these things show up a lot in interviews, and if you can relate why you made your code the way you did to one of these three points (or something else) you should be pretty well off :D
  
  How do I land an interview?
  
  
• In your resume make sure to list any CS projects you want to mention, a link to your website (if you have one) or to other work. As well as Operating Systems you're familiar with (Linux is a big plus, but not absolutely necessary), IDE's you're familiar with (things like Eclipse, Visual Studios), and Languages you know. If you can, make sure to relate those three bullets to your project and work somehow to reiterate your experience with each language.
  
  
• A lot of recruiting is done on-campus, but there are other options, like applying online or even better...
  
  
• Network your way in. This gets your resume through the massive HR screen
  
  
• Edit, edit, edit (ask friends who are in the industry).
  
  How do I study for an Interview?
  
  Typcially, an interview will have you and the interviewer. The interviewer will first ask questions about you, what you're majoring in. And then maybe ask questions about your previous projects, and then he'll throw you a programming problem. Sometimes these can just be questions like "Which is faster: quicksort or mergsort?" or something like that, but other times they'll have you code something. If the interview is online, this will either mean you'll need to tell them the code you're writing or you'll code online on some collabarative envirionment (i.e.: you type the code online). If it's in-person they may have you write on a whiteboard. There are other formats of interviews as well, so make sure to research. Typically, for most larger companies, they won't care what language you code in (hopefully though it's mainstream!), but if you don't code in a language which they use, they may test you later for proficiency in one of their languages.
  
  
• As I mentioned before, Algorithms and Data Structures are usually go-to's for interviews, but other topics may come up so check out the req's for each job specifically.
  
  
• It may have been a while at this point since you studied your material, to brush up on interview questions, Cracking the Code Interview is a great book to brush up on your topics for an interview, it also has some resume advice, etc. if you choose to follow it.
  
  
• Be sure to practice talking out loud while you're coding, as this can help you during interviews. If you're stuck but your thought process is good an interviewer can help push you in the right direction.
  
  
• If you struggle with interviews, try having a friend who you know has experience and having him ask questions, better yet if you know a friend at the company, ask him to mock interview you.
  
  
• If you have time ALWAYS make sure you run test cases through your code mentally, and mention the test you're running and what it's supposed to catch (expected behavior) to your interviewer! If you have time and choose to ignore these, it can give the interviewer a wrong impression :\ (it also makes you look really good if you come up with all the boundary cases)
  
  Sorry, not sure if this helps or not!
  Good luck!

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.

Disclaimer: I teach at a bootcamp in the midwest.

Here are some things I'm noticing:

1. Your job sounds like it sucks quite a bit.
   
2. You're feeling a lot of pressure to make a big move right now.
   
3. You're feeling afraid that you don't currently have what it takes to make a big move.
   
4. You've got some funds saved up.
   
   I'm going to suggest a couple of things to try before you enroll in a boot camp.
   
   
5. Spend a few hours researching job boards in your area. Make a list of jobs where you've got 50% or more of the qualifications listed, or where the thing listed is close enough to what you already know that you could learn it sufficiently quickly. Make another list of things that appear pretty frequently, and see if you can categorize them. What's in your area? In my city, we've got lots of graphic designers who mostly build out Wordpress sites, a small but growing number of startups who mostly use Rails or an MVC Javascript framework, and a whole bunch of big finance corporations who mostly use Java. Your city is probably different, but it's also got some trends.
   
6. Reach out to your network. You surely know some folks from college, from meetups, etc. Don't tell them that you need to escape your current terrible gig, but do tell them that you're looking for a change and see if they know anyone who's looking for a junior dev, especially one with a CS degree. Be frank -- you've been working mostly QA and support for the last year and a half, and you'd like to move to development instead.
   
7. Take a few days off. They can even be unpaid days (if you can swing boot camp tuition, you can swing not getting paid for a few days). Doesn't even matter if you code on those days off. Just give yourself a chance to be a person.
   
8. Pick up a copy of Cracking the Coding Interview and practice. Don't know Java? No problem. Do the exercises in a different language. Do one-sided mock interviews and record your answer with your webcam, then watch it. Don't worry about 'ums' and 'uhs' -- instead worry about clear, concise, and precise responses. (NB: almost everyone hates watching themselves talk, and almost everyone finds it excruciating. Don't worry about that part. You don't suck anywhere near as much as you think you do).
   
9. Once your finances are set (i.e. at least 6 months worth of living expenses in the bank. Even better if you've got a year of living expenses, as that'll help if you've got an emergency), quit your job.
   
   From here, it's a matter of learning. You're never going to learn everything (there's too much out there), but you can definitely learn quite a bit.
   
   If you've got a CS background, you should be able to pick up the basics of Ruby on Rails. Michael Hartl's Rails Tutorial is pretty commonly cited; if you want to do web development, go through this tutorial twice. Maybe three times. Then start building projects on your own. Alternatively, Daniel Kehoe's Learn Ruby on Rails is also pretty commonly cited.
   
   A good understanding of Rails, plus a solid foundation in HTML, CSS, and Javascript/jQuery will make you a reasonably compelling junior developer for a company that builds web applications. Doubly so if you can show off a few good personal projects. A good bootcamp (like the one where I teach) will give you a structured and guided opportunity to learn these skills. A terrible boot camp will also give you this opportunity, but you'll have to work a lot harder on figuring out how to make it all happen.
   
   In addition to self-study and building projects, start attending meetups and actually talk to people.
   
   If you do decide to start looking at different boot camps, here are some questions to ask:
   
   
10. What will we be learning?
    
11. What sorts of jobs do graduates have?
    
12. What are your placement rates? How many graduates have internships after graduating, and how many go into full-time jobs? What sorts of support do you provide graduates who are searching for jobs? How long does it usually take for all the graduates from a given class to find jobs?
    
13. What is the typical experience for new graduates in their first 6 months as an employee?
    
14. What are some examples of student projects? What are some examples of average work? Some examples of really stellar work?
    
15. What opportunities will I have to design and build a project of my own determining? How many portfolio pieces can I expect to have by the time I graduate?
    
16. What are some examples of typical days?
    
17. Who's the instructor? How long have they been teaching? What are their qualifications?
    
    Of course they can lie to you, or use weasel-words to obfuscate, or make stuff up, or.... Of course that's the case.
    
    A good boot camp will give you lots of opportunities to practice AND will help you find your first job. We (where I work) do a lot of talking with recruiters and companies in our network, and we work really hard to make sure that our students get jobs that offer lots of opportunities for growth and development, and, when possible, that align with strengths and interests (there's not usually too big of a disjunct there). So far, we've had quite a bit of success in terms of our students finding employment, and even the companies that have been resistant to hiring students like our grads have started coming around (albeit slowly) as more and more companies hire our grads and have good experiences with them. But it'll be at least another year or two before our grads reliably get hired as junior devs in the bigger corporations (as their first or even second job) without first having a CS degree.
    
    There are lots of different ways you can find success, and almost anything you do (quit your job and self-study, stay at your job and self-study, go to a boot camp, backpack around Europe, and so on) can be reasonably explained in an interview, especially if you can demonstrate that you are someone who is smart and gets things done.
    
    Even your current job can be explained. Sure, your dev skills aren't what you want them to be, but you've got a ton of practice fixing code, which means you've got a huge list in your head of all the different mistakes you might make while writing code (which then means that you can, given adequate leeway, build systems that help you avoid or at least catch those mistakes). Don't discount that. It's important stuff that you learned, even if the way you learned it makes you feel really terrible.
    
    Hope this helps.

I'm doing EE/CS at a top uni. as well, and I was able to land a PM job after some hard work. Some tips I'd give:

1. Make sure you really want to be a PM, really research what it's about, and imagine yourself working everyday as one, will this make you happier?
   
   
2. Dedicate a technical class worth of time to do applications, interviews, emailing, and interview prepping. PM jobs are harder to find, particularly for new grads. You want to maximize your chances. I was spending nearly 3 hours each day on recruiting-related stuff during my peak month, going to at most 3 on-site interviews per week.
   
   
3. Taking business/entrepreneurship classes definitely helps, but make sure to not waste too much time learning the wrong things. For most new-grad PM jobs, you don't need to learn complicated economic mathematics or MBA-level management methods. You'd rather spend that time studying for interviews and analyzing the market.
   
   
4. Framework, market knowledge, and interview prep can only get you so far. You really need to like thinking about this stuff and have a good product intuition. My friend wrote a great blog post about new grad PM and she has some great tips. I'll paste her "why PM" here:
   
   > - If you have a creative vision
   > - If you love to talk about or review products
   > - If you like wearing many hats
   > - If you like shaping the big picture
   > - If you have a keen eye for design, but also the technical chops to run with the engineers
   > - If you are a technical person who doesn’t see yourself simply coding all your life
   > - If you are double majoring in computer science and [business, psychology, economics, etc]
   > - If you enjoy getting messy with data
   > - If you don’t shy away from problems but instead actively look for solutions
   > - If you can explain ideas well
   > - If you are interested in what the users have to say
   > - If you enjoy people
   > - If you send well-written, actionable emails
   > - If you are the master of your inbox
   > - If you like to move around and not sit at your desk all day
   > - If you can stay organized and on top of deadlines
   > - If you are passionate about what you do
   
   If this list doesn't sound like you at all, then no amount of interview prepping will come through as passion, good vision, and intuition.
   
   Lastly, get the book called Cracking The PM Interview. I won't try to parrot some great interview and company specific knowledge in this book, it helped me a lot.
   
   TL;DR: Make sure you actually want to be a PM, spend a lot of time writing emails/applications and studying for interviews, only take classes useful to PMing, and read that book.

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 looked at the FreeCodeCamp curriculum, it looks good for an entry level javascript developer, so since you already started it, you might as well finish it (since, like I said, everybody implicitly expects you to know at least one of python/js/perl as well as HTML+CSS).

2 hours per day is a bit too little IMO - but I understand that it's hard to find time when you have a demanding job and a family that needs time and attention. Just study as much as you can, 2h being the mininum (do keep in mind that CS students, your competition, will be studying at least 8h/day for at least 4 years with tons of homework and more advanced material). So you should probably focus on studying more in the weekends (just typing and thinking about this, I'm actually lucky I started when I was a kid, with all my bills paid for!)

Anyways. You should focus on getting a job first - do keep doing the FreeCodeCamp, as many hours in the day and weekends as you can. Explain to your significant other, if you haven't already done so, your plan - that you're studying hard to upgrade your career, that it might take some time away from them but it will pay off in the long run, etc. Ideally you should be studying at least 4h/day, so try to keep close to that, study more on weekends if necessary. Check this guy for reference on his plan and what he's studying (and note that he's studying full-time - a luxury, I know, but just to put your 2h/day into perspective). This guide is helpful too. Note that you don't need to know all that to get an entry-level development job, but keep that plan in mind for the long run (as you progress your career).

Once you finish the FreeCodeCamp, or even before (I would say, once you finish "Basic Algorithm Scripting"), try doing some local interviews if you can do it without jeopardizing your current job just to get a feel of how interviews work. You won't be trying to get a job (but hey, if you do, awesome), this is just to get your feet wet on interviewing (which is a skill in itself). Since you're not shooting to get a job right now, you won't be as nervous, which is the state of mind you want to be in. If you're relaxed you can talk better, think better, make jokes, be more presentable, which is great - this will put you in the right mood for your future interviews. Try finding people online that can do mock interviews with you in the area you will be focusing on (web/javascript/frontend initially).

Once you're past the basic HTML/CSS part and you start studying JavaScript, I suggest you look into Python as well at the same time. It is a very simple language, quick to learn, and will double your opportunities for employment. As you study both at the same time, you might notice that you like one or the other better - if that happens, focus more on the one you like better, this will accelerate your learning and get you ready for a job faster in your chosen language.

At one point you'll finish HTML/CSS and JavaScript+Python (finish as in be comfortable with them - you'll see that you'll still learn new things as years go by, it will take a few years for you to "master" them). After you're comfortable with JavaScript and Python (and hopefully gainfully employed in development), start studying that book (where you'll learn a GREAT deal about many important things, it will be a dense read, and you will come out of it knowing assembly and C) and then you can focus on algorithms and exercising your thinking with algorithmic puzzles and how computer networks work, operating systems and everything that is generally on this list.

Then after studying all that and with 2-4 years of experience under your belt (and still studying 4h/day), you can start thinking about the next level in your career and preparing for it (larger companies, mid to senior positions, etc) - add a couple more years of experience and you'll be ready to interview for large Valley companies (Google, Apple, FB, etc).

If you plan to self-study all the way through and never join an University, you can look into full-fledged CS courses online and follow that to get a complete theoretical background on CS (that all your colleagues will eventually have and expect of you, at some point in the future).

well depends on what you want to learn. Do you only want to do webdev stuff or learn a ton about CS concepts? I'm going to answer in terms of learning CS stuff, but first here's a page on how to go from knowing nothing to knowing a wide range and depth of CS topics: you do this, you'll be a grade A software engineer!

OK, moving on. First the basics which it sounds like you've got covered.

1. understand basic programming concepts (conditions, loops, functions)
   
2. learn a programming language pretty well, it doesn't matter what language. Being good at and Understanding CS concepts does not involve mastering a single language... once you get the concepts any language will be easy to learn... It sounds like you know some Javascript (not my personal recommendation for learning CS concepts), personally I'd recommend Python (easy syntax, great resources, wide use, etc..)
   
   OK, now where it sounds you stand. Learning the Advanced stuff.
   
   
3. Algorithms: The bread and butter of programming. There are many resources out there, if you want to buy a book, the gold standard is "Intro to Algorithms, 3rd edition ". Other than that, I'd suggest just the relevant Wikipedia article for algorithms. Take the pseudocode and implement it yourself in your language of choice. Understand what the algorithm is doing. Compare it to similar algorithms, understand why/when it's better or worse.
   
   
4. OK, now that you've got that done, you can start making more complicated stuff. Come up with some silly or interesting real world examples to practice with. I suggest at this point learning more about Object Oriented Programming... learn about Classes, class structure, generics (this all varies by language). Practice, practice, practice. 4 hours of coding a day if your not doing anything else, spend the rest researching/reading.
   
   
5. Learn how to use Unix/Linux. it's good for you(tm)
   
   
6. optional but cool: Learn about Computers structures and how operating systems work, bonus points if you want to build a basic OS from scratch (this requires learning a systems language like C/C++/Rust and some assembly).
   
   anywhoooo that's kind of an overview/recommendation... feel free to ask any more questions/clarifications/suggestions for resources.

> Okay, that makes sense. For clarification purposes, is a spec the documentation?

Languages generally speaking have a documentation which specifies itself. That's the spec for the language. Someone interested in creating a compiler, interpreter, or some sort of analyzer, and so forth for the language needs to know how the language is supposed to work. The spec is the document which talks about that in detail. It's like the official documentation if you will.

> And just to make sure I'm interpreting it correctly, do you mean that because Scheme (at least R5RS) had a small pool of reserved keywords and special forms, it made it minimalist, while languages like Clojure and Haskell allowed the programmer to have a wider range of tools at their disposal?

"Minimalist" is not very exact terminology. It means the language has a small set of concepts and things that you can use. The nice thing about scheme is that from this small set of features, you can do tons of stuff. It usually implies a small set of keywords, but that's not just it. Generally speaking, it has a small features set, which isn't very exact terminology either.

> Do you think your previous experience (the C-based DS&A course and the PHP web dev) help you get through SICP? Or was that knowledge independent of what was taught in SICP, and didn't really apply?

These weren't courses per se. I did this before getting into college. The C programming I was talking about came from K&R2 (https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/) and looking things on the web. I think it helped. Not sure how much. I don't think the PHP web dev helped.

> Would you recommend anyone to take any sort of background/intro course (e.g. the MIT 6.00 intro course, perhaps) before delving into SICP?

I have no clue what is the better choice in here. Try both at the same time? I think MIT 6.00 even uses "how to think like a computer scientist" (the book I mentioned before).

> I think I might take a look at that. Is it meant to prep students for SICP even though it's taught in Python? Or is it meant as a general introduction to programming?

Both. It's meant as an introduction to programming and computational problem solving. In one of the lectures I think the professor talks about how people do better in SICP if they take this course before.

> I only ask because each language has its own paradigm, so I don't know if one's knowledge of Python would transfer well or apply well to SICP/learning Scheme. You can of course implement objects in Scheme, and do other OOP-based things, but it's not as laid out or simple as it is in Python, from my experience at least.

That is true, but there is more to it than that. Each language has its ways of doing things. When people are making new languages, they're highly influenced by other languages. To the point that most languages I've seen have nothing new but a few pieces, and most of everything else is just a "rehash" of ideas from other languages. Generally speaking, you'll see a lot of commonalities among several languages. It is true that each language has its style, but that style shares plenty in common with other styles from other languages. There will be things in common, and very rarely stuff you learn in one language won't help you in another language.

Even though the way you program in python will be different from the way you program in scheme, there is plenty in common.

In the end, you'll have a bag of cohesive programming techniques. That's not really language dependent as much as some people will tell you. Languages aren't that important as far as I can tell. I remember, back when I was starting to learn how to program, giving real importance to programming languages. Maybe they are really important, but it doesn't seem to me like they are anymore. The programming techniques and ideas behind them are though. The language is just a "conduit" by which you apply those techniques to solve problems, which has its importance but it's greatly exaggerated by most programmers if you ask me. In fact, in SICP, you'll end up learning that a way to make problem solving more approachable is to make a language that is a better means to apply the programming techniques that you think help in solving the kind of problem that you want to solve.

Nowadays, some languages are nice enough that you'll be able to do that by just cleverly designing a new library or framework. Making new languages is still valuable though, and in my opinion, underrated.

> Truth be told, though I am younger and wasn't around for when CS was emerging [...]

I didn't see it emerging either. I started to study programming and CS in 2006 (I think). All I've said is based on "stories" and reads that came up while I was reading books, reading blog posts, talking to people, etc.

> He has had one junior developer interview that I found for him (another client of mine, after I talked up his progress and how proud I am of him) but he froze up and didn’t get the job. Since then it’s been mostly daily auto rejection emails. I can tell he is starting to lose hope and shut down because he is very ambitious and hardworking (much more than I’ve ever been).

> So, what actions, steps, courses, books, words of support, etc did the people in your life share with you or do for you that made a long, difficult job search bearable or better or easier? Or what do you wish they had done or said differently?

So I don't know your BF, but one thing to keep make sure is that he welcomes your help. I know some people take offers of assistance as a sign of weakness. It's great you're trying to help him, but it's best to make sure.

I've been through the same process - albeit single at the time. But I understand the stress and fear of uncertainty he's going through. One of the best thing you can do is not involve this in your interactions/dates/etc. Just being a good girlfriend/boyfriend is usually more than enough when someone is going through a stressful time. Having small moments with you where he can destress will do wonders for his mental health.

More than anything - be understanding. I've known some couples that have broken up because the other party didn't understand the stress the other party was going through. For example, having issues with not spending enough time together, closing up, etc. Being understanding and being there for him is really one of the best things you can do even if you don't directly help him. If he needs time alone, don't make it a personal issue - he's probably dealing a lot within his head and he will come to you after he's had time to himself. If he lashes out at you due to his stress (which is quite common since he's trying to find an outlet), try to defuse it or just shrug it off. Of course, don't take it lying down if he crosses the line - but know that it's coming from a place of fear and assuming it's no big deal, just letting it go will work wonders.

When this is all over, he will know all the things you've done for him and will appreciate you that much more as a girlfriend/boyfriend.

One book I do recommend is Cracking the Coding Interview. It's been basically my bible when I went through the interviewing phase and it's helped out tremendously. It goes through in-depth about how to change your mindset during an interview and what to expect. Having more knowledge builds confidence. Having confidence will prevent him from freezing up. I don't know if your BF already owns this book, but it would be a great gift - assuming he's welcoming to your assistance.

Algorithms.

Algorithms is an important class, but depending on how its taught, it may or may not prepare you for the challenge of actually developing an algorithm to solve a problem.

Its important to be familiar with certain algorithmic concepts. Each concept (CLRS is a great book for this but it can be...difficult to digest) is a type of solution for a certain type of problem.

Once you have some core tools in your algorithm tool box, then you can start to see how certain problems resemble certain other problems and how a solution can be crafted as a modification of a similar solution.

But to me, the real skill with algorithms isn't whether or not you can memorize a ton of algorithms, its taking a very systematic approach to developing the algorithm, and there are lots of books and classes that aren't very good at helping you learn that part. I find that sections of Programming Pearls and Programming Interviews Exposed are actually very good at helping explain the process of finding the solution.

Having a good process of algorithm building is much more important, imvho, than being able to memorize every algorithm in CLRS. That takes some study, but a lot of practice.

Data Structures:

Anytime you are writing a piece of code, you are probably doing a set of steps that looks like this:

1. Problem definition
   
2. Algorithm design
   
3. Data Structure choice.
   
4. Implementation.
   
5. Testing.
   
   Data structure choice is on that list, separate from implementation for a reason. IMVHO, smart data structure selection is what HELPS you arrive at an elegant implementation...a poor choice can yield similarly poor results in implementation.
   
   Data structures are important. Learning how to make them from scratch (lists, trees, stacks, etc...) is a good way to build your skills in a language, and its frequently the meat of programming interviews in some languages...but in the real world, you will very likely spend most of your time just focusing on selection and then using an implementation from an already well established/tested library.
   
   Knowing when to use a queue vs stack, when to use a list/array versus a hash, knowing what kind of tree will perform better under the specific conditions of your program (avl, red/black, splay, etc...)...these are things that when chosen well, will save you a massive amount of headache in the implementation and testing phases of development. Learning how to traverse those data structures is important too, for example: Recursion is taught to every cs graduate when they learn trees but then in production code it can be frowned upon for various reasons such as what happens when someone who isn't great with recursion has to maintain/debug it, or when it would put too heavy a load onto the call stack.
   
   Also, what /u/bvcxy said is spot on, its one thing to know the theory, but there is that whole other side of understanding source control, how a makefile works, learning how to use continuous integration tools like jenkins.
   
   And we haven't even gotten into debugging, that is its own skill and you will eventually also need to understand how to debug with breakpoints, inspect memory, check your code for leaks, etc...
   
   The nice thing is that so many IDE's out there are integrated with source control and memory inspection tools, so you can pick a good IDE and dive deep into understanding how to get the most out of it. Write a program in C/C++ and then deliberately put a heap memory leak into it, and learn how you can catch this with tools but also how you can inspect the memory at runtime with breakpoints to see what happens.

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

Throwaway account because I'd rather not have my current coworkers knowing about this.

About a year ago, I heard about Google Foobar from an article on Hacker News. I had never seen that before but it sounded interesting, and I'd always wanted to work for Google (sent my resume some years ago, heard nothing). Long story short, I found a backdoor way into Foobar, and went through the coding challenges until I got past level 3, at which point they ask if you'd like a Google recruiter to contact you. I said yes and gave them my details.

Fast forward to about two months ago. I finally got an email from an internal Google recruiter asking to talk. I freak out a little bit and start madly researching what a first contact entails (as it turns out, just an informal phone call about your career and what you might want to do at Google). During my research I also looked into what the infamous Google technical interviews might look like, and discovered that I needed to brush up on my algorithms and data structures, and fast. I told the recruiter I needed two to three months to prep (this is apparently not too uncommon, thankfully). She said that when I was ready, I should send her my resume and the jobs I'm interested in (probably in the Pittsburgh office so we can stay close to my wife's family), and she'll get the ball rolling. She also mentioned that it's possible that I could skip the standard video tech screen (since they already had a coding sample in the form of my Foobar submissions) and proceed directly to the onsite interviews.

The thing is, I've been primarily doing PHP web development for ages. I've done a bunch of freelance work previously and I've been working for a great startup for the last few years after immigrating to the US from Canada in 2009. But as far as I know, Google doesn't do much / any PHP, and we all know the general opinion on the language. I have, thankfully, done many other languages throughout my career... Javascript (lots), Java (college / some Android development), C++ (in my college days), C (when I was first teaching myself to program in a real language). But my professional experience has been dominated by PHP.

As far as education goes, I have an associate's degree in programming and about two years of a CS program (interrupted to move to the US). I always thought Google had a hard Bachelor's requirement but that's apparently not the case (you just have to show that you have the aptitude, skills, and experience necessary).

My prep so far has been reading through The Algorithm Design Manual (at least the theory part of the book), and more recently, reading through Cracking The Coding Interview and doing the questions, on paper first, and then verifying on my laptop. I am doing these questions in Python, which was the language that I did Foobar in, and probably the language I will interview in. That said, I learned Python for the first time going through Foobar, so I'm far from an expert in the language. I'm doing this prep while managing my current full time job and caring for a four month old, which I wouldn't even come close to managing without my wife's amazing support.

Doing a search here, I found the MIT Hacking a Google Interview site which seems like a goldmine, and Pramp which also seems like a great resource once I'm done with CtCI. Considering Interview Cake but only if people think it's indispensable ($200).

I have about one month left in the original timeframe I gave the recruiter. I am incredibly excited by the prospect and also incredibly intimidated. Do you have any advice for me on how to maximize my chances?

Also, should I apply as a SWE or a SWE-Frontend? My full stack web development experience seems relevant to SWE-Frontend but I don't want to only end up doing frontend work and I don't want it to be career-limiting; I like the backend stuff as well, and I'm definitely not a designer.

Thanks!

Edit: For those looking for the Foobar backdoor, it no longer works. It was a crossword you could solve that randomly generated (easy) CS and crypto clues, and was accessible from an IP apparently found in promos for The Imitation Game, but the crossword entrance has since been shut down. However, I figured out why I couldn't get in through the main method (searching Java- or Python-related CS queries). You have to both be logged into Google, and, crucially, you have to have search history enabled. Once I reenabled search history, the Foobar break-in came right up after a couple Python searches.

If you already have an engineering degree then you already know how to study. What experience do you have with embedded? If you don't have any then you should be sure it's what you want before you commit to anything huge.

I think the best way to get a job in embedded systems is to build embedded systems, and not bother with language certifcations. I might be going against the grain here a bit but I would suggest starting to dip your toes into embedded systems by buying an arduino and messing around with it.

Arduino gets a lot of flack for being "not real" embedded systems, and while it's true nobody is going to hire you because you can make an impressive arduino project, IMHO it's a great introduction to what embedded is about. The hardware equivalent of "hello world" is blinking an LED. If you are serious about learning then you will quickly outgrow the arduino, but you can always throw away the bootloader and try to program the ATmega with bare metal gcc and avrdude.

I don't know what you already know nor how you feel about math, but things you will want to learn include:

• Analog electrical theory, DC and AC, resistance/capacitance/inductance. Understand basic circuit networks and input vs output impedance. Hopefully you remember complex numbers and frequency response. You don't need a lot of circuit theory but you will need to understand what a pull-up resistor is and why it's necessary. Depending on your math background you can get into filters, frequency response, fourier analysis. A good introduction here might be www.allaboutcircuits.com
  
  
• Digital theory, starting with boolean algebra, logic gates, adders/multiplexers/flip-flops, all the way up to computer architecture. I like this book because it has a very holistic approach to this area https://www.amazon.com/Digital-Design-Computer-Architecture-Second/dp/0123944244/ref=sr_1_1?ie=UTF8&qid=1494262358&sr=8-1&keywords=harris+digital+design
  
  
• Linux, C. Linux and C. You need to understand pointers, and the best way to understand C is to understand computer architecture. If you're not already running Linux, install linux, as well as gcc and build-essential. Start learning how to manipulate memory with C. Learning about computer architecture will help here. My favourite book on C is one of the classics: https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/ref=sr_1_1?ie=UTF8&qid=1494262721&sr=8-1&keywords=the+c+programming+language
  
  If you get this far and still want to become an embedded systems engineer then you're doing pretty well. I would say just try to build projects that utilize these skills. Maybe you can use your mech background to build a robot and then design the software to support it. Get used to reading datasheets for parts, and imagining what the digital logic inside looks like. Get used to searching google for answers to your questions.

Hi! I love your username btw.

I'm going to try and find stuff over time, so I may add to this comment. It's going to take a bit to trudge through, but if you get just a little practice with each concept, you'll be pretty set. These companies don't need you to answer everything perfectly, that would give you a 99th percentile or whatever on Leetcode. If you know the basic concept, and you can mold it to the problem and give a time complexity, you'll be fine.

1. Cracking the Coding Interview is a good book that details interview process and gives a basic view of data structures.
   
2. There are some good courses in this link. I can't tell you which ones are the best, but I would probably recommend one by a university. Most are free without a certificate, but if you wanted to go for a certificate for any reason, it would look much better to have it from an reputable university.
   
3. I have the algorithms book from this set on my phone. I have used it for review quite a bit. There is a lot in there, but what I would recommend is to use it to supplement your algorithm exercises online.
   
4. I'm sure everyone else has recommended Leetcode, because it translates very well to the big N interviews. I would like to personally recommend Exercism. There aren't a ton of unique problems (a lot of the language tracks have repeat problems), but it has the advantage of giving you free code reviews, a summary of unit testing frameworks in the various languages, and I prefer the way it works. You can maintain a GitHub repo with all of your problems, and submit them through the command line. I'll have to warn that it is slower, because you have to wait for code reviews to continue on the core exercises. I would sprinkle this in with your other practice.

I think it depends on your location. If you live in or a commutable distance to a city with a strong technology sector, they will be quite a bit of companies willing to hire an high school level intern.

For example, a friend of a friend got an internship after graduating high school for the summer in the city he lives. I live outside the city and I am taking a year off before university because I got sick in the summer. I'm better now but all the companies near me are kind of old fashioned and they don't accept interns after a lot of cold calling; my calls and emails get sent to their HR manager, and they don't feel like giving me a chance. Also the benefit of an internship in the city for him was that he used pretty modern web development stuff.

As a high school intern unless you find a research group, you will highly unlikely use R. You can probably do front-end web development, so learning HTML, CSS, JavaScript, Jquery, and the Bootstrap framework would be awesome. If you don't want to do front-end web development, you really have to market yourself and make sure you are competent in Python if you want to use Python.

As a person who graduated high school last year and is taking a year before university to recover from an illness, I have to compete with other university students of various years who even the freshman have some sort of qualification as a candidate for a bachelor of applied science or math degree which tells the potential employer the applicant is knowledgeable. If you want to be competitive with the freshman or maybe the sophomore students, you really need a good GitHub portfolio which shows you are knowledgeable as them.

For example, in my GitHub portfolio, I have an Android application (GitHub and Google Play). In this small to medium sized application (35, 000 lines of code), I show I can use a version control system and a bug tracker by using Git and GitHub, respectively. Furthermore, in the bug tracker, I show I can debug by showing results of me using an allocation tracker, a heap dump analyzer, a GPU rendering profiler, and the like. In the actual source code, I show my experience with Java. But more importantly, I show I can implement an architectural pattern like Model-View-Presenter (a deviation from Model-View-Controller), some design patterns like wrappers, singletons, mappers, adapter, presenters, contracts, providers, and factories, and design an API which performs network requests, database queries, and file input and output. In the source code, I try to apply as much as I can from reading, Effective Java (2nd Edition), Clean Code: A Handbook of Agile Software Craftsmanship, Design Patterns: Elements of Reusable Object-Oriented Software, and Introduction to Algorithms while I get acquainted with reading Software Engineering: A Practitioner's Approach. I still need to try to utilize TDD and Agile practices; I read about them, but I never tried them out.

I think if you have a GitHub portfolio with project(s) of a good size that shows a lot of computer science and software engineering concepts, you will be ahead of most freshman students whose only projects might be a small class project in their Intro to Java class which all their peers did.

Currently, the application has around 5,000 downloads in about a month with 4.4 rating to place it 5th in its specific category above 4 stars on Google Play: https://play.google.com/store/search?q=Manga+Reader&c=apps&rating=1; it took about a month and a half. However, every time I send my resume to a local company outside the city for an internship, I get no response. I'm going to a Career Fair at a friend's university in the city on Friday, so I'm a test my luck there; they have quite a few recruiters for mobile application interns, and one company develops a full stack product and service whose mobile applications kind of match mine. Overall, it's feasible if you are near a city, willing to commute, and can prove you know as much as a freshman student who they could hire instead.

I read your question as having two parts:

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

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

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

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

Disclaimer: I'm still a student, so if you want to, go ahead and disregard my response. On the other hand, I have put in many hours contemplating this very question.

In "Coders at Work," Peter Seibel interviews the founder of JSON and JavaScript architect, Douglas Crockford.

Seibel poses the question
> Have you ever had problems ... (with) people who've been successful in one language (who) sometimes have a hard time giving up their old ways, even when working in a new language where they don't really make sense?

Crockford's response:
> I don't care. I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it. (...) Generally, I prefer generalists. I want someone who's capable of learning any of those APIs but isn't necessarily skilled in any one.

In The Pragmatic Programmer, authors Andrew Hunt and David Thomas say
>The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don't stop there. The face of computing changes rapidly -- hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.

The emphasis in comfortable is mine. It doesn't say the more technologies you master or are proficient at. Instead, being comfortable with many different areas, topics, technologies, languages, etc., will allow you to express your value to an employer in many different ways.

Now, specific to your current position. I have been with my current company for 9 years now. I started out as a cashier, moved into management after 9 months, and now I am a service technician working with all of the networking, computers, surveillance, construction, project management, etc. I am essentially a corporate representative with a LOT of autonomy, responsibility, and I wear a lot of hats. I am also the highest paid technician in the company for these very reasons. My job is perhaps one of the most stable in the company given the amount of general knowledge I have about the areas I work on actively.

Now, software might be different in that knowing a lot about everything is incredibly hard. However, picking a couple of specialized areas and being comfortable with many other areas is very likely to make you a valuable employee. It allows you to think up insightful solutions to multi-disciplinary problems. You can be the hero who comes up with novel solutions to larger problems, whereas people who specialize in C++, JavaScript, or Haskell might only know how to solve the same problems in their respective languages.

From what I can tell by reading the literature, those are the differences between people who specialize and people who generalize. I think you are experiencing what it's like to be good at generalizing. Incidentally, I would also equate CEO's, CTO's, COO's and other C-level people to generalists. They are capable of abstracting away the minutiae and details of their problems and delegate to others in order to get stuff done. They focus on big-picture stuff and let the specialists (accountants, technicians, programmers, drivers, etc) deal with the details.

> My strong suit is ruby/rails which I feel like is pretty rare and specific when it comes to most internship positions. (I can count on 1 hand the people who know rails in my school).

First off, trust me, you're not that special.

> So far, I have had interviews with 6 of the companies, and have yet to miss a question, & every time I am able to solve the technical questions relatively quickly (e.g. 45 min coding problem, done in 20 etc.) and then we go on to talk about interests etc. The thing is EVERY single company, after the technical interview (usually the 2nd-3rd phone interview), I am in limbo. Usually from 2-3 weeks, before I get denied.

So far, I'm picking up an attitude problem.

> I have only now started asking for feedback(but of course nobody replies to my emails).

Yeah, don't do that.

> I know they are large companies (vmware, yahoo, dell, etc.) but is it strange to have an interview go well and then just go into the void?

YMMV, but it's entirely possible. However, for myself I'd say 95% of the time, someone gets back to me.

> Also I am not socially inept, yet it always seems as if me and the recruiter get along great, while the technical people give off a cold disconnect (but still nice).

How often is this happening? I'd say there are some technical people who are just like that, but I'd say the majority of the time I see them acting that way in an interview is because it isn't going well.

> However it seems pretty inefficient to apply to jobs with 2000 kids hunting for 2 open positions, so it may be the lottery effect that is killing me.

Maybe, but if you're applying to 100s of jobs, you'd think something would eventually edge out in your favor.

Honestly, to me it sounds like:

1. You give off a cocky/bad attitude
   
   
2. You aren't doing as well on the technical questions as you think you are.
   
   There's nothing much you can do about an attitude problem other than hold your tongue and think before you speak on anything that isn't directly related to the technical question at hand. Explain, don't boast about past projects and experiences. Be open to learning.
   
   As for technical questions, the best I can do is prescribe the usual: Cracking the Coding Interview. Good book for getting the basics down for technical interviews. Others will suggest other books after that, but I've had good luck with geeksforgeeks and the interview section of Glassdoor for companies like Google and Yahoo for going above and beyond.
   

I also come from a strong math background, and love "mathematical programming," and have probably faced some of the same obstacles you're about to face.

Anyway, the one are where I suspect you lack the most (and your code seems to confirm this) is in the area of clean code, architecture, and software design. And no, I'm not talking about adding comments ... but rather time-tested practices that make code much easier to debug, maintain, use (as an API), and add/remove features by other software engineers whom you've never met.

Perhaps the fastest way to get you up to speed on modern practices is this book:

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

After that book, start reading books on software design and architecture.

Peer code-reviews are also an amazing way to improve. If I had more time (I wish I did), I'd probably give your code a detailed code-review, and possibly refactor your code because your code is not "bad" per-se, but could be SO much better. :) When you look for a job or internship, ask them about their development process or cycle. If you hear anything about "unit tests" and "code reviews," that's probably a good thing.

> Should I apply even though I am still learning the requirements?

PHD in mathematics, which the ability to code? If I was in a hiring position, there would be a good chance I'd hire you.

Of course. I always encourage people to go into CS but I also tell them it’s going to be a tough road, but not an impossible one.

I have two last pieces of advice. The first is to get your first rejection over with. Be ready for it, take it like a champ, learn from it and move on. If you can be immune to rejection the road will become so much easier.

The second is to buy Cracking the Coding Interview by Gayle Laakman McDowell. This is the field guide to getting a career in CS, and easily the most popular book in the field. I give my degree credit for giving me the knowledge to be a software engineer, and this book credit for giving me the skills I needed to get a career in CS.

It has a roadmap that starts a whole YEAR before your interview, which is perfect because you can start that roadmap today, and a year from now when you apply you’ll be ready to crush that interview. Also, Gayle has been a recruiter at Microsoft, Apple and Google, and she has personally conducted hundreds if not thousands of interviews, so I can’t think of anyone better to author a book like this. It’s on sale right now on Amazon for 30$ and will probably be the best 30$ you ever spend:

Cracking the Coding Interview: 189 Programming Questions and Solutions https://www.amazon.com/dp/0984782850/ref=cm_sw_r_cp_api_i_dEX2Cb9N4AE74

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

Don't let the lucrative offers some people get, deter you from turning down a very solid offer to get some good experience even if it's a little below your compensation expectations. Being unemployed for 3+ months and never getting that 110K + bonus + relocation @ [Insert Big N Name] is a shitty situation compared to some 65-70k at a less expensive city with a smaller company that has some new tech they're trying to scale.
In a year, you'll be surprised how much you can save and if you play your cards right, network, do a great job, you'll be worth a decent amount of money after a year.
Have friends whiteboard you for practice. Get used to writing "nearly" build ready/compile ready code using built in Java language data structures and functions. Especially get used to the Collections library, iterating over two collections in a single pass while checking for duplicates or comparators on each entry.
Buy this book and this book and sign up for LeetCode on a free account.
Honestly, try to enjoy your spare time. Do something logical but fun like playing strategy games or solving puzzles. Go to meet & greets, club meetings, volunteer at a dog shelter. Don't try to "win" this game because out of all the people that "win", some end up having severe issues with stress, time management, "loving" the job/life and life after college is nowhere near as sunshine and rainbows as during.
I wish I could "skip" a lecture and work from home, watch Netflix or go with some friends to go eat food in a town nearby or catch a convention or watch some concert on campus. All the college fun stuff? It's gone. Now it's just work... Well, work and money but still... Not as much fun college stuff. Some fun college stuff, but not as much.

So there's not a lot for us to go on here, but one thing I'll say is that good software development jobs are not easy, even for those completely qualified for them. If he's in the middle-high range salary-wise, then the challenge and expectations are probably all there. Software engineers are not cheap, so while they're treated very well to attract and retain talent, they're also seen as a big investment that had better pay off.

I was laid off from my first full time job and while my coworkers spoke very highly of my skills and the care I took with my work and went out of their way to emphasize how bright my future was in the industry both in person and in my peer reviews, my managers made things very clear: For the level of work they needed me to do, I simply was either not skilled enough or experienced enough to make the cut. It wasn't personal, or a statement about how smart I was, it was a cold and completely practical business decision.

What did I take away from that? Well after I stopped feeling bad for myself I realized that there wasn't anything wrong with me, that I was perfectly capable of cutting it in this industry, that many engineers less smart than me got along just fine, and that I simply needed to up my game and get a new job. It wasn't about getting smarter, it was about getting my shit together and working out of Cracking the Coding Interview daily, learning the hot frameworks that everyone needs engineers for, building a real portfolio and GitHub profile, and being ready to work that hard even after I got a new job. And I got a new job where I was paid over twice as much and so far I love it.

Depends on what language or area you want to specialize in.

But the basics are important. Not so much being able to solve those stupid white board tests (I would not shoot for a company that does those as a self-taught first job individual. You'll just be discouraged. I've got 6 years experience and I doubt I could pass those stupid test without extensive studying.)

It's hard to say, b/c of some of it is...just exposure and your ability to think about abstract problems. I'm honestly not sure how to word it. But people who have had to go through academic training. EG Algorithms, data structures, modeling, etc... seem to just have a better understanding of abstract processes (if that makes sense).

Some things I feel are personally important.

Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_2?keywords=clean+code&qid=1563404400&s=gateway&sr=8-2 Believe this is the one. I've never read it page by page but we had one college professor who basically taught the concepts from it.

Ability to actually talk about what it is you've done and know. The best way to do this is to have actually tackled a complex problem or project. Even if you need to make one up, you'll learn a lot. Things like properly structuring objects. Data flow. Singletons. Data storage. Security (if you're doing something web based). I personally built an entire website from the ground up. It included a content management system for the homepage. Custom permissions and a forum's section. I learned more from that personal project than I have from work honestly. It's now trashed in Github somewhere, but that wasn't the point.

Abstraction abstraction abstraction. This kind of goes with the clean code point.

Knowing the importance of testing. Difference between unit and e2e (if you're doing web). Some companies don't even write test so your mileage may vary on this one. Usually they still pretend like they do in the application and interview. But once you get in, they'll have zero test. And this isn't the worst if the application isn't very large or complex. There's a lot more to test but unless you're applying for that kind of position, it may not be as important. But being able to talk to some of the basics is good. (Like knowing some terminology. Black box testing, smoke testing, uhh, drawing blank on the others...you can tell what jobs I've had sigh...)

I would say the tl;dr is...actually make something. And not something simple. And do it right. This will give you a lot of things to learn and think about and discuss in an interview. It'll make you more engaged and willing to learn. And most importantly, it'll demonstrate you can actually do what you say you can.

> Most of the jobs out there are temporary or contract (short/long/C2H)

This sounds patently untrue. I'm certain that the vast majority of people in CS have full-time jobs rather than temp or contract.

> Recruiters won't even look at you if you don't have a knowledge in a specific stack (even for entry level)

Also untrue, especially for entry level, where good companies won't care what tech stacks you know.

> Recruiters don't even look at your resume, all they do is keyword search

Partially true. Resumes are often automatically filtered by how many buzzwords they contain. If you can use buzzwords without making your resume seem over the top, do it.

> I've been told that I shouldn't even apply for SDE jobs because I'm a "tester" and how I probably don't know of any CS fundamentals (because my degree is in CompE, not CS)

Bullshit. Any company worth working for - most companies - will not take that attitude. They might be skeptical, but they would never suggest you don't apply.

> Interviewers don't seem to have interest in interviewing

It doesn't matter; it's their job. And most interviewers are competent at interviewing, so nothing to worry about, regardless of how "interested" they are. (Though an "interested" interviewer, while rare, is a pleasure!)

> Companies have absurd hiring standards (they are all looking for a unicorn for 50-60k/yr pay, through contract)

Depends on the company.

> * Entry level jobs require years of PROFESSIONAL experience in a specific technology


Entirely false.

---

The current job market is fine, prosperous even. Craft a strong resume, post it in the resume advice thread, and send it out to companies. Apply to a bunch of companies, account for a 5-15% response rate (higher if you're more skilled).

Getting interviews will be the easy part; to pass them, you'll need to pass difficult algorithms questions. Books like Cracking the Coding Interview and Elements of Programming Interviews are essential reads; then go on a website like LeetCode and grind away at problems until you can solve easies in 20 minutes or less, mediums in 30 minutes or less, and hards in 60-120 minutes. I'd say a 3:9:1 ratio of easy:medium:hard would be a good ratio to go with, and do as many problems as possible until you're comfortable with where you are (for me, that was about 120 problems). The premium subscription is well worth it for problems tailored to certain companies.


Edit: spelling

Everyone sucks at something at one point, but with practice you'll definitely be able to get better! I highly recommend writing over typing out the solution when you practice. Also, 90% should be dedicated to planning out path to the solution and 10% for writing/typing the solution out. Sooner or later, things should start clicking and making sense. Here's a list of resources that helped me get all the way to the Google on-site interview (Didn't get an offer but it was an amazing learning experience)

Data Structure And Algorithm 1: http://www.youtube.com/playlist?list=PLLH73N9cB21W1TZ6zz1dLkyIm50HylGyg

Interviewcake: https://www.interviewcake.com/

Khan Academy: https://www.khanacademy.org/computing/computer-science/algorithms

Leetcode: https://leetcode.com/

Cracking the Coding Interview: http://www.amazon.com/gp/aw/d/0984782850/ref=pd_aw_sbs_14_1?ie=UTF8&dpID=51F6Lwyq5JL&dpSrc=sims&preST=_AC_UL390_SR390%2C390_&refRID=1PE4XEBQDDHEF4T1ZA9K

Algorithm Design Manual: http://www8.cs.umu.se/kurser/TDBAfl/VT06/algorithms/BOOK/BOOK/BOOK.HTM

Make sure to practice everyday and have a strong understanding of the concepts. Network, contribute to open source projects, and keep on learning!

Everybody's learning style is different. Here are some books I believe to be essential for any novice or pro.

Programming For Dummies. It has a stupid title, but it is well reviewed for good reasons. I read through this beast in three weeks. There is no coding involved, as it is mostly theory, but it covers most of the bases of computer science and programming logic. Looking back, much of it confused me at first read, but the big ideas are all presented here. Reading this during the summer before first semester was a huge boost for me. All of the major computer languages are discussed in the book.

Cracking the Coding Interview. A book meant for veterans trying to get into highly demanding top tech companies, the book is a great introduction to programming paradigms. There are numerous examples of problems in each chapter with answers at the back of the book. The whole thing is in Java, with a short chapter on C++.

Design Patterns. As you learn more about object oriented programming, the concept of design is introduced. This book is the holy grail of software architecture and recommended by many. I would hold off acquiring it until you are certain that CS is where you want to be, it is quite technical. This book follows C++, although a Java version of the patterns exists on Github.com

A non-technical book just for fun:
The Innovators is essentially the story of computer science and how it got to present day. It follows the characters, human beings, that were involved each step of the way right up until modern day. Your professors will be impressed that you know who Alan Turing, Grace Hopper, and Charles Babbage were. If only I had been at THE MOTHER OF ALL DEMOS! The actual stories of Microsoft, Apple, The internet, the PC, video games, the space program, etc. On Quiz Up, a trivia app, every other question in the CS category involves names from this book. Read it just to be a real geek that knows where this stuff came from, and the drama/tension that led to innovation. The book is actually really funny at times.

>Oh well, can't work on the past

Everything you do today is tomorrow's past.

You need to do some light learning. I'm linking a few books that are fantastic in accomplishing these goals and I think your english is pretty great, so I don't anticipate so much trouble. I highly recommend doing everything in Java; not because I'm arguing that java is what will help you the most, but because almost every code example from these classics refer to Java.

For design patterns, Gang of Four is a good introduction, but it's a little harder to understand http://amzn.to/1giIrF6
I would recommend finding AND implementing these patterns.

Grab a copy of Code Complete by Steve McConnel and Clean code by Robert Martin. That will help you write nice code that you'd be proud to share with a company.

This book reference gets overused, but Design Patterns was a change for me in the whole way I saw code. It's not easy to get through and some of the patterns take several reads for the lightbulb to go on, but once you get a design pattern, that knowledge stays with you through any OO language, not just C++. The patterns in the book are things that you run into all the time in programming, and that spidey sense of "I've seen this before" when you're working through the design of a problem is beyond valuable. Knowing what the patterns do, and more importantly, when it's appropriate to use them, is a key differentiator especially in C++ programmers.

Technically, for C++ specifically, knowing your stuff on memory management is a highly valuable. Not just how memory management works, but what are the best practices? Who is responsible for freeing the memory if a function creates a new instance of an object and returns a pointer to it? How do you know that all references to an object are out of use once an object is released from memory? (I saw smart pointers referenced before) When do you have to zero-init alloc'd memory and why? alloc, free, calloc, realloc, new, delete, learn all of that memory management stuff.

/rant Something that concerns me about this sub is how up and coming Software Engineers ask for handouts of information that they can easily acquire by googling and researching. Now I'm going to reward this behavior by pointing you in the right direction.
/endRant

First off: The FAQ https://www.reddit.com/r/cscareerquestions/wiki/index

1.) Resume: https://www.careercup.com/resume

Using Latex: https://www.overleaf.com/gallery/tagged/cv (A lot of people love the Deedy Resume template - note that if you choose to use Latex then your output will be pdf which may not be processed well by automated resume processors)

Using Word: https://templates.office.com/en-us/Resumes-and-Cover-Letters

Notes: White space is valuable. Target your resume to the position(s) (but don't lie). Write it, then proofread it, then edit it, and repeat (grammar/poor wording looks terrible). The easiest way to maintain a good resume is to do just that - periodically (every ~6mo) open it up and add new experience (ignore the proofreading if you want.. just write anything new down).


2.) https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X and https://leetcode.com/

Notes: East Coast/Tier 2 companies typically don't ask as many (or as difficult) programming questions so focus on behavioral and domain knowledge. For the technical questions practice on an actual whiteboard with a partner while explaining your thought process out loud. Communication skills are probably more important than technical skills but this sub doesn't bring that up as much.


3.) See 2.


Final Notes: Maintain & update your LinkedIn. Prepare for your job search to be a grind (mentally). Do lots of research. Try and get referrals to increase the likelihood that you get an interview. There's no magic advice that will enable you to land a BigN job without hard work (though some will achieve it more easily than others - many people interview at Google 2-3+ times before they land a job there). Reading "Clean Code", "The Pragmatic Programmer", "How to Win Friends and Influence People", and at least owning a copy of "Code Complete" are often suggested here as ways to improve your abilities as an SWE.

My schools curriculum had one UG class for data structures and algorithms as well and it covered most of the things I mentioned. We did stacks, queues, hash tables, b-trees, red-black trees, disjoint-set Forests, MSTs, Dijkstra's, some dynamic programming computing string edit-distances, and several other algorithms. We might have done heaps but I can't remember. The really basic stuff you will learn in CS1 and 2, most likely. Other than that I learned A* search in my AI course and graph min-cuts in Computer Vision (not that I needed either in any interviews).

That being said, professors can only devote so much time to each topic, so some of the coverage might have been cursory, and when you are interviewing 2 years after you took data structures you might have gotten rusty even if you were good when you took the class. You will definitely need to prepare prior to interviews somehow. Keep the book you get for your Data-Structures class (mine was this one); even if you don't cover everything you need for interviews in class the book will likely cover it somewhere. Cracking the Coding Interview is a great resource as well for getting a feel for solving interview style questions. Coding competition sites are great practice too (you don't need to know how to solve the really hard stuff).

Never ever ever ever ever ever ever EVER ever ever EVER tell a company "I'm not suited for the job". Have some balls! Sure, you messed up, but hold your head high. Everyone messes up in their life at interviews; I know I have many times. Confidence can go a long way in promoting your personal image.

FizzBuzz is probably the most simple, commonly used interview question out there to see if a programmer can actually program. It doesn't get much simpler than that. I hate to break it to you, but Modulus is one of the most basic foundation concepts you need to know, and it's definitely taught in any entry level OOP book or Uni program. I dare you to show me a "Learn programming in Java/C++/Any other OO Language" book that doesn't cover it in the first few chapters.

You are over-thinking the solution here: it's meant to show how well a candidate can easily write clean, short code. There's no reason for you to abstract the functionality of finding whether a number is evenly divisible into a method - that's over complication in design, and it's a red flag for employers. I think you may have believed that isolating specific mathematic processes into methods seemed like a good idea to show off that you know object oriented principles. You're on the right track. However, if the process you're writing can be completed in a single line of code, let alone under 10 characters, you're just adding more dependencies and complication to a simple block of code. I would suggest this as a more clean solution to fizzbuzz (in Java):

for (int x=0; x<=100; x++) {
if(x%3==0 && x%5==0)
System.out.println("FizzBuzz");
else if(x%3==0)
System.out.println("Fizz");
else if(x%5==0)
System.out.println("Buzz");
else
System.out.println(x);
}

I personally struggled with a decent amount of interviews until I started to actually prepare for the interview. I recommend finding time to work through these two books; they'll help prepare you for what kind of questions to expect.

http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Landing/dp/1118261364/ref=sr_1_1?s=books&ie=UTF8&qid=1377704276&sr=1-1&keywords=programming+interviews+exposed

http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X/ref=sr_1_1?s=books&ie=UTF8&qid=1377704294&sr=1-1&keywords=cracking+the+coding+interview

And most important of all: NEVER get down on yourself! Every tough problem or terrible interview you have is just a learning experience. Never tell yourself you aren't good enough, or just outright give up. You aren't allowed. Stick with it, and prepare months in advance, like homework. You don't have to be that person dedicating every waking moment of their life to programming, but if you're serious about keeping your interview skills sharp, you need to dedicate some time to learning the questions. Good luck!

EDIT: Grammar, etc.

That sounds pretty normal especially for a small-ish company. A lot of learning comes from reading on your own. Like blog posts, StackOverflow etc. I really recommend Clean Code in terms of the stuff you're talking about. This book is basically a software engineering best practices bible.

Unit testing is something your team should help you with though. If a system is not there, you can also try to do some research and propose a system for your company to use or implement!

> For me, I wish I had more mentoring so I can pick up new skills.

It sounds like you're learning a lot though. You built something that works using a new tech you learned from scratch. That's pretty impressive. It's a pretty unique opportunity to try new things and get paid.

I remember reading a study where researchers found that people who were smart generally felt that they were dumb and people who were dumb, generally overestimated their intelligence. So I thought that's something you should maybe think about since you mentioned that you think you're not a smart guy. With that said, I think you should go for it for sure and I think that with enough preparation and planning, you can increase your chances of getting an offer from Google. And if you don't get it the first time, you should try again. I've read that some got in on the 2nd or 3rd try.

Your plan looks sound. I would recommend focusing on a specific language though instead of focusing on functional programming, C, JavaScript (unless you plan on doing front-end work, I don't think JavaScript would be useful in this situation). Java is one of the widely used languages at Google.

Buy Cracking the Coding Interview. It's such a useful book. The material it goes over isn't very in-depth, so don't expect to use it as a way to learn about various algorithms and computer science concepts. Rather, solve the problems in the book. The problems are of varying levels, some easy while some may really challenge you. You will feel really dumb trying to solve some of these problems, but spend as much time as necessary and try to come up with a solution that you then refine. You may not come up with the optimal decision on the first try.

Solve problems on CareerCup. From what I understand, some of the questions on there are actual Google interview questions.

Make sure you have a thorough understanding and know how to implement basic data structures such as Linked Lists Hashtables, Trees, Binary Trees, N-ary trees, Graphs and Di-Graphs. Know how to perform breadth-first search, depth-first search on both trees and graphs. Know post-order, pre-order and in-order tree traversal. There's more but that's what I remember off the top of my head.

The last interview of the on-site interview will be about system design and it requires a more general architecture knowledge (HTTP, SSL, compression, network latency, disk latency, etc...).

Search for blogposts of people who've interviewed at Google. There are like a dozen or more of them. They give you a good overview of the process and some even contain questions.

Best of luck!

Edit: I forgot to mention the Big-O notation. It's important and every interviewer will ask you for the time complexity of the algorithm you just implemented.

Usually the CTCI referred to here is Cracking The Coding Interview. It´s probably the best known interview preparation book. You can easily find the PDF online but I would recommend buying it because it´s like an algorithms/datastructures bible and it will make it easier to take notes (it´s also a tiny investment compared to the potential pay-off). I think if you can comfortably do all of the questions (incl. moderate+hard) then you will be close to ready for Google. It depends from person to person. But I would recommend doing some LeetCode Google flagged questions afterwards to gauge how well prepared you are. For some people CTCI alone is enough while for others an additional 50-100 LeetCode are sufficient (some skip to LeetCode directly and do 150-300 questions on there). Note that CTCI is an alternative to EPI (Elements of Programming Interviews). Doing both would be a bit redundant. From what I gather EPI has more challenging problems so might prepare you better for Google, but if you´re very rusty then CTCI might be an easier start.

There´s plenty of resources available on this; I suggest checking out the relevant FAQs in the sidebar of this subreddit.

I cannot recommend Clean Code by Uncle Bob nearly enough. I learned about him from his (rather idiosyncratic) videos on the subject, and it literally changed my outlook on writing software, top to bottom.

This might seem hyperbolic, but I can't stress the value of his ideas enough - my old company had access to his videos on our internal network, and the first 5-7 videos became required watching for the entire team I worked on. It was a lot of time to devote to something that wasn't coding, but I really believe it helped even new graduates understand the ideas behind "good code" and how to make clean systems in practice.

Let me know if you have any questions about the what or why of the suggestion.

Edit: In the spirit of PM_ME_UR_PIN_NO, I would also emphasize that there is no royal road to writing perfect code, because there isn't even consensus on what perfect code is. This kind of thing is the part of what we do that is more art than science, but I have yet to see a more effective collection of useful tactics than Uncle Bob's work.

>Do you find that the standard system of technical interviews (data structures & algorithms) is an effective way of assessing candidates? Why or why not?

When I was an undergraduate, the dominant interview approach involved brainteasers like "why are manhole covers round?" Initially, these were reliable indicators of future success. But after every other company started copying Microsoft mindlessly and asking the same set of questions, the approach quickly became less effective. People optimized for interview performance with books like How Would You Move Mount Fuji? and How to Ace the Brainteaser Interview.

Brainteasers were mostly phased out after Google introduced the current approach involving data structures and algorithms. Initially, these were reliable indicators of future success. But after every other company started copying Google mindlessly and asking the same set of questions, the approach quickly became less effective. People optimized for interview performance with books like Cracking the Coding Interview and Elements of Programming Interviews.

There are certainly parallels between what happened then and what's happening now. The difference today is that people have taken things to another level with platforms like Pramp and bootcamps like Interview Kickstart. New businesses keep popping up that focus on cracking the current system, and I don't think that bodes well for its future.

But what can we do about it? The fact is that any interviewing process can be cracked once its format becomes popular and standardized. Let's say that some major company like Facebook introduces a new standard that involves candidates giving two-hour presentations about significant personal projects and then answering tough questions from a committee. You may be familiar with this format if you've ever applied for a research position. I actually think this would be great for 2-3 years until everyone starts doing it and Gayle Laakmann McDowell or whoever publishes "Cracking the Personal Project Presentation." And then a bunch of new businesses will pop up to sell you slide templates, professional reviews, etc.

In short, I'm not a big fan of the current system (EDIT: because it's been "cracked") but I honestly don't know of a better one (EDIT: that won't suffer the same fate).

im not sure what you do with CIS, but im guessing sysadmin type stuff? if that doesnt interest you and the job listings dont either, look into a straight BS in CS degree. you can probably transfer some credits. check out an algorithms book like this one (google it for the pdf) http://www.amazon.com/Algorithms-4th-Edition-Robert-Sedgewick/dp/032157351X or this one http://www.amazon.com/Introduction-Algorithms-Edition-Thomas-Cormen/dp/0262033844 and if they interest you check out CS. take some courses for free on codecademy and see if web programming interests you. theres a million ways to go online and check out other cs related avenues that might be more for you. explore cs classes on your campus after reading the course descriptions, audit a class for free. sign up and then leave during drop add. see how things sound. check things out. good luck!

Yes - knowing how to write a great sort algorithm is fairly useless in the real world. You're better served learning good programming and principles of software design. Please get a copy of Code Complete and absorb it, as well as finding out your company's particular methodology.

The biggest problems with fresh-out-of-the-womb coders is you make mistakes that make your life more difficult down the line - use functions, don't write code in-line. Don't make everything global variables. Name your functions and variables carefully. Understand scope. If you're doing something complex and hacky to achieve a goal, take a step back and think if you can solve your problem a different way. Don't hesitate to ask for advice, online or at work. It is not a sign of weakness, but instead a sign that you're willing to learn.

For scripting this kind of thing is not nearly as important, but you may as well start trying to write nice code there. Ask for a coder to look it over and give you tips. Make sure everything you write is well documented and readable!

Good luck, have fun!

I feel for you OP. I recently inherited a fully functional system already in production that was horribly coded. It is now in very good shape, and with a 92% test coverage. It is possible OP! ;)

Yes definitely create the UML diagrams. When you understand it well enough to create a high-level diagram, you will be much better armed, both for making changes, and for showing outsiders why A and B are important to do, since you have something concrete to go from. I would recommend this UML editor for it.

Next, is the code sufficiently under test?
If not, buy and use the book Working Effectively With Legacy Code by Bob Martin. It helps a lot. First step is getting at least some of it it under test. The book is a big one, but you don't need to read it all to get cracking. It is like a recipe book:

"Let me see, okay, I have eggs, chicken, and a 1000+ lines class calling into an unknown legacy system. Then I should use the coding recipe on page 432, and plenty of garlic. Always use plenty of garlic."

Best of luck OP!

The Engineering Practicum is the one for, like, freshmen and sophomores, right?

Look, just... be cool about it, haha. Check out LeetCode and get comfortable with the Easy questions. FYI, you probably won't know a lot of the stuff — but that's okay! Mostly you just wanna get comfortable with the types of questions. If you want, you can pick up a copy of Cracking the Coding Interview (CTCI), but I'm not sure it's worth it if you aren't applying to other internships this cycle. Honestly I've just used it for questions mostly, and there are plenty of questions on LeetCode.

Just keep positive and study what you can. Let us know how it goes! :)

Short answer - yes, self-taught coders can (and do) get great jobs in the industry. You can absolutely pursue a software career.

Long answer - first and foremost figure out if this is the right path for you. Do you genuinely enjoy coding? There's no way to answer that question other than to start learning and building things. There are ample resources available online for free, so all you need is a computer with internet and lots of free time.

Then figure out what areas you're interested in, whether it is front-end/UI development, back-end services, full stack, mobile apps, windows apps, databases, big data/analytics or anything else.

You can either build up a portfolio of personal projects or go to college. A 4-year CS degree will obviously be ideal, but is definitely not necessary. Do note that it is much harder for self-taught programmers to get noticed and get hired, so along with sharpening your resume and coding skills also attend job fairs and networking events and make connections.

Before you start applying for jobs, I would check each box on this list:

• Know at least one mainstream programming language (C++, Java, C#, Python, Ruby etc.) really well.
  
• Have an up-to-date resume with lots of relevant personal projects.
  
• Try and get some part-time programming jobs (or internships) on the side to put on your resume.
  
• Be familiar with common data structures and algorithms. I suggest reading Introduction to Algorithms.
  
• Prepare for interviews by reading Cracking the Coding Interview or a similar book, and practice solving as many coding problems as you can in your language of choice.
  
  All of this is assuming that you want to be a programmer. There are a lot of other career options in the industry, like IT/operations, DBA, product management etc. so give those a thought as well.

Contribute to open source. Create something of your own, and contribute to other projects. Since you are basically self taught and you are going for your first gig, conveying to prospective employers that you care about design, testing, and that you are not a cowboy will help. Read and understand books like Practical Object-Oriented Design in Ruby. Also, don't be a one trick pony. Tackling JavaScript could be a next logical step. Needless to say, all your open source and projects you demonstrate should have good test suites.

Learn about the non-technical stuff as well. I think Land the Tech Job You Love is great, and you probably want to look into Cracking the Coding Interview as a starting point for learning more about algorithms and data structures. Upcase is another great resource for beginning/intermediate Ruby programmers who want to up their game. Start solving challenges on e.g. codewars.com.

> Have a lot to learn about OO

Read Head First Design Patterns. It is written in a style that is super-corny but actually sticks in your head really well. Also, the syntax it uses is java, but you don't need to know how to write Java.

Learn how to write Automated tests. They will help keep you from spending late nights hunting down bugs. Test-Driven Development with Python is excellent and free.

Also, learn to use assertions and pdb to find bugs.

Learn how to set up your development environment and servers. I recently wrote a tutorial on this and would be grateful if you would check it out and give me feedback: https://amfarrell.com/saltstack-from-scratch/

I'm sorry you're going through this. Other commenters have said it'll get better and stuff (which it will!), but below I've linked some resources I've collected over the years for you to use. Hopefully this will help!

1. Cracking The Coding Interview
   
2. Read through this site and this Wiki, really try to understand what it's talking about. Try some simple implementations of the patterns. The main thing with patterns is being able to recognize and apply them. Sometimes in reality they don't look as simple as the nice graphs on the page.
   
3. This is another good article on good API design practices.
   
4. This is a good article on writing Testable code.
   
5. Here are some terms for writing good unit tests, you should Google these and start looking into it: Domain Analysis (Input and Output), Structural Analysis, Unit Test Patterns, Mocks, Test Driven Development.

Here are some extremely good books for getting ready for Computer Science/Software Developer interviews:

Cracking the Code

Programming Interviews Exposed

Elements of Programming Interviews: The Insiders' Guide

Also if you want to build a programming portfolio you could create an account on Github and post samples of your code and other projects. Heck you could go through old textbooks and create code and post that up.

Additionally a popular, although paid, resource is pluralsight which has a $29 monthly subscription with tons of Computer Science topics and programming languages. I emphasize that pluralsight is optionally though. There are many free resources available.

Good luck! You can do it!

Please tell him that practicing for interviews is an absolute MUST in this field. I have a CS degree (with a high GPA) and 5 years of experience, and even I need to spend a minimum of three weeks full time reviewing and practicing for interviews to do well (potentially longer if I'm also working). These things are very tough, and a totally different beast than anything you experience at school or work. The payoff is amazing if you do this though, as there is such a high demand for people with tech skills. If you can combine those tech skills with great people skills, even better. You just have to put in the hours and endure the pain of jamming algorithms and datastructures into your brain for a few weeks. Interviews are changing in some places to have a more practical focus, but the traditional type of preparation will still be useful. My recommendations:
https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850
https://www.hackerrank.com/domains/tutorials/cracking-the-coding-interview
Interviewing.io

Getting the first job is the hardest, and if he feels like the person who he is talking with could be a good mentor, it might be the right choice. However, it sounds like he didn't prepare as well as he could have, so he might be eligible for other jobs that are better located. Definitely consider his mental health, though, and don't push him to keep going if he clearly is suffering.

Lots of waffling in that last paragraph there, sorry. I just finished the interview process and accepted a job, so I feel his pain. I was lucky to have several job offers all at once, but I would have been very tempted to stop if I had only received one, even if it wasn't great. It's a grueling process!

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.

Every single management position on the planet is uniquely specific to the team/group being managed. People are unique and different. The work they're doing may share some things in common with similar groups, but it is also unique and different in meaningful ways.

I don't think it's necessary for every engineering manager to have first been a high-performing 10x-er engineer. I do think there are inherent benefits to having those individuals progress to leadership/management positions within a company, but there's a lot more that goes into what makes a "great manager" than simply being able to finish projects to spec, of quality, on time.

Recommended reading: The Manager's Path and Managing Humans, "A Meritocracy is a Trailing Indicator".

So I am more of a book guy these days. I found Algorithms + Data Structures = Programs by Niklaus Wirth to be pretty solid. For something a bit more contemporary Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein is a very good textbook. If you're into math and learn best from repetition I'd suggest The Art of Programming Vol 1 by Knuth as well.

The issue I have with a lot of online content is the economics of the Internet are such that its not profitable to go in-depth, so its definitely worth paring online courses(whether they're from an accredited university or not) with a textbook or two. You might even want to crawl down the rabbit hole further and dig into the camps of mathematics where these concepts derive like Queue Theory or Set Theory. If your the type of person who gets the most out of things by tracing concepts to their roots digging into the maths helps a ton.

Three CS fundamental books in the order I'd suggest someone read them if they don't have a background in CS.

• Modern Operating Systems - Tanenbaum. This, or any good OS book is something that anyone writing software that runs on servers should read. If you happen to only write frontend JS or HTML, you can probably skip it or push it to the end of the list.
  
  
• Design Patterns:
  Elements of Reusable Object-Oriented Software - "Gang of Four". My preferred way to consume this book is to read it lightly, understand the basics of the patterns, and then come back to them individually when you encounter them in the wild or think you want to employ one of them.
  
  
• Algorithms - Sedgewick. If you want a more mathematically rigorous treatment, Introduction to Algorithms - "CLRS" is excellent as well.
  
  
  
  
  Then there are these books that aren't really "CS books", but are geared more twoards practitioners.
  
  
  
• Clean Code - Martin
  
  
• Code Complete - McConnell
  
  
• Working Effectively with Legacy Code - Feathers
  
  
• The Managers Path - Fournier This one might seem like a weird suggestion, but even if you don't have plans to become a manager, it can help with understanding the path to a Tech Lead type of role. You'll also get a good idea of how your boss can and should be helping you, and what you should be asking of them.

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.

I'll let you know once I figure that out.

The biggest problem is that as cool as design patterns are, real world problems rarely, if ever, fit directly into the mold of a design pattern. Sometimes you need to combine multiple patterns. Sometimes you need to majorly tweak the pattern to make it fit your problem. Then there's question of, are you over-engineering your solution?

All hard questions to answer. The best way to know is... experience. Have real world experience of trying these things out. So to answer your question, the best way to learn how to use design patterns effectively is to use them on real world problems. Not a satisfactory answer by any means, but for some things in life, there are no shortcuts.

It's like answering, "How do you get good at public speaking?" The answer is to speak in public. There's no book you can peruse, there's no youtube video you can watch. You just have to do it again and again and again.

That being said, reading about design patterns is step 1. Everyone knows GoF. It's a really dry read. Personally, I own Head First Design Patterns. Very easy to read. I haven't bought the design pattern resource you listed, but I did read the freely available ones. Personally I think it's too simplified. Again, I highly recommend Head First Design Patterns. I wish there was Head First everything.

Current Microsoft intern here! You've got your first sentence perfectly in order of increasing importance. Since you interned at IBM, I'm assuming you have a decent grasp of data structures and algorithms. If not, you now know where to start!

Do some thinking around your app -- if that's a highlight for you, then it's going to come up. Who was your audience? What was the goal of the app? What were the design choices you made? What could you have done to make it better? faster? more secure? What did you learn?

Go pick up an interview book or two -- I used Cracking the Coding Interview to prepare. If you notice yourself stumbling anywhere (especially the first two-thirds of the chapters), be sure to do some learning around the things giving you trouble.

I wrote about my interview experience at Microsoft, if that interests you. It's also got some links to other people's experiences.

Refactor as you go.

Here are some sources on how to get better over time, at doing right the first time as well as getting it right afterwards :

• First quick read : www.sourcemaking.com
  
• How to write readable and maintanable code : clean code
  
• How to refactor as you go : working effectively with legacy code
  
  Take your time with it. It took me ~5 years of practice before i was able to produce good code. And it will probably take me another 5 to produce great code. That's the way it is.
  
  I was in your exact position at my first gig : i also removed my name from all the code. But that's good because it meant that i improved enough to see what i was doing wrong at the time.
  
  After that i discovered unit tests, and then clean code, tdd etc.

I'm still pretty inexperienced, so I would LOVE feedback as well!

Code should be self-documenting. Variables, functions, classes, etc. should be named descriptively. Here's a rather contrived example:

if(flag1 && flag2 && flag3)
doSomething();

What do the flags, well, actually flag? What are they meant to symbolize? What the hell does doSomething() do? At first glance, I can't tell what the point of this code is.

boolean isHireable = person.isCompetent() && person.isFriendly() && person.hasGoodHygiene();
if(isHireable)
addToCandidates(person);

If I leave this project for a year and then come back, I might forget how the underlying implementation works, but at least here, it's MUCH easier to make an educated guess.



Comments should be used sparingly. Unless there's a good reason, you shouldn't use comments to describe your code (remember, your code should be self-descriptive). What happens if the code changes, but the comment doesn't? Then the comment becomes misleading or even incorrect, which can confuse maintainers down the line.

If anything, the comment should reflect the intention of the code, rather than the code itself. That way, even if the specific implementation of that intention changes, the comment still accurately describes the purpose of the code.

You should also remove commented-out code (use version control instead!). At least in my experience, it can cause a lot of confusion and clutter.



Sometimes you'll find yourself repeating the same or similar code across many different functions. Maybe that code can be extracted into it's own function, and you just call it when you need to.

Try to keep your functions small, they should really only do one thing, and one thing well.



You might also be able to find guides for your specific technologies. For example, best practices for a designing a Java class hierarchy might not apply to handling events in Javascript. Your company might enforce a styling guide or the community surrounding a particular technology might have de facto conventions.



I've also found this book to be a pretty good resource. It's based in Java, but you can apply the principles to a lot of different areas. http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Do you have evidence of what you're capable of? (Contributions on Github, a website, a portfolio, published researched papers, etc.) If they have an idea of what you can do before you start the interview, that'll help them a) tailor questions to your skill set and experience, and b) understand that you do know what you're doing.

I've seen Cracking the Coding Interview recommended on this subreddit quite a few times - the author probably has much better advice than anything I can think of. :) Best of luck.

Not sure if it exactly follows this situation, but one of the best books I've read - helped me develop some good habits. Highly recommend.


Clean Code: A Handbook of Agile Software Craftsmanship https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_api_irVJzb23P5CQ3

Does anyone know what would be best to prepare me for interviews for new-grad interviews that'll probably open during Fall 2019? I don't think it's that important to have side projects as I have internships/experience under my belt, so I just want to be studying/enhancing the foundation I have. I currently own CTCI and The Algorithm Design Manual. I'm planning on getting the Gang of Four Design Patterns, but I'm not 100% yet. Anyone know any good resources for System Design? Any feedback on how should approach this preparation? I know it's super early, but better early than late.

It would help to identify what point you made it in the recruiting process.



Recruiting Step | If you didn't make it here...
---|---
Company Reads your resume | Apply to lots of companies, network (tell everyone you're looking for an internship), and attend recruiting events / career fairs
Company invites you to initial interview | Polish your resume / cover letter
Company invites you to follow-up interview | Improve your interviewing skills
Company offers you an internship | Improve your interviewing skills

Improving your interviewing skills includes learning how to communicate, but more especially for CS related interviews it includes learning how to complete those coding style questions you'll be asked. This book might assist with coding questions.

The few times I have been asked by my employer to participate in recruiting I mostly looked for candidates who correctly knew how to use data structures, understood Big O notation and correctly analyzed their code using it, and also clearly explained what they were doing as they were solving the problem. Candidates were less desirable when they sat there silently not explaining their thoughts to me or writing a really convoluted solution that completely ignores well known data-structures / algorithms (even though we told them they were welcome to use any that they knew).

First of all, this is an excellent post. I've seen so many questions posted here but yours is the most concise and upfront. I know exactly what your background is and so I'm more confident that what I want to suggest would actually be relevant.

You have solid industry experience with academic foundation. And I think you already are aware of the pitfalls of expert beginner (http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/). I think you are in a sweet spot where you can afford to invest resources without immediate gain - unlike early-career coders, you don't have to necessarily learn another language/framework right this second. You can afford to deepen your higher-level understanding of concerns and concepts that are timeless and not bound by the language/framework of the day.

I'd like to suggest you read other people's code/design. Here are some books to get you started.

• The Architecture of Open Source Applications
  
• Beautiful Code: Leading Programmers Explain How They Think
  
  Another thing you can invest in is everyday skills as a programmer. This is a classic on this subject.
  
  
• The Pragmatic Programmer: From Journeyman to Master
  
  You can couple ideas and tricks from here with any devops tools of the day to automate much of your workflow, such as bash/git/unix concepts onto automation tools such as docker/jenkins/ansible. Additionally, familiarizing/customizing your personal development environment. Improving scripting skills to automate many many things (practically everything that we do on computers that doesn't involve creative process are automatable. It's just a matter of ROI.).

I wish I could have done double degree/major at my university. I could have taken CS courses but curriculum structure between CE/CS was too big of a difference... Needing a ton of pre-requisitions that I did not have in CS. And department wasn't willing to give me an override (yay overpopulation).

And my CE is mostly hardware focused albeit it is being advertised as CS+EE. And hardware as in... mostly non-computer related. Quantum physics in circuits, microelectronics, etc etc. I'd consider those as more of EE with electrophysics concentration. And you'd be surprised how many low-level embedded programming classes we have.... three. Two of those three aren't scheduled to be offered in the next five years, including previous 3 years, due to budget cuts. So basically one. Every semester we were promised more CE courses would be offered.... except more CE courses were cancelled instead.

Any particular book you would recommend? I'm currently reading through this book and it is helping me a lot.

And congrats on your offers!

As anyone working in tech will tell you, landing a job/internship can be attributed to some combination of past work, interview practice and luck.

Some good resources for interview practice are https://www.hackerrank.com/ and https://coderbyte.com/. There's also Cracking the Coding Interview, which is a must have for any technical interview prep.

To find a side project to work on, I would suggest trying to solve a small problem you have in your daily life with software. For example, maybe you want to brush your teeth for longer, or remember to do something everyday. A project like this will allow you to both write actual code, but also talk about your process with deeper understanding to interviewers.

Besides that, there are other great online resources that can help you learn more nuanced aspects of software engineering like https://egghead.io or https://doyen.app.

I can address a couple points from the perspective of a new-grad software engineer in the Silicon Valley with a lot of internship experience.

Having no experience hurts you regardless of your age or school status. I'd recommend actually finishing some personal projects so you have something to show and talk about in an interview.

Charm and enthusiasm are important for CS interviews, but less so than in softer fields. They can easily test your programming strength in an hour interview, unlike with many other professional skills. In a CS interview they are going to want to get an idea about your actual CS abilities.They'll ask questions about algorithm complexity and design and will probably have you do some coding on the whiteboard. I'd recommend reading a book like Cracking the Coding Interview and working through every single exercise in the book.

> I'll also make sure I have the necessary skills before even considering interviewing and preparing more when I do.

No. Interview often and for jobs that might not even fit your skillset. If the company grants you an interview based on your (honest) resume, then they think you have at least a chance at getting the job. But more importantly, it will give you more confidence and make you more comfortable in those intimidating situations.

I got by BS in compsci last year and have been working at an ok company since then. I interviewed about every other month that whole time with other companies, some I didn't even care about. But I just got an offer from one of the Big 5 this week and I think a lot of my success came from interviewing often and becoming comfortable with that situation. Also, Cracking the Coding Interview helped with a lot of the preparation. Knowing what to expect from these types of interviews and preparing for that scenario is a big confidence-booster.

Also, as a side note, what school did you get your degree from that you hadn't heard of the modulus operator before?

Make sure you can whiteboard all the easiest questions from this book: http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X

But do so in a way where you are not memorizing answers but instead learning the concepts and the problem solving techniques. A side benefit is you will almost certainly write better code and find more elegant/performant solutions at your current job as well.

Well, I would say you should try to work your way through this: http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
The other thing you might want to do is find a personal project you're interested in and contribute/complete it. When you work on your project you would be able to brush up on your skills and have something to talk about in your interview. As far as tutorials go, you could try Coursera, Udemy, or MIT's open courseware. If you have any of your projects or textbooks from school you could look over those and try to "improve" your work if possible. I'm new to this sub but have been visiting daily for a quite a while and I think these things would all be something to look into. You might also want to look into finding an internship where the pressure might not be as high and the compensation won't be as high as if you were full time but you'd get some experience and if you do a good job you might get an offer at the end of your tenure. Best of luck!

I went through the Google interview process not too long ago. Here's my recommendations:

• Don't focus all of your effort on one concept. You will have at least four different types of problems and there is no guarantee that DP will apply. While this is an anecdotal n=1 observation, I did not have any DP problems. You should still look into DP so that you may better understand where to apply it and the basics of applying it, but don't neglect other areas (graphs for example).
  
• Grab cracking the coding interview and practice on a white board. I used a small travel whiteboard that you can get on amazon for ~$6.00. (Though, based on the reviews, I also grabbed some better markers.)
  
• Practice easy questions to warm up, then give yourself 30-40 minutes to solve the more challenging questions.
  
• Don't focus on memorizing the exact implementation of different algorithms. Know their basic flow and different places to optimize, but more importantly know where to apply them and what their complexity is.
  
• Remember to talk through the problem before solving it. Your interviewer will often give you some indication of whether or not it's the solution they want to see. When actually writing the code, don't feel obligated to explain every line as you're writing it. If you feel like you're making a good decision, explain what it is and why in a sentence or two, but otherwise focus on getting your thoughts on the board. You should explain your solution at some point, but unless they ask questions about it, don't feel obligated to talk while you write.
  
• Don't try to solve every part of the problem at once. If you hit something you're not sure how to solve, call a function that does not yet exist and tell them you'll come back to its implementation.
  
• You mentioned being able to solve things in 23 minutes. I don't think that really applies. Some interviewers will give you one hard problem which may be optimized several ways. They will expect you to implement a solution and spend the rest of the time optimizing it. Other interviewers will give you perhaps 4 problems, but all of them are inter-related and earlier solutions to problems are used as components to later problems. You may also be given one or two small warm up problems before a larger problem. However, it is unlikely that you will be given two very different and complex problems and have 23 minutes to complete each one. Furthermore, completing every problem isn't a requirement. Demonstrating good problem solving skills is. Don't focus on a specific amount of time, focus on the problem solving process. This is also true because it will take you less time to solve the problems in the interview because of guidance from your interviewer.

Don't leave on that account alone. If you have a passion for programming, these concepts you missed can still be learnt. You do not stop learning once you finish your studies, on the contrary, CS is one of those professions where you have to constantly update your knowledge pool.

I would not worry as much about the details of what a protected class and if a subclass can access private members or not. Master instead concepts like encapsulation, separation of concerns, abstraction, ... concepts that transcend language-specific syntax. If you are actively studying by yourself, you will get always improve.

If you want to polish your OO skills, I highly recommend you find yourself a copy of Applying UML and Patterns. I would also recommend reading Code Complete 2, a must-read for all software developers.

As far as your courses go, the best book I can recommend is Algorithms in a Nutshell. It is a small book which quickly introduces you to most of the core algorithms you will use throughout University. It also covers measuring efficiency through "big O notation" - a very important concept in CS.

If your University's SE program is anything like the one I am familiar with, you will also be focusing on software engineering principles. The most important SE books I ever read are:

• Code Complete
  
• Design Patterns
  
• Clean Code
  
  These three books have strongly influenced me as a developer

You were showing off. I probably would have hung up as well.

The best code is boring. It just reads like prose. And it's tremendously difficult to write.

I am an architect / dev lead. I read a lot of code that others wrote. I don't want to spend any brain cycles parsing your code; I need to be able to focus on what you are doing and what the overall design is.

We have one developer here who apparently gets a bonus every time he uses the ternary operator. He likes to nest them as well as AND and OR his conditions.

return cond1 && cond2 ? val1 : !cond1 && cond3 || cond2 ? val2 : val 3

Very cute, but utterly unreadable.

My advice to you is to read the following books:

• The Elements of Style - I'm absolutely serious. It teaches you to write English clearly and the same principles apply to coding clearly.
  
• Clean Code by Bob Martin.
  
• Implementation Patterns by Kent Beck.
  

I have been interviewing the past few weeks. The 2 things that have helped me prep:

• HiredInTech - They have pretty good guides on how to prep for interviews. As someone who has interviewed 100s of people for Amazon it is pretty solid.
  
• Cracking the Coding Interview Book - Has great example questions and tips for interviewing

A couple things:

1. Pick up a copy of [Cracking the Coding Interview] (https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850/ref=dp_ob_title_bk)
   
   
2. Register for a trial Pluralsight account and go through the Javascript/JS libraries tutorials
   
   
3. Have a decent portfolio. Make a blog site to show you understand dynamic input. Have a site where you input some values in a form and use those values to calculate something (take home pay calculator, mortgage calculator, student loan repayment, ect).
   
   
4. You're competing with not only other college grads, but people who've been interviewing for awhile too. Make sure you practice your interviews with a friend. Don't skimp on the HR questions. I've stumbled on the "Tell me about yourself question" more times than I'm proud of.
   
   
5. Have some stuff on GitHub that you can show off.

It happens. Try not to worry about it too much - things are going to be OK. There's a job for you out there.

Practice a lot. Find lists of interview questions online, and try to code all of them - first on paper and then with the help of a computer. Learn them through and through, so that you can easily recognize variations of them. Consider getting this book.

Feel prepared in your next interview. Good luck!

fwiw, bare minimum working code is often a good idea if we're talking about the amount of code to do some task :)

Design patterns are most useful in that they help you start recognizing patterns in your own code, and they show you a number of common patterns which can be useful - but it's good to keep in mind that you shouldn't force a design pattern somewhere just because it's a design pattern.

Anyway, the Design Patterns book is good, and so is Head First Design Patterns.

While there are coding standards at companies bad design is the main culprit of bad code.

I work at a 600 person company and on the project I'm on there are 10 software engineers for a verity of subsystems. The subsystem I am in charge of had gone through 4 other developers before I it came to me. I work with 2 other people since it's a fairly large subsystem. When you look at the code it was pretty crappy and you could tell 4 different people with 4 different design plans were in there. Class that were 3000+ lines were common. No division of responsibility or anything.

I made sure every time I fixed an anomaly I fixed that code too. It could be something as making a new class, fixing variable naming or just cleaning up methods. Then issues came up where the current design just didn't work and me and the people I worked with just redesigned the whole thing using inheritance and all. So over time the code will look great I hope.

On the flip side when it's time to cut a release I'm always cutting it close since to fix anomalies I redesigned code to make sense and not patched/band aid the fix it like other people. Other subsystem leads ether don't want to do redesign for being scared of breaking it or just don't give a shit. I know every time I mention something about redesign or new module at status meetings this one engineer always likes to joke about how I have to be done sooner or later.

I guess the point is there are software engineers who like the design aspect and some who are indifferent and look for easy solutions and not necessary that elegant one. Taking a feature and figuring out how the classes will be laid out and who will be responsible for what is interesting and enjoyable for me The coding is fun too, but once you have your design everything is just following that design for the most part.

I've found the following book to be a good read. I don't necessary agree with all of it as I think some of the concepts they present are taken too far, but the ideas they are presenting have a good foundation. http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

I rarely see this posted here for some reason, but I've found Elements of the Programming Interview to be a really great book, and far more helpful than websites like careercup.

well, since no one has said it yet Cracking the coding interview is a great resource for learning the stuff you'd be tested on.

Over summer, for a project it doesn't have to be amazingly unique, just something you're interested in.

If you have some free time learning a functional language like Haskell really helps learn a different side of programming than the traditional imperative/objective norm.

Sadly there are a lot of companies that operate like this and I wish I could say this isn't common , but it is, especially around non technical companies that do in-house development. However, there are lots of companies changing and trying to improve their process and code base.

Working with legacy code is something every developer has to do at some point. There are techniques to make the process easier. Checkout the book Working Effectively with Legacy Code

Also, try and follow the boyscout rule of programming. Always leave the code base slightly better than you found it. You don't have to go crazy, but little improvements here and there. Test the new code you write and over time you'll have a much cleaner and better system.

I used to work on a web application that was so horribly coupled together that any small change literally break the whole thing and cause hours of debugging. I know your pain.

A few suggestions for you:

1. Buy and read Effective Java, 2nd Edition. It's a fantastic book on good patterns & habits to use with Java, written by one of the language's authors.
   
2. Strongly consider using Maven, Gradle or something else that can pull Maven dependencies as your build system. It's so much nicer than keeping a bunch of jars around, and can make it much easier to reuse any libraries in your portfolio.
   
3. If you have a server-ish pc at home, try setting up a Jenkins server on it to automatically build & test the projects in your GitHub account.
   
4. When your applications start getting bigger, check out the Spring Framework. Especially the JDBC stuff when you start using a database, and Spring MVC is hands-down my favorite way to write a web API (it's the closest to Flask/Rails I could find for Java).

I was surprised to see that Gayle Laakmann Mcdowell (author of [Cracking the Coding Interview] (http://www.amazon.com/Cracking-Coding-Interview-6th-Programming/dp/0984782850/ref=asap_bc?ie=UTF8), which I see recommended pretty frequently around here) uses [Square Space for her site] (http://www.gayle.com/). So no, it would seem not to matter so very much, to most people.

However, I still chose to take down my Jekyll site to code one by hand because (1) I wanted to customize things that were difficult/buried in Jekyll and (2) my general front-end newbiness made me feel like it was still the better option.

If you are an old pro like McDowell or a pure back-end dev with few aspirations to be otherwise, it probably doesn't matter. However, if you want to employ or contract someone at the junior level to do front-end work, you'd probably prefer someone who didn't use a template for their own site, would you not?

I would recommend brushing over some basic CS concepts first. Since you've been out of school for a few years now, it might be a good time to start working on little side projects and/or programming exercises if software engineering is what you want to get into.

You can also check out this book, which will help you prepare for a programming/tech interview.

What type of job are you looking to get? Are you interested in software support? development? IT? Your preparation will depend on what route you want to go down.

Copy pasting my response to a similar question:

Edited to have more resources and be easier to read.

It's hard to draw the line between "essential" and "recommended." That depends a lot on what you want to do. So, I will present a rough outline of core topics covered in the 4 year CS program at my university (UC Berkeley). This is not a strict order of topics, but prerequisites occur before topics that depend on them.

Intro CS

Topics include Environments/Scoping, abstraction, recursion, Object oriented vs functional programming models, strings, dictionaries, Interpreters. Taught in Python.

The class is based on the classic MIT text, "Structure and Interpretation of Computer Programs." Of course, that book is from 1984 and uses Scheme, which many people don't want to learn due to its rarity in industry. We shifted recently to reading materials based on SICP, but presented in python. I believe this is the reading used now. This course is almost entirely posted online. The course page is visible to public, and has the readings, discussion slides / questions and solutions, project specs, review slides, etc. You can find it here.

Data Structures and basic algorithms

DS: Arrays, Linked Lists, Trees (Binary search, B, Spaly, Red-Black), Hash Tables, Stacks/Queues, Heaps, Graphs. Algorithms: Search (Breadth first vs depth first), Sorting (Bubble, radix, bucket, merge, quick, selection, insert, etc), Dijkstra's and Kruskal's, Big-O analysis.

This class uses two books: "Head First Java" and "Data Structures and Algorithms in Java" (any edition except 2). The class doesn't presupposed knowledge in any language, so the first portion is covering Object Oriented principles and Java from a java book (doesn't really matter which), then moving to the core topics of data structures and algorithms. The course page has some absolutely fantastic notes -- I skim through these before every interview to review. You can also check out the projects and homeworks if you want to follow along. The course page is available here (note that it gets updated with new semesters, and links will be removed -- download them soon if you want to use them).

Machine Structures (Intro Architecture)

Warehouse scale computing (Hadoop Map-Reduce). C language, basics of assemblers/compilers/linkers, bit manipulation, number representation. Assembly Language (MIPS). CPU Structure, pipelining, threading, virtual memory paging systems. Caching / memory hierarchy. Optimization / Performance analysis, parallelism (Open MP), SIMD (SSE Intrinsics).

This class uses two books: "The C Programming Language" and "Computer Organization and Design". This class is taught primarily in C, so the first few weeks are spent as a crash course in C, along with a discussion/project using Map-Reduce. From there in jumps into Computer Organization and Design. I personally loved the projects I did in this class. As with above, the lecture slides, discussion notes, homeworks, labs, solutions, and projects are all available on an archived course page.

Discrete Math / Probability Theory

Logic, Proofs, Induction, Modular Arithmetic (RSA / Euclid's Algorithm). Polynomials over finite fields. Probability (expectation / variance) and it's applicability to hashing. Distributions, Probabilistic Inference. Graph Theory. Countability.

Time to step away from coding! This is a math class, plain and simple. As for book, well, we really didn't have one. The class is based on a series of "Notes" developed for the class. When taken as a whole, these notes serve as the official textbook. The notes, homeworks, etc are here.

Efficient Algorithms and Intractable Problems

Designing and analyzing algorithms. Lower bounds. Divide and Conquer problems. Search problems. Graph problems. Greedy algorithms. Linear and Dynamic programming. NP-Completeness. Parallel algorithms.

The Efficient Algorithms class stopped posting all of the resources online, but an archived version from 2009 has homeworks, reading lists, and solutions. This is the book used.

Operating Systems and System Programming

Concurrency and Synchronization. Memory and Caching. Scheduling and Queuing theory. Filesystems and databases. Security. Networking.

The Operating Systems class uses this book, and all of the lectures and materials are archived here (Spring 2013).

Math

Those are the core classes, not including about 4 (minimum) required technical upper division electives to graduate with a B.A. in CS. The math required is:

• Calculus 1 and 2 (Calc AB/BC, most people test out, though I didn't)
  
  
• Multivariable calculus (not strictly necessary, just recommended)
  
  
• Linear Algebra and Differential Equations.
  
  Those are the core classes you can expect any graduate from my university to have taken, plus 4 CS electives related to their interests. If you could tell me more about your goals, I might be able to refine it more.

I think it would be good for you to read Clean Code. The things you dismiss as unimportant are in reality super important to make for a codebase that lasts longer than a couple of months.

Good, accessible code does not contain spelling errors. A 500-line class is too long. At my work, even things like //This method does x usually get a comment saying "missing space between after //".

Yesterday, we merged in a PR that had been open for 2 days and had 76 comments on it (that, admittedly, was too much, but it goes to show that the details matter, even in large PRs). Reviewing again after incorporating code review feedback is just as important because it's brand new code that others will have to approve.

Also agree with /u/batsam that we try to keep our PRs small so it makes it easy to review.

I'm going to disagree with a several of the other comments here: don't feel pressed to ask textbook questions that are narrowly related to the job you're hiring for. Hiring narrow specialists tends to yield devs that are good at a narrow set of tasks. "Abstract algo questions" have a better track record of hiring strong devs that are better able to pick up any task that may come up.

Remember: it's easier for a great programmer to learn a new technology than it is for someone who knows that technology to become a great programmer. I should know: I've done over two hundred interviews for my current employer, most for positions where I would have to work with the developer directly. I've been in interviews where we hired the wrong candidate and it's almost never worked out well. In most of those failed hires, the rationale was "well, yes, he didn't do great on the interview, but he has experience with $TECHNOLOGY that we desperately need!"

As for your question: I highly recommend "Elements of Programming Interviews" by Aziz, et al. Amazon link

It provides a wide range of questions that you can tweak to suit your needs, in a range of difficulties from relatively easy to mind-bendingly difficult. None of the problems, however, are trivial in the way FizzBuzz is. (And seriously, if you're asking FizzBuzz or similar in interview, your sourcing process needs some work.)

I hope this helps. Interviewing programmers is a devilishly hard problem and tough, pointed data structures, algorithms, coding, and design questions under interview conditions isn't an ideal solution, but it is the least shitty one anyone's yet found, so far as I know.

Best of luck in your search!

Program Manager can mean different things at different companies but I'd highly recommend checking out Cracking the PM Interview. Even though it's interview themed it will teach you all the basics of product management (which may or may not align with what you're doing in your day job but will certainly be related and good to know).

Depending on what your current job entails I can also recommend some books on project management, user experience, soft skills, etc.

wow. I'm surprised these two aren't listed yet:

Pragmatic Programmer - this one's at the top of my list. I think that every single programmer should read this book.

Effective Java - although it's written for Java there's some great fundamentals in there.

a lot of people also mentioned Clean Code - while some things in there are important, I personally don't agree with everything that Bob writes about

This book is the much more hardcore version of CODE. I always cite the two as my personal favorites in terms of enjoyment and truly providing ground-up explanations of how computers really work: https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686/ It's also known as "NAND to Tetris," perhaps you've heard of that before.

Otherwise, more in the direction of CTCI, this is one of the best interview prep books I read, without being explicitly about interview prep: https://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693/

As /u/Amarkov said, you're not screwed and you really should put in the time to learn basic algorithms and data structures. But, I also think it's a bad idea to go overboard.

For example, you should know why and when you'd use a binary search tree over a hash table, and be comfortable implementing basic graph algorithms (BFS, DFS, shortest path). But, much beyond that, and you are likely better off spending your time actually building stuff and developing your coding skills. I know most of the big tech companies will grill you hard on CS, but many smaller companies will be more concerned with how quickly you'll be productive with their tech stack. Rather than have you implement a graphing algorithm, they'll want to see that you're comfortable with Java's threading model or writing a JQuery plugin or working with Active Record or whatever.

I'd recommend grabbing either of these books and working through at least 2 or 3 questions in the chapters you're weak on. At a minimum, they'll help shine a light on your blind spots.

• http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
  
• http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Landing/dp/1118261364/ref=sr_1_1?s=books&ie=UTF8&qid=1407703243&sr=1-1&keywords=programming+interviews+exposed
  
  tldr; You're not screwed, and learning the CS essentials well enough for NotGoogle-level interviews can be done with a few weeks of effort.
  
  
  
  

Good news is you have previous experience and C is a very simple language.

Learn C The Hard Way has some weird shit in it (wtf does "make is your Python now" even supposed to mean?) but it is largely good and do tend to recommend it despite the warts.

Really though, why not go straight to the source?

Just make sure you master pointers. It is really useful to understand what memory is on a physical or near physical level to understand pointers. It is one of those concepts that makes instant sense if you come from a hardware point of view, but can trip up newbies with a software point of view.

I think people in this comment section will do a good job with the ideas, but here are some questions you should know. Maybe some are fairly hard since you seem to be playing down this interview, but you can never be too prepared. Some of these are from: an Amazon interview me and my friends went to, other interviews I had, internet, and a book I read.

Java Questions:

"Whats the difference between final, finally, and finalize in Java?"

"How does garbage collection work in Java?"

"Whats the difference between HashMap and HashTable in Java?"

"Whats the difference between String, StringBuffer, and StringBuilder? What are the advantages and disadvantages of each one?"

General questions:

"Tell me everything you know about HashMaps and then implement a simple HashMap (lets say key of type String and value of type String, don't bother with any fancy java generics)"

"How do you modify your HashMap implementation so that it can pick a random element in O(1) time?"

"What is the range of a 32 bit Integer"

"How do you rotate a 2D matrix 90 degrees?"

"Explain and give the average and worst case complexity of: Heap Sort, Bucket Sort, Radix Sort, Quick Sort, Merge Sort"

"What is the worst possible set of data for Quick Sort and how long does it take (without any fancy optimizations, just the classic vanilla version). How do we help alleviate this case?"

"Implement Quick Sort (vanilla/classic version) and Merge Sort"

"What are the 4 famous/common simple recursion functions"

"How do you find the biggest substring palindrome in a string in O( n^2 )?"

"How do you reverse a linked list?"

"Explain how Dynamic Programming works."

You should probably also run through fizz buzz, it'll only take you a few minutes, but the last thing you ever want to do is make a stupid mistake on such an easy question haha.

Every interview I have ever had, they grilled me on HashMap, so I would highly recommend you know that data structure in and out.

And of course, if you're going to try and solve these problems, do it in pen and paper. That's how the hardcore interviews work.

Talk out loud explaining your reasoning while you do it. Interviewers want to hear how you think, and why you make your decisions. This is arguably more important then getting the answer right.

Never disagree with your interviewer.

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

http://online.stanford.edu/course/algorithms-design-and-analysis-part-1

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/

http://www.geeksforgeeks.org

Those are 4 great resources if you're interested in closing that gap. I've heard good things about the Stanford one, maybe check that one out first. The geeksforgeeks site is decent as well if you like quick digestible articles.

Elements of Programming Interviews is a fantastic book to check out once you've gotten through Cracking the Coding Interview (and maybe Programming Interviews Exposed; I never worked through that book, myself). It's challenging on a whole new level and is completely worth every penny, especially once you consider how much you'll be making because of it. CtCI is a good intro, but you'll soon want something better, especially if you're interested in top-tier companies. Now that I think about it, this book outclasses CtCI in every way. Just get it.

This list is truly excellent, these are all on my shelf and highly recommended. I credit much of my success to these books.

The only big one missing for me is Pragmatic Programmer. (Yes I know it's listed further down a few times)

The feedback about "jargon for development" can be solved by going through some books cover to cover, making sure you understand the theory, and implementing the exercises. I understand that feedback to mean that the person who gave the feedback believes there is too high a chance you will inflict damage on the codebase by making decisions not grounded in solid theory.

Examples of titles that are classics and widely known:
Algorithms (4th Edition): https://www.amazon.com/Algorithms-4th-Robert-Sedgewick/dp/032157351X (there is an accompanying coursera course).

Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1469249272&sr=1-1&keywords=code+complete

Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?s=books&ie=UTF8&qid=1469249283&sr=1-1&keywords=clean+code

Functional Programming in Scala: https://www.amazon.com/Functional-Programming-Scala-Paul-Chiusano/dp/1617290653/ref=sr_1_2?s=books&ie=UTF8&qid=1469249345&sr=1-2&keywords=scala

Learning Python: https://www.amazon.com/Learning-Python-5th-Mark-Lutz/dp/1449355730/ref=sr_1_1?s=books&ie=UTF8&qid=1469249357&sr=1-1&keywords=learning+python

Effective Java: https://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683/ref=sr_1_5?s=books&ie=UTF8&qid=1469249369&sr=1-5&keywords=java

Haskell Programming From First Principles: http://haskellbook.com/

I included multiple languages as well as language-agnostic ones. Functional programming is the near-to-medium term future of software engineering, and most languages converging towards that as they add functional features.

I don't think bootcamp is required. Learning how to learn is the most important thing. If you get into these books, lose track of time, and feel "aha! that's how these things that I previously thought were unrelated are actually the same thing!", and are able to keep it up for weeks, then that is a good sign that you can get to where you want to be.

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.

You say you haven't done an algorithms or data structures class yet at university, which tells me you're probably not even at the midpoint of your student career. There are plenty of internships and opportunities out there. If I'm right about your current progress at university you have time on your side too, so I wouldn't sweat it too much.

If you think you're having trouble with the interview process itself you might want to check out Cracking the Coding Interview. It goes into detail about the entire hiring process, what you should DEFINITELY know, what you should probably know, how you should go about coding on the whiteboard, and goes so far as to even suggest how you should dress for the interview. The bulk of the book are the useful sample questions and answers. Definitely worth a read.

Yes, go to your local library and find the Cormen book (by the way, don't buy textbooks, borrow them!).

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

This is the bible of computing. Don't worry if stuff's hard to understand at first, even I go back to the book every now and then (15 years later). Try to grasp the concepts presented, and most importantly, try to implement them yourself.... and soon (~within a few months) there'll be a breaking point where suddenly everything makes sense.

Ninja edit: yes, I know there are plenty of libraries that implement everything that is in this book. That's not the point, however. Don't look at these libraries for inspiration. Try to create your own code purely from the reference of the book. Only once you're done compare with other people's code.

This solution requires some knowledge of how C works. A pointer is a number referring to a point in memory (and memory is one continuous blob of data). A C string is just a pointer to a character- you start at the location given and keep reading until you hit a NUL (character 0). C doesn't have a boolean type, so you use 0 is false and anything else is true. Once you understand those things, it's a fairly straightforward answer- you start at the beginning of the string, increment the pointer (you can literally imagine a finger pointed at a specific spot in a container if it helps) until you reach the end of the string (marked by character 0), then swap the character from the front with the character from the back, moving each pointer towards the middle as you go.

Having enough knowledge of C to implement this solution is different than a general knowledge of algorithms. On the C side of things, you could read something like Learn C the Hard Way, or buy a copy of K&R if you just want something to refer to as you practice. On the algorithms side of things. For the algorithms side of things this is a pretty popular textbook on the subject.

This is a great book for computer fundamentals that you should just read if you have any interest in computer science. But realistically you will not use much from this book in the real world. It is something to read to understand how things work.

You will get a lot more useful things out of a book like Intro to algorithms than SICP. The biggest thing i find self taught devs lack is an understanding of data structures. They know how to code and write solutions but dont know which data structure is efficient or why. They may learn by trial an error that one data structure is better for certain task but dont know why. If you are able to understand how the standard collections library for most major languages work you will be ahead of most devs

Design Patterns (sometimes called the "gang of four" book) is the best book I know of about design patterns- and I haven't heard of it being used in college courses (I could be wrong). This will give you a sense of the patterns that are out there, but knowing which pattern to use when is still mostly experience and even team-based preference/convention.

CS programs give you a broad overview of computer science theory, which is helpful but is not in any way sufficient to prepare you for programming practices. What you're going through is totally normal.

Debugging someone else's code is a skill that is also not taught in schools. I actually did a talk on debugging skills a few years ago; the slides don't make much sense but we made a PDF of our main points. I'll see if I can find video when I'm not on my phone.

I'm happy to talk more about this stuff with you or anyone else reading this; pm me or email carol dot nichols gmail.

Seeing as you are working on an Android app, you presumably know Java. C# is really similar. Objective C is for iOS development. I'd recommend C++ or just plain C. This is a good book. Python is also awesome though and pretty straightforward... So C or Python

I recently completed a job search in a major career shift. I have degrees in a different engineering branch, like yourself, and have been working in that industry for the past few years. Along the way I picked up programming as necessary. For various personal reasons that I'll skip over, I recently decided to make the jump to tech/CS, and have accepted a job at one of the "big 4" -- haven't started yet.

In terms of prep, here's what I did. YMMV.

1. I was already pretty proficient in Python. If you're not proficient in one of the widely accepted interview languages, learn at least one, and be very comfortable in int.
   
   
2. I had basically zero CS theory under my belt, so this is where I had to do the biggest prep. I picked up these two books, which are widely recommended (1: https://amzn.com/1118261364, 2: https://amzn.com/0984782850). Then I worked through them cover to cover -- I read every chapter first, and then I just solved problem after problem.
   
   Sites like hackerrank.com have some good problems to practice, too.

GET OFF YOUR SAD HORSE MY FRIEND. There's literally never been a better time to be a technologist who wants to learn more (and get paid more).

Yes, you're struggling. Yes, you want to change. But DON'T FEEL CONSTRAINED BY YOUR DEGREE. Draw on the experience you've had and look for new challenges. You certainly don't have to be a manager if you don't want to be.


if you think theory is holding you back, there are AMAZING online classes - online algorithms classes from Stanford/MIT. (The Stanford one is more of a refresher on basics). If you're finding that algorithms are holding you up in interviews, then read "Cracking the Coding Interview,"' cover to cover.

EVERYONE is looking for great technologists right now. Our company (untapt) is US-based, but feel free to message me with questions.

Starting your own projects or getting involved with open source projects shows initiative to recruiters when you apply again in the Fall. At the same time you could get ready for future interviews by studying technical questions and making sure you could answer basic behavorial questions well.

Its okay to not have internships the first 1 or 2 years. Being a freshman definitely makes it harder because you are not about to go fulltime anytime soon. I myself did not have any offers for the first two summers. But I did what I just described to you and landed a Big 4 company without any internship experience.

The fact that you already tried applying will help you in the future because you will learn from any mistakes you may have made.

These are the books I used, like many others:

http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X/ref=sr_1_1?ie=UTF8&qid=1395274746&sr=8-1&keywords=cracking+the+coding+interview

http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Landing/dp/1118261364/ref=sr_1_1?ie=UTF8&qid=1395274783&sr=8-1&keywords=programming+interviews+exposed

The first contains shorter explanations of topics and mainly questions and solutions. The second has longer explanations of what you need to know for each topic. Very great resources that helped me become comfortable with interviews.

Have you had your resume reviewed by anyone? I thought my resume was solid 2 years ago but now that I look back at it, there were tons of mistakes.

Hopefully this helps.

I would recommend picking up Working Effectively with Legacy Code. It sounds like you could really use it. It teaches how to get unit tests in, how to start finding places to split up the monolithic jumble into smaller, more testable components, how to add features without breaking stuff, and that is just cracking the surface. it is a highly recommended book in the community and I suggest you pick it up.

If you were in PHP I would recommend a book called Modernizing Legacy Applications in PHP, which was my saving grace when I was in your position. If you can find a book like that for Rails then you are set.

I also want to point out that this is a fantastic opportunity for you. They don’t usually teach these skills in college and they are very important. My first job out of college I was in a very similar position. I had a 250,000 line PHP site that was business critical. I had unrestricted access to its very helpful author, however, he had no idea as to modern software development practices and architecture. No source control, no tests, no rollback procedures no documentation or comments, and the site was the spaghetti monster, but holy cow it worked. Oh don’t even get me started about the crazy database naming conventions, the 5000 line “this takes all night to run because the database table doesn’t have a single index” stored procedure, or the crazy hack jobs of ETL from seven or eight other databases.

I ended up reading a lot of code, writing tests, doing a ton of refactoring, and added some features too. It was very, very painful but I learned a lot. Learning to work with complicated code you don’t understand is a very very important skill you will use for the rest of your career. And you can do it!

One other thing. Please do not openly or privately criticize or blame the previous authors or even the code. It is easy to play the blame game and use that to justify things you were doing. Others might be doing it too. Regardless, it will be seen as immature and unprofessional. There are many ways to indicate places for improvement without tearing down the people and code. Please learn from my mistakes.

I wish you the best and offer any other advice, mentorship, or moral support that you require. Just pm me.

I would mainly recommend that you read Effective Java. It contains a number of tips and best practices for writing good Java code. Read it through, and when you get a Java job, be sure to incorporate the practices from the book in your coding.

> Thing is I have no background in CS, apart from having done competitive mathematics back at high-school (IMO) and that I really really enjoyed learning C.

Applying as a software engineer, you will be administered algorithms interviews. If you cannot pass these interviews, it's very unlikely you will make it to the next phase.

> How real it is to pick up the necessary in my free time and actually land the job?

Difficult, though not insurmountable.

> I'd call myself mathematically mature due to my current background but algorithms and discrete math are foreigners to me

You must rectify this if you want to work at Google as a software engineer. Your mathematics background is a great start! Pick up a copy of CLRS and get to work. The subject matter should be at least familiar to a mathematician.

Why stay at a school where you're not studying what you want, and which doesn't even offer what you want nor one of the most popular in-demand majors??

Anyway, there are any number of online courses/tutorials about Data Structures, and how to build/use them in various languages. You can use C++ for them, or try to learn something else too. For speed & simplicity in interviews, a lot of people seem to prefer Python for discussing DS&A, but by their nature the concepts are fairly language-agnostic.

Try visualalgo for one ... there are plenty of others.

Since a lot of algorithms require/suggest the use of specific data structures to make them work, it's probably better to learn what those are first, and then try to tackle the algorithms that rely on them.

Grokking Algorithms - illustrated & pretty basic intro to concepts

Common Sense Guide to Data Structures and Algorithms - slightly less so, but still pretty basic intro to concepts

CTCI - problems covering arrays, linked lists, stacks & queues, trees, graphs ... Actually kind of useless if you don't already know what those are though.

Introduction to Algorithms (CLRS) - 1 of 2 standard U.S. college-level algorithms textbooks

Algorithms, 4th Ed. - the other standard U.S. college-level textbook, w/free online "book site", code, and a free Coursera course to go along with it.