Reddit mentions of The Algorithm Design Manual

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

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

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

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

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

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

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

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

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

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

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

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

Best of luck.

TL;DR: Just read it. Sorry.

EDIT

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

EDIT 2

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

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

Algorithms are language agnostic but certain books are not. I recommend Introduction to Algorithms which is language agnostic and accompanied by lectures here. But there is also Algorithms by Robert Sedgewick which is in Java and accompanies these lectures and The Algorithm Design Manual which is language agnostic.

http://www.programming-challenges.com/

The accompanying book has quite good problems (all your CS intro ones, Towers of Hanoi etc)

Another book by the same author (Steve Skiena) called The Algorithm Design Manual is great.

http://www.amazon.com/gp/aw/d/0387948600 -- great book. I used it when studying for my Google interview. The first quarter or so is theory and the rest is just a BUNCH of algorithms, what problems they are good for, what their trade offs are, etc. I'd recommend it.

Skiena's The Algorithm Design Manual. Really helped clear out all of the haze and confusion the impenetrable CLRS book provided even without support of the subpar Algorithms profs I had both in undergrad and grad school.

another alternative is the algorithm design manual (personally, i like clrs as a reference and this for understanding; sedgewick feels like a textbook, which i guess is an odd criticism, but there you go).

The standard reference is the Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein. But it's huge and very detailed.

A much more gentle and very practical introduction to algorithms and complexity is the Algorithm Design Manual by Steven Skiena.

There are some good books to help you in your quest, they discusses all programming techniques needed in competitions: greedy algorithms, dynamic programming, data structures... A lot of overlap
between them :

Competitive Programming 2 : Great book, a lot of
information packed

Art of Programming Contest : FREE book available from ACM site

Programming Challenges : From a famous
competition Professor (Skiena)

The Hitchker Guide to Programming Contests : Another FREE book,
Great Ideas

The Algorithm Design Manual : Another book from
skiena, talks about the practical applications of famous techniques and
algorithms used in competitions

Introduction to algorithms : THE book about
algorithms... In-depth explanations

Google code Jam contest analysis : Google Code Jam is a great
competition, with a lot of hard problems. And all of them have a
solution and analysis !

Some books I enjoyed:

The Algorithm Design Manual by Steve S. Skiena, $61.15

Real Time Rendering, 3rd. Edition by Tomas Akenine-Moller, Eric Haines, Natty Hoffman, $71.20

Structure and Interpretation of Computer Programs, by Hal Abelson's, Jerry Sussman and Julie Sussman, Free

Clean Code by Robert C. Martin, $37.85

I'd read through this book:

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

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

This one looks like it would fulfill your requirements. I'd totally swoon if I caught my wife reading it (beach or no).

So lots of folks here have mentioned algorithms. If you're someone who likes to read hard copy books then check this one out - The Algorithm Design manual. An all round good book, even for beginners. Of course, it can be had in ebook format too.

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

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

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

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

Steve Yegge's 5 Essential Areas

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

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

I've had correspondence with the author before. He's a really good guy. If this is more than just a simple curiosity, then man up and buy the book.

http://www.amazon.com/gp/offer-listing/0387948600/ref=dp_olp_used?ie=UTF8&condition=used

While it's not purely a data structures book (and may be a bit too close to a textbook for you), The Algorithm Design Manual is hands down the best Data Structures/Algorithm book I've seen.

It does a great job explaining the concepts and has some very helpful examples. If you're interviewing, it also has several exercises and interview questions for each topic.