Public service announcement to job applicants: you must know what O(N) notation is for the code you write for both runtime operations and memory usage. I don't care if you have a computer science degree or not, but you cannot write good implementations of algorithms if you don't have a clue about it. Your "8 years of experience" on your resume is garbage if you can't tell me why an O(N) array search is slower than an O(log N) search in almost every case. Also, you need to know how much memory you allocated, even if you don't have to explicitly free it because the garbage collector cleaned up your mess.
No, the programming language doesn't matter. No, your favorite library does not matter. No, there is no magic speedup to be found in Linq, inlined functions, lambda functions, or whatever other garbage you googled. Kids of today! Geez, get offa my lawn.
And while I'm at it, you must know the fundamental rule of multi-threaded programming in Windows: there is only one UI thread, it owns all UI objects, and you cannot access any UI objects from any other thread. Not ever! Your program will crash and burn with some cryptic errors the next time your callback in the thread pool tries to change the text displayed on screen. If you don't know how to transition from background threads to the UI thread, that is your fault. No, you can't get away with it because there was no compiler warning message. No, you can't catch every multi-threading exception and silently discard them. No, the operating system will not help you to fix this error. No, your favorite programming language does not absolve you of this responsibility, even if it does have a billion ways to manage threads (C#, I'm looking at you).
Does nobody learn these concepts anymore in college? There are so many excellent textbooks available, and it is your responsibility as a professional programmer to read at least some of them. Reading "Sams Teach Yourself C# in 24 Hours" and writing garbage code for a few years does not make you a professional.
Please read some or all of these before applying to a job and sending me an 8 page resume with glowing but vacuous recommendations:
Foundations of Computer Science, which is the Stanford textbook used in programming and CS classes. Specifically, Ch 3. The Running Time of Programs.
Introduction to Algorithms, the MIT standard textbook. Please dear lord tell me you know what a hash function is and what it does. (Or map, dictionary, associative array, or whatever other name your favorite language is now using; the name doesn't matter as long as you know when to use it.)
Cracking the Coding Interview: 150 Programming Questions. If you can't write code without an IDE (i.e., by hand on a whiteboard or on paper), you're not going to pass an interview.
The Art of Computer Programming by Don Knuth. Any volume. Really, anything written by Knuth. If you don't know what a regex or Turing Machine is, you've got a lot of catching up to do. No, seeing "The Imitation Game" does not count.
Operating Systems: Design and Implementation by Tanenbaum et al. You must know what a mutex is and why you'd need to use it. No, you cannot google it during the interview. No, you cannot avoid learning about how the OS schedules and manages threads inside your process, even if you never explicitly control it.
Kids of today! Geez. Now please excuse me, I have to mow my lawn.