Agree strongly with most of the points. In terms of interviews, I prefer to give a problem decomposition question: e.g. class design of a real-simple real-worl

Agree strongly with most of the points. In terms of interviews, I prefer to give a problem decomposition question: e.g. class design of a real-simple real-world system based on rough requirements Primary goal for me in interviewing is to 1. Filter out candidates which lack the skill or willingness to get things done 2. Identify potential red flags which would be a risk. Most red flags are communication or attitude. Knowledge gaps can be filled. Things I'm testing for: * able to follow rough instructions top sequentially break down problem into multiple layers of abstraction * naming - unambiguous and conveying purpose * attitude - easy to collaborate with? do they appreciate/enjoy new challenges? I'm certainly not perfect but I have a pretty high degree of confidence on sorting most people's level and fit based on a 1 hr interview > junior (IC1): difficulty separating concerns / naming, struggles with use cases. Needs to be very coachable. > junior-to-mid: has some experience, takes feedback well. needs a lot of coaching. Gaps in knowledge. Would need mentorship > mid (IC2): competent at programming/data structures. Able to implement a specification but need coaching turning requirements into specification. Thoughts or code may not be very organized. mid-senior: organized. Makes fast progress. Needs minimal coaching to finish problem before time. Cares about naming and names things well. > senior (IC3): able to solve problem quickly (30 mins to finish problems which would take 1 hr for mid-level). Intuitively/quickly understands problem without need for much coaching. > lead/principal/architect (IC4): IC3 with greater maturity. Make take longer than IC3 because of greater detail and thought. Spends extra time clarifying requirements, testability and testing. Very thorough yet able to complete within time allotted.