The Technical Interview Is Dead
techcrunch.com
techcrunch.com
The "audition project" is a trend story with, from what I can see, very little empirical evidence to back it up. When the most notable example of a company routinely employing audition is Treehouse --- all due respect to Treehouse, but still --- that's a red flag.
The bigger red flag is that the paid audition project method has obvious flaws. The top 20% of software developers are almost uniformly employed. Prospective new employers for these people court them actively; in fact, the problem of companies luring top developers out of other companies is so challenging that large SFBA tech companies have entered into illegal compacts to stifle the practice. Companies are so hard-up for talent that they'll "buy" startups just to get access to their teams.
In this environment, why would a top developer, who has their choice among tens of different high-paying interesting jobs, moonlight for a prospective new employer just so they can make sure the relationship's going to work?
Most technical interviews are terribly flawed. They aren't standardized and they aren't rigorous so you can't compare candidates on any apples-apples basis and you can't correlate them to job performance to make them more predictive. Most of the developers tasked with conducting them suck at interviewing; many use interviews as a sort of hazing ritual, and most use them as opportunity to project their own subjective views about how software should be built onto candidates. Many technical interviews are trivia games punctuated by awkward attempts at working through code on a whiteboard or a piece of paper in a high-pressure environment.
The solution to this problem is to improve technical interviews. It's not to pretend that the whole market for devs has suddenly embraced temp- to- perm hiring. It hasn't. It's getting harder to find good developers, not easier, and the notion that companies have the luxury of inflicting "audition projects" on candidates is counter to reality.
I don't think I saw this mentioned but another technique that companies use it to subject you to formal tests. Usually produced by some 3rd party. I have huge experience with Excel and spreadsheets since Lotus 123 and have worked on and produced some enormously complicated, but successful spreadsheet/VBA solutions. I am almost invariably seen as the resident Excel expert in all the organizations I have been employed, yet have failed a test to prove my Excel "competence" because somehow the Dictionary Object was considered all important by this 3rd party test and yet in 15 years of spreadsheet is never something I touched.
I don't doubt that the Dictionary object is very useful in some use-cases but to fail an Excel competence test because some test producer decided to get cute is hardly an indication of real world knowledge and experience with a product.
That is just Excel, I shudder to think what a test in C++ would do to even a highly experienced C++ programmer if it decided to explore all the edge cases and obscure gotcha's that exist in C++.
This is not to say that some tests cannot be useful - just be very careful of what you are actually testing for and how you are doing it.
IMHO, the ideal technical interview would be one where the interviewer is able to dig in deep into the candidate's experience and able to ask intelligent questions that reveal the candidate's technical depth. But this requires very strong interviewing skills as well as an appropriate technical background on part of the interviewer -- this will not scale.
The "audition project" is a non-starter for the reasons you mentioned and as you correctly point out, we have no evidence that it works in the large.
So back we are to the flawed coding interview. Like some wag said about democracy: it's a shitty system, but there's nothing better.
A standardized interview process is one where every candidate receives (roughly) the same set of questions, so that the company can look over the last 18 months of interviews, compare every candidate regardless of who gave the interview, and make observations across candidates.
A rigorous interview (for lack of a better term) is one where questions have either correct answers or quantifiable answers. "Best algorithmic approach" to a problem is usually not a rigorous question (unless the problem domain is very well defined and very well studied). But "number of valid algorithmic approaches offered" is, as would be "validated time complexity of best offered approach".
The idea that a tech interview should be digging deep into a candidate's background to assess their experience and derive intelligent questions that reveal depth is, I believe, the pervasive myth underlying all bad technical hiring. The people who conduct technical interviews are developers, not trained psychologists. Developers have a pronounced tendency to overestimate their own confidence in things like interviews. For lack of a more eloquent way to put this: developers suck at interviewing.
There's no better way I know of to interview devs than to have devs do interviews, because it takes a trained developer brain to accurately classify answers to useful tech questions (ie, "is this unexpected response incorrect, or is it a correct response that uses a more clever approach than the one we expected, or is it a correct response phrased in different terminology than we're used to", &c). You have to have devs doing interviews.
So the next best thing is to stop pretending that devs are capable of doing something that they're mostly not capable of doing. To me, that says "take a couple weeks to come up with a standardized interview that every developer will give".† Watch the responses to those interviews. Look at who those interviews select; if those people seem to be working out, stick with it, else adjust.
† One indicator I'm playing with: if anyone on your team looks forward to doing interviews, you're doing something wrong; for the interviewer, the process should be mostly very boring.
I have my doubts that I'm a top developer (I have a long list of things I'd like to understand/do better in order to consider myself in that category), but I've done and would consider doing a paid audition project.
The job I have right now pays market rates, offers good benefits, and involves work for famous clients. It's not a bad gig, and there are enough people who've been there for over five years that it's clearly a good environment for some. On the other hand, I don't find the work itself particularly satisfying. Most of our projects themselves are a bit staid (as projects from established brand clients who feel they have more to lose than gain from risky moves can be), and a lot of what I've ended up doing is production front-end work rather than much problem solving.
This is different from the picture I got during the interviews. That could be as much about my own ability to read what day-to-day life was likely to be like post-hire as anything else, but whether it's uniquely difficult for me or for everybody, I'm left with the same problem -- how do I get a glimpse of what working there is really going to be like?
Seems to me a paid audition is one good answer.
I'd rather do 2-3 months on contract than a 2-3 day project, but I'd rather do the 2-3 days of real work than nothing.
And I think the 2-3 days of real work idea beats another practice that's becoming prevalent: the ~1 day (unpaid!) work sample/code challenge. I don't mind such challenges in and of themselves; a small exercise can be educational and an opportunity to use all the things you've been thinking would be good ideas to fold into a new project. What I dislike is that real feedback seems to be scarce. Even the people who've hired me didn't give me much feedback beyond "it met the requirements and we learned a thing or two from your work." By the time I've invested a workday of focused time in a company, I'd appreciate a "we were hoping to see" or "here's what we liked", and I'm finding I don't get much of that from challenges/exercises. Whatever the flaws of the conventional interview process or the paid real project may be, at least they're both generally more symmetric in terms of investments required and opportunities for evaluation.
You sound like someone who'd rather be consulting than working full-time jobs. Great! You'll probably also make more money and get more professional experience faster than people who take the less-risky full-time job path.
What I object to is the notion of temporarily converting full-time workers into consultants so that companies can mitigate their concerns about how inept their own technical interviews are. Consultants and full-timers are two very different things, and they aren't easily convertible.
The problem is that it's not always your choice to make. Noncompete clauses exist, and, if you're outside the state of California, are generally enforceable. I don't know about you, but I'd really rather have a system where taking an interview wasn't a fire-able offence.
You need to be concerned about the employers who "learn a thing or two from your work" and don't hire you.
Some programming "team leaders" I've met wouldn't hesitate to bring in applicants to work unpaid for a day on coding challenges containing technical blockers from their own projects.
And of course much of what happens in the open source programming world is the same on a larger scale without even needing to supply office space for a day.
The reason you get to test drive cars is that the people who have cars to sell are desperate to sell them to you.
There's a lot less overhead to driving a car for ten minutes than there is to living in a new place for a day or two... to get the right impression of a car, you drive it in a residential area, you drive it on the highway, and there, you have at least an overview. To do the same for a house? Move in, settle in, meet the neighbors, live in it, then move out, because someone else wants a test drive, too.
And, of course, neither applies well at all to interviewing a person.
The metaphors just don't work here, and they're not helpful. Maybe there are things that work while car/house/pet/food shopping that can be applied to interviewing, but that correlation does not necessarily indicate any similarity between those situations, and comparison isn't useful unless the activities themselves actually are meaningfully comparable.
There are two possibilities:
1) You're looking for a co-founder of for perhaps the founding engineer, e.g., Sergey Brin and Larry Page hiring Craig Silverstein. You've impressed them to a great degree (they like your product demo, your background), and they are already willing to pay potential opportunity costs (a job at an established company, finishing their Ph.D. program, etc...) to join you. Then this really isn't a hiring problem per-se, this is a "finding a co-founder or founding engineer" problem; you are less likely be hiring someone "from the cold" for this in the first place (this is why so many companies are started by graduate students or former coworkers...)
2) You're willing to hire people who are unable to find other full-time work, in other words someone with no formal experience or experience in a completely wrong area (e.g., someone who worked on internal business web applications, but who wants to get into embedded programming).
Then you're really looking to hire an intern (in case of no formal experience) -- where the process is essentially that, a contract to hire, or simply take a calculated risk. In other words, you are able to see potential in this person (which they've demonstrated by perhaps building an app in their spare time) and are willing to set them up for success (as oppose to trying to find the best candidates out of a pool).
The group I'm in (all flash SAN storage) has gone from single digits to ~80 people in under a year, and basically the only predictive metric is referrals from people who have made other good referrals. We're writing a complete HPC OS, and it's sink or swim. The referrals are almost all swimming.
That's it. Almost all other hires have been completely random in quality.
So these amazing engineers that you're really struggling to hire are actually being hired because of a career long audition with their peers. It's wildly incestuous, and has some interesting effects. Some effects are bad: no one knows new tools/new development styles. Some effects are good: at the top, gender split is much closer to 50/50.
I'd love to figure out how to vet someone in under 3 months that is not part of this professional tribe, but even typing that out I'm almost suspicious they'd succeed and become part of it if they aren't in the tribe already. It seems like even my attitudes are a problem in opening up these kinds of candidate searches.
The phenomenon you're describing is what makes recruiting such an interesting problem. The largest or wealthiest employers can often afford to constrain their candidates to people who have proven themselves in other settings. Which of course leaves a "Moneyball"-type opening to the employers who can figure out how to hire for aptitude instead of experience. Which makes hiring at those savvier employees a high-stakes, high-value process, instead of a tedious formality inflicted across the whole team.
Without the public displays of performance that baseball has, there's another level of indirection that you must filter through to try and illustrate a candidates performance.
This makes it something like the "Moneyball of Moneyball of programming".
I want to call for tokenadult's canned "within the US, look for a work sample. Outside the US, use an IQ test" post. We figured out _how_ to hire for aptitude a long time ago (subject, of course, to the fact that prediction is never perfect); Malcom McLean apparently filled his new shipping company top-down by who, among the people who worked for his old trucking company, scored highest on an IQ test. But then we decided that that would be illegal in the future?
The interesting effects here for people building teams then are in the dispossessed. The folks who didn't graduate college (so shunned by many of the big names) or the folks who took an off beaten path. My concern is that if Google fixes their blind spot with respect to this talent pool it will get that much harder for startups. So far I've not seen any indication that they have but I worry about it.
[Edit: I can't even joke without getting it wrong.]
What neither the Googlers nor Ptacek are saying is that the solution to the screening problem is to ask candidates to accept a deal that most full-time employees, and most clueful contractors too, would reject out of hand.
If your screening strategy would reject any sizable percentage of people who are currently successfully working for someone else, your screening strategy is bogus. Unless your express goal is to hire promising juniors who don't know their own value. Which does feel like the goal of many hiring managers: As market rates get bid up, they're desperately looking for people who are just clueful enough to succeed, yet just clueless enough not to ask for money in return.
----
[1] I do not presume that any single person speaks for all of Google. In particular, I would be surprised if that giant company of folks who were all hired via brainteaser interviews has actually entirely stopped using brainteaser interviews. Fixing interviewing culture is hard.
When I attend technical interviews I hear questions like this: "How would you implement an arbitrary-precision decimal number class, like Java's BigDecimal? Can you write out the add function on that whiteboard?"
When Google's Laszlo Bock [2] says "On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything." it seems fairly clear to me the idea he's dismissing is brainteasers, not whiteboard coding.
That's consistent with other reports [3,4] from a few years ago saying brain teasers were not used.
The author of the TechCrunch article seems to interpret Bock as saying whiteboard coding is an ineffective practice. I'm not convinced the Bock interview said that.
[1] http://online.wsj.com/article/SB1000142405297020455230457711... [2] https://www.nytimes.com/2013/06/20/business/in-head-hunting-... [3] http://www.technologywoman.com/2010/05/17/debunking-the-goog... [4] http://www.guardian.co.uk/technology/us-news-blog/2012/oct/0...
It's the same stupid behaviour with "scrum post-its" when there are tools available.
Yes, you can't interview a surgeon by giving him a scalpel and a patient, but this is not the case with software development interviews
http://www.google.com/about/jobs/lifeatgoogle/hangout-on-air...
This could be part of what's going on. Small companies are getting the leavings of the big ultra-competitive companies. Small companies notice no matter who they hire, they are never up to par. Small companies blame this on the technical interview.
In such a situation the usual "false negative is okay, it cost more to hire a wrong person than to skip a right one" stops working. Skipping a right one will cost a lot in the long run.
And how do you filter the candidates who you give audition projects to in the first place? That's very difficult without a technical interview.
I don't know if this problem is specific to our industry or not. Do people apply to be English teachers when it takes them an hour and a stack of reference material to form one English sentence? Do people apply to be carpenters who don't know how to hold a saw?
Both give you the guarantee that it's not pointing at the NULL address. In the case of const pointers, that's because you can't reassign it, and you'd never deliberately assign a const pointer to NULL. In the case of references, it's because there's actually no such thing as a null reference in C++.
That's not the case in Java and C#, which allow "null" to be a right-hand value for all types.
Uhh no. Neither the const pointer nor the reference can be reassigned. And you have it the wrong way around. References cannot be null, pointers can.
The other difference is that if you try and dynamic_cast a reference and it failed, it throws an exception where as a pointer just returns nullptr.
>That's not the case in Java and C#, which allow "null" to be a right-hand value for all types.
That's also wrong, primitives are not nullable.
I was wrong on reinitializing references as well. Thanks for pointing that out. As far as const pointers, I meant that they were unlikely to be null, since they would have to be initialized to null. Of course, then I realized that you could easily assign them to another null pointer that you didn't realize was null.
Not a good day for me, but I don't think it warrants that kind of snarkiness.
To my credit, please reread the part where I said "there is actually no such thing as a null reference."
I truly believe he knows his stuff, but even he made a mistake. He, however, didn't have to come up with his answer while people are staring at him.
myref = otherref + 10
is equivalent to
* myptr = * otherptr + 10
Now, most languages also have a notion of values that are neither pointers nor references, and primitives generally are expressed as values, but hopefully you get the point.
If you have a variable and you want to pass-by-reference, making any changes to the original variable effect the originally allocated value.
You use a pointer for instance if you want to dereference a physical memory address as part of an array of allocated memory addresses.
// reference example
int value = 0;
int value1 = &value;
value1 = 2;
// value should equal 2
// pointer example
int value[5] = {1,2,3,4,5};
*value += 1;value++;
*value += 1;value++;
*value += 1;value++;
*value += 1;value++;
*value += 1;
// should now be {2,3,4,5,6} // reference example
int value = 0;
int& value1 = value;
value1 = 2;
// value should equal 2When I was interviewing people, phone screen with some basic concept questions would filter out 80% of applicants with nicely looking resumes; an hour-long whiteboard screen with FizzBuzz kind of problems would take care of the rest. Very quick and efficient process.
The problem with the "audition project" is precisely that it has the same inconvenient economics as dating, finding an apartment, or job hunting/hiring in general, only more so. There is greatly increased "opportunity cost." This alone can explain the lack of data. It might be like a lot of "better" tests -- it might be a better way to gauge suitability on an instance-ti-instance basis, but the economics preclude it from being widely used.
If it doesn't work out there's always the next 3 month interview...
It is not about testing, it is about having a gift (or not) and a character - willingness to become a master just for the sake of ones love/passion/enjoyment of the craft, not any stupid job or position.
Fact is, you have to do everything up to that 'mini project' then just go with your gut and hire/no hire. If they underperform in the role you need to either change the role, try and train them up or let them go.
This trial period is just a way of pushing the risk of a bad hiring decision back onto the candidate and allowing the manager to avoid the discomfort of actually firing someone (although telling the candidate that the project didn't work out is functionally the same thing).
That's why I think you already do see it with one large category of tech job-seekers where that isn't a problem: students. Tech companies hire student interns for a summer effectively as a trial period, and both sides often like that arrangement.
Once I was given a much smaller, unpaid task as part of the interview process. It wasn't a puzzle or trick, but something actually useful. All told it took me a couple of hours one evening. You might be thinking, "How much can you learn about someone from such a small task?" It depends on the task, of course. Mine was typical network code, with a couple of non-obvious but absolutely real-world edge cases. I spent time making sure my comments were great, and then wrote a man page. I think they learned some important things about me, and on my end it was an easily paid investment.
One thing we noticed was that there is small handful of mistakes that many candidates tend to make. The ones that note the existence of a mistake or work around them skillfully are typically the best.
To do something small, you don't need to quit a job, just dedicate few evenings and weekends and earn some extra cash.
This method can be beneficial for candidates, that can get to know potential employers much better, and avoid ones that look interesting only on job ads.
It is tough firing people. But that doesn't mean it can be avoided.
And this is a good time to remind everyone: Firing an employee doesn't mean the employee failed. It means that everyone (including the company and everyone else involved) also failed. Such a failure in an organization should be a time of reflection for everyone; to think about and talk about what worked, what didn't, and what everyone can do better next time.
The good news is that more and more companies (and especially the small ones that I like to work for) do the coding sample/test code thing. And every time I get one of those I absolutely crush it. I've never once been denied an offer when asked to write an offline code sample - and the offers have been from a number of the top startups in the game.
What does any of this mean? Well, in the last two companies I worked with I ended up rising to be the top technical person on my team. I've never had any kind of negative review of any sort. And in the last round this happened after I was denied an offer from two different companies because I couldn't code.
So I guess I'm that guy. I've been rejected from Google 3 different times because they keep begging me to interview based off my experience/internal recommendations, and then I interview and their interview/hazing process weeds me out. It would be nice if they woke up and realized that process isn't an effective filter, but I'm not holding my breath. In the meantime there's plenty of companies who will happily hire me after they see me do work that's actually relevant to the job. And when I interview people for my team I steer clear of trying to stump them under intense pressure, and instead ask for a mini project. I guess it doesn't feed the ego quite like breaking someone with a super awesome whiteboard question, but screening candidates more effectively makes up for that.
There's obviously a massive difference between "can code proficiently" and "can code proficiently in an interview situation" and I would guess that a significant amount of even fizz-buzz fails are due to this, let alone complex algorithmic stuff.
When you're an interviewer doing many sessions it soon becomes very routine, to the point of tedium. Being an interviewee is on the other hand hugely stressful for a lot of people, and that just isn't conducive to good "on the spot" analytical thinking. And interviewers in their comfort zones completely forget this and don't factor it into performance (done so myself).
There is simply no way to reliably hire skilled people without at least attempting to assess their skills. For technical people this means technical interviews. And an interview process that includes a trial project... is still a technical interview.
This is distracting from the real issue. Most companies are really bad at scaling their interview policies/processes. Quiz/Brainteaser interviews are born from an effort to standardize evaluations across multiple interviewers and multiple candidates. So rather than focusing on developing an interview process that's focused on finding people that are a good fit, you're focusing on developing an interview process that's first easy for anyone on your side of the table to execute. Structure and process are good when they benefit the prior case, and stifling when they benefit the latter. In the end you wind up with a very expensive and completely repeatable noise generator that's of no benefit to anyone.
It also means that as the interviewing company that you don't legally own the IP rights for the code you just put into production, which opens you up to a lawsuit as well.
And that's just for when you're hiring someone from another random company, if you're hiring someone from a competitor you've got a whole different layer of complexity in terms of NDA, non-compete, etc. violations.
And then you get into employment law and accounting complications. Who's declaring tax on the payment ? - if the candidate isn't setup for contracting work they'll need to do a bunch of work to sort out the taxes, if the company takes care of taxes than that might be taken as evidence of employment.
It's one of those ideas that might seem nice superficially but which will get you into a world of pain in the long term.
It's the reason major open source projects require a waiver from your employer if you're contributing substantial code even if you're doing it in your spare time.
Legally: a lot of graduate student employment contracts bar any other paid employment with clauses like your graduate student tuition deferment being lifted if it is discovered that you have a side job.
Practically: So, you moonlight for a competitor for a week and if your boss finds out that you added a shipping feature into someone elses product, and you didn't get the job..?
Just because a contract says something doesn't mean its enforceable. Many grad students moonlight with consulting work in computer science and other technical disciplines.
However, I'm pretty sure that I CAN do the following (even under pressure): Work through a problem rationally, work constructively with others, pay attention to detail without losing sight of the big picture, write code. And I would much rather focus on side projects than studying variations on Towers of Hanoi.
So this whole interviewing trend makes me want to cry out of relief.
You should get over that. It is probably very important for your career (and life) that you not care about looking stupid in front of other people. It's going to happen (a LOT) in your professional career, dealing with it gracefully is one of the skills to have.
I feel the same way. One thing that helped me cope with it was taking some improv classes. I still get nervous, but I can feed off the nervous energy instead of letting it get in my way.
When somebody is saying he or she has 20 years of C++ experience and 150 projects shipped yet he or she does not know what is virtual function - this means he or she lied on the resume. If you had not conducted a technical interview - you'd learned about this much later, at much greater cost. Chances are that somebody who lies on the resume is also good at BSing about "past projects" and "greatest achievements".
FizzBuzz or a general screen test won't help because people have different skills. If you are hiring somebody who writes Perl it's stupid to ask about C++ and vice versa.
Writing a test project - probably the best way to hire recent graduates. Probably the worst way to hire somebody who already has a job and you are desperate to poach, not really good at picking people who have several offers to choose from either.
What does carry along with the person is still something about the way that person thinks, handles problems, basic aptitude, knowledge and understanding, etc. Fizzbuzz is a good measure of basic programming aptitude [2]. I have constantly used simple equivalents of Fizzbuzz for electrical engineering and have hired some great performers.
[1] I have conducted over 100 interviews. [2] C++ vs. Perl should not matter much since the question is about the basic algorithm.
This depends on the position. If the position requires an MS degree and 5 years of experience you'd need to spend couple of weeks testing for the whole corpus of knowledge, that these requirements demand. It's quite expensive and few candidates are willing to spend this much time. The only practical way is to go with the credentials the person already has.
If you are looking for somebody to write websites using frameworks then, indeed, you can test all required skills in a day of technical interviews.
The handling of problems would be nice to know but, unfortunately, is hard to test. Somebody who just flew into the interview and is confronted by a bunch of strangers is not in the best shape to handle problems. If he can even in these conditions - good, now you know that this person can work under stress. Successfully solving simple puzzles though does not show anything more than this - you are likely looking for somebody to solve much harder problems that require weeks and months of research. Neither does a negative result mean much - this is most likely a result of stress.
So the brain teasers and "how many sorting algos you can write on a white board in 30 mins" type of questions, in my opinion, are useless. Asking concrete questions in the domain of the candidates knowledge on the other hand, lets you quickly verify much wider set of skills.
I also can't imagine what HR would say if I told them I wanted to hire someone for a week just to see how they get on. "Well, then your HR system is broken and you should totally hack it to make it better." I'll get right on that, just as soon as I become Vice-President of HR. They'd tell me to do my job and hire people who can do what they're hired for.
Where this is going is the ripost that this kind of suggestion always comes from the small part of the industry where it might be practical; the are are a great many programming jobs in companies where it really, really isn't.
I did an online coding interview a few months back, and after working with some dude for 20 minutes on some program he asked me if it was ready to ship. And I was "uh, no, of course not" since we had done no testing of any sort apart from mentally running through the code. "Well, make it ready to ship!" I don't think he understood. The two of us certainly didn't agree on what software engineering means.
It opened up with a sort of multi-faceted FizzBuzz followed by long "behavioral" discussion like one of the references refers to [0].
The audition process doesn't make any sense to me. It's essentially a short duration temp-to-hire. Great people tend to be employed or at least not idle, unemployed people are looking for jobs, not 1 week gigs.
0: http://www.nytimes.com/2013/06/20/business/in-head-hunting-b...
My favorite interview that I took part in and got hired was when I was given 2 hours to pair program a project with the interviewer. So I really like the concepts in this post. Anything to get the developer to calm down and feel at home.
1. Think how to improve and practice for the next interview.
2. Bitch about how technical interviews are unfair, biased, miss the best people and ... OMG - DEAD!!!
I dropped the ball on one employer because the audition project took too long.
Overall although, I think people are far more comfortable with typing on a 15" macbook pro vs scribbling something on a whiteboard.
I then ask them a fairly broad open-ended set of questions to see how they describe the process of solving said problem.
This usually involves talking about tools, their process, their libraries of choice(something more generic here for other fields) and generally helps to assess their personable skills.
If I like them, I will ask them if they have any personal projects they want to share or something they are enthusiastic about in their domain of knowledge.
I think the biggest thing is that a lot of companies doing technical interviewing only reserve a small period of time to determine their new candidate. For people long in the industry, their resume should speak for itself. For younger people, it's kind of like, would you sleep with a woman you just met? How does that experience usually turn out? It's a 50/50 or worse chance you end up with a nightmare. Spend some time to interview your candidates, or end up with the one-night-stand.
In my version of a perfect world, each company would have a "speaking hour" designated once per week. Each speaking hour would feature two or three speakers, each with 15 minutes to speak about something interesting they've worked on. The idea being if you wanted to work for a company, you'd apply to speak at their next "speaking hour". If you show up and give your talk and the audience approves your talk, then its understood you're hired.
But, you should also carefully examine the past code that the candidate has written (that he can legally disclose) and also design a programming test for candidates to complete.
My observation is that recruitment is only one part of the problem. The other part is that companies do very poor job at assessing skills during employment and loose/fire randomly. This seems to be much more important problem for top companies leading to slow degradation of skills over time.