The interview process is still something that hasn't been solved. A lot of companies make hiring decisions based almost entirely on how well someone does non-co

The interview process is still something that hasn't been solved. A lot of companies make hiring decisions based almost entirely on how well someone does non-coding work under extreme social pressure, which is about the worst possible way to measure the prospects of a developer! Personally I really like the interview process a previous empoyer used: shortly before the interview starts we had them look over a roughly CS 102-level programming project, then we ask them to design the architecture on a whiteboard while the interviewers ask questions/give guidance. What we're really looking for here is: a.) how do they handle the social aspect of working with a superior who will often (gently) criticize your work and/or ask you to thoroughly explain why you're doing what. b.) that they have enough chops to architect a simple program. If they can pass those test I'm confident they'll be an effective team member, because at the end of the day all you really want is someone who is competent enough to be useful, and fits into your culture/team. Everything else will shake itself out. You don't need some "superstar/rockstar/ninja" (unless you're solving a particularly hard domain-specific problem) so stop looking for them and excluding everyone else. Instead start building an effective team.