"It could also sew some bitterness within the engineering team: it might be seen as unfair that some people can get hired through the nepotistic route, while others have to do the tech loop."<p>More importantly, it will reinforce your organization's demographics. If your trusted referrers are white and male, their networks will be overwhelmingly white and male and it's just putting up another block toward those not already in the system. If that happens in one company, it's likely not a big deal. If it happens systemically, you'll see a bigger problem.<p>(People build networks in college, with people of the same demographics -> people use those networks to get people in with a lower bar of entry while those without the benefit of the network will face a barrier that the people that were hired might not have been able to clear.)<p>The problem is that we don't have a better solution to the technical interview.
I tend to look at a candidate's work history.<p>If they've worked at least 10 years, as a coder - it's VERY unlikely that they're a complete liar. Especially if you can call former co-workers, or look at code samples they have online on a personal github, or look at their post history on stackoverflow, or things like that.<p>Even a technical description of prior projects - is a really good indicator of whether they're competent.<p>Puzzle solving - on the other hand, bears little resemblance to actual job requirements in the real world. It's honestly a dumb way to vet candidates. Would I like to see if a candidate, out of a pack of 5 or so potentially equal candidates, has a better approach to creative problem solving? You bet. But I'm more interested in their inter-personal skills, communication skills, and their instincts towards the ethical challenges we face as engineers. (like: when things go south - and blame starts flying). Who do I want on my team? That's the most important question.
I grew up poor, and out of (mechanical) engineering college new a grand total of zero engineers. I would still be unemployed to this day if this type of hiring were the norm (although it is not entirely uncommon). I can also say, that the engineers that we have had come through our organization based on referrals have not been the best quality. They tend to be engineers that are generally likeable, but not very good. Referrals are probably the way with the least friction to hire someone, so any time the way with the least friction is not being used as much, you have to wonder why.
I don’t even <i>want</i> the ability to refer someone into my company. That’s very risky and puts pressure on me to be right, when I might be wrong. I have referred friends who’ve been rejected, and I’m glad because that’s better than hiring my friend and having them not fit in. Then it’s <i>my</i> fault.<p>I’ve interviewed and referred many people and made a lot of hiring decisions, I would rather have everyone agree, I don’t think the ability for a single person to refer someone past the interview process is a good idea at all.<p>None of the risks listed even compare to the risk of hiring someone who isn’t actually very good or doesn’t get along with the team.... and despite thorough interviews that still happens all the time. If the candidate is worth referring, then the interviews will not likely be a problem. Things do go wrong occasionally, but not very often.<p>Edit: I also meant to add that I think referrals are already weighed very heavily in interviews in my experience. Sometimes even too much. Interviews are already easier for candidates when someone who’s respected makes the referral, so to some degree the proposal here already reflects reality.
I use interviews to evaluate a whole lot more than just hire/no-hire.<p>I'm looking to understand what role someone is going to play in the organization, and to help understand which team a person we're likely going to hire will be a best match for.<p>We organize our interview loops around this, and a critical part of the conversation in the debrief is role and team matching - not just a hire/no-hire decision. Plus, we use this time to provide feedback to whoever the hiring manager is about the candidate and potential future team member, which streamlines more than just headcount.<p>Finally, the interview loop is an opportunity to manage cronyism. While we've got a lot of people I trust to refer exclusively strong candidates, I don't trust a single one to make fiat decisions. There's a human element to giving someone that level of decision making authority, and without sharing gory details - I've benefitted from having committee decisions in this situation.<p>Managing the feelings of referrer's getting their candidates rejected in a hard problem. I've dealt with that in the past a number of ways but don't have a working theory, other than "it's a job, people make mistakes, and hiring is fit and timing as much as it is about technical prowess".
This is a no go in large companies, because the large company wants to avoid 'cliques of incompetence' and personal fiefdoms developing, not to mention all of the other problems people have mentioned.<p>In large organizations, there are too many people for execs to know everyone, so a standardized but rigorous process is better from their perspective.<p>I say tech's process is better than many other industries processes, which is outsourcing evaluation based on credential prestige.
This is a bad idea and the person proposing it should feel bad.
-- Every underrepresented group in tech ever, as well as introverts and junior folks or those switching from other specialities<p>(Seriously, I get that we have problems with pipelines and tech. interviews can be pretty terrible, but this is worse. Respected people are already in a pretty set demographic that's harder to break into, and anyone they've worked with is going to be similar. )
> The risk that they will be humiliated at some point during the interviews.<p>As a candidate, this has happened far more often than I care to admit. I don't take it personally: having worked at many corporations, I know that its usually not any kind of personal animosity or judgement, its just work politics. But the fact remains that it does happen.
Not a great way to increase diversity, and totally incompatible with referral bonuses.<p>A hidden cost here would also be exposing perceived statuses (eg an engineer who isn't as well respected would have their recommendations denied).
Trusted referrals have always been a valid approach to getting candidates <i>in the pipeline</i>, as long as it doesn't privilege those candidates over others who came in through other channels.<p>However, I don't agree with waiving the technical interview.<p>Sometimes referrers, though well-meaning, have either an outdated or incomplete idea of the candidate. Assessing a candidate's quality is quite a complicated thing, and not everyone does it well though everyone thinks they do. I say this because I've made erroneous referrals myself.<p>It's a bias-variance tradeoff. If you trust 1-2 key people, and if they are right about a person, good, but if they are wrong they can be very wrong. Whereas if you collect more data points from independent sources, you mitigate the probability of huge errors in hiring, which can be expensive to fix.<p>Of course there are exceptions. In a world where if Larry Page wanted to bring Jeff Dean on-board a fledgling Google because he's seen his work elsewhere and decides to waive the technical interview, then it's a different story. But I'm not sure if these exceptions abound...
I suspect this might work better than expected. The fear is that employees will exercise some form of nepotism that would “lower the bar”. That might not happen in practice though. Would love to see an experiment.
So in summary: If your company has a seemingly broken hiring process that weeds out good people, bypass that process for people your people judge as good, and keep it for everyone else.<p>I suggest that it is better to fix the hiring process in the firsr place and just run everyone through it.
One big issue in hiring is that <i>error exponentially multiply</i> as organization grows. One bad hire would hire two more bad hires and so on. Many would say this is the single most important reason why great companies starts to falter as they grow old - the ratio is no longer the same.<p>So in this proposed "solution", a misplaced trust will soon cause chain reaction. Many companies place such trust in hiring manager giving them veto power to go ahead even if all interviewers were in disagreement. I have rarely seen this work out well. All good hiring process have checks and balances - implicit infinite trust is never good idea in any system design.
A technical interview done well is a good thing. You get to ask the candidate questions and they get to ask you questions. As the candidate, the technical interview is where I can really size up the company. How are coding standards decided? How does the development process work?<p>This is all interesting stuff to talk about for a candidate.<p>The closest thing to whiteboard coding I can think of as useful to the employer is data structure and algorithm knowledge at a toolbox level. What data structure would you use to implement a spell checker? A search for restaurants within X km?
Technical interviews are awful. They are grueling and they are prone to major false signals in both directions. However, I'm not sure this is the way to go either.<p>Personally, I'd love for a "common form" application where you could do a timed take home coding exercise, in absence of that, why not just talk through code with an interviewee. You don't need to watch them code, if you are a good judge of technical skill, you should be able to tell just by the way that a candidate talks you through tradeoffs, refactorings, etc whether than can code or not in a way that nothing else shows.<p>So you really need someone to write tests for their moon rover they just made you to see that they can actually write unit specs, or would you rather talk through testing tradeoffs, when they use mocks or not, what issues they've encountered with long running test suites or flickering tests, how they test the frontend, what their thoughts are on strict versus loose TDD, etc.<p>Get your candidate excited and let them ramble and you'll learn far more than any contrived coding exercise, even if it isn't a whiteboard interview.
I wouldn't want to be hired by a company that did this. I want to work with good people. A rigorous hiring process, uniformly applied, will tend to select good people, so it's an attractive feature of a company for me.<p>Although i have been lucky enough to work with some good people so far, i wouldn't trust any of them to fill a company with equally good people merely by recommendation.
I worked with an intern for 6 months. He was great. Did everything I asked of him and has code still running in production.<p>He went back to school and then applied for a full time position, so I referred him with a glowing recommendation.<p>He was rejected because he was quiet and not a good cultural fit.<p>And that's why I avoid giving recommendations for friends. It's not worth the risk of rejection.
Rather than doing this on the individual company level, which leads to all kinds of problems that many other comments here have noted, it would make sense to do this on an industry-wide level. We should have something like a "Master Engineer" credential that should require another master to vouch for you and some rigorous testing. If implemented correctly then it would become obvious that asking FizzBuzz type questions to master engineers is a waste of everyone's time. If we want to be treated like professionals, we should have professional standards. After all, when doctors go for job interviews nobody asks "what is a cell?"or to diagram the Krebs cycle on a whiteboard.
My preferred interviews were those with programming tests to do at home with some days before the deadline, allowed me to work like a remote dev would. On-site interviews then included a code review of the test. No white board coding, no timed programming exercise without internet, no asking things as if I could memorize all the docs of all the tools I work with.<p>I also liked well designed tests because the more I feel actual work skills are checked, the more confident I am that I would have well qualified colleagues to work with and learn from.<p>With your scenario, I fear in most places it would end up like "we hire all our friends, it's fun". Not even sure it would be legal to discriminate about people you just don't know, however qualified they may be...
This seems like a situation where they came up with the wrong solution to the problem.<p>The great engineering leader refers people who don't make it through the technical interview. So the supposition is that "The company is missing out on great developers due to filtering in the technical interview, lets get rid of it"<p>When it should be "Fix the process so it doesn't filter out people while still testing for technical competence"<p>We just don't do whiteboards, we usually do a take home assignment/test where the candidate can make use of the tooling/environment in which they are comfortable. We feel this is also most similar to how they are going to work any ways so it is a true test of their work output.
This already happens in SF. If you think a CEO or CTO of a startup is letting some technical interview failure stop him from hiring people he already knows work well, you’re off your rocker.<p>I know one of my best bosses and mentors was hired off a terrible interview and a strong referral. Well, that’s what I expect to happen.
The problem with this approach is that it requires every employee to be referred in. Unfortunately, most people don't know that many people who are looking for jobs, especially people significantly older or younger than them or from different regions.
Such referrals are extremely useful datapoints to refine your technical interview and reduce the false negative rate of the interview process. If your interview process is rejecting a lot of quality people, that should be a sign you need to reform it.
This idea already happens in the industry every day. The last two corporate gigs I received didn't require a technical interview at all and I absolutely refuse to apply to any company that makes me white board or submit anything coding related before they are paying me. I don't mind answering their questions though.<p>As one of the previous commenters stated already, there is already plenty of evidence as to whether or not somebody can code. If John Skeet applies to my company, I'm an idiot if I ask him any programming questions.<p>If there isn't sufficient evidence online to showcase their skills, than make them do the stupid coding examples.<p>In my case, I won't ever work for any company with whiteboard coding exercises. It's the first thing I ask the recruiter and than I politely decline the offer to interview and tell them exactly why. If more people do this, it will catch on.