Interviewing...

http://www.glassdoor.com/index.htm

http://www.topcoder.com/

http://java.dzone.com/articles/guide-tech-interviews

http://c2.com/cgi/wiki?FizzBuzzTest
http://infiniteundo.com/post/78755712062/interview-questions-for-quality-assurance-engineers
http://katemats.com/interview-questions/
https://oj.leetcode.com/problemset/algorithms/
http://www.fastcompany.com/3026794/leadership-now/the-secrets-to-hiring-people-who-will-stick-around
http://www.nytimes.com/2014/02/23/opinion/sunday/friedman-how-to-get-a-job-at-google.html?ref=thomaslfriedman&_r=0
https://sourcegraph.com/blog/programming-interview
http://thoughtworks.github.io/p2/issue09/hire-polyglot/
http://www.thepminterview.com/ (if you want some new interview questions) 
https://twitter.com/HarvardBiz/status/586165500704641024/photo/1
http://softwareforallseasons.blogspot.com/2011/09/interviewing-ebay-part-iii-software.html

http://1000projects.org/projects/java-based-projects/

http://www.mariogerard.com/a-new-kind-of-program-manager/
http://www.mariogerard.com/technical-program-manager-career-path/ 
http://www.mariogerard.com/technical-program-managers-vs-product-managers-vs-product-managers-technical-vs-engineering-managers/ 
https://medium.com/@AyunasCode/tpm-technical-program-manager-f4e8e2004741
https://blog.aha.io/the-product-manager-vs-the-technical-product-manager/
http://www.telegiz.com/articles/10532/20161113/amazon-works-backwards-earn-billions.htm
http://www.businessinsider.com/amazon-unusual-process-to-decide-on-new-products-2016-9
https://www.quora.com/Amazon-company-What-is-Amazons-approach-to-product-development-and-product-management

http://www.fastcompany.com/3026794/leadership-now/the-secrets-to-hiring-people-who-will-stick-around

http://www.nytimes.com/2014/02/23/opinion/sunday/friedman-how-to-get-a-job-at-google.html?ref=thomaslfriedman&_r=0

https://sourcegraph.com/blog/programming-interview

http://timesofindia.indiatimes.com/tech/slideshow/10-tough-questions-google-apple-others-ask-in-interviews/itslideshowviewall/39616105.cms

Design Patterns

Let us start looking at the Design Patterns:

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

http://www.codeproject.com/KB/architecture/#Design+Patterns

http://sourcemaking.com/design_patterns
http://sourcemaking.com/antipatterns

http://www.oodesign.com
http://javapapers.com

http://apievangelist.com
http://apigee.com
http://www.objectaid.net/
http://www.learnerstv.com/
http://howtodoinjava.com/
[Liskov's Substitution Principle]

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
http://en.wikipedia.org/wiki/Don't_repeat_yourself

Adapter Pattern: Class Adapter vs Object Adapter:

• Class Adapter uses inheritance and can only wrap a class. It cannot wrap an interface since by definition it must derive from some base class.
• Object Adapter uses composition and can wrap classes or interfaces, or both. It can do this since it contains, as a private, encapsulated member, the class or interface object instance it wraps.
  The difference is subtle. Usually the later approach (favoring composition over inheritance) is the preferable as explained in the link which I'll quote here:

  Object-Oriented Programing (OOP) has too well known candidates for the reuse of functionality: Inheritance (whitebox reuse) and Composition (blackbox reuse). If you try to reuse code by inheriing from a class you will make the subclass dependent on the parent class. This makes a system in many cases unnecessarily complex, less testable and makes the exchange of functionality at run time unnecessarily hard. As a [Clean Code Developer] you should follow the Liskov Substitution Principle (LSP) when you need to decide if inheritance is appropriate.

  Composition means that one class uses another. You will further promote decoupling by defining the interfaces clearly. That will also give you the advantage that implementations can be easily replaced. So before you start applying the Liskov Substitution pronciple, think about the Favour Composition over Inheritance concept and ask yourselve why you shouldn't prefer composition right away.

  "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)